The CommonsBlog


Random Musings on the O Developer Preview 1

Each time Google releases a new developer preview, I rummage through the API differences report and the high-level overviews, to see if there are things that warrant more attention from developers, with an emphasis on mainstream features that any developer might reasonably use. I also tend to emphasize things that may not get quite as much attention, because they are buried in the JavaDocs.

As with the N Developer Preview, there is quite a bit to the O Developer Preview that lies “under the surface”, below what you will find as talking points in media coverage. On the other hand, whereas N had multi-window, O seems to be lacking a user-facing “big-ticket” feature. My guess is that we will get something more in O at Google I|O and as part of the O Developer Preview 2.

First, though: many thanks to whoever decided to publish the O Developer Preview JavaDocs live, rather than through a ZIP file download. Linking to the documentation is hugely useful.

What Scares Me

Clearly, the biggest trouble area will be with the next phase in “the war on background processing”. I expect many apps to keep their targetSdkVersion low as a result, since many of the changes only affect those apps that embrace the new API level. I also expect many more apps to just make all their services be foreground services. Blocking the receipt of implicit Intent broadcasts will just add to the “Android is unreliable” complaints, as users used to apps responding in real time to environment changes (e.g., toggling airplane mode) will now find their apps lagging by seconds, minutes, or perhaps longer, waiting for some background job to decide to run.

I am nervous about the multi-display support. This appears to allow users to “throw” an activity onto an external display. In principle, this sounds neat. However, I do not know if any O preview-capable hardware can support external displays — HDMI seems out, and I don’t know if any even support Miracast. We need to be able to test this behavior, to see what it means for one of our activities to be shown on a non-touchscreen display. Plus, apps that are using Presentation or related techniques for handling multiple displays already need to know how O’s multi-display changes affect their existing app behavior.

There are now disk space quotas, presently imposed solely on cache directories. That does not scare me much, though developers using cache directories should ensure that they are testing that thoroughly (e.g., what happens if only part of the cache is cleared, or if the cache is cleared while your process is running?). I am more concerned over the possibility of Android P or Q imposing disk space quotas more broadly. As a user, this is fine; as a developer, this is the sort of thing that should have been added years ago, and who knows what impact such quotas will have on our apps?

And, while personally the move to support only API Level 14+ with the Android Support Libraries does not bother me, I worry about the splits that this and the similar Play Services SDK limitation will cause in the developer community. In many countries, Android 2.x are niche devices. In many countries, Android 2.x remains relevant.

What Intrigues Me

You can now set a Notification to automatically time out at a certain time This seems very useful, though it will be interesting to see if they handle all the edge cases. For example, suppose you create a foreground service, but set the Notification to time out after a minute. Do you remain at foreground priority?

I hope that a bunch of apps using floating windows to show random stuff will switch to the new picture-in-picture support.

I wonder to what extent we can create a quasi-backport of the new font resources. We cannot invent a new resource type for older devices, but we might be able to alias fonts to point to raw resources, which could be used on older devices.

We finally get support for seekable streams backed by things other than files, courtesy of ProxyFileDescriptorCallback and openProxyFileDescriptor(). My guess is that this cannot be backported… but it would be seriously useful if it could.

The document APIs have a few interesting additions:

  • Providers can now offer to create “Web links” for documents, presumably with an eye towards cloud storage providers

  • You can convert a MediaStore Uri into an equivalent document Uri

  • Providers can advertise that they support a “settings” activity for some or all of their document Uri values, where clients can arrange to launch that activity for the user to do… something (rename the document?)

WebView will now honor the network security configuration allow-cleartext setting. With luck, Google will continue migrating WebView to support more of network security configuration.

As the Android Police pointed out, there is now an app-level grant of rights to be able to install and uninstall other apps. That’s a welcome acknowledgment from Google that there actually are ways to distribute apps that does not involve the Play Store.

IPC with providers got a boost. The paged queries feature got the attention, but there is also now a refresh() method to tell a provider to update the data associated with a Uri.

Just as Android 4.0 gave us ActivityLifecycleCallbacks, Android O gives us FragmentLifecycleCallbacks. This will be good for creating fragment management utility code without forcing everyone to have to extend specific Activity subclasses.

SmsManager can create “SMS tokens”. If this does what I think it does, it resolves an issue that arose in Android 4.4: implementing SMS-based authentication became a problem, because apps could not handle those messages automatically and avoid those messages going into the user’s inbox. SMS-based authentication has plenty of problems, as SMS is about as secure as a piece of tissue paper, but there are still plenty of people trying to use this.

SharedPreferences storage is now backed by a pluggable interface. This raises the possibility of having better secured preference storage options while still allowing normal SharedPreferences usage (notably the preference UI classes).

And, as Cyril Mottier pointed out, findViewById() now returns a typesafe value, for those still dealing with casts there (e.g., no data binding, no Butterknife).

What Else You Might Care About

Here are some other bits that might interest you:

However, in every Android release, there are casualties. Of note, ZoomButton zooms no more.

About the Book

Monday, I shipped Version 8.4 of my book.

