Mark L. Murphy's Blog, page 11

Inside Code Transparency: The JWT File

I am starting to spend a bit of time poking around the implementation ofcode transparency,with an eye towards filling in some of the gaps that I wrote aboutin my initial thoughts post.

This time, let���s add code transparency to an App Bundle and see what that really means.

Adding Code Transparency

The first thing that you will need is a suitable Java keystore. This should notbe the one that you use for any purpose other than code transparency. It alsoneeds to have a 3072-bit key size (or higher, presumably). This means thatthe Android Studio keystore UI will not work,and you will need to create the keystore the old-fashioned way:using keytool.

You will also need an up-to-date copy of bundletool.

And, of course, you will need an App Bundle for your app.

From there, you can use the add-transparency command toadd code transparency to a copy of the App Bundle:

bundletool add-transparency \ --bundle=/path/to/your/AppBundle.aab \ --output=/path/to/your/AppBundleWithCT.aab \ --ks=/path/to/your/keystore.jks \ --ks-key-alias=WhateverAliasYouUsed

In a nutshell:

--bundle points to the App Bundle that you created (e.g., from Studio)

--output points to where you want bundletool to write the augmented App Bundle

--ks points to your keystore

--ks-key-alias is the alias of the key inside that keystore that you wish to use

You will be prompted for the keystore password at the command line, or there areways to use a --ks-pass command-line option to supply it.

This may take several seconds or longer, depending on the size of your App Bundle,the power of your machine running bundletool, the current phase of the moon, etc.

Examining the Augmented App Bundle

App Bundle .aab files are really ZIP archives, so you can examine them using yourfavorite ZIP utility. In an App Bundle with code transparency, you will find afile at:

/BUNDLE-METADATA/com.android.tools.build.bundletool/co...

The BUNDLE-METADATA/ directory ���is what it says on the tin���: it is metadata aboutthe contents of the App Bundle. Akin to JAR metadata contents, the contents ofBUNDLE-METADATA/ appear to be namespaced by use, so com.android.tools.build.bundletoolwill contain metadata related to bundletool. code_transparency_signed.jwtis the actual code transparency file.

Decoding the JWT

That file is a JSON Web Token (JWT).It will be a very long encoded string. For example, a new projectfrom Android Studio 4.2.2 resulted in a 3460-character code transparency JWT,looking a bit like:

eyJhbGciOiJSUzI1NiIsIng1YyI6WyJNSUlFMVRDQ0FyMmdBd0lCQWdJRVMwekdQVEFOQ...

(with a few thousand additional characters in place of the ...)

So, we need to decode itby one means or another. JWT is used by lots of systems, and so you may alreadyhave some tools for decoding its contents. Otherwise,this Web siteoffers online decoding, and Linux developers can add a bash functionto decode at the command line.

(macOS and Windows developers: I���m sure you have something good to use too!)

Note that these tools merely decode the JWT, allowing us to see what is insideof them. They do not validate that the JWT has not been modified ��� thatis a separate step.

Examining the JWT

That scrap project ��� based on the ���Empty Activity��� template FWIW ���gives us the following JWT payload, after decoding:

{ "codeRelatedFile": [ { "path": "base/dex/classes.dex", "sha256": "c8a57ffe798c896f1b2c5f33862cbde817bb233c291217e3511245e1e9b91c82" }, { "path": "base/dex/classes2.dex", "sha256": "192a3e51f14682fb41b91b99e916b068e818ad598d7d5659ea9c7e26c201de15" }, { "path": "base/dex/classes3.dex", "sha256": "08cae05a2180b2249079bbabedaf3a8ac20bef1e4a3d4f8ea319ea4c2f42a396" } ]}

There is no specification for this payload, something that we will need to rectifyat some point. But, inside the codeRelatedFile array, we have individualJSON objects, each having:

path: a relative path, from the base of the .aab ZIP contents, of a ���code-related file���, such as a DEX file

sha256: the SHA-256 hash of the contents of the identified file

DEX files get this shorthand JSON syntax. Native libraries have a couple ofadditional properties:

{ "path": "base/lib/x86_64/libflipper.so", "type": "NATIVE_LIBRARY", "apkPath": "lib/x86_64/libflipper.so", "sha256": "3f4d0a1a03b7825cb5350453c579d39f9f3369f885b8906dfdf1748510186664" },

