The CommonsBlog

Yesterday, the 2018 edition of the Android Summit was held.

There, I delivered a presentation entitled “Slices: What They’re Not Telling You”, focusing on the high-level use of slices, beyond the scenarios that Google is focusing on today.

This resource page has links to the slides, the sample project (two slices and a slice host), plus a screen recording that I made of the live presentation.

Videos of the conference presentations should make their way to YouTube in the coming weeks. Even if you cannot attend a conference, watching their videos is a great way to learn about various Android topics, and there were a number of excellent presentations at the Summit.

I’d like to thank the conference organizers for able assistance and prodigous patience, especially when dealing with all the problems that crop up whenever you hold a conference with a Murphy among the presenters.

—Aug 17, 2018

Subscribers now have access to the latest release of The Busy Coder’s Guide to Android Development, known as Version 8.13, in all formats. Just log into your Warescription page and download away, or set up an account and subscribe!

This update:

• Adds a chapter on hosting slices, plus updates the existing coverage of publishing slices

• Updates the Android 9.0 appendix for the final release of 9.0, plus extends coverage of the StrictMode callback option added in 9.0

• Adds a section on using ListAdapter with RecyclerView

• Updates the material on LeakCanary for version 1.6.1

• Updates the chapter on Samsung DeX to cover the DeX Pad

• Updates the chapter on Chrome OS to cover Chrome OS tablets and Chromeboxes (Chrome OS desktop devices)

• Retires the chapter on embedding a Web server in an Android app

• Has a slight change to the PDF formatting rules to try to keep images and their preceding paragraphs together

• Has other bug fixes and minor improvements

The timing of the next update to this book depends a bit on the release schedules for AndroidX 1.0.0 and Android Studio 3.2. My guess is that this will come out in 2-3 months, with lots of other material showing up in other books between now and then.

—Aug 13, 2018

Epic Games appears to be planning on distributing Fortnite for Android outside of the Play Store.

Frankly, I’m surprised that it took this long for somebody to do this. For a firm with their own payments and software distribution infrastructure, Google’s 30% cut is going to seem awfully steep. For strong brands, the lost sales from people unwilling to go through the alternative installation process may be lower than the 30% losses incurred through Google Play distribution. The only reason why Google can continue to charge 30% is due to the near-monopoly status of the Play Store on many Android devices.

The primary counterpoint to Epic’s decision is security. While one can obtain APKs from places other than the Play Store, conventional wisdom is that this is less secure. In particular, unwitting people might be tricked into installing malware that is disguised as Fortnite (or some other app of relevance).

Today, that conventional wisdom is likely to be true. And yet:

• Malware can be found on the Play Store. Google is not infallible.

• China lacks the Play Store. I had the opportunity to discuss app distribution with a manager from a large Chinese Android device manufacturer, and he expressed incredulity when I explained that Western developers often only ship their apps through the Play Store. In China, there are dozens, if not hundreds, of app stores, all competing for attention. Developers there are used to distributing their apps through many different channels. I have no evidence that users are routinely pwned as a result. Perhaps we can learn a bit from how they are handling this situation.

• Play Protect and third-party security products can analyze APKs installed from elsewhere. The Play Store’s internal analyzers are not our sole line of defense, even today, nor should they be.

• We are headed towards a world where a significant percentage of Android developers delegate app signing to Google. This allows Google to do whatever it wants with the contents of APKs… and it allows others to direct Google to do whatever they want with the contents of APKs. Quis custodiet ipsos custodes? We assume that Google is always a good actor with respect to app distribution – will that assumption hold up?

We definitely need more robust options for helping users identify what sources of APKs are safe. We definitely need more robust options for helping users safely install such APKs. We definitely need more ways to help users and developers ensure that the APKs that users install really are the APKs that the developers distribute. Perhaps Epic could contribute some towards such efforts, as they would gain PR benefits against those who accuse them of actively harming the Android ecosystem.

But, in general and IMHO, those who endorse monopoly in exchange for a little security are causing strategic harm to user security, as much as Epic is causing tactical harm to user security.

—Aug 06, 2018

It is common, though perhaps not widespread, to be given a checksum or hash when you go to download something. For example, when you go to download a Google Pixel image for Android P, you are given SHA-256 checksums for the ZIP files. That way, you can confirm that the ZIP file was downloaded correctly. Back in the early days of the Internet, checksums were good for confirming that some bits didn’t get flipped by accident in your download.

(if you’re under 40, ask your parents about “dial-up Internet”)

Nowadays, though, the concern is security. Having a separate checksum makes it a bit more difficult for an attacker to substitute a hacked file for the real one that you are trying to download.

Gradle offers support for this as part of the Gradle Wrapper. In addition to having a distributionUrl line in gradle-wrapper.properties, you can have a distributionSha256Sum line with a SHA-256 checksum for the Gradle ZIP listed in the distributionUrl. So, for example, if you have:

distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zip

you can also have:

distributionSha256Sum=7a2c66d1a78f811d5f37d14630ad21cec5e77a2a4dc61e787e2257a6341016ce

You have to get the SHA-256 checksum value yourself, from the server that has the ZIP files. When the Gradle tooling API, gradlew, or gradlew.bat need to download Gradle, they will check the SHA-256 hash of the downloaded ZIP file against the supplied distributionSha256Sum. If there is a mismatch, that ZIP will not be unpacked.

Ideally, we would have distributionSha256Sum values in all of our gradle-wrapper.properties files. Instead, few do, for (at least) two reasons.

First, the process is very manual. Android Studio could add the appropriate value when it creates or modifies the gradle-wrapper.properties file. It doesn’t, though, so developers need to go get these values themselves, or hope that somebody gives them a tool that simplifies it a bit.

Second, if there is a mismatch between the SHA-256 checksum and the actual ZIP file hash… Android Studio crashes hard, without even an error dialog. Android Studio needs a better UX here. That in turn might require fixes to the Gradle tooling API to provide more options for handling this situation, though it has been a couple of years since I filed the issue to try to stop Android Studio from crashing here.

Long-term, with some amount of luck, these things will get addressed. I look forward to someday having distributionSha256Sum in more Android projects.

—Aug 01, 2018

The Android Summit is an annual Android developer conference in the Washington DC area.

(not to be confused with the Android Developer Summit, held sporadically by Google in Silicon Valley)

I have spoken at the Android Summit each year since its inception, and the organizers were kind enough to include me in this year’s agenda.

I’ll be talking about slices:

• What are slices?

• How do we create them? (with particular emphasis on the new Kotlin DSL)

• How do we display them ourselves?

• What the heck are they good for, anyway?

If you can make it to Northern Virginia for August 16th, there is plenty of other good stuff on tap, such as:

• Two talks on Flutter

• Two talks on Kotlin

• Four talks on Jetpack and the Architecture Components

• Three talks on Material Design

• A whole track of testing talks

• Two keynotes to bookend the event

• And much more!

Plus, it’s being held at a Ritz-Carlton hotel, so you just know it’s going to be glam!

(well, OK, I won’t be glam — I’ll be my normal schlubby self — but the venue will be glam, as might many of the other speakers!)

Sign up today!

—Jul 30, 2018