The CommonsBlog

Each time Google releases a follow-on developer preview, I rummage through the incremental API differences report, the release notes, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize things that mainstream developers might use but may not get quite as much attention, because they are buried in the JavaDocs.

Beta 2 has a bit more change in the API surface than I would expect… and yet still does not have everything that might yet show up in Android 12.

What Google Thinks Is Important

Of the things that Google highlighted in Beta 2, few require developers to do anything. That is nice, considering that this is Beta 2. For example, apps do not have to change for the microphone and camera indicators to appear or for users to be notified about apps reading from the clipboard.

There is a new SensorPrivacyManager, which can let you know if the device supports microphone and camera toggles. It cannot tell you what the state of the toggle is — you just use the microphone and camera normally and get silent/blank output if those hardware features are toggled off.

The new Privacy Dashboard is very nice. If you would like your app to be able to provide explanations for why you used certain dangerous permissions, you can export an activity for that, though pay attention to the docs around ACTION_VIEW_PERMISSION_USAGE_FOR_PERIOD.

What Quietly Got Documented

Somewhere along the line, without an announcement that I can remember, AppSearch is now documented.

AppSearch boils down to a full-text search engine, with an API that developers can use to index content and search it later. The docs specifically compare it to SQLite’s full-text search capability.

This is certainly a nice addition. The docs point to an androidx.appsearch artifact, along with androidx.appsearch:appsearch-compiler and androidx.appsearch:appsearch-local-storage, though. It is unclear what the relationship is between these artifacts and the Android 12 API.

What Makes Me Wonder “What Are They Waiting For?”

The view translation APIs still exist and received their own updates. Yet, there is no sign of documentation, the way that stuff crept in for AppSearch. And, there were some strange reversals, such as FEATURE_TRANSLATION being removed.

In particular, there is no sign of how apps can control this translation, including opting out, if the app developers are not in position to support users with Google-supplied translations.

What Is New and (Potentially) Important

There is a new BLUETOOTH_ADVERTISE permission, described as “Required to be able to advertise to nearby Bluetooth devices”. The only thing that I see as requiring it is ACTION_REQUEST_DISCOVERABLE, and that only needs it once your targetSdkVersion reaches 31.

What Continues to Get Sweet, Sweet Love

RemoteViews got more changes. From the lineup of changes, they feel targeted at app widgets, more so than for other uses of RemoteViews (e.g., custom notifications).

Bubbles continue their march towards usefulness:

• We can find out if bubbles are enabled

• We can find out if our activity was launched from a bubble.

The new “lights” API got some changes. It is still unclear what this is all about.

What Notable Got Renamed

The “optimized” storage access from before is now “raw” storage access, as seen in requestRawStorageAccess and related changes to ApplicationInfo. It still seems limited to file managers and galleries.

VIBRATOR_SERVICE is deprecated, as they steer you towards the new VibratorManager.

What Met Its Untimely(?) Demise

We can no longer ask if a job is a foreground job.

The whole android.service.dataloader package that was added in Beta 1 got nuked in Beta 2.

getDefaultAdapter() on BluetoothManager is deprecated, in favor of getAdapter(). getAdapter() has been around since API Level 18, though, so this change hopefully will not be a big one.

DATE_FORMAT on Settings.System is deprecated in favor of TIME_12_24.

What Else Caught My Eye

The “attribution tags” added in Beta 1 got a bit easier in Beta 2, as it appears that we may be able to add them in the manifest.

We can find out if our app was granted the ability to schedule exact alarms.

There is a new PerformanceHintManager.

We can get and set the “effect color” for RippleDrawable. It is unclear whether this refers to the sparkle effect that was seen in earlier previews. If it does, and your designers hate the sparkle effect with the fiery passion of a thousand suns, this might lead to an option to disable it within your app.

—Jun 10, 2021

---

Subscribers now have access to an update to Exploring Android, known as Version 2.1, in PDF, EPUB, and MOBI/Kindle formats, in addition to the online reader. Just log into your Warescription page and download away, or set up an account and subscribe!