As it turns out, there is a protobuf .proto file in the bundletool projectthat appears to describe this JSON structure. NATIVE_LIBRARY is an enumvalue, where DEX is the other value (and presumably is the default value if nothingis provided). apkPath is documented as ���Path to file in the APK���; it is notquite clear to me why this is needed for native libraries but not DEX files.

I still have not yet torn into the bundletool implementation, but the verificationprocess probably is something like:

Confirm that the JWT is signed by the expected signing key (with that chore largelybeing up to us)

Iterate over the JWT payload entries, find the corresponding DEX or .so file inthe APKs installed for this app, and validate the SHA-256 hashes

Iterate over the DEX and .so files of the APKs installed for this app and confirmthat everything there was represented in the JWT (so there has not been a code insertion attack)

I will continue blogging about code transparency in the coming weeks and months,as I try to make sense of how we can cover what Google has not: actually usingthis to ensure that our apps are not being manipulated.

Initial Thoughts on Code Transparency

Over nine months since I broached the uncomfortable questions about app signing,we have the official response. It is simultaneously more than I would have expectedand less than what we need.

These materials have only been in my hand for a few hours, and I expect I���ll write moreabout the situation next week. But, let���s see what we got.

First, there is this FAQ entry from ���The future of Android App Bundles is here���,the post where Google firmly declared that the App Bundle requirement is coming in a month:

When distributing apps on Google Play, how do I ensure my app is delivered to users the way I intend?

At any time, you can download and inspect artifacts from the Play Store, from the app bundle explorer in the Play Console, and via the Play Developer API to verify your app. In addition, code transparency for app bundles is a new, optional feature that can be used to inspect that code running on a device matches the code that was originally built and signed by the developer.

The first sentence is typical subterfuge. At best, all downloading those artifacts dois tell us the state of those specific artifacts.Google is perfectly capable of delivering different artifacts to different people. Itis not significantly different than is serving different Web pages to different people,which Google has been doing since its inception. So, they can give unmodified artifacts tothe developer and give tampered artifacts to other parties.

In terms of the second sentence, the passive tense in ���can be used��� is doing a lot of heavy lifting.As it turns out, ���can��� is somewhat theoretical at this time.

More of the details are in the ���Code transparency for app bundles���page in the developer documentation.

(Google seems indecisive over whether or not App Bundle is a proper noun ��� I will giveit The Capital Treatment here for consistency with past posts on this subject)

Code transparency creates a roster of SHA256 hashes for each DEX file and each .sofile that is part of the App Bundle. If that file ships to a user as part of an app,somebody could use it to confirm that the DEX files and .so files in the app match theirhashes. And, the code transparency file itself is signed, using a signing key private to the developer,so in principle we can determine if the code transparency file itself has been modified(e.g., to reflect hashes of tampered files rather than the original files).

That sounds good, and to an extent, it is.

However, all Google needs to do is remove the code transparency file from the apps that they deliverto users. After all:

They have full signing authority, so they can remove whatever they want

There is no legal or contractual requirement for them to ship this file

There is nothing in the operating system that is looking for this file, as they readily admit:

Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs.

If there is no code transparency file, there is no code transparency.

Also, verifying that the code transparency file itself is the original implies that wecan validate that its signature is intact and was from the developer���s signing key.There is no current infrastructure for this, as Google also admits:

Important: To verify that the signature comes from the original developer, the printed fingerprint from one of the following methods must be compared with the public key communicated by the developer through a trusted channel. For example, the developer can host their public certificate on a secure website that is known to belong to them. To ensure no other changes have been made to the app, checking the APK signature is also necessary and recommended.

In addition, the code transparency file conveniently omits some things:

It does not include the manifest (or resources, assets, etc.)

It does not seem to preclude there being additional DEX or .so files, beyond the ones in the code transparency file

There has been an app-resigning attack available since Android 8.0 that neatly fits thosetwo omissions.

The upshot is that we, the developer ecosystem, will need to build a secure, reliableway for developers to advertise, for any given versionCode of an applicationId,that a code transparency file was included in the App Bundle, along with the certificate (orcertificate hash) that was used to sign that code transparency file. Google, at leastat present, is washing their hands of that mess. Without this, we have no way of knowing,for any given app, whether a missing code transparency file is a problem and whetheran existing code transparency file is valid.

