Mark L. Murphy's Blog, page 28

Android Summit 2018, Again

The fine folk who organized the Android Summit 2018 have posted
a YouTube playlist of videos from the event.
There are plenty of interesting talks, including some that I attended live, such as:

Britt Barak���s high-level depiction of Android app navigation

Kevin Galligan���s ���state of the union��� of Kotlin Multiplatform

Dan Galpin���s layered look at data binding

Ahmed Nawara���s discussion of Mobius, an MVI-ish framework

My presentation on slices is also available:

On my conference videos page, where I have an embed of the YouTube
video

On the presentation resource page,
where I have a link to a downloadable screencast of my presentation

Android's Architecture Components Version 0.11 Released

Subscribers now have
access to an update to Android���s Architecture Components,
known as Version 0.11, in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!

This small update:

Adds a chapter on using ViewModel to manage connections to bound services

Adds a chapter exploring the Room OnConflictStrategy options

Overhauls the chapter on using Room with RxJava

Updates coverage of WorkManager for alpha08

Fixes various errata and makes other small improvements

The next update to this book should be late this year.

Android Summit 2018 Materials

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.

The Busy Coder's Guide to Android Development Version 8.13 Released

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.

Fortnite, Security, and Monopoly

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.

Android Studio and distributionSha256Sum

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/gra...

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.

Android Summit 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!

Slices From Afar

From the ���Things That Make You Go ���Hmmmmm������ Department���

Recently, I was puttering through the source code to Google���s Slice Viewer app.
This app can be used by developers to test their
slices, since we, um, don���t
have many (any?) real places to use slices right now. I was double-checking
to see if my own implementation of a slice host was missing anything of note
that Slice Viewer used from the slice APIs.

As I was wandering through the code, I noticed something very curious: Slice
Viewer supports slices coming from three Uri schemes. A SliceProvider
is a ContentProvider subclass, and it will use the content scheme, and I
thought that content was the only option.

But Slice Viewer also has code that specifically
shows support for http and https, such as
here
and
here.

When I rummaged through the source code for slices themselves (e.g., the slice-core
artifact), I did not see any signs of http/https support, though my search
was fairly cursory. It is entirely possible that the Slice Viewer code was
for some experiment and never got cleaned up, or perhaps it is for some internal
implementation of the slice API that has not been released yet.

But, it���s worth considering the possibilities here.

Most of what makes up a slice is a snapshot of static data: text, images, and
metadata about how those should be rendered (lists, grids, etc.). That could
easily be obtained from a Web site. If you wanted to minimize the round trips to the server,
you might package the whole slice up in single payload, using protobuf to blend
text and binary content in a single blob.
AFAICT, slice data is already being published as a stream (versus a database structure)
from a SliceProvider ��� a stream from a Web server is just another stream,
perhaps with a distinctive MIME type.

This would allow Web sites to surface content directly in arbitrary slice-enabled
Android apps, without custom code in those apps. Just by hosting and rendering slices, you would
be able to support slices from both local providers and Web sites. Interested brands could
publish Web slices with an eye towards having them lead users either back to the Web
site or to use the brands��� Android apps, perhaps even including Instant Apps.

This is not a perfect solution. Some functionality of local slices would be lost:

Unless they decided to bring websockets into the mix, there would be no good
way to push slice data updates from the Web server to the client. Polling would
be an option, of course, based on a supplied expiry time, but��� ew.

Slices can have actions, which for a SliceProvider come in the form of
PendingIntent objects. A Web slice might use URLs instead. Those with https
schemes would be wrapped in ACTION_VIEW Intent objects; those with
the ill-used intent scheme would be used verbatim with startActivity().
Or, perhaps there might be an encoding that triggers simple Web service
GET requests back to the server.
Still, those are less flexible than the options available to local slices.

Local slice providers ��� at least those implemented using official code ���
are secured. The user has to agree to allow the slice host to have access to
slices from the slice provider. It is unclear how that sort of permission grant
would be mapped to Web slices.

Discovery of Web slices is as big of an issue as is discovery of locally-available
SliceProviders. How does a host know the Uri to use? Obviously, Google
could do stuff through their own search engine, but what about the rest of
the Android ecosystem?

So, I don���t know if there is anything to the http/https code that exists in Slice Viewer.
But it is something that I will be watching for, as it could really change the
way that we think about slices.

Android's Architecture Components Version 0.10 Released

Subscribers now have
access to an update to Android���s Architecture Components,
known as Version 0.10, in PDF, EPUB, and MOBI/Kindle formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!

This update:

Adds a new chapter on WorkManager

Adds a new chapter on backing up a Room database

Expands the material on LiveData and data binding

Moves all of the sensor-related sample code into a Sensors/ directory

Fixes various errata and makes other improvements

The next update to this book should be in September.

SQLCipher for Android, WAL, and Parallel I/O

While working on some compatibility tests for SafeRoom,
I ran into
what appears to be an irreconcilable conflict between SQLCipher for Android and Room.
This does not appear to be a huge problem right now, though
that might change in the future.

SQLCipher for Android was developed in the early days of Android and was based
on Android 1.x/2.x implementations of things like SQLiteDatabase. Needless to
say, the framework implementation of SQLiteDatabase has changed over the years.
One of those changes is in how SQLiteDatabase interacts with SQLite itself.

Back in the day, SQLiteDatabase had native methods to talk to SQLite
(by way of some native framework code). Each SQLiteDatabase had an individual
separate ���connection��� to the underlying SQLite database.

Nowadays, the story is more complicated. SQLiteDatabase has a ThreadLocal
SQLiteSession object, so a SQLiteDatabase used across multiple threads
will use multiple sessions. Each session uses a database connection from a small
pool of connections, with some guarantees that a connection will be used by only
one thread at a time. But, connections might be used by parallel threads
simultaneously. In particular, with write-ahead logging (WAL) mode enabled,
it is possible to have an open transaction for writing, while in a separate
thread execute a read operation, and have both succeed, with the read returning
a result even while the write transaction is still open and outstanding.

While SQLCipher for Android is moving to adopt some of the newer SQLiteDatabase
capabilities, this is not one of them. It will continue to use the older one-connection-per-database approach,
as I understand it. So, while we can enable WAL mode, and that may have some benefits,
this sort of parallel I/O is not going to be possible. This situation might improve,
but for the moment, ���it is what it is���.

Right now, this means that one of Room���s tests fails with SafeRoom (actually,
it hangs indefinitely, and if I hack the test to avoid the deadlock, then it fails).
It remains to be seen how much this limitation will be a problem with real-world
uses of Room and SafeRoom.