---

The book is now up to date for Android Studio 4.2.1 and newer versions of all the dependencies.

The biggest change, in terms of the actual content, is switching to use ActivityResultContracts as alternatives to things like ACTION_CREATE_DOCUMENT for generating a report. The new version of Navigation required some minor tweaks in how we handle adding a new to-do item. Upgrades to the AppCompat and Core dependencies triggered a collision in some license files, requiring the addition of a packagingOptions directive to app/build.gradle. And the newer Koin requires some changes to imports and the addition of some annotations.

A corresponding update to Elements of Android Jetpack should be out in July.

—Jun 07, 2021

---

Each time Google releases a follow-on developer preview, I rummage through the incremental API differences report, the release notes, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize things that mainstream developers might use but may not get quite as much attention, because they are buried in the JavaDocs.

After a slight delay for the API differences report to be released, let’s peek at what we got in Beta 1!

(and many thanks to Wojtek for the help in getting that report!)

What Continues To Be Disappointing

The overall improvements to app widgets that I have been reporting on in past musings are great. But the mandatory rounded corners make me wonder if targetSdkVersion got deprecated or something. This is now the second UI change, after the splash screens, that can materially affect apps and cannot be postponed until developers have time to deal with it. Every app widget will have rounded corners, like it or not.

I can stomach mandatory immediate changes that affect privacy and security. But aesthetics? As one developer put it to me on Stack Overflow a decade ago, “if I wanted somebody to tell me what my app had to look like, I’d be writing for Apple”.

Wanting a standard launch UI and, um, roundy app widgets is perfectly reasonable for Google… but, please, give developers reasonable time to adapt.

What May Cause Your App to Show Up In Klingon

It appears that some devices — whose names might end in “ixel” — are going to be able to offer system-supplied translations of user-visible strings. This is almost completely undocumented, though there are many classes in a new android.view.translation package, plus related methods on View. You can also query PackageManager to see if the device supports FEATURE_TRANSLATION.

My questions are:

• Is this opt-in? Or is this like splash screens, and apps will get translated without developer consent?

• If this is mandatory, is Google going to supply the multilingual customer support needed for app developers to deal with questions in unsupported languages?

I like the concept, but this opens a big can of worms. Having this show up, undocumented, in Beta 1 is disturbing.

What Else Might Cause You Grief

I like the concept of app hibernation, which appears to boil down to “we press the ‘Force Stop’ button, so you don’t have to!”. However, the documentation mentions that ACTION_BOOT_COMPLETED will be sent to the app after it moves out of hibernation, which may break apps that assume that ACTION_BOOT_COMPLETED happens at boot time. This, at least, only kicks in with a targetSdkVersion of 30.

If you like your castles to be bouncy, you may run into some compatibility issues. Alas, at this point, due to the passage of time, it is probably not a good idea to have your castles be spongy instead.

What Security Improvements Make Me Happy

Approximate location seems like a blissfully simple solution.

AttributionSource seems interesting.

We can query for version information regarding the hardware keystore.

And a bullet on a slide in “What’s New in Google Play”, referring to “code transparency”, offers some hope with respect to my uncomfortable questions.

What Else I Am Looking Forward To

The new Bluetooth permissions greatly reduce the “fear factor” that needing ACCESS_FINE_LOCATION imposed on apps looking to talk to Bluetooth devices.

For developers maintaining alternative app stores, you can now perform silent app updates, if the user grants permission. Which, since that permission is normal (inexplicably), you should just get by having it in the manifest.

What Has Me Scratching My Head

The docs for “Extended file access support” state:

Additionally, the media URIs that are granted by createWriteRequest() now support the APIs in the File class. These APIs provide the ability to read, write, rename, and delete files.

But… Uri does not have the methods of File. If what this is trying to say is that developers should be reverse-engineering a filesystem path out of a Uri… well, that takes me from “scratching my head” to “pounding my head”.

