IzzyOnDroid repo: Publish arm or arm64 builds?

[ColorfulRhino]

Thanks to Izzy who's hosting the IzzyOnDroid repo we have a great way to update AuthenticatorPro with an F-Droid store app, without the need for any Google Services. Currently, only the arm-v7a build is hosted at the IzzyOnDroid repo.

The issue: Most Android devices from the past few years support 32 and 64-bit apps. However, we currently live in a time where there are some 32-bit-only (many devices from 2015 and earlier, plus as some low-end phones) as well as 64-bit-only devices (the Pixel 7 series for example) in the wild. The arm-v7a build is incompatible with the 64-bit-only devices and the arm-v8a build is incompatible with the 32-bit-only devices.
This means, if the 32-bit build is hosted on the IzzyOnDroid repo, the 64-bit-only devices won't be able to get updates through their F-Droid store and if the 64-bit build is hosted, the 32-bit-only devices won't be able to receive automatic updates anymore.

Since the universal build (56MB) which can be installed on both kinds of devices is much bigger than the app size limit for the IzzyOnDroid repo (30MB), publishing this universal apk is not an option.

We are having a discussion on IzzyOnDroid's GitLab page (https://gitlab.com/IzzyOnDroid/repo/-/issues/371) about this, specifically regarding AuthenticatorPro.
On one hand, some people might want to use AuthenticatorPro on their old or low-end 32-bit-only device. On the other hand, 64-bit-only devices will get more and more market share in the coming months and years as more 64-bit-only devices get released and people upgrade their devices.
Izzy's take on this is leaving the last word about this decision to the app's author. @jamie-mh what do you think about this? Do you have a preference on which build (32-bit or 64-bit) you'd like to have published on the IzzyOnDroid repo?

[jamie-mh]

Hi,

On Google Play, I can see what percentage of the install base is compatible with each ABI. However, this includes devices that support more than one, I don't know what percentage supports only one or the other.

Due to the poor lifespan of most devices these days, I would assume that most new installs are from devices with 64 bit compatibility. It may be best to use the 64 bit build in this case? I don't really have a good answer.

Either way, I provide both versions on GitHub for anyone who wants them. It's much less convenient, but it's always an option.

Cheers

[IzzySoft]

@jamie-mh as the question was raised on my repo, you can find some more arguments following the link given by @ColorfulShire in the initial post. You already know my arguments here, we've discussed the very same topic about 2 months ago (thanks for the updated graphic). I don't remember what time frame the graphic covers – but it's not more than a year or two I'd say it might indeed b better to stick with the 32bit one in my repo. If OTOH it's about 5+ years (or you prefer it fr some other reason), just let me know when I should switch.