Tuesday, Google shipped the O Developer Preview, possibly in response to some car maintenance.

As a result, it will be a few weeks before I can publish a Version 8.5 and dive into Android O in earnest. Look for an update in April.

Mar 22, 2017


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

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

This is a fairly small and sooner-than-expected update, mostly to revise everything for Android Studio 2.3. In addition to updating screenshots and descriptions for the new IDE version, I:

  • Added a chapter on Stetho

  • Added material on the Espresso Test Recorder to the chapter on Espresso

  • Updated the coverage of consuming documents with a new “diceware” sample and the use of the CWAC-Document library

  • Updated the chapter on RecyclerView to cover the new(-ish) built-in list divider option

  • Fixed a bug in the Sensor/Monitor sample app in the chapter on sensors

  • Added more material on working with removable storage to the chapter on files

  • Made various miscellaneous improvements and errata fixes

Readers of the APK edition of the book who were running into crashes from the new double-tap gesture to hide and show the action bar should have better luck now.

Also, the APK edition has an appinar on viewing PDF files in your Android app.

Alas, Google Play Books continues to not like my EPUB edition. That situation is unlikely to change any time soon, as I have no means of debugging the problem.

The next book update should be in late April or early May. As with this update, the next one is contingent on what Google might do over the next several weeks, such as release an O (Oh? Owe?!?) Developer Preview.

Mar 20, 2017


Google Play Books and My EPUBs

Google Play Books is not accepting the EPUB edition of Version 8.3 of my book… and I don’t know why. The workaround is to upload the PDF into Google Play Books, or to use another EPUB reader, or to use another book format in another reader.

I have tried to patient with whoever Google has for providing technical support for Google Play Books, but that process seems to be going in circles, with agents handling an open case telling me to go talk to the people that opened the case in the first place. “Passing the buck” is a time-honored tradition in technical support, but it does not solve many problems.

If anyone happens to have a contact person at Google Play Books that might be interested in determining why multiple, valid, error-free EPUBs would result in “This file cannot be processed” when uploaded into Google Play Books, let me know.

Otherwise, at some point, it is possible that Google Play Books will start working again, but I cannot predict when. My apologies to all who are affected by this.

Mar 01, 2017


Qualcomm, Trepn, and EULA Nonsense

Qualcomm’s Trepn Power Profiler — which helps to measure battery, CPU, and GPU performance of systems and apps — cannot be used by most developers. The tool may be fine. It end-user license agreement (EULA) is not.

In particular, section 2.3 (“Additional Restrictions”) states:

You will not: …use the Software and/or Documentation to create or develop any developer tools (including without limitation plug-ins and middleware) or any software other than end-user targeted computer vision software applications

This seems oddly specific. If you are writing a computer vision app, you can use Trepn. Otherwise, you cannot.

Except that another clause may prevent many developers from using it even for that purpose:

You shall not… incorporate, link, distribute or use any third party software or code in conjunction with… any software, products, documentation, content or other materials developed using the Software

From the standpoint of you as a developer, the Android Support library is “third party software or code” that you “link” to your code. If you use such a library, and you use Trepn (“the Software”), arguably you are in violation of the EULA.

This is par for the course for Qualcomm and Trepn. This tool has had EULA problems as long as I can remember.

Other bits of nonsense:

  • Saying that you cannot “commence any installation process” of Trepn if you do not agree to the EULA… for an app distributed by the Play Store, such that you can only read the EULA after having installed Trepn.

  • Bug reports are mandatory (“You agree to report to QTI all bugs you experience or encounter with the Software…”). There is no word on what caliber of bullets will be used by Qualcomm’s firing squad for developers neglecting to report a bug in Trepn.

  • A product that has been around for years, and is presently at version 6.2, “is a prerelease, beta or experimental version and is not at the level of performance and compatibility of a final product”. In related news, Qualcomm’s legal counsel really does not like the Oxford comma.

Suffice it to say, I have not agreed to this edition of the license agreement, as I am not developing computer vision applications.

Perhaps one of these days Qualcomm will have a EULA for Trepn that makes sense. Perhaps one of these days I will wake up with a full head of hair.

Feb 27, 2017


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

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

This is a fairly small update, in which I:

  • Added a chapter on Android Things

  • Fixed some flaws in the chapter on RxJava

  • Added material on using “transcript mode” to the chapter on advanced RecyclerView techniques

  • Revised the coverage of integrating Java and JavaScript in the chapter on advanced WebView techniques, including adding material on using WebMessage and WebMessagePort

  • Updated the chapter on the Design Support Library, showing how to use the CWAC-CrossPort edition of those widgets with Theme.Material, rather than using the Design Support Library and having to use appcompat-v7

  • Changed a bunch of sample apps to switch from using onPause() and onResume() to using onStop() and onStart(), to be friendlier to multi-window environments

  • Made various miscellaneous improvements and errata fixes

The next book update should be no later than early April. The timing depends in large part on if Google ships something significant (Android Studio 2.3? Android 7.2? O Developer Preview? Android for Datacenters?!? Google Knit?!?!?) that I need to cover quickly.

Feb 13, 2017


Older Posts