Mark L. Murphy's Blog, page 14

A Poor Default (Or: Why Your Button Does Not Work)

Android Studio 4.1���s new-project wizard creates projects that include
the Material Components for Android library by default, and sets up
the default theme to use Theme.MaterialComponents.DayNight.DarkActionBar as
a base, at least when using many of the templates.

For an experienced developer, this is a reasonable choice. However,
a new-project wizard should not be aimed at experienced developers, as experienced
developers probably already have their project. A new-project wizard should
be aimed at newcomers, because their very first experience with Android app
development will come from the project that the wizard creates.

And for newcomers, Material Components for Android is a dreadful choice, in part
because newcomers have no idea that this library exists, what it is for, or how
it impacts app development.

For example, suppose you are a brand-new Android app developer. You install
Android Studio 4.1 and use the new-project wizard. You add a <Button> to your
activity_main layout resource, and you want to change its background.

At this point, you���re already screwed, and you are only a few minutes into your
first attempt at app development.

Suppose you decide that reading the documentation is the thing to do.

You go to the documentation for Button,
and you see a helpful paragraph on just your topic of concern:

Every button is styled using the system���s default button background, which is often different from one version of the platform to another. If you are not satisfied with the default button style, you can customize it. For more details and code samples, see the Styling Your Button guide.

So you click that ���Styling Your Button��� link
and proceed to read about how you might consider setting your theme to Theme.Holo,
because that page has not been updated in six years or so.

But, it goes on to say:

To customize individual buttons with a different background, specify the android:background attribute with a drawable or color resource.

Fantastic! So you set up a color for your android:background, or maybe even a <shape>
drawable resource, as this developer did���
and you find that your background does not take effect.

Why? Because Material Components for Android does not work that way.

If you happen to know where
the Material Components for Android documentation for Button
resides, you will stumble upon:

Note: <Button> is auto-inflated as <com.google.android.material.button.MaterialButton> via MaterialComponentsViewInflater when using a non-Bridge Theme.MaterialComponents.* theme.

Even experienced developers might have a difficult time interpreting that.

But that might lead you to this page on MaterialButton,
where it says:

Do not use the android:background attribute

So, the documentation says to use android:background, and the documentation says not to use android:background. Great.

The MaterialButton documentation does not do a particularly good job of explaining
what the alternative is (hint: use android:backgroundTint or adjust colorPrimary in
your theme to change the color).

So, we have to wander to multiple sites and deal with conflicting documentation,
just to set a background color on a button.

AppCompat is far from perfect. But, it at least works fairly conventionally. Yes,
inflater magic means that <Button> turns into an AppCompatButton, but AppCompatButton
tends to behave like a regular Button, at least in terms of things like
setting the background color. Newcomers to Android, reading the documentation or Medium
posts or Stack Overflow, are more likely to succeed in what they are trying to do
with AppCompat than with the Material Components for Android.

Moreover, AppCompat has been the official Google recommended choice for quite a few
years now. Quite a bit has been written specifically for AppCompat. So, answers to
questions like ���how do I BLEEP-ing well set a background color on a button?���
are likely to exist. Far fewer of those answers will exist for Material Components
for Android��� and that even assume the newcomer has any idea that Material Components
for Android has something to do with their project.

This is not to hate on Material Components for Android as a library. It is a perfectly
cromulent set of widgets for experienced developers. IMHO, it is a poor choice to inflict
upon newcomers, and that���s why I think it is a poor choice as the default for
Android Studio���s new-project wizard.

Where Compose Could Go

This week marked the Milestone 1 release of Jetpack Compose for Desktop.
I wrote about this back in April,
when the first desktop-related artifacts showed up. It is great to see this continuing
to move forward. There is no published timetable for a stable release, but it will
almost certainly be after Compose itself becomes stable sometime next year.

So, we have Jetpack Compose for Android and now for the desktop. This raises
the question: where else might Compose-based UIs turn up?

Web

