Maps Sans Play Services

One of the bigger reasons why developers depend upon Google Play Services is for MapsV2, the native Android mapping engine. Lots of developers are comfortable with just implementing MapsV2, on the grounds that most Android devices are part of the Google Play ecosystem and therefore can use MapsV2.

This, of course, makes manufacturers outside the Play ecosystem sad.

Some of those manufacturers have elected to provide their own mapping solution. Amazon, for example, offers maps with an API that is very similar to MapsV1 (the old API) and MapsV2. However, this still requires developers to code to these distinct APIs, perhaps employing product flavors in Android Studio and Gradle for Android to isolate the ecosystem-specific code bits. After all, Amazon’s maps only work on Amazon hardware, so you still need something that can work elsewhere.

One way to try to deal with this is to use a compatibility layer. Airbnb went down this road, and last week they released AirMapView based on their work.

AirMapView is designed to give you a map, regardless of the device that you are running on. It tries MapsV2 and falls back to maps powered by WebView and the Web edition of Google Maps. Airbnb indicates that support for Amazon’s mapping engine is forthcoming. I hope that somebody contributes an OpenStreetMap extension for it as well. And, they too offer an API that is close to MapsV2. If it works as advertised, you can get the best possible map for a given device, without constraining yourself to only devices that offer MapsV2.

The 1.1.2 AAR for AirMapView clocks in at ~100KB, so it will not grow your APK too much. AirMapView is definitely a project to keep track of, and to evaluate when it makes sense for your team. Having the ability to support non-Play devices may prove important to you in the long run. Anything you can do to isolate the Play-specific code and have options for replacing it would be good, all else being equal.

Mar 30, 2015

AlarmManager Regression in Android 5.1

Manny Karyampudi pointed out to me a problem with some of my book samples, that turned out to indicate a regression in the behavior of AlarmManager on Android 5.1.

(book sample apps are useful canaries in the Android coal mine…)

Up through Android 5.0, the repeat interval for setRepeating() and setInexactRepeating() could be fairly low. Some of my book samples, like this one, go as low as 5000ms, mostly so developers can see the results without waiting too long. In the book itself, I point out that frequent polling will be bad for CPU usage, battery life, etc.

In Android 4.4, they made setRepeating() inexact, but only if your targetSdkVersion is 19 or higher. My samples have a targetSdkVersion below this, once again so developers can see the results in an expected fashion. Using inexact alarms, so AlarmManager events can be batched, is very useful for battery life. However, for development purposes, they are aggravating, in part because we have no idea when the alarms will go off.

In Android 5.1, they appear to have set a limit, where low polling periods are rounded up to 60000ms (one minute). Repeat intervals higher than 60000ms are left alone. This shows up in the adb shell dumpsys alarm output as well as in the actual results when running the code. This affects setRepeating() at minimum, and it appears to affect apps with any targetSdkVersion.

As a user, I don’t mind this, as it means that I should get better battery life, in the face of apps that are too aggressive with their use of AlarmManager. As a developer, I know that I should not be using AlarmManager for anything rapid-fire like that, in part because I should not be trying to do frequent work in the background, and frequent work in the UI layer is better handled by postDelayed() loops instead.

However, also as a developer, I am once again dismayed to see that there has been a fundamental change to a key piece of Android that went unannounced and undocumented. I am hoping that Google will publish something to the Android Developers Blog that explains what is going on.

Many thanks to Mr. Karyampudi for pointing out this change in behavior!

Mar 23, 2015

Developer Trust, and the XCode Hack

As many of you may already be aware, a report was published early Tuesday morning, indicating that the CIA has created a “whacked” version of XCode — Apple’s IDE and development toolchain — that can leak developer private information or inject malware into apps created with the altered IDE.

While that particular report does not get into Android, I feel fairly confident that Android developers are wide open for targeted attacks via development tools and development processes. And these attacks may not require CIA-level “dark arts”, but would be more within reach of other nations or organized groups. Some of those attackers will be less interested in affecting our apps and more interested in peering inside our office networks.

We need to do a better job, overall, of making sure that developers can trust the tools that they use. We need to trust that the tools were not written with malicious intent in the first place. We need to trust that what we download and use is really what was published by the tools’ authors, not some “whacked” version. And we need to trust that the various services that we use, from ad networks to distribution channels, are not having similar impacts.

Personally, I need to climb the learning curve on OpenPGP signing of Maven artifacts, both to sign my CWAC libraries and to advise developers on how they can be validating artifact signatures as part of the build process. I am hoping that, in the coming days and weeks, the publishers of the major tools and ecosystems that we as Android developers use will explain to us what is being done to help prevent, or at least detect, XCode-style attacks.

Mar 12, 2015

Random Musings on the Android 5.1 SDK

With each Android SDK release, Google issues an API differences report, outlining things that were added, changed, or removed in a new API level compared to the previous one. Android 5.1 is no exception, with its differences report available for analysis.

I always review this to see what’s different beyond the sorts of changes that get more disclosure.

Android 5.1 is tiny, in terms of updates. In fact, most of the API changes stem from one thing: making HttpClient officially deprecated. If you need to continue using the HttpClient API, consider switching to OkHttp and their HttpClient compatibility layer, or consider switching to Apache’s separate Android edition of HttpClient. Otherwise, switch to HttpURLConnection or OkHttp’s native API.

Beyond that, here are a few other tidbits that I found interesting:

  • The official multi-SIM support will be welcome, as that is a popular line of inquiry on Stack Overflow, given the prevalence of multi-SIM devices in various parts of the world.

  • One of my issues with Android itself was addressed, as boolean support was moved from Bundle to BaseBundle, making them available to PersistableBundle. Many thanks to whoever did that!

  • A new version of createChooser() on Intent was added, providing a hook to find out what the user chose in the chooser. This has been a popular question out on Stack Overflow.

  • Activity now has a getReferrer() method that will return a Uri identifying what app or Web page started this activity. Bear in mind that this may still return null, and the value can be spoofed, so do not rely upon this, particularly for any sort of security stuff.

  • We have a couple of new Settings action strings, to try to launch the battery-saver mode settings and the notification listener settings.

As I said, Android 5.1 is pretty small overall. That being said, these are generally welcome changes. And, I don’t have to race to push a book update out the door, which is always nice. :-)

Mar 10, 2015

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

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

This update is dominated by a rather large chapter on RecyclerView. It covers how to get back all of the stuff that RecyclerView lost from ListView and GridView, plus some things that RecyclerView can do that its predecessors cannot. Basically, it covers the RecyclerView equivalents of pretty much everything the book has on ListView and GridView, including how to support choice modes (e.g., checklists, activated states) and action modes. It also demonstrates CardView along the way.

In addition, there is a new chapter on Parcelable (what it is, how to make your own classes Parcelable, and Parcelable problems) and various other minor improvements.

The next update is tentatively scheduled for the second half of April.

Mar 02, 2015

Older Posts