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?).