Random Musings on the Android 13 Developer Preview 1

Each time Google releases a new developer preview, I rummage throughthe API differences reportthe 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 developermight reasonably use, along with things that may notget 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 mightship as early as August.

My initial reaction to 12L was that schedules slipped, so they elected to movetablet-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 bitearlier 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_DOCUMENTuse a different UI for image/video MIME types. Still, anything to improve content accessfor 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 servefor 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 maywant to pay close attention to CloudMediaProvider.

What Makes Me Want to Speak in Tongues

Per-app language preferencesis 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 solutionis great! Even better is a statement about Jetpack support for older devices.

Still, most of my questions from that earlier postremain unanswered. For example, if the device language is English and the applanguage 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 viaACTION_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 configurationchange when the app language changes, just as there is a configuration change when thedevice language changes. LocaleManager lets you directly manipulate the user���sselection of language.

What Other High-Profile Things Are Nice to See

If you need to talk to local WiFi devices, the NEARBY_WIFI_DEVICES permissionprobably 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 soundpromising, if you���re into that sort of thing. Similarly, if you have had hyphenationperformance anxiety before, faster hyphenationis nice, except that it will be years before that improvement is something that is outfor a majority of devices.

And, for the ~148 developers writing tiles, helping users add your tilesis 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 appearto be a security thing, as external apps can still start your components ��� theyjust cannot do so via a purely explicit Intent.

Themed app iconscontinues 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 onBackground 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 holdto raise notifications ��� is in the JavaDocsbut is not mentioned in the required app changes documentation. My guess is thatthis is a documentation gap. Mishaal reports thatit will only be enforced for apps targeting API 33.If true, this gives developers a year to ignore it, only to then scrambleat the last minute to deal with the change.

(not you, of course ��� you are reading this blog post, so clearly youare 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 developersbeyond 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_EMPTYto 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_STATEseems overused.

Speaking of permissions, not only can you request runtime permissions, but onAndroid 13, you can revoke ones that you were granted earlier.

One of the long-standing problems with registerReceiver() is that the resultingBroadcastReceiver 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 uscurrentNetworkTimeClock(),which reports the time from a network time source (e.g., SNTP). As the docsnote, 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 andreplaced 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_BACKGROUNDpermission. Presumably, it is required for background apps that wish to read heartrate or similar data, such as on Wear OS. This permission has scary languageabout being ���a hard restricted permission which cannot be held by an app until theinstaller on record allowlists the permission���. If your app already requestsBODY_SENSORS, pay close attention to what eventually gets documentedabout 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 morewill 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 migrationpaths for apps that presently rely upon it, such as sharedUserMaxSdkVersionand 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_SERVICEname. It is unclear what this is for.

Mishaal Rahman writes about ���hub mode���,and the docs have things like showClockAndComplicationsthat 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 isnot a huge loss. This too might show up in some later developer preview.

There are a bunch of new KeyEvent keycodesthat really could use some explanation (e.g., what is ���Video Application key #1���, exactly?).