[guardian-dev] GP libraries and apps that will be impacted by Android L changes?

Hans-Christoph Steiner hans at guardianproject.info
Thu Oct 16 09:14:16 EDT 2014


Nathan of Guardian wrote:
> 
> 
> On Wed, Oct 15, 2014, at 10:27 PM, Hans-Christoph Steiner wrote:
>>
>>
>> Josh Steiner wrote:
>>> On Wed, Oct 15, 2014 at 4:47 PM, Hans-Christoph Steiner
>>> <hans at guardianproject.info> wrote:
>>>>
>>>> It would be worthwhile to see if this can be done without gradle.  There is no
>>>> gradle setup on the build server, and gradle is very much a moving target,
>>>> with incompatibilities between versions and no clean, easy way to install it,
>>>> so its a lot of work to support it on a build server.
>>>
>>> I think the gradle wrapper we ship in our project should handle off of
>>> this for us.
>>
>> I haven't tried gradle, but I've heard a lot about it from the FDroid
>> team.
>> It sounds like the gradle wrapper does not live up to its promise.
>>
>>
>>>> I think gradle will only really help if we go the approach of building
>>>> multiple APKs.  Having each APK include only the exact targeted platform
>>>> (armeabi, armeabi-v7a, x86, mips, armeabi-PIE, armeabi-v7a-PIE, x86-PIE,
>>>> mips-PIE) means that users cannot do FDroid swapping of that app unless the
>>>> two people swapping have the exact same platform.
>>>
>>> That's true, so maybe we need to make a giant build for fdroid, that's
>>> just another build variant in the gradle config, it shouldn't be hard
>>> to setup.
>>
>> Its not just a matter of the APK that is uploaded to FDroid.  The point
>> is to
>> build up an ecosystem of sharing APKs, no matter where they got them from
>> (as
>> long as they are not malware).  So if there is a wide variety of
>> different
>> StoryMaker APKs out there, it'll only make it more confusing to users. 
>> So
>> either all native bits are embedded into the one official APK, or users
>> are
>> frequently not going to be able to share their APKs with other devices.
> 
> Since we are mostly concerned about ARM devices, maybe we could include
> both non-PIE and PIE binaries in a single ARM APK build. I am content
> with breaking sharing capabilities between ARM and MIPS or ARM and x86
> for now. If we include all the native bits for all the possible
> platforms, plus the PIE variants, our APKs will be so huge that no one
> will be patient enough to install or share them anyhow!

Yeah, I think this makes sense.  We're not even shipping anything on x86 or
MIPS right now anyway.  I think the two architectures to use are 'armeabi' for
all ARM devices older than android-16, then 'armeabi-v7a-PIE' for all devices
android-16 and above.  I think that android-16/4.1 devices without v7a CPUs
will be quite rare, but then again, I don't know the Chinese device market
well.  But I can say that the Azpen tablet that I bought new for $20 has a v7a
CPU (its often seen for $50 or $80).

Since StoryMaker is targeting 4.0 and above, it could just do armeabi-v7a and
armeabi-v7a-PIE, and then totally ignore armeabi and armeabi-PIE.  The v7a
stuff helps a lot with video processing.

For Orbot, perhaps it should use armeabi and armeabi-PIE to ensure maximum
compatibility.  I can't imagine the v7a stuff makes a noticeable difference
with Orbot.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81


More information about the Guardian-dev mailing list