JetBrains is already at work on a Kotlin/JS edition of Compose. Presumably,
this will use a Web canvas Skia wrapper, along the same lines as to how Flutter for Web works (as I
understand it). It remains to be seen how practical this will prove to be,
in terms of runtime performance and, more importantly, Web app load times.

iOS

In principle, one could use Compose on iOS, much as how Flutter does, using a Skia-compatible
layer. However, the Flutter team took the time to create their ���Cupertino��� widget
set, in an attempt to mimic a native iOS UI. So, not only would a Compose variant
for Kotlin/Native be needed, but a similar widget set would seem to be required.
My guess is that a Material Design UI on iOS will not be well-received.

However, since Compose for Desktop (and presumably Compose for Web) are tied into
Kotlin/Multiplatform (KMP), a project could elect to use Compose for non-iOS
platforms, write a native Swift-based iOS UI, and share KMP modules between
those platforms.

Chrome OS

Between Compose for Android, Compose for Desktop (targeting Linux), and a possible
future Compose for Web, we should have multiple options for writing Chrome OS
apps with Compose. It will be interesting to see which of these turns out to be
the dominant choice.

Fuchsia

We have not heard much about Fuchsia, Google���s next-generation OS. There was a lot
of hype about it a couple of years ago, and a lot of ���radio silence��� since.
It is unclear to me whether a Compose for Fuchsia would be practical or not.

Platform X

If you were trying to create a new platform, to compete with the desktop, mobile,
and Web options that we have today, your new platform will need apps. Adopting
one of the cross-platform options (React, Flutter, Compose) would help a fair
bit in getting developers interested in trying your platform, at least for conventional
apps. For gaming-centric platforms, trying to adopt Unity 3D or similar cross-platform
game engines would be the likely starting point.

If Google alone were pursing Compose, it would likely be an Android thing and that���s it.
The fact that JetBrains has apparently decided to make Compose a focus area means
that Compose is going to go further than just Android devices. We will have to see
how well that turns out ��� after all, there is no guarantee that Compose will
succeed beyond Android. But it has a lot of promise, and it will be interesting
to see how the next 12 months or so play out!

���Exploring Android��� Version 1.9 Released

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

This update adds a new tutorial, for scheduling work with WorkManager.

It also makes some minor adjustments to support Android Studio 4.1, and fixes a smattering of bugs.

The next update ��� Version 2.0 ��� should be out in roughly a month,
just with bug fixes. The next substantial update will not be until Android Studio
4.2 ships in final form, and I am not expecting that to happen until 2021.

(assuming that 2020 ever ends)

���Elements of Android R��� Version 0.4 Released

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

The existing material was updated to reflect the shipping version of Android 11.

And, a new chapter was added on device controls.

Plus, there were minor tweaks, such as replacing most occurrences of ���Android R���
with ���Android 11���.

In terms of updates from here:

Late November should see the release of 0.9, with a bit of new material plus
any changes required based on testing on a Pixel 5

The final release should ship before the end of the year

youtube-dl, and Avoiding Pointless Copyright Problems

Yesterday, youtube-dl, a popular command-line utility to download YouTube
videos, was taken down from GitHub.
And, near as I can tell, the justification of the takedown is over sample links,
where those links point to copyrighted material.

This seems flimsy, but I���ll leave it to the various attorneys to sort that
out. Regardless, for the time being at least, youtube-dl is
hampered by this move.

And it seems so pointless. AFAICT, there is nothing about those links that
youtube-dl depended upon. They were samples, nothing more. The developers
of youtube-dl could have used links to other materials and avoided some
risk.

Major copyright holders are ���ratcheting up��� enforcement actions, as this incident
and Twitch���s takedown wave
as examples from just the past few days. And way too many Android developers
use copyrighted materials for samples, whether that material shows up
in library documentation or in
Play Store listings.

And that���s a shame, because there is so much stuff that you get get that
you can use freely, particularly with Creative Commons licenses:

Need clip art? Try OpenClipArt!

Need photos? You probably have an Android device with a camera. Go take some!