Then, we, the developer ecosystem, will need to create practical tooling aroundthis stuff. What Google has given us is new commands for bundletool.As a reference implementation, that���s great. As a practical matter, that is very limited.For example, an anti-malware app running on Android itself is not going to be using bundletooldirectly via a shell command, if that���s even realistic. We are going to need a specificationfor the code transparency file, along with implementations that can be used in moreflexible ways (e.g., a library). It is unclear to what extent Google will be interested inany of that.

In addition, we, the developer ecosystem, will need to experiment with extending thissystem to include other developer-chosen content, such as the manifest, and deal with the���what if there���s other stuff here than what���s listed?��� issue.

Plus, we, the developer ecosystem, will need to get tools in the hands of users to actually validate the code transparency. It does us no good to have code transparencyfiles if nothing checks for them and verifies that the app was not modified by Google.This will likely need to be some mix of existing security-relatedapps (e.g., the aforementioned anti-malware apps) and dedicated code transparencyaudit apps. Google is unlikely to help here, and frankly, we should view any such helpas being suspect (���the fox guarding the henhouse���).

Also:

None of this affects APK-based uses of Play App Signing ��� official code transparency isonly for App Bundles

None of this affects other distribution channels that employ equivalents to PlayApp Signing��� such as the Amazon AppStore for Android,coming to a Windows 11 installation near you soon

We, the developer ecosystem, are going to need to figure out how to address thosescenarios as well.

Worst of all, these are just the things that I have thought of. I am certain to be missingsome problems or skipping over some scenarios, and those might add to the pile of work to be done.

Google���s implementation of code transparency is more than I expected,insofar as I really did not expect Google to do much ofanything. I have no idea how robust the core elements of their solution are, and we willonly find that out over time. But, the fact that this even exists is a positive step, incompleteas it may be.

That incompleteness is why this is less than what we need.

And all of this is just to avoid allowing developers to continue distributing APKsthe way that they have for over a decade, if they so choose.

In essence, Google has slashed our car tires, and then has generously offered to pay for alift home. While that is a nice gesture, it does not address the problem with the car, and itwould have been nicer if Google had not slashed the tires in the first place.

Again, I expect to write more about this in the coming weeks and months. Suffice it to say:there���s a lot of work ahead for those of us concerned about the problem. If you areconcerned about the problem, enough to perhaps help with that work,please reach out!

Windows 11, Amazon, and Uncomfortable Questions

The big Android news of the week was the announcement that Microsoft is addingAndroid support to Windows 11. Alongside the existing Windows Subsystem for Linux,they are adding a Windows Subsystem for Android.Android apps will live alongside Windows apps in the Microsoft Store, and installedAndroid apps will live alongside Windows apps on desktops and notebooks.

This should be a positive development for Android and app developers.Adding hundreds of millions of potential users does not happen all that often.I thought that Google might be aiming for Android-on-Windows withthe introduction of ARC five years ago asa way of getting apps onto Chrome OS. Extending that to Chrome browsers on Windows wouldhave been very interesting. Microsoft adding it to Windows 11 has the potentialfor much better OS integration than Google might have been able to pull off.

However, there is a dark cloud with all of this: the primary source of Androidapps for Windows 11 users appears to be the Amazon AppStore for Android.

Amazon introduced their AppStore for Android over a decade ago.Few developers think about their store, because it pretty much is just fortheir Fire series of devices, including tablets, the Fire TV family, and the oft-malignedFire Phone. However, Amazon had originallyenvisioned it as being an alternative to the Play Store (then called the Android Market).Amazon let you sideload their store onto phones, and they struck distribution deals withsome manufacturers. All of that dried up, and it would be interesting to learn more aboutwhat all transpired there, perhaps in the context of some antitrust litigation.

The reason why I haven���t written much about the Amazon AppStore for Android is simple:Amazon pioneered the ���replace the developer signature��� approach that Google uses withApp Signing. And, Amazon does so specifically to be able to modify every Android appthat they distribute. In other words, the very problem thatI ranted about with Google back in Septemberis something that Amazon has been doing for over a decade:

