Table of Contents
Random Musings on the Android 13 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.
I am not feeling the best today, so I apologize if that impacts the quality of this post.
What Gives Me the “Time Has No Meaning” Vibe
12L has not shipped in final form yet, and we already have a 13 developer preview?
Even more surprising is the timeline, indicating that a final edition of 13 might
ship as early as August.
My initial reaction to 12L was that schedules slipped, so they elected to move
tablet-focused items out of the 12 release timeframe. Now, I do not what to think.
However, you will want to plan on getting your 13 compatibility testing done a bit
earlier than you have had to in previous years.
What Makes Me Want to Pick a Peck of Pickle Photos
ACTION_PICK_IMAGES is interesting.
I am uncertain what the advantage is of a new Intent action over having ACTION_OPEN_DOCUMENT
use a different UI for image/video MIME types. Still, anything to improve content access
for developers is a positive thing.
Note that the photo picker seems to be backed by CloudMediaProvider objects.
These appear to serve the same role for the photo picker that document providers serve
for the Storage Access Framework. If your app is in the business of making photos available,
particularly from collections that MediaStore does not index (e.g., cloud), you may
want to pay close attention to CloudMediaProvider.
What Makes Me Want to Speak in Tongues
Per-app language preferences
is a very nice improvement. As I wrote about a month ago,
developers use hacks to try to get this sort of behavior, and having an official solution
is great! Even better is a statement about Jetpack support for older devices.
Still, most of my questions from that earlier post
remain unanswered. For example, if the device language is English and the app
language is Spanish, and we use ACTION_PICK_IMAGES, what language is used by the photo picker?
From an API standpoint, you can bring up the relevant Settings screen via
ACTION_APP_LOCALE_SETTINGS.
In theory, you can react to changes via ACTION_APPLICATION_LOCALE_CHANGED,
but that apparently requires an undocumented READ_APP_SPECIFIC_LOCALES permission. Hopefully, there is a configuration
change when the app language changes, just as there is a configuration change when the
device language changes. LocaleManager lets you directly manipulate the user’s
selection of language.
What Other High-Profile Things Are Nice to See
If you need to talk to local WiFi devices, the NEARBY_WIFI_DEVICES permission
probably is a big help. This is a common requirement for bootstrapping IoT devices, for example.
JDK 11 support is nice.
If it only goes back to Android 12, it will be years before it matters, but it is still nice.
Programmable shaders sound
promising, if you’re into that sort of thing. Similarly, if you have had hyphenation
performance anxiety before, faster hyphenation
is nice, except that it will be years before that improvement is something that is out
for a majority of devices.
And, for the ~148 developers writing tiles, helping users add your tiles
is a handy thing.
What High-Profile Things Make Me Yawn
I am somewhat mystified by “Intent filters block non-matching intents”,
in terms of what the actual problem is that is being solved. This does not appear
to be a security thing, as external apps can still start your components — they
just cannot do so via a purely explicit Intent.
Themed app icons
continues Google’s Material You initiative. Color me uninterested.
What Was Rumored But That Google Is Hiding
The Android Resource Economy (TARE) is yet another salvo in The War on
Background Processing. Mishaal Rahman reports that it is there,
but it appears that Google did not document it.
By contrast, POST_NOTIFICATIONS — the permission that you need to hold
to raise notifications — is in the JavaDocs
but is not mentioned in the required app changes documentation. My guess is that
this is a documentation gap. Mishaal reports that
it will only be enforced for apps targeting API 33.
If true, this gives developers a year to ignore it, only to then scramble
at the last minute to deal with the change.
(not you, of course — you are reading this blog post, so clearly you
are a forward-thinking developer)
Mishaal also mentions that the clipboard will automatically clear,
which is a win for privacy, but really ought to be pointed out to developers
beyond this blog post.
What Makes Me Scratch My Head, But Over There, Not Here
There is a new NEARBY_STREAMING_POLICY permission.
The underlying policy “controls whether to allow the device to stream its notifications and apps to nearby devices”
(emphasis added).
There is also canDisplayOnRemoteDevices,
which says “whether the activity can be displayed on a remote device which may or may not be running Android”
(emphasis also added).
This makes me wonder what Google is up to.
What’s Old is New Again
Android 12 added a mandatory splash screen. Android 13 appears to make that less mandatory:
a launcher could try to use setSplashScreenStyle()
with SPLASH_SCREEN_STYLE_EMPTY
to perhaps inhibit that splash screen. At least, that is how I interpret this API.
What Requires Better Penmanship Than I Possess
Handwriting is getting system-level love, such as supportsStylusHandwriting.
This matters little to me, as my handwriting sucks.
What Are Other Nice Changes
There is a new, non-dangerous READ_BASIC_PHONE_STATE permission.
It is unclear what you get access to with that permission, but READ_PHONE_STATE
seems overused.
Speaking of permissions, not only can you request runtime permissions, but on
Android 13, you can revoke ones that you were granted earlier.
One of the long-standing problems with registerReceiver() is that the resulting
BroadcastReceiver was always exported. This is not great from a security standpoint.
Now, it appears as though we can control this.
A popular request in places like Stack Overflow is for a way to get the current time,
from a time source that cannot be modified by the user. Android 13 gives us
currentNetworkTimeClock(),
which reports the time from a network time source (e.g., SNTP). As the docs
note, this time still could be modified, but not easily.
What Will Require Some Work
All those PackageManager methods that took a “flags” int? They are all deprecated and
replaced with ones that take richer objects.
If you work with Parcel directly, there are lots of deprecations and lots of replacements.
What Else Might Break Your Apps
There is a new BODY_SENSORS_BACKGROUND
permission. Presumably, it is required for background apps that wish to read heart
rate or similar data, such as on Wear OS. This permission has scary language
about being “a hard restricted permission which cannot be held by an app until the
installer on record allowlists the permission”. If your app already requests
BODY_SENSORS, pay close attention to what eventually gets documented
about the need for BODY_SENSORS_BACKGROUND.
There is a new “light idle mode”, as seen in isDeviceLightIdleMode()
and ACTION_DEVICE_LIGHT_IDLE_MODE_CHANGED.
This is when “when a device has had its screen off for a short time, switching it into a batching mode where we execute jobs, syncs, networking on a batching schedule”.
The “networking” aspect of this is particularly disconcerting, and hopefully more
will be explained about this mode.
Some methods were outright removed from the SDK, mostly in android.webkit.
What Else Might Break Your Apps In the Not-Too-Distant Future
android:sharedUserId is already deprecated. Google appears to be working on migration
paths for apps that presently rely upon it, such as sharedUserMaxSdkVersion
and EXTRA_UID_CHANGING.
My guess is that android:sharedUserId will be ignored in some future Android release.
If you are relying upon android:sharedUserId, start work on some alternative mechanism,
and watch for documentation on how best to migrate to a non-sharedUserId world.
What Really Needs Documentation
There is a new system service, advertised under the SUPPLEMENTAL_PROCESS_SERVICE
name. It is unclear what this is for.
Mishaal Rahman writes about “hub mode”,
and the docs have things like showClockAndComplications
that seem to tie into that. Perhaps this will debut in a later developer preview.
There is a TvIAppManager,
described as being the “system API to the overall TV interactive application framework (TIAF) architecture, which arbitrates interaction between applications and interactive apps”.
Right now, that system service has no methods, so the fact that it is undocumented is
not a huge loss. This too might show up in some later developer preview.
There are a bunch of new KeyEvent keycodes
that really could use some explanation (e.g., what is “Video Application key #1”, exactly?).
