Random Musings on the Q Developer Preview 1
Each time Google releases a new developer preview, I rummage through the API differences report the high-level overviews, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize mainstream features that any developer might reasonably use, along with things that may not get quite as much attention, because they are buried in the JavaDocs.
As with the previous two releases, Q seems to be lacking a prominent user-facing feature. Q is certainly better, but I have no idea what I will tell my mother that she’ll gain if her phone gets the Q update at some point.
However, there are a number of changes for developers.
What Will Piss Off Developers
Google has done quite a bit over the past several releases to improve privacy and security in Android. That tends to be a double-edged sword, though, where the changes break existing app functionality. So, for example, developers of file managers are going to be rather disgruntled with scoped storage, which says that you can no longer access all of external storage via the filesystem.
The roles system is an
interesting concept. At one level, it might mostly be there for the benefit
of the Play Store and other app distribution channels, to better identify whether
apps are justified in holding certain permissions. However, the relationship
between roles and permissions is almost completely undocumented. For example,
ROLE_SMS “Can send and receive SMS messages; can read contacts” mean
that no other app can read the contacts, despite requesting the
permission? The fact that we need to run experiments and attempt to reverse-engineer
the documentation is never a good sign.
Other things will just pour salt into existing wounds. For example, the “non-SDK interfaces” push continues in Q, so developers that dodged bullets in P might now run into problems in Q, if their preferred hack is no longer available.
Plus, there is your usual barrage of changes that won’t affect everyone but
might dramatically impact some developers. Starting an activity from the background
has long been considered to be poor form; developers who stuck with it
now have problems.
SYSTEM_ALERT_WINDOW has been dodgy for years; developers who stuck with it
now have problems.
Background access to the clipboard is gone.
Using locations in the background is overhauled. And so on.
What Will Piss Off Me
Google says that they have changed
but they did not seem to document what changed.
At least on the
onPause() stuff, prior reports indicate
that multi-window environments — including foldables — will now
leave apps in the resumed state even if they no longer have the input focus.
There appears to be a new
activity callback to find out if this activity is now the “top resumed activity”,
which I am guessing means “the activity with the input focus”.
What Has Me Worried
There is a whole new set of APIs around “content capture”. Unfortunately, the central class has “TODO” for its documentation. However, it is tied to the detestable autofill APIs and seems to report when views come and go. In the hands of responsible individuals, this has interesting characteristics for app testing. In the hands of irresponsible individuals, this could be yet another privacy leak.
Similarly, there is an
InspectionCompanion “used to inspect views”. This, at
least, seems like it may be only some kind of in-process capability, even though
it is largely undocumented.
There is a new
GET_AND_REQUEST_SCREEN_LOCK_COMPLEXITY permission, which
“allows an application to get the screen lock complexity and prompt users to update the screen lock to a certain complexity level”.
On the surface, this seems fine, but this is a
normal permission, so users
are not prompted about it. Historically, this sort of functionality was limited
to device administration apps.
There is a new
SMS_FINANCIAL_TRANSACTIONS permission, which
“allows financial apps to read filtered sms messages”. However, I don’t know
how one defines either “financial apps” or “filtered sms messages”. The
protection level of this permission is undocumented.
There is a new
setAllowSystemGeneratedContextualActions() method on
that “determines whether the platform can generate contextual actions for a notification. By default this is true.”
Frankly, the notion that Android will automatically put actions into our notifications
creeps me out.
What Has Me Wondering How Far Down the Rabbit Hole Goes
Google has been pushing us away from background services for a couple of releases,
forcing a lot of developers to switch to foreground services. Now, with Q,
there are “types” of foreground services, described via an
attribute (in the manifest?). Available types include
startForeground() call can now also pass in the type of foreground service
it will be (or a
FOREGROUND_SERVICE_TYPE_MANIFEST flag to say “read the values
from the manifest”). So, now we have services, then foreground services, then
types of foreground services. What’s next? Subtypes? Plus, it remains to be seen
what the system does with this type information.
What Has Me Intrigued
makes its return, having been in one of the past rounds of developer previews
but removed from the SDK prior to release. If you catch one of these, you
have a dedicated message and
RemoteAction for being able to help fix whatever
the problem is.
There is a new
<service> in the manifest.
It allows an isolated service (
android:isolatedProcess) to have its process
forked from “an Application Zygote, instead of the regular Zygote”. From the docs,
my guess is that this is here for Chrome and similar apps that may want to fork
lots of isolated processes for executing possibly-unsafe code. However, isolation
from the regular app zygote may also mean that attacks that affect the app
zygote (and therefore all normal app processes) might not affect these isolated services.
There is a new
isRunningInUserTestHarness() method on
This apparently is not to detect normal instrumentation tests, but rather some
other style of tests for “a device farm/testing harness (such as Firebase Test Lab)”.
The idea is that you would use this flag to skip over stuff that might screw
up such tests. It remains to be seen exactly where this is
In Android 8.0, we gained the ability to launch an activity into a particular
display. This is a useful alternative to the
Presentation API. Apparently,
though, there are some external displays that will show up in the system as
displays, but for which you cannot show an activity on them. There is a new
isActivityStartAllowedOnDisplay() method on
ActivityManager to use to determine
if a particular display is good for activities. My best guess is that this
is for foldables, but that’s just a guess.
There are a bunch of new methods on
NotificationManager. A lot center around
the notion that you can allow some other app to post notifications on your
app’s behalf (a “delegate”).
FontFamily, and related classes are now part of the framework APIs.
MediaPlayer2 and related classes were added, apparently as a replacement
MediaPlayer. I have not worked with ExoPlayer, so I do not know how
MediaPlayer2 might relate to ExoPlayer in terms of API or implementation.
There is now a
DnsResolver class “for asynchronous dns querying”. In related
news, AWLTCLB (Abbreviations Would Like Their Capital Letters Back).
toSafeString(), which attempts to redact some information to make
the resulting text safe for logging purposes. My guess is that the resulting
string will then be useless for debugging, but perhaps I am being pessimistic.
They added a
FileUtils class, mostly containing various
Environment now offers dedicated public directories for audiobooks (
and screenshots (
PowerManager now offers methods to get the “thermal status” (i.e., is the device
being throttled to reduce its temperature) and register a callback for status changes.
This may be useful for games or other high-intensity apps, so they can provide
a UI indicator that explains why things are now running more slowly (so the device
can cool down).
The new settings panels seem nice, though I’m uncertain why bloggers keep insisting
this has something to do with slices. We show a settings panel via
so most likely they are just activities themed as a bottom sheet dialog. Then
again, it would be nice if slices were used for something. Just sayin’.
What Is Now an Ex-API
The entire preference system, outside of
SharedPreferences, is deprecated.
PreferenceManager and the entire preference UI. Developers
are steered towards the AndroidX replacements.
ACTION_UNINSTALL_PACKAGE are deprecated.
Instead, we appear to need to use the more-cumbersome
ACTION_NEW_OUTGOING_CALL is deprecated. There are new
CallScreeningService APIs for apps that formerly did that sort of work
by listening for
The “preferred activities” APIs in
PackageManager are now deprecated.
NetworkInfo is deprecated, along with the methods on
that return a
StorageVolume.createAccessIntent() is deprecated. More importantly, it will
fail fast. This was used to request access to one of the
public directories, as an alternative to needing
and therefore getting access to the entire external storage area. It would appear
that the scoped storage feature not only replaces this but is incompatible
with this. So, if you are using
createAccessIntent(), you will need to add
code to take a new approach on Android Q and higher devices.
Where Things Go From Here
There are six beta releases on the docket. Beta 4, due in early June, is supposed to have final APIs, so I’ll have a few more “random musings” posts to write in the upcoming weeks.
Plus, I’ll be giving some of this new stuff a workout, and I’ll have new material for subscribers covering Android Q soon.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!