Amazon wraps your app with code that enables the app to communicate with the Amazon Appstore client to collect analytics, evaluate and enforce program policies, and share aggregated information with you. Your app will always communicate with the Amazon Appstore client when it starts [To do this], Amazon removes your signature and re-signs your app with an Amazon signature that is unique to you, does not change, and is the same for all apps in your account.

Back in September, I was not worried about Amazon, just because they had little presencein Android app distribution. While the Fire devices are doing fairly well (Fire Phonenotwithstanding), ���fairly well��� is still a tiny fraction of the billions of Androiddevices out there that use the Play Store. Getting the Amazon AppStore for Androidon millions upon millions of Windows 11 machines changes that. Now, the Microsoft/Amazoncombination has vastly improved reach: Amazon supplies the apps, while Microsoft suppliesthe users.

The problem is that Amazon modifies all those apps to be different than what the developersintended to ship.

Some will worry that Amazon will modify those apps to contain morethan to ���collect analytics, [and] evaluate and enforce program policies���, in ways that might rankle those concerned about Amazon���s behavior. After all, this is the same firm that tried sneaking Amazon Sidewalk in through the back doorand has a dubious privacy and security track record with Ring,and that is ���just for starters���.

But this puts them in the crosshairs of the same fine folks who might want to introduceother modifications to those apps. I can think of a number of countries who wouldlove to convince Amazon to modify Facebook Messengerto bypass end-to-end encryption, for example. That would have been nearly pointlessjust to reach some Fire tablet users. Fortunately, Facebook has a desktop edition of Messengeralready in the Microsoft Store, so (hopefully) relatively few additional people willwind up using an Amazon-distributed Messenger app. But, what about future generations ofpersonal communication apps?

Perhaps Microsoft will lean on Amazon and convince them to abandon this app tampering practice.Perhaps Microsoft will emphasize other distribution channels as well as the AppStore for Android,ones that have a better track record of ensuring that apps are not modified by anyone.Perhaps Microsoft will start their own way of distributing Android apps, bypassing firms like Amazon.

So, let���s ask Amazon and Microsoft their own pair of uncomfortable questions:

Will Amazon agree to distribute Android apps unmodified from what developers upload, withthe original signatures intact? Amazon���s behavior is policy, and policies can be rescinded.

Will Microsoft commit to having ways to distribute Android apps to Windows 11 users, wherethose apps are unmodified and retain their original signatures? If we have alternativesto Amazon���s AppStore for Android that are reasonable for developers, reasonable for users,and avoid the tampering, that would be a massive win.

Giving Amazon lots more reach compounds the problems that I outlined inmy original ���uncomfortable questions��� post.That, combined with Google dragging their feet with details of ���code transparency���,is deeply disturbing. Hopefully we can get this to all work out in the end, but Isuspect that it will require a lot of effort.

Random Musings on the Android 12 Beta 2

Each time Google releases a follow-on developer preview, I rummage throughthe 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 notget 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 stilldoes 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 doanything. That is nice, considering that this is Beta 2. For example, apps do nothave to change for the microphone and camera indicators to appearor for users to be notified about apps reading from the clipboard.

There is a new SensorPrivacyManager,which can let you know if the device supportsmicrophone and camera toggles.It cannot tell you what the state of the toggle is ��� you just use the microphoneand 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 usedcertain 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 developerscan 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 andthe 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, includingopting out, if the app developers are not in position to support users with Google-suppliedtranslations.

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 onlything 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 forother 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 inrequestRawStorageAccessand 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 thischange 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 appearsthat 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 earlierpreviews. If it does, and your designers hate the sparkle effect with the fiery passionof a thousand suns, this might lead to an option to disable it within your app.

���Exploring Android��� Version 2.1 Released

Subscribers now haveaccess to an update to Exploring Android,known as Version 2.1, in PDF, EPUB, and MOBI/Kindle formats, in addition to theonline reader. Just log intoyour Warescription page and downloadaway, or set up an account and subscribe!

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

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

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

Random Musings on the Android 12 Beta 1