Need audio or video content (or photos that you did not take yourself)?
Search for Creative Commons-licensed material!

Need text? Try Zeynep Tufekci���s Twitter and Tear Gas,
a book covering how network-centric protests have both pros and cons compared to classic
forms of protest.

Need more text? You can download 4,041 pages of (older) material on Android app development,
written by some balding guy. Have fun!

Need still more text? Will millions upon millions of Creative Commons-licensed questions and answers on computer programming work?

Need even more text? USE WIKIPEDIA!

I mean, seriously, you almost have to go completely out of your way to use
stuff where you���re going to be at risk of a takedown. Yes, you like Olaf (because
who doesn���t like snowmen?) and so you want to use screenshots from Frozen��� but is
it worth the risk of Disney coming after you?

Even big firms get this. Google can use copyrighted materials in
a Play Store listing
in part because they license this stuff. But a firm like Samsung ��� who can
probably hire more attorneys than you can ��� uses placeholder data in
their similar Play Store listing.

Now, it is entirely possible that even if youtube-dl would have used sample links to
Creative Commons-licensed material that the RIAA would still have filed a takedown
notice. It would have made an already-flimsy argument that much more flimsy. And
if the point behind your app is to invite a takedown, as you intend to fight this
in court, more power to you, and be sure to let us know where to contribute to your
legal defense fund.

But, in general, you will have less risk if you use safer stuff for your sample
content, rather than stuff whose copyrights are owned by people who like issuing
takedowns. Unless the risk is the point, consider avoiding the risk.

Android Studio 4.1, Library Modules, and VERSION_CODE

Android Studio 4.1 ��� or, more accurately, version 4.1.0 of the Android Gradle Plugin ���
has a breaking change: it no longer adds VERSION_CODE (and, sometimes, VERSION_NAME),
to BuildConfig.

This was originally reported back in June,
with Canary 4, but despite being a P1 ticket, it did not get resolved before
AS 4.1 shipped. I found out about it from Stack Overflow.
And, since it was mentioned in the release notes,
this might not change.

If you create a scrap AS 4.1 project, your app module will have typical
versionCode and versionName properties:

defaultConfig {
applicationId "com.commonsware.android.myapplication"
minSdkVersion 21
targetSdkVersion 30
versionCode 1
versionName "1.0"

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
}

That module uses the com.android.application plugin, and it generates a
BuildConfig that contains VERSION_CODE and VERSION_NAME:

public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String APPLICATION_ID = "com.commonsware.android.myapplication";
public static final String BUILD_TYPE = "debug";
public static final int VERSION_CODE = 1;
public static final String VERSION_NAME = "1.0";
}

If you then add a library module to the same project, it too will come
with the same versionCode and versionName lines��� but they do not get
reflected in the module���s BuildConfig:

public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String LIBRARY_PACKAGE_NAME = "com.commonsware.android.mylibrary";
public static final String BUILD_TYPE = "debug";
}

I am somewhat surprised that the ticket was not closed as ���working as intended���,
as this change was intentional

this was done on purpose as having a version for libraries (present in the manifest file or in code) does not make sense for libraries in Android. Only applications have an android version.

UPDATE: A few hours after I posted this, it was indeed closed as ���intended behavior���.
Somebody who I suspect is Xavier Ducrohet posted an extended explanation
of how all this came about.

And the release notes
suggest that versionCode and versionName will be removed from the Gradle DSL
in the future.

What worked for me was to declare them manually, based on this issue comment:

defaultConfig {
minSdkVersion 21
targetSdkVersion 30
versionCode 1
versionName "1.0"
buildConfigField 'int', 'VERSION_CODE', "1"
buildConfigField 'String', 'VERSION_NAME', "\"1.0\""

testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
consumerProguardFiles "consumer-rules.pro"
}

In my case, I just hard-coded the values, but you could arrange to pull them
from some common location.

Note that there may be varying behavior here. In the Stack Overflow question,
SO user Void reported two differences from what I am seeing:

