The CommonsBlog

On June 17th, I will be talking about Jetpack Compose at an online Meetup jointly hosted by the GDG Boston and GDG Toronto Android communities!

This is open to anyone, not just members of those GDGs, so if you are interested, register to attend!

My talk is entitled “What to Expect When You’re Expecting… Jetpack Compose”.

This is not going to be a review of Jetpack Compose syntax and APIs — it’s a 30-minute presentation, so anything I cover will be out of date by the time I’m done. Instead, my focus is on planning: given what we know about Compose and what we saw with Google’s adoption of Kotlin, how should your project be preparing for migrating to Compose in the coming years? So, while we will see bits of Compose code, you do not need to be familiar with Compose, or even Kotlin, to get value out of the presentation.

I look forward to (virtually) seeing you there!

—May 28, 2020

Subscribers now have access to Version 0.9 of Elements of Android Jetpack, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page to download it, or set up an account and subscribe!

This update adds one more chapter, covering dialogs. This also ties into a new section in the chapter on architecture, looking at the differences between states and events.

There is also a new section on view binding as an alternative to data binding, Kotlin synthetic accessors, or older techniques. Most of the samples that had used Kotlin synthetic accessors or older techniques have been revised to use view binding.

This update also upgrades a bunch of the dependencies used by the sample apps, with minor tweaks to the code and the prose to match.

Also, a change in the publishing process for the EPUB and MOBI editions should improve the readability of some of the images.

And, as usual, it fixes lots of bugs.

0.9 versions are a “release candidate” for 1.0. I expect to release Version 1.0 in about a month, with bug fixes but no significant new material.

—May 26, 2020

A couple of months ago, I wrote about raw paths and “all files access” on Android R, using R DP2. And… what I had there on raw paths is not completely accurate for R DP4. I am not certain how much of that represents changes in Android R and how much of that represents screwups in my original testing.

What I am seeing in R DP4 is:

• With no permissions, your app can create files of any type in the Documents/ and Downloads/ directories. Your app can then manipulate those files afterwards.

• With READ_EXTERNAL_STORAGE permission, your app can read “media files” in any directory other than Android/. The precise definition of “media files” is indeterminate. More on this later.

• Whether files can be read will depend on whether they are indexed by the MediaStore. So, for example, files that you push up using adb push will not be visible until sometime after MediaStore indexes them (e.g., after a device reboot).

• No additional abilities appear to be gained by holding WRITE_EXTERNAL_STORAGE (as expected) or having a targetSdkVersion of R.

The second bullet lines up with the minimalist documentation on raw paths, which states:

Android 11 allows apps that have the READ_EXTERNAL_STORAGE permission to read a device’s media files using direct file paths and native libraries.

(emphasis added)

The definition of “media files” is murky. It appears to be tied to MediaStore indexing, not just file extensions. So, with READ_EXTERNAL_STORAGE:

• We can read PNG files

• We cannot read text files

• We cannot read text files with a .png extension

• We cannot read text files created by an app in Documents/ or Downloads/, even though those apps were able to create the files directly in those directories

• We cannot read PNG files that were put on the device that MediaStore does not know about yet (e.g., the adb push scenario)

So, media file formats that MediaStore does not know about might not be accessible this way, even if you and your users think of those formats as being “media”.

If your app is mostly focused on media, this situation may be an improvement over what we have for Android 10. But, given the undocumented definition of “media files”, I would be somewhat hesitant to rely upon it.

—May 16, 2020

A couple of years ago, I warned you to vet the contents of your manifest. But, if you are like me, the past two years have felt like a decade. So, it’s not unreasonable to have forgotten the lessons from that blog post. Since a recent bit of news highlighted this problem again, perhaps it is time to revisit the topic.

What you ship in your app is your job to manage. That includes all the entries in the merged manifest. It does not matter whether the entries were added by you, by a library, or by a space alien 👽. If it is in your app, you own it and any problems it causes.

So, there’s this app. It is not a Web browser. However, as Kate McNamara pointed out, the app really wants to be a Web browser, offering to handle random URLs as an alternative to the user’s real browser.

The app has a splash screen, in the form of a SplashActivity. That activity’s manifest entry has the following <intent-filter>:

<intent-filter>
  <action android:name="android.intent.action.VIEW" />
  <category android:name="android.intent.category.BROWSABLE" />
  <data android:name="http" />
</intent-filter>

If another app calls startActivity() for a matching Intent, and the user chooses to have this app handle it, this app will start up and show its SplashActivity. However, that is a very generic <intent-filter>, having little to do with the app or its maker.

This is not good.

Fortunately, it only honors the insecure http scheme. 🙄

Having an activity in your app that responds to your own domain name is reasonable. It is a key element of deep links, for example. But the <intent-filter> needs to be scoped to your own site using android:host on the <data> element. In this case, that was not done, to users’ detriment.

Every so often, scan through your merged manifest and ask yourself: do we need all this stuff? You might be scared by what you find in there.

And, um, don’t try to be a Web browser. Unless, y’know, you are writing a Web browser.

—May 13, 2020

Subscribers now have access to an update to Exploring Android, known as Version 1.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!

Mostly, this update contains bug fixes, along with changes to support Android Studio 3.6.3 and updating many of the dependencies.

I plan on a more significant overhaul of the tutorials in the next update. Right now, I’m tentatively planning on that in August, assuming that Android Studio 4.0 ships in stable form in the next month or so. Since it is in Beta 5 right now, that seems likely but not guaranteed.

—May 11, 2020