I will be presenting at
DevFest DC. This is a two-day event,
held September 11-12 at AOL’s headquarters near Dulles Airport
in the Greater Hey Look At All the Monuments! Metropolitan Area.
The morning of Saturday the 12th, I will be:
Delivering a 45-minute presentation, recapping the major stuff in
Android 6.0 that you should be thinking about
Leading an updated edition of the Android 6.0 runtime permissions
code lab that I held at droidcon NYC last week, where we will see
(LIVE!) how to take an existing app and start asking for
permissions at runtime and dealing with cases where we do not have them.
This is an inexpensive event, though
this discount code
makes it more inexpensive. Less expensive. Whatever.
If you are interested in attending the code lab, not only should
you register for the event using that discount code, but you should
also fill in this Google form. This
is to gauge interest in the various code labs, so they can put the
right lab in the right room at AOL. Filling in that form is not
essential, though it would help the organizers. And the organizers
are good people, so helping them would be nice.
If you live in the DC area, or DC is in your travel plans for the
12th, I’d love to see you there!
—Sep 01, 2015
Some developers wonder
where extra permissions in their app come from.
Other developers wonder why they are not getting the permissions that they
are asking for. If you have a
<uses-permission> element, and you are
SecurityExceptions or other symptoms that suggest that you
do not actually hold the permission that you asked for, there are a few
You Have the Element in the Wrong Place
<uses-permission> elements should be inside the
element, but outside the
<application> element. In other words, this
<?xml version="1.0" encoding="utf-8"?>
<!-- cool stuff goes here -->
but this is not:
<?xml version="1.0" encoding="utf-8"?>
<!-- cool stuff goes here -->
While Android Studio will report this if you manually analyze your
manifest (Analyze > Inspect Code… from the main menu), it will not
automatically show a warning just by having the elements in the
You Cannot Hold That Permission
Some permissions that used to be in the Android SDK, such as
cannot be held by ordinary Android applications. They usually
require your app to be signed by the signing key that signed the
device firmware (i.e., be part of a custom ROM). Some might alternatively
allow your app to hold the permission if your app is installed on the
partition (i.e., be part of a custom ROM or have been moved there by
a rooted device user).
However, you are not told at build time that the
you have in your manifest
is tied to a permission that you are unlikely to be able to hold.
Your targetSdkVersion Is 23 or Higher
The big reason for not getting your permission nowadays is because
your project has a
targetSdkVersion of 23 or higher, and the permission
that you are requesting is “dangerous”. In Android 6.0, this includes:
For these permissions, not only does your
targetSdkVersion 23+ app
need to have the
<uses-permission> element(s), but you also have
to ask for those permissions at runtime from the user on Android 6.0+
devices, using methods like
As a temporary workaround, drop your
targetSdkVersion below 23.
However, eventually, you will have some reason to want your
targetSdkVersion to be 23 or higher. At that time, you will need
to adjust your app to use the new runtime permission system.
The Android 6.0 preview documentation has
a page dedicated to this topic,
and my book has a lot of material on how to make this work
in your app.
—Aug 31, 2015
Subscribers now have
access to the latest release of The Busy Coder’s Guide to Android Development,
known as Version 6.8, in all formats. Just log into
your Warescription page and download
away, or set up an account and subscribe!
First, here is what has been added:
Version 6.7 added an appendix on the M Developer Preview. Version
6.8 updates that for Android 6.0. Some of the material that had been
in the appendix has moved to more permanent homes, with links to
that material from the appendix.
I have added a standalone tutorial, independent from the EmPubLite
series, for upgrading an app to use the new Android 6.0 runtime
permission model. Given a starting app that uses the camera to take
pictures and record videos, the tutorial will help you progressively
add the logic to that app to handle requesting runtime permissions,
both up-front and on-demand. I will be going through this tutorial
live at droidcon NYC 2015 and DC DevFest 2015.
Android Studio 1.3 was released since the last book update,
so this update tweaks the book, particularly Tutorial #1 and
Tutorial #2, for Android Studio 1.3.
I have added a new chapter on the Android 5.0+ native
plus a corresponding section
appcompat-v7 chapter on the
I have also added a new chapter on the Design Support library and its alternatives
for Material Design elements: FABs, snackbars, and
elements of the Design Support library will be added to this chapter
in future book updates.
The book has had two chapters devoted to the camera for a while:
how to use third-party code to work with the camera and how to use
android.hardware.Camera API. I have updated those chapters with
an eye towards the Android 5.0+
I split the original chapter on
SharedPreferences into two, adding
an advanced preferences chapter to the trails. A lot of additional material
was added to these chapters, including dependent preferences, nested
preference screens, etc.
I added a sample of using OkHttp’s native API, which for many people
will be an easier alternative to
HttpUrlConnection as an escape route
from the deprecated-and-removed HttpClient API.
Various other chapters were updated, such as the chapter on SQLCipher,
along with the typical roster of errata fixes.
Now, here are the other changes:
The chapters on
NotificationManager were moved
into the trails. Courtesy of Google’s “war on background processing”,
any sort of background operation is definitely an advanced topic.
Similarly, I removed what had been Tutorial #17 and Tutorial #18
from the EmPubLite series, as they covered
NotificationManager. The former Tutorial #19 is the new
I have removed the Eclipse instructions from the tutorials, as the
first pulse in a gradual de-Eclipse-ification of the book.
For some reason, changebars are showing up on a lot of the code listings,
despite the fact that I did not change the code for those samples. I
apologize for the additional noise in the change reporting.
Version 6.9 should be released in the latter half of October 2015, barring
something huge happening in the world of Android requiring a faster
—Aug 25, 2015
At droidcon NYC, happening at an NYC
near you on August 27-28, Larry Schiefer will be delivering a
presentation, “Android, May I?”,
covering the new Android 6.0 runtime permission system. His
presentation is slated for Friday (August 28th) at 10:10am.
While augmented reality, annotation processors, and typography are
all fine topics in that same time slot, everybody at droidcon NYC
should be attending Larry’s presentation.
Later that day, I am scheduled to run a code lab at droidcon NYC,
where we will put the runtime permission system through its paces.
Come armed with your Android 6.0-equipped developer notebook
(and maybe an Android 6.0-flashed mobile device), and you’ll be able
to update an existing app to ask for runtime permissions as
needed: on first run and if the user asks to do something for which
we do not have permission yet.
For those of you who are more of the Washington inclination, I will be
reprising the code lab at DevFest DC,
though the exact schedule is (ahem) not yet published. I believe
the lab will be on Saturday, September 12th.
At DevFest DC, I am also delivering a presentation on
what’s new in Android 6.0, covering the runtime permissions, the war
on background processing, and other bits of goodness (and not-so-goodness)
(and downright bad-ness) (but with a marshmallow filling) (and parentheses!)
coming our way.
DevFest DC is September 11-12, at the AOL headquarters in Northern
If you are unable to attend either event:
Ask the organizers of your favorite Android developer meetup/GDG/etc.
to see if
I can do something for your group.
That might even be live if you are in the eastern PA/north-central NJ/NYC area.
Otherwise, we can look into some sort of webinar.
The code lab itself will be backed by a standalone tutorial being
added to the next version of The Busy Coder’s Guide to Android Development,
due out… um… before I have to deliver the code lab. So, early next
week. Right now, I’m digging out from under a large marshmallow that landed on
my writing plans.
—Aug 19, 2015
Each time Google releases a new SDK platform, I rummage through
the API differences report,
and the high-level overviews (which are missing at the moment),
to see if there are things that warrant more attention from
developers, with an emphasis on mainstream features that any developer
might reasonably use.
Android 6.0 extends what we had in the M Developer Preview. A quick
scan indicates that most of my interests and concerns from the original
M Developer Preview SDK are still there, so I recommend that you start
by reviewing my original four(!) posts:
Beyond those, here are some things that I noted in the Android 6.0 SDK
that either were not in the M Developer Preview or I glossed over back
A whole mass of permissions and permission groups were removed,
not merely marked as deprecated. This should not affect your manifests,
but if you were referring to the symbols in Java code, you’ll have to
implement some workarounds. More importantly, any apps that use any
of the removed permissions will need to determine what the right
course of action is to be able to go forward with Android 6.0. The roster
of removed permissions includes:
If you have been using
ACTION_INSTALL_PACKAGE to ask the installer
to install an app, and your
targetSdkVersion is 22 or higher,
you now must hold the
It is unclear if “22 or higher” is a typo or if this really was
a requirement for Android 5.1 that perhaps was itself undocumented.
PendingIntent now has a
FLAG_IMMUTABLE option. This indicates
that you do not want the extras in the underlying
Intent to be
modified by anyone invoking this
PendingIntent. I can see this
being very useful, from a security standpoint, in many
Several interesting new Settings screens are now accessible via
Settings action strings. One that will get a lot of attention
ACTION_MANAGE_WRITE_SETTINGS, where users can indicate whether
apps can write to system settings or not. If your app requests
WRITE_SETTINGS permission, you may appear on this list, and
you can call
Settings.System to see if you were
There is also
ACTION_MANAGE_OVERLAY_PERMISSION, where users can control
which apps can “draw over other apps” (chatheads?). It is unclear
how apps get on this list — I would have expected it to be tied
SYSTEM_ALERT_WINDOW permission (akin to the
scenario above), though if that is the case, it is not documented that
I can see. UPDATE: An
Settings, and so the
SYSTEM_ALERT_WINDOW flow is akin to the
Settings actions pertain to “app standby” and the whitelist
whereby users can grant your app the right to continue running normally
even if you have not been used for a while.
leads to the Settings screen where users can generally toggle on and off
who is on the whitelist, and
for apps to beg to be put on the whitelist. Note, though, that to use
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, you have to hold the
REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission, though at present
this is a
normal permission and should be granted.
Also related to the above are some methods on
indicates if the device has not been used in a while, indicating that
we might drop into Doze mode soon, and apps in “app standby” status may
also stop running. A broadcast (
go out when this status changes.
isIgnoringBatteryOptimizations() will tell you if
the user has indeed put you on the “app standby” whitelist.
The “App Assist” stuff that powers “Now on Tap” has a modest amount
of documentation, stemming from the new
onProvideAssistData() method on
now defines broadcast action strings for
ACTION_DISCHARGING. No word on whether these
can be registered for in the manifest (as opposed to
ACTION_BATTERY_CHANGED), though presumably they can, as that status
should not flip too frequently. There is also a simplified
method to determine if the battery is charging or not.
As part of the overhaul of the permission system, the concept of
signature|system permissions are deprecated. Instead,
we have a bunch of new
that I am sure that a lot of folks who root devices will be experimenting
Pretty much the whole
Browser provider has been removed. This, at least
in theory, would allow you to access bookmarks and such from a browser.
Other than the original AOSP Browser app, I am not aware of other browsers
actually supporting this, and the fact that it is removed (not deprecated)
StrictMode now supports
detectResourceMismatches(). It is designed
to catch places where the resource system would do conversions for you that
you could avoid. The cited example is having an resource that you
retrieve via a call to
getInt() on a
Resources object. While this
works, it would be more efficient to have an int resource.
will report these to you. I am rather surprised that the instrumentation
for this does not swamp the performance savings from doing the conversion,
but, hey, they didn’t ask me…
TextView now offers greater controls over the line-break strategy
and hyphenation, via XML attributes (
android:hyphenationFrequency) and corresponding accessors.
Line-break strategies are: simple, high-quality, balanced, where
“high-quality” is the only one that cites using hyphenation.
Hyphenation strategies are: none, less-frequent, and standard.
The default strategy for
TextView is high-quality, while the default
EditText is simple.
WebView now offers support for HTML5 “MessageEvent” interfaces, by
means of classes like
WebMessage and methods like
Of interest to analytics folks is the new
ActivityOptions. This allows you to register a
that, when invoked, will hand you a couple of extras containing information
about how long the user used the app that you are launching.
There are now hooks for dealing with “captive portals”, those aggravating
interstitial pages that you encounter when you have to request access
to a network at a hotel, coffee shop, etc. For example,
ConnectivityManager has an activity action named
designed for apps to help users sign in (saved credentials, perhaps?).
There is a
that comes along for the ride.
There are now hooks for apps to be able to request that users
replace the dialer (presumably with their app), plus configure and switch
to different phone accounts, as part of
android.telecom package got substantially expanded, with hooks
to all sorts of new capabilities through the
TelecomManager. We have
new classes regarding calls, conferences, gateways, phone accounts, and so forth.
We finally get a type-safe implementation of
MODE_MULTI_PROCESS was deprecated. This was a mode flag used for
SharedPreferences to allow multiple proceses to read and write
SharedPreferences simultaneously. Mostly, this was to support
having components run in separate processes via the
SharedPreferences between processes was always
described as unreliable, and they are making that more official now by
getting rid of support for it. As the documentation suggests, please use
a real IPC API (broadcasts,
ContentProvider, etc.) for communication
between multiple processes that represent your app. Or, stick to a single
We now have official support for round screens (see
Presumably, this is for Android Wear. Either that, or
the Motorola Aura is making a comeback.
Build.VERSION_CODES value is still
M. It is unclear
if this is a mistake (and
MARSHMALLOW will show up later) or whether
the new convention is to stick with the single-letter values. It also
contains no significant JavaDocs, which is rather surprising considering
that Android 6.0 is a major version update.
—Aug 17, 2015