The CommonsBlog

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

—Oct 28, 2020

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.

—Oct 24, 2020

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.

—Oct 14, 2020

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.

—Oct 10, 2020

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.

—Oct 05, 2020