Also, there is a new DataLoaderService, which seems to tie into the app installation process. The documentation is scant at best.

And, DevicePolicyManager now lets you control the “app streaming” policy. That is described as:

App streaming is when the device starts an app on a virtual display and sends a video stream of the app to nearby devices.

I am uncertain if this refers to Android Auto, scrcpy, Windows 10, or something else.

What Makes Me Giggle

Performance class sounds like we’re talking about car trim lines (“the silky-smooth screen, the two-speaker audio system, and the Corinthian leather back mark this phone as being truly ‘performance class’…”).

What Else Caught My Eye

Android 11’s package visibility changes apparently had a hole that is being closed.

TypedArray is now an AutoCloseable, which seems like a nice addition. Too bad Jetpack Compose means we will be using TypedArray a whole lot less…

We can now detect if the device network is connected to an automotive head unit. I’m not savvy enough with Android for Vehicles with 4+ Wheels to know if this is for Android Auto, Android Automotive, or something else. It probably is not for Otto.

—May 19, 2021

---

Last August, Google stated that:

we intend to require new apps and games to publish with the Android App Bundle on Google Play in the second half of 2021

To publish an App Bundle, we must use App Signing:

it is a requirement to use Play App Signing in order to publish with App Bundles on Google Play.

As a result, Google can do whatever Google wants with the contents of the App Bundles. Some of that could be positive for all parties. Some of that could be very bad, though, which led to some uncomfortable questions about app signing.

In November, Google publicly responded to those uncomfortable questions, indicating that Google was “looking into how [Google] could alleviate some of these concerns”.

Since that time, AFAIK, there has been “radio silence” on the subject. There has been no reversal of the mandatory-App-Signing requirement, and I have not seen any announcement about how Google might “alleviate some of these concerns”.

Worse, time is running out.

There is some Play-specific content presently on the Google I|O 2021 agenda. However, other than a 15-minute “What’s new in Google Play”, keynote I do not see any obvious session where announcements like this might be made. Other keynotes could cover it, but I do not find that to be likely.

They do have quite a few “AMA” sessions, where presumably they are taking live questions. I did not see any tied to Google Play. Wojtek Kaliciński, who provided the best statements in the public response to the concerns, is participating in an AMA, albeit on “Developer Tools and Languages”.

I certainly recommend attending whatever of Google I|O that you can. A lot of content is “on-demand” (i.e., pre-recorded), and presumably the live sessions will be available shortly afterwards in YouTube as well. If you are interested in the App Signing concerns and you get a chance to ask an AMA question about it, great! However, please bear in mind that most developer relations people will have little insight on this, as this is a Google Play concern. Somebody helping with the Jetpack, for example, is unlikely to have any information about App Signing policy changes. Please be respectful of their time and the time of other AMA participants.

Regardless, I hope that we get more clarity on this situation.

—May 01, 2021

---

Each time Google releases a follow-on developer preview, I rummage through the incremental API differences report, the release notes, and even the release blog post, to see if there are things that warrant more attention from developers. I try to emphasize things that mainstream developers might use but may not get quite as much attention, because they are buried in the JavaDocs.

Today, let’s take a look at the (presumed) last of the developer previews, DP3, as we race towards betas. As usual, things start to slow down the deeper into the release process we get, but there are still some DP3 changes to consider.

What Makes Me Very Angry

Splash screens. Specifically, Google-mandated-and-designed splash screens. Even more specifically, Google-mandated-and-designed splash screens that affect every app regardless of targetSdkVersion.

What Does Not Shock Me

Adding the SCHEDULE_EXACT_ALARM permission is unsurprising. If anything, I am surprised it took this long.

Similarly, continuing The War on Background Processing by adding an even more restrictive “restricted” app standby bucket is unsurprising.

