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
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
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
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
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
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
AlarmManager. As a developer, I know that I should not be
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
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
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,
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
making them available to
PersistableBundle. Many thanks to whoever did that!
A new version of
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
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
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
It covers how to get back all of the stuff that
GridView, plus some things that
can do that its predecessors cannot. Basically, it covers the
RecyclerView equivalents of pretty much everything the book has
GridView, including how to support choice modes
(e.g., checklists, activated states) and action modes. It also
CardView along the way.
In addition, there is a new chapter on
Parcelable (what it is,
how to make your own classes
problems) and various other minor improvements.
The next update is tentatively scheduled for the second half of April.
—Mar 02, 2015