VERSION_NAME was getting generated, but not VERSION_CODE

Using buildConfigField for VERSION_CODE would not work, but using a unique name would

In light testing, I could not reproduce those findings, but be prepared for
some variation in symptoms.

The safest thing to do, if you elect to go the buildConfigField route, is to
not use VERSION_CODE and VERSION_NAME, but instead use your own unique
names, as Void did. Basically, consider VERSION_CODE and VERSION_NAME
to be part of a Google-managed
namespace, and assume that Google might mess with them. If you use your own names,
with luck, they will be untouched by future changes to the Android Gradle Plugin.

UPDATE: In the aforementioned extended explanation,
Google echoed this recommendation: use your own custom fields.

Android Summit Presentation Materials

As part of my presentation at yesterday���s Android Summit, I published
a resource page
related to the Android ���software supply chain��� and security issues.

(originally, this URL pointed to a broken copy of the slides ��� I sincerely
apologize to those who tried to access this immediately after the presentation)

This page has links to a few dozen articles, videos, code samples, and the like,
in addition to a lightly-modified edition of the presentation slides.

I believe that this was my last conference presentation. To those events who
gave me speaking opportunities over the years, I am grateful for your faith in me.
For those who attended, I hope that I was at least a little bit useful to you.

���Elements of Kotlin��� Version 0.3 Released

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

In this update,
there is one new ���main��� chapter, covering significant changes in Kotlin 1.3 and 1.4.

There is also a new ���Kotlin, WTF?��� short chapter, covering inline classes.

And, as usual, there were several bug fixes.

I hope to publish Version 0.9 and 1.0 in the next several months. After that, though,
the timing of updates mostly will be dictated by the timing of Kotlin releases.
That means 1-2 years between updates, depending on JetBrains��� plans.

That being said, leaving this book at 0.2 for 14 months was��� not good. ����
I apologize for that and hope to do better overall.

More on Android Summit 2020!

I mentioned a couple of weeks ago that
I will be delivering a presentation on app security at Android Summit 2020.

The schedule is now up. We
have four presentations on app security, all in a row on Friday. I���m bringing up the rear,
after talks by
Enrique L��pez-Ma��as,
Dustin Summers, and
Dinorah Tovar.

And, of course, this is all being held online, so these talks are available worldwide!

If you are interested in attending,
you can get 35% off of your ticket price.
All proceeds go to benefit Women Who Code.

I hope to see you there!

And remember: my presentation is BYOMH
(Bring Your Own Murder Hornet).

Uncomfortable Questions About App Signing

Dear Google Play Team:

Recently, you stated:

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

(emphasis yours)

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.

This gives you signing authority over the APKs that are delivered to people.
As far as I can tell, this means that you can do whatever you want with the contents of
those APKs, including adding to and replacing the original code supplied by the
app���s developers. Worse, this requirement for new apps
feels like a trial run for eventually requiring all developers to opt into App Signing.

Given that��� we need to talk.

Some people may be worried about you modifying apps for your own benefit,
such as degrading performance for apps that compete with Google properties.
That does not keep me awake at night.

This does:

A country ruled by a repressive regime is oppressing a minority group. The leadership
of that regime tells Google: ���In order to do business in our country, you need to
agree to distribute altered versions of certain apps to people of our choosing. We will supply
you with the altered apps, and we will supply you with the identities or criteria
for choosing the people who should receive these altered apps. That criteria might be
narrow or wide, up to and including all people within our country.��� They then supply Google
with the identities of leaders of the minority group, along with altered versions of
next-generation end-to-end (E2E) encrypted messaging
apps. These altered apps capture communications by grabbing the data
out of the app���s UI directly and sending them to a regime-controlled server, bypassing
the encryption. Google gives the regime each version of the targeted apps as they
get released and postpones those releases
on the Play Store, under the guise of the app review process, so the regime can make
its changes to those apps. Google signs those altered apps ��� no different than if the
apps came from the original developers ��� and distributes those altered apps
to the designated victims.

