Request to Restore Support for Legacy Architectures (pre‑arm64‑v8a)

[Ananas-Kuchen]

Since v3.0.0, the qrserv app supports only arm64‑v8a. Could you restore support for other architectures? Some users still rely on older architectures.

Thank you

[uintdev]

Hi,

There were several reasons for the decision.

Reported usage

According to Google Play Console (and I'm not sure whether it also captures data if installed outside Google Play when GMS is installed), the vast majority are using arm64-v8a. armeabi-v7a and armeabi both show high but matching numbers, but I suspect that a majority are, in fact, ARM64-capable devices. One user is reported to be using x86_64.
IzzyOnDroid had been using the armeabi-v7a build until now, so that might have thrown off the analytics slightly for those who ended up using that version (not knowing whether any of the devices are truly armeabi-v7a or are, in fact, ARM64-capable). I don't know for certain, though. The analytics really aren't great or clear, and it is a black box.

There are computers that use ChromeOS, an Android distribution, or a compatibility layer of some sort. Perhaps those absolutely will need an x86_64 variant to even run. I'm not aware of anyone running or intending to run this app in such environments, though. Even then, the UI is designed around the usual mobile display aspect ratio and size (not sure if I want to imagine how it'll look on a foldable's internal display as it is).

Maintainability

ABIs are a factor because the app uses Flutter (native libraries). It’s an inconvenience, tends to have bugs, and I exclusively test the ARM64 variant on a physical device. If the other ABIs still work fine (and they normally do), that is good. The only time I ended up using the Android Emulator (x86_64) was to test all the supported Android versions to see if certain platform-specific functionality worked as expected.

Beyond that, due to the version code situation in the past, splitting by ABI can be a hassle (version codes would differ, which I get why, but it’s not great in my case). A workaround would be to use a script to build each APK with its ABI one by one instead. I would need to justify doing that, though, as it adds to the overall build time. There are 'full APKs,' but, for reasons, I would rather avoid that.

Version codes are important to try not to mess up, as they're depended on to see if the application is newer or older. On several occasions, users couldn't update and had to instead install the newer version of the app from scratch, as the version they were on had a far higher version code than the version of the app they were trying to update to.

By keeping it to one ABI, it also keeps the build and deployment process simple.

All that said, restoring support isn't off the table. I suppose the question would be how strong a justification could be made to continue offering armeabi-v7a and x86_64 builds in 2026.