Each time Google releases a follow-on developer preview, I rummage throughthe 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 notget 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 atwhat 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 widgetsthat I have been reporting on in past musings are great. But themandatory rounded cornersmake me wonder if targetSdkVersion got deprecated or something. This is nowthe second UI change, after the splash screens, that can materially affectapps 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. Butaesthetics? 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 goingto be able to offer system-supplied translations of user-visible strings. This is almost completelyundocumented, though there are many classes ina new android.view.translation package,plus related methods on View.You can also query PackageManager to see if the device supportsFEATURE_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 theapp after it moves out of hibernation, which may break apps that assume that ACTION_BOOT_COMPLETEDhappens 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 locationseems 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 permissionsgreatly reduce the ���fear factor��� that needing ACCESS_FINE_LOCATION imposed onapps 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 sayis 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 classsounds like we���re talking about car trim lines (���the silky-smooth screen, the two-speakeraudio 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 usingTypedArray 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 thisis for Android Auto, Android Automotive, or something else. It probably is not for Otto.

Google I|O 2021 and Uncomfortable Questions

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 hasbeen no reversal of the mandatory-App-Signing requirement, and I have not seen anyannouncement about how Google might ���alleviate some of these concerns���.

Worse, time is running out.

There is some Play-specific content presently onthe 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 statementsin 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 shortlyafterwards in YouTube as well. If you are interested in the App Signing concerns and youget a chance to ask an AMA question about it, great! However, please bear in mind thatmost developer relations people will have little insight on this, as this is a Google Playconcern. Somebody helping with the Jetpack, for example, is unlikely to have any informationabout App Signing policy changes. Please be respectful of their time and the time of otherAMA participants.

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

Random Musings on the Android 12 Developer Preview 3

Each time Google releases a follow-on developer preview, I rummage throughthe 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 notget 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, aswe race towards betas. As usual, things start to slow down the deeper into therelease 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 affectevery app regardless of targetSdkVersion.

What Does Not Shock Me

Adding the SCHEDULE_EXACT_ALARM permissionis 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 bucketis unsurprising.

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

The fact that RenderScript is dead is unsurprising��� other than the factthat 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 somelimits 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 redactionin 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_CONNECTand BLUETOOTH_SCANpermissions. My hope is that these will mean that we will no longer have to requestlocation permission to work with Bluetooth devices. OTOH, it seems like this should bedocumented more by now, particularly since they are dangerous permissions andpresumably require runtime requests. These appear to be in a new permissiongroup, 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 locationdespite 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 herein 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 developerpreview 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 LightsManagerthat ���allows control over device lights���. It is unclear whether or notthere 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_MEDIApermission. If I understand it correctly, apps that hold it can have a somewhatstreamlined user experience with media management, with fewer confirmation popupsto grant access to the managing app.

There is a new wordy START_FOREGROUND_SERVICES_FROM_BACKGROUNDpermission. 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 deservesto have the right to start foreground services from the background is beyond me.

Somewhere, perhaps in the manifest, we can specifyandroid: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���, whateverthat means.

Bubble can suppress their bubbles.Sometimes.

The app search APIs expanded massivelyyet remain unannounced. In completely unrelated news, Google I|O 2021 willbe 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 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 poweredby ScrollCaptureCallback.

���Elements of Kotlin��� Version 1.0 Released

Subscribers now haveaccess to Version 1.0 of Elements of Kotlin,in PDF, EPUB, and MOBI/Kindle formats. Just log intoyour Warescription page to download it,or set up an account and subscribe!

This is unchanged from Version 0.9, other than updating two screenshots and standardchanges in the preface. Version 1.0 is a milestone release, and there were no bugsreported against Version 0.9, so that is why it is largely the same.

I plan to update this book after new versions of Kotlin ship,such as the upcoming Kotlin 1.5.

���Elements of Kotlin��� Version 0.9 Released

Subscribers now haveaccess to Version 0.9 of Elements of Kotlin,in PDF, EPUB, and MOBI/Kindle formats. Just log intoyour Warescription page to download it,or set up an account and subscribe!

There are a few new ���Kotlin, WTF?��� chapters:

Extension properties

Class delegation

Local types

noinline and crossinline

Receivers in function types

And types of keywords

Plus, there were a few bug fixes.

In about a month, Version 1.0 will be available, which will be purely bug fixes.

After that, I plan to update this book after new versions of Kotlin ship,such as the upcoming Kotlin 1.5.