You can supply your own values for the country and the minority group. There
are many options to choose from.

App Signing, and your upcoming moves to make it mandatory for new apps,
opens you up to this sort of coercion. Right now, you have ���plausible deniability��� ���
you can claim that certain apps simply did not opt into App Signing. Your new
requirement removes that defense for new apps after your chosen date for that
requirement. If you eventually force all developers to opt into App Signing, then
this form of coercion seems inevitable.

Project Dragonfly,
is a depressing demonstration of executive intent.
However, there seemed to be some internal push-back within your firm to
Project Dragonfly, at least among engineers.

I am hopeful that those of you who are being forced to implement this new policy have a
plan for how to block this sort of coercion or otherwise prevent
my scenario from playing out. It would be good if we knew what that plan was, as it
is much easier for us to help with plans that way.

So��� what���s the plan?

Right now, publicly, the plan appears to be to claim that this just will not happen.

For example, in a Medium post
about app signing, a Google developer advocate wrote:

we don���t modify and distribute your application code without your knowledge and approval

and:

As stated before, Play will not modify the functionality of your application without your knowledge and approval.

Notably, this person used ���don���t��� and ���will not������ as opposed to ���can���t��� and ���cannot���.

However, you readily admit that you modify the app from what we give you as the
App Bundle. For example, that same Medium post includes:

For apps uploaded as app bundles, we will improve this security by introducing what is called a source stamp. This source metadata is inserted into the app���s manifest by bundletool.

That sort of metadata change apparently has been going on for a couple of years.

Besides, Amazon has been doing this sort of thing for the better part of 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.

You admit that you can do the same sort of re-signing for apps distributed via App Signing, even those shipped as APKs:

Google verifies and strips your signature from the APK, and then resigns the APK with the app signing key

So, it seems like ���don���t��� instead of ���can���t��� represents a policy of forbearance.
You appear to be capable of doing much more, but you are deciding not to do so at the present time.

However, policies can change, at any time, for any reason, without warning. Or,
as some guy in a dark helmet once said:

I am altering the deal. Pray I don���t alter it any further.

So, one possible plan is for you to have teeth behind the ���don���t modify and distribute your application code without your knowledge and approval���
claim.

So:

Is your claim that modifying the code is impossible? It seems like it is possible,
but perhaps I am missing something. I would love to see a technical explanation
of how you would be unable to change the bytecode or resource content prior to signing
the APKs.

Are you pursuing legislation to ban this practice? Perhaps you
are working with lawmakers in major countries to ban this sort of behavior,
with suitable penalties for firms (and their executives) that participate in it.
That might cover more than just app modifications ��� it might also ban
modifications made to Web content in transit by ISPs, such as the various
���super-cookie��� sorts of changes that crop up from time to time. If this is your
plan, it would be nice if a wide range of participants, including those from
organizations advocating for civil liberties, would be involved.

Perhaps the plan is that you really will not require App Signing for App Bundles.
After all, just because one of your staff members said that
App Bundles require App Signing
does not mean that this requirement will hold indefinitely. Perhaps it will
be relaxed before the App Bundle mandate comes into play. Or, perhaps the
App Bundle mandate itself might be relaxed.

After all, App Bundles are not a technical requirement. We have been distributing
APKs for over a decade, and in that time,
the dead have not risen,
kaiju have not laid waste to major cities,
and aliens have not invaded.

(then again, it is 2020���)

Also, App Bundles would not appear to be necessary to achieve your technical objectives. Your
goal is to deliver the right subsets of an app to a device based on device characteristics.
To do that, you generate a sliced-up app out of an App Bundle and deliver a
few APKs that, when combined, implement the app without extraneous resources and
stuff. We know this because bundletool lets us generate those APKs, and we can
even install those APKs ourselves to demonstrate that they work. bundletool will
even sign them with our signing key.

