Thread by @farmerbb1

There are several API changes made in Android Q Beta 1 that, as both a developer and enthusiast, are troubling to me. These changes, while made in the name of "privacy", seem to have been ill-thought out and ultimately hamper some of the things that make Android unique.

https://twitter.com/chrismlacy/status/1106374238733164544

One of those changes is the restriction on activities being launched from a background app. I totally understand that there are certain kinds of ransomware attacks that this change will help prevent, and improving the security of the Android platform is ultimately a good thing.

But as @chrismlacy points out in the above tweet, this restriction will hamper certain categories of apps, specifically device automation apps, that provide legitimate value to the user.

What's puzzling about this decision is that, according to the docs, "for the purposes of activity starts, foreground services don't qualify an app as being in the foreground." Why is Google bending the rules on what counts as a foreground app in this scenario?

(Thankfully my Taskbar app, which uses services to host a floating overlay with an app launcher, shouldn't be affected by this change, since overlays count as having a "visible window" as outlined in the Q Beta docs.)

Another change in Android Q that troubles me is the decision to revamp how external storage access works.

Not only has Google deprecated the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions, but they have changed how they work so that each app accesses their own sandboxed storage space instead of one unified space for all apps.

This will completely break many existing apps that assume a unified external storage space is available. Again, I understand that some developers abuse external storage and leave clutter around in places that they should leave it.

But what's wrong with simply deprecating the existing permissions and leaving the original behavior as-is for apps that need it? Or perhaps only applying this behavior to apps that target Q or later?

To give one example of a class of apps that will be broken by this change:

As a retro gamer I use emulators, frontends and source ports regularly on my Android devices. All of these apps rely on having access to a shared external storage space where I store my (legitimately obtained) ROMs and other game data.

I also use a cloud storage syncing app to automatically keep these files up to date several times a day. Again, this workflow operates completely via the shared external storage space that Android, up until Q, has provided for the user.

This is a baffling change because Android has already provided a private, sandboxed internal storage space for apps to use. Sandboxing external storage just makes things redundant. Why even have an external storage space to begin with?

Yes, I'm aware of the Storage Access Framework, which is Google's recommended alternative to having full access to external storage. In my experience, however, the Storage Access Framework is awkward to work with and doesn't offer the flexibility of the standard Java File APIs.

Also, as Emile Belanger points out on Reddit (reddit.com/r/androiddev/c…), this is not a viable solution for apps that use the NDK, such as his Doom / Quake ports (and pretty much all emulators)

Here's to hoping that Google will listen to our feedback early and rethink some of these API decisions that have been made in the Android Q Beta. Android is a unique, innovative platform and I'm hoping that with the final Q release, it stays that way.