Random Musings on the Android 14 Developer Preview 1

It���s that time again!

When 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.

What Might Make You Want to Wait

Apparently, you can only run your app once on Android 14 DP1 from Android Studio, and you then have to uninstall it.And the fix is going to be in a canary release of Studio, rather than a patch releaseon the current production version.

What Might Be Less ���Orphan Black��� and More ���She-Hulk���

Mishaal Rahmann reports that Android 14 might support app cloning.Here, ���app cloning��� appears to mean that the user can set up an app to havemultiple distinct sets of internal storage (e.g., getFilesDir() on Context).This can allow them to, say, use multiple logins for the same app, simply by switchingwhich clone they run.

This may cause some compatibility problems, because some developers refuse to usemethods like getFilesDir() and instead hardcode filesystem paths. That has not beenreliable in many years. However, many app developers can get away with it, becausethe scenarios where the hardcoded path might not work are uncommon (e.g., multiple deviceprofiles, work profiles). App cloning may add yet another scenario where those hardcodedpaths are a problem, and some apps will wind up getting smashed.

FWIW, launchers might need to play along with this ���see ACTION_PROFILE_ADDED.

What Might Get Photo Access In a Bigger Pickle

Mishaal also reports that Google may be unhappy with the rate of Photo Picker adoption, and thatGoogle might shoehorn the Photo Picker into the permissions flow.I agree with the premise that this can improve privacy and security. However, thischange does not appear to be documented, and it will be interesting what the impactsare from a compatibility standpoint.

What Else Screams ���Compatibility Concerns���

There is quite the list of things that are documented that might break appsfrom unwary developers. Some of these will affect many current apps, such as:

Broadcasts sometimes no longer being deliveredwhen your app is running but is not in the foreground

SCHEDULE_EXACT_ALARM no longer being granted by default

Others will crop up later in 2023, when you raise your targetSdkVersion to whateverthe magic number will be for Android U:

Mandatory foreground service types,complete with exceptions,and a veiled threat of the ban-hammer swinging freely on the Play Store for apps that fail to comply

Blocking implicit Intent use even further

Requiring registerReceiver() to specify if the receiver should be exported

Usually, there are some undocumented (or late-documented) compatibility challengestoo.

What Would Matter If Device Manufacturers Were, Y���Know, Reasonable

There are new foreground service types, such as for health.It would be even nicer if these actually mattered, as device manufacturers routinelynerf your foreground service anyway.

There is a new data transfer type of Job.Maybe device manufacturers will pay attention to these and let them actually run.

What Makes Me Consider Using Jedi Mind Tricks

Android 14 has CredentialManagerand CredentialProviderServiceand a bunch of other code tied to ���credentials���. This appears to be in supportof a Jetpack libraryfor integrating traditional logins, passkeys, single-sign-on services, etc.

Ideally, this would be awesome. Google���s track recordmakes me less than interested,at least until this code gets seriously vetted. At least it is part of the AOSP ���I would have expected this to be part of the closed-source Play Services SDK.

But, seriously: an OS that has an entire class hierarchy for ads doesn���t exactly strikeme as the sort of OS where I want to be trusting the OS itself very much.

Note that View now has isCredential() and setIsCredential(), to flag UI elementstied to credentials. It is unclear what impact this has, though it would be niceif they were automatically redacted in screenshots.

What Might Be Signs of Competition

An app using PackageInstaller can now request enforcement of update ownership.In other words, if Store A installs an app and requests this, other stores willneed permission from the user to update the app, even of those other storeshold INSTALL_PACKAGES and can otherwise freely install apps. This also canbe requested in the manifest,apparently.

My guess is that the Play Store will apply this to everything it installs��� butthis implies that Google sees a future with more stores.

What Else Is Rich

setStyleShortcutsEnabled() on EditTextapparently lets common hotkeys like Ctrl+B apply formatting. This is the first tinystep towards getting first-class rich-text editing in Android, which would be welcome,if the current support is limited to people using keyboards.

In somewhat related news, support for handwriting recognition seems improved,with several new methods on Viewand ViewConfiguration.

What We Might Be Allowed To Do

There are many new permissions.Of note:

Each foreground service type now has its own associated permission, suchas for access location data

We might need a permission to turn the screen on

They appear to be adding hooks to allow apps to find out when screenshots are taken,which would be a nice addition

It is unclear how they define Wifi display,but it would be sweet if we somehow got Miracast support back

Google Glass might be making a comeback

What Features Might We Require

There are a few new elements we can add, including:

Support for the aforementioned CredentialsManager, which implies that this willnot be available on all devices

Support for ultra wideband

Support for seamless refresh rate switching

What Means We Can���t Have Nice Things

Another new element is for ���device lock��� support. This probablyties to DeviceLockManager.The primary cited use case: a ���financed device, where the financing entity has the capability to lock the device in case of a missed payment���.

The concept of having financed devices is fine. The concept that financers andand complicit device manufacturers can lock the device for non-payment is unsurprising.Having this ���feature��� baked into the OS is disturbing.

What I���m Surprised Took This Long

As a native English speaker, I am frequently unaware of all of the different nuancesof other languages. But I am a bit surprised we made it this far withoutsupport for grammatical genders.

What Is Going��� Going���

Criteria-basedAPIs on LocationManager are now deprecated.

What Else Intrigues Me

We can now, finally, figure outwhat other app started our app.

There is a VirtualDeviceManager.It is undocumented what this pertains to, other than probably not the Android SDK emulator.However, it also ties to the notion of creating a ���device Context���.And, given this listener,this appears to be for moving an app to a different device, such as from your phoneto the rumored tablet/hub thingy that Google is building.

More of Health Connect is baked into the OS now, with the addition ofHealthConnectManager.

TextView can now have highlights.It is unclear how this related to the rendering of Spanned objects, whichwas our traditional way of highlighting certain portions of the text.

You can get the shape of a Display.It is unclear if this is designed for Wear OS or for other scenarios.

There are new types of KeyEvent,including for stylus buttons.

StrictMode can now complain if you manually request garbage collection.

As part of adding a few hundred OpenJDK 17 classes, we got StackWalker.I can see this being useful for diagnostic tools like LeakCanary.

The media projection APIs now supportscreenshots for a specific or user-selected Display.

Our existing runtime resource overlay (RRO) supportis getting expanded withfabricated runtime resource overlay (FRRO) support.

There is an AltitudeConverter,hopefully not for Android-powered airplanes.

Android now supports Dvorak keyboards,though really the international keyboard types are more important.

We can now find out how much memory the user was told their device has,which might not resemble how much memory their device really has.

Apps on Chromebooks can now request to move to full-screen mode.

And, finally, we can now ask to create a note,even on the lock screen.