That means that we do not need to send you an App Bundle for you get
the benefits of one. We could send you the signed APKs created by bundletool instead. For
example, we could ZIP those up into an ���App Assortment��� and upload that to the developer
console instead of the App Bundle. You appear to get everything that you need to achieve
your technical objectives, just without the ability to sign. Instead, we sign
the APKs, just as we do today, albeit perhaps via bundletool.

This is not to say that you should stop offering App Signing, just that it should
be a choice, as it has been since you introduced it.

Perhaps something along these lines is how you intend to avoid coercion ��� you
can claim that any app that regimes want to alter is still being signed by the app���s
developers, not you. So:

Will you extend App Bundles to allow for developer-signed artifacts and no App Signing?
This seems to be fairly trivial, given the existing capabilities of bundletool.
But, if there is some reason why bundletool output that seems to work does not
actually work��� that would be good to know, with adequate details, of course.

Will you rescind the App Bundle requirement, and allow for developer-signed APKs indefinitely?
After all, you are the one announcing that App Bundles are going to be required.
You can change your mind on that.

Perhaps you can modify apps prior to signing, and the reason
that you are requiring signing authority is because you think that you might
want to modify apps in the future, even though you claim that you are not
doing so right now.

Maybe your plan is that we would detect any nefarious modifications, should
you ship some.

If so, I would be interested to know how you would like us to go about doing that.

Technically, the regime-hack scenario could happen today, even with developer-signed APKs. However,
in that case, you cannot sign the altered app versions. So, developers who monitor the signing
keys used for their apps would be able to detect the fact that you are distributing
an altered app. Plus, the risk would be limited to new installs of the app ���
any user with an existing app installation with the developer���s signed app would refuse
to install the altered app, as the signing keys would not match. Admittedly, we could
do a lot more here to monitor for this sort of attack, but we get a lot of protections
���for free���, just from having developers sign the apps. And a regime has a much more
difficult time coercing an app developer, because that developer does not distribute
the app, so everybody has to get the alterations, making them more likely to be discovered.

But, with App Signing, we cannot just check an app���s signature. The signature will be valid; the
contents of the APKs are what is in question, because you can modify them based on
the demands applied via the coercion.

Perhaps you are counting on the new App Bundle explorer:

You can download and attest the exact APKs that Play generates for delivery

The problem is that we have no way to know if these are the actual APKs that
Play will distribute. After all, you are perfectly capable of distributing one
set of APKs through the explorer and another to Android device owners.

Perhaps your vision is that we would use hashes or something to confirm that
the APKs delivered to people match those from the explorer. The implication is that
it would be up to us developers to:

Confirm that the explorer APKs match bundletool output, as we can see
what bundletool does and confirm that it is not doing anything malicious; then

Publish hashes of the bundletool/explorer output in such a way that security apps (and perhaps our own apps) could validate that
the installed APKs are valid; and

Ensure that those hashes themselves are not able to be modified by some attacker

That is not out of the question. However, it is a fair bit of infrastructure.

More importantly, though, it gets back to the root concern outlined in section
of this letter: if your plan is that you want to modify the apps,
then presumably someday you will do just that. So now we���re in a situation
where bundletool output intentionally does not match what you are shipping to people.
Detecting changes would be insufficient ��� we would need to determine (somehow)
whether those changes are malicious or not, and do this on a massive scale (one
that precludes manual inspection).

So, how are you expecting us to ���attest��� these APKs, for real? What is the process by
which you are expecting us to confirm that, while you have made changes to the APKs,
that those changes are beneficial and not harmful? And how do you expect us to do
this for everyone who is using the app, given that you could modify the app for
some people and not for others?

When App Signing came out, I was concerned for the reasons that I outlined in this
letter. However, it was opt-in, and so while I would quietly steer developers
away from it, that is all that I did. Now that you are making it mandatory for
some apps ��� and appear have the ability to make it mandatory for all in the
future ���
I think that it is time that we figure out how to minimize the risk to the ~2.5
billion Android device owners.

So��� what���s the plan?

Sincerely Yours,

Mark Murphy (a Commons Guy)