One other aspect to consider: does it still run smooth on 32bit? When testing apps for F-Droid (remember I'm one of the maintainers there, so I also perform reviews on new apps for inclusion) I always try to test the "bigger ones" on "lower devices" and on an Android Go device I had noticed that, once the APK exceeded around 25 MB, the app was quite laggy there. Authenticator already broke through the 30 MB limit of my repo. So could you please have an eye on reports coming from the "32bit space" and watch out for this? It could well be that half of the new 32bit installs do not live that long, for "performance reasons". Which then could suggest the point we want to switch to 64bit in my repo.

Due to the poor lifespan of most devices these days

You get what you paid for I guess. My currently active devices include:

• Motorola Milestone 2 from 2010 (with a single battery replacement last year, so the initial one held for 12 (!!) years): just serves as night-stand and alarm clock still. Running on Kitkat thanks to CM. 32bit.
• Fairphone 2 from 2015 (again a battery replacement last year): my personal daily driver. Running Android 11 thanks to LOS, but starting to show its age. 32bit.
• SHIFT8mq (2020) as my "business device". A SHIFT8 from the same vendor (still in its funding phase) will replace my FP2 end of the year. SHIFTPHONES is the German pendant to Fairphone: modular devices designed for a long live. Admitted, not your favorite "discounter deal" – upper middle class for around 600 €. But wonderful devices from a wonderful vendor with a wonderful community – see my article Android without Google: Shiftphones for details. Oh, the 6mq is running ShiftOS-L – original ROM from the vendor, totally Google free. Both are 64bit; the Phone8 might be 64bit only (vendor didn't make the final decision yet but asked already concerning my repo and its 32bit preference – yes, they have a focus on sustainability)
• That cheap AndroidGo device mentioned above lived not much longer than a year before it became unusable. Wasn't that great before either – but it came for less than 100 €, so what could you expect. 32bit – but rather dead (still lying around here for a refresh as test device, but wasn't powered up for at least half a year).

[ColorfulRhino]

@jamie-mh Thank you for the diagram! I honestly would have guessed that arm64 support would be far more widespread if the diagram only covers the last 12 months.

we've discussed the very same topic about 2 months ago

@IzzySoft Sorry, I didn't know that this discussion already took place a short while ago. I apologize for not searching the issues in this repo for a similar discussion.

One other aspect to consider: does it still run smooth on 32bit?

Unfortunately I don't have a 32bit device to test AuthenticatorPro's performance on it. Like you said, for the moment it's probably best to stay on 32bit and @jamie-mh can have an eye on reports on its performance.

the Phone8 might be 64bit only (vendor didn't make the final decision yet but asked already concerning my repo and its 32bit preference – yes, they have a focus on sustainability)

A little bit off-topic: Google claims that 64-bit-only devices are "faster, safer and use less memory" (https://android-developers.googleblog.com/2022/10/64-bit-only-devices.html). In more detail, the blog entry states:

64-bit apps run faster because they have access to extra registers and instructions that aren't available to 32-bit apps. In addition, newer CPUs deliver up to 25% better performance when running 64-bit code or even drop support for 32-bit code altogether.

64-bit can help improve security. The bigger address space makes defenses like ASLR more effective and the spare bits can be used to protect control flow integrity. These countermeasures may reduce the chance an intruder can take control of your device.

Removing support for 32-bit code saves up to 150MB of RAM, which was used by the OS even when not running 32-bit apps. These memory savings result in fewer out-of-memory conditions meaning less jank and fewer background app kills.

In my opinion, if these claims are true, it is more sustainable to have a device opt for 64-bit-only since the performance and memory gains will likely make it feel less sluggish in outdated in the future, which would lead to the device being used for longer. @IzzySoft as you said, the final switch to 64bit will be inevitable in the future.

[IzzySoft]

I didn't know that this discussion already took place a short while ago.

No worries – even I only remembered when I saw that graphic 🙈

Google claims

Yeah (they also claim to care for our privacy, right? 🙊). But to me that sounds rather vague. Maybe I'm reading it wrong, but let me write how it could be read:

64-bit apps run faster

That might be true, provided you have the proper hardware – but there are still 32bit devices around which cannot benefit from it. "newer CPUs deliver up to 25% better performance" is fine, but same thing. As they do that even when (just) drop support for 32-bit code, that could be an argument – but "up to" would also include "just 2%". You know those shopping arguments: "up to 40% discount" – and then you find a single article you don't need having that discount, while all others are around 5..10%.

64-bit can help improve security.

Read: "can" – not "does"? Also, "may reduce", not "do reduce". So kinda vague. I may live up to 120 years – but there is no guarantee for it.

Removing support for 32-bit code saves up to 150MB of RAM

Oh wow. So on those latest shiny devices which ship with 4+ GB of RAM, it saves "up to" 150 MB. Yes, nice thing of course. But on those devices you can afford it, plenty left. If you want to save more, avoid apps written in RN, Flutter & Co where a simple "Hello World" results in a 5 MB APK file 😉

TL;DR: those arguments do not convince me dropping support for legacy devices. My arguments for sustainability are stronger 😜

[ColorfulRhino]

those arguments do not convince me dropping support for legacy devices.

Sorry for the misunderstanding, my point was not to convince you with those arguments. They are more like, if I had to design an Android device right now and had to decide if I want to preserve 32bit support or not, those arguments would convince me to go 64-bit-only. Besides some specialised apps, there are very few 32-bit-only apps that are still widely used, since Google required apps to be 64bit compatible since 2019. Even if dropping 32bit support on a device only means slightly higher security and slightly more RAM available, it does mean that users will get the maximum performance out of their apps since they can't accidentally install 32bit apks. (The last point is a whole other discussion though, like "should end-user systems force users to update their systems to install the latest security patches after a while, like Windows currently does afaik, to help users/prevent inexperienced users running around with gaping security issues in their OS/software and to make life a bit easier for developers?")

@jamie-mh Feel free to close this issue whenever you like 😀 If you decide to have the 64bit build on Izzy's repo at one point, based on feedback from 32bit users or other feedback or arguments, let him know. For now I guess all the builds are readily available from GitHub.

Cheers

[IzzySoft]

Sorry for the misunderstanding, my point was not to convince you with those arguments.

Oh man, come on. No I must apologize that I didn't mean it that way 🙈 All fine. And I meant Google won't convince me with that. It's good to have all arguments on the table for a wise decision, so thanks a lot!

there are very few 32-bit-only apps that are still widely used, since Google required apps to be 64bit compatible since 2019.

What is Google? And who's bound to those requirements? Is there a world outside the walled gardens? 🤪

since they can't accidentally install 32bit apks.

Sorry, I cannot resist this – but didn't you just state "Google required … since 2019"? So where do those suddenly come from now? 🙊 💨

Disclaimer: Not fighting here, actually enjoying the discussion 🤣 – and sincerely hope I don't annoy anyone with this! But yeah, full ack, this is Jamie's repo. And Jamie's app, so I follow whatever Jamie decides on this.

[ColorfulRhino]

Not fighting here, actually enjoying the discussion 🤣 – and sincerely hope I don't annoy anyone with this!

No worries! I'm not annoyed by this, I'm even learning new things 😀

What is Google? And who's bound to those requirements? Is there a world outside the walled gardens? 🤪

I assume most apps use Google Play or another big Appstore as their main distribution channel, since otherwise the userbase they reach would be way less. And usually, even with open source non-commercial software you want your userbase to be somewhat high for motivation, donations and so on, don't you? So even if the app is available on GitHub, F-Droid and so on, where you can have 32bit apks, you will still have to have 64bit/universal builds to be able to upload them to Google Play.
Basically, while there certainly are 32bit builds for apps, I don't see how there would be more than a few recent 32-bit-only apps.

Sorry, I cannot resist this – but didn't you just state "Google required … since 2019"? So where do those suddenly come from now? 🙊 💨

Well, you could still accidentally install a 32bit build of an app if you download it from GitHub for example and choose te wrong apk. Or, well, by using the IzzyOnDroid repo to install some apps of which only their 32bit builds are being distributed, even if a 64bit build would be available 😀 If you would download those apps from Google Play, you'd get the 64bit versions instead.

[IzzySoft]

And usually, even with open source non-commercial software you want your userbase to be somewhat high for motivation, donations and so on, don't you?

You wouldn't find any piece of mine willingly offered by me in a walled garden. And similarly, there are more devs keeping their apps out of there than you might expect (we just noticed that again when some imposter published a load of those as their own, "enriched" my some "monetizing modules" to make money from other people's work – luckily their account was taken down rather quickly). But yes, I assume a bigger part putting their apps in both places (and no offense to that). As pointed out earlier, some make them paid at play while fully free at F-Droid. And believe it or not, some apps are even exclusively in my repo.

And there of course you have your point: the majority of apps in my repo, when I needed to decide on a single ABI, are 32bit indeed – while 64bit variants are available attached to their releases.

[jamie-mh]

The only 32-bit device I have is a 2013 Moto G. The app runs fine, faster than many other apps surprisingly.
I also have a 2015 Moto X Play, which is a 64-bit device. I'm going to run some tests to see the difference between the 32-bit and 64-bit builds, if any.