Adding additional blocks on what apps can handle ACTION_VIEW for Web URLs also is unsurprising. Unfortunately, this has some anti-competitive aspects, as it puts additional burdens on third-party clients for existing Web properties, as well as for alternative Web browsers.

The fact that RenderScript is dead is unsurprising… other than the fact that zombies are remarkably tough to kill sometimes.

What Security-Conscious Developers Should Ponder

android:allowBackup no longer affects device-to-device data transfers. There is a separate configuration mechanism that you can use to try to put some limits on that.

There is a new getRedactedUri() method on MediaStore. Given the Uri of some piece of content, getRedactedUri() will return a Uri that serves up the same content with some form of redaction in place. The cited example is removing location/GPS-related EXIF headers from images. It is unclear if there are other forms of redaction that are offered.

There are new BLUETOOTH_CONNECT and BLUETOOTH_SCAN permissions. My hope is that these will mean that we will no longer have to request location permission to work with Bluetooth devices. OTOH, it seems like this should be documented more by now, particularly since they are dangerous permissions and presumably require runtime requests. These appear to be in a new permission group, NEARBY_DEVICES.

Possibly related, there is a new android:usesPermissionFlags that goes somewhere (<uses-permission> element?). The one supported value is neverForLocation, which basically says “we pinky-swear that we are not going to use your location despite asking for location permissions”.

There is a new DisplayHashManager system service, which is “used to validate information about what was present on screen”. This begs the question: under what circumstances would this hash fail? See also generateDisplayHash() on View.

What Continues Its Remarkable Turnaround

RemoteViews, particularly for use with app widgets, is getting more love here in Android 12. I mentioned a bunch of improvements in my DP2 post. In DP3, we get a whole bunch of additional RemoteViews improvements. It looks like we can adjust android:layout_* attributes now, for height, width, and margins. And, it appears that we have a simpler option for populating a ListView, using RemoteCollectionItems.

Also, the deprecated AnalogClock class continues getting new capabilities.

What Is Going Away

If you were using system-supplied playlist tracking via MediaStore.Audio.Playlists, do something else.

The “network slicing” APIs added to DevicePolicyManager in an earlier developer preview are now gone.

And our ripples no longer have style.

What Is Back

Deprecated is no longer deprecated.

What Relieves Me Tremendously

We made it to DP3 without any obvious changes to scoped storage.

What Makes Me Go “Hmmmmm…”

There is a new LightsManager that “allows control over device lights”. It is unclear whether or not there are four lights.

Theoretically, there is a new DomainVerificationManager system service, obtained using DOMAIN_VERIFICATION_SERVICE… except the documentation leads to a 404.

There is a new MANAGE_MEDIA permission. If I understand it correctly, apps that hold it can have a somewhat streamlined user experience with media management, with fewer confirmation popups to grant access to the managing app.

There is a new wordy START_FOREGROUND_SERVICES_FROM_BACKGROUND permission. Right now, we cannot start foreground services from the background, but with this permission, you can. However, ordinary apps cannot have it, only privileged apps and those in certain roles. Why a gallery app deserves to have the right to start foreground services from the background is beyond me.

Somewhere, perhaps in the manifest, we can specify android:requestOptimizedExternalStorageAccess="true". That can only be granted to apps with MANAGE_EXTERNAL_STORAGE or, once again, gallery apps. If granted, “bulk file path operations will be optimized”, whatever that means.

Bubble can suppress their bubbles. Sometimes.

The app search APIs expanded massively yet remain unannounced. In completely unrelated news, Google I|O 2021 will be held May 18-20.

We can now find why our JobScheduler job was stopped, which is a rather nice addition.

There is a new singleInstancePerTask value for android:launchMode.

compileSdkVersion is now reported for installed apps. This includes a separate compileVersionSdkCodename value apparently for things like android-S.

AudioManager now lets you control “the audio device that should be used for communication use cases” via setCommunicationDevice().

The scrolling-screenshot capability being added to Android 12 may be being powered by ScrollCaptureCallback.

—Apr 23, 2021

---