|
And all this article is "just" about the building of the Java/Kotlin application :) Native NDK is another can of worms, with updates linked to SDK or sometimes not, unclear documentation about device and API compatibilities, compiler behavior changes and other requirements (like the 16K one) that impact so many 3rd party native libraries. But, of course, the rules on the uploading and the changes of the Console, that changes so often is what makes it painful. The absolute nightmare is about giving Google the root signing key of your application, the unfinished business about app bundles (which should reduce the size of the downloaded app, and more often than not, make it bigger), the changes in compliance, letters to sign for different countries, the compatibility for Google form factors (XR, TV, Auto, Automotive), Inline installs and other Teacher Progams, Play for family and so on. All of this changes non-stop and is very poorly documented :) At least, the Play Store is still GPLv2 compatible, so for now, we're saved (VLC) |
I wish more people talked about this. At Amazon, I helped with the early threat modeling around adoption of "App Signing by Google Play", which requires sending your app's root signing key to Google (and is now required, with no publicly-available opt-out for new apps.) It would have added some nice things for Android devs: app bundles, smaller downloads, instant apps, etc.
That said, we imagined the following scenario, and were unable to find a reasonable mitigation at the time:
It seems plausible the US government could send a NSL (or similar) to Google and force them to distribute modified APKs for apps like Signal (ex: to exfiltrate keys). This would be nearly impossible to detect, especially if the modified APK were distributed to only an individual user, or a small group. A few people raised concerns [1], but I don't recall Google ever giving a reasonable response.
[1] https://commonsware.com/blog/2020/09/23/uncomfortable-questi...
Edit: clarify no opt out applies to new apps