The CommonsBlog

DevFest DC

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 dangerous 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

Hey, Where Did My Permission Go?

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 encountering SecurityExceptions or other symptoms that suggest that you do not actually hold the permission that you asked for, there are a few possible culprits.

You Have the Element in the Wrong Place

The <uses-permission> elements should be inside the <manifest> element, but outside the <application> element. In other words, this is fine:

<?xml version="1.0" encoding="utf-8"?>

  <uses-permission android:name="INTERNET"/>
  <uses-permission android:name="ACCESS_NETWORK_STATE"/>


    <!-- cool stuff goes here -->



but this is not:

<?xml version="1.0" encoding="utf-8"?>


    <uses-permission android:name="INTERNET"/>
    <uses-permission android:name="ACCESS_NETWORK_STATE"/>

    <!-- 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 wrong spot.

You Cannot Hold That Permission

Some permissions that used to be in the Android SDK, such as BRICK, 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 /system 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 <uses-permission> element 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 checkSelfPermission() and requestPermissions().

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

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

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 Toolbar widget, plus a corresponding section in the appcompat-v7 chapter on the Toolbar backport

  • I have also added a new chapter on the Design Support library and its alternatives for Material Design elements: FABs, snackbars, and TabLayout. Other 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 the android.hardware.Camera API. I have updated those chapters with an eye towards the Android 5.0+ android.hardware.camera2 API.

  • 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 AlarmManager and 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 AlarmManager and NotificationManager. The former Tutorial #19 is the new Tutorial #17.

  • 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 book update.

Aug 25, 2015

Android 6.0 Runtime Permissions Code Labs

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 Virginia.

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

Random Musings on the Android 6.0 SDK

Each time Google releases a new SDK platform, I rummage through the API differences report, the new Build.VERSION_CODES entry, 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 in June:

  • 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 REQUEST_INSTALL_PACKAGE permission. 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 PendingIntent scenarios.

  • Several interesting new Settings screens are now accessible via Settings action strings. One that will get a lot of attention is ACTION_MANAGE_WRITE_SETTINGS, where users can indicate whether apps can write to system settings or not. If your app requests the WRITE_SETTINGS permission, you may appear on this list, and you can call canWrite() on Settings.System to see if you were granted permission. 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 to the SYSTEM_ALERT_WINDOW permission (akin to the WRITE_SETTINGS scenario above), though if that is the case, it is not documented that I can see. UPDATE: An eagle-eyed developer noticed canDrawOverlays() in Settings, and so the SYSTEM_ALERT_WINDOW flow is akin to the WRITE_SETTINGS flow.

  • Two other 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. ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS leads to the Settings screen where users can generally toggle on and off who is on the whitelist, and ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 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 PowerManager. isDeviceIdleMode() 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 (ACTION_DEVICE_IDLE_MODE_CHANGED) will 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 package, and the onProvideAssistData() method on Activity.

  • BatteryManager now defines broadcast action strings for ACTION_CHARGING and 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 isCharging() method to determine if the battery is charging or not.

  • As part of the overhaul of the permission system, the concept of system or signature|system permissions are deprecated. Instead, we have a bunch of new protectionLevel flags that I am sure that a lot of folks who root devices will be experimenting with soonish.

  • 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) is telling.

  • 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. detectResourceMismatches() 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:breakStrategy and 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 strategy for EditText is simple.

  • WebView now offers support for HTML5 “MessageEvent” interfaces, by means of classes like WebMessage and methods like createWebMessageChannel() and postWebMessage() on WebView.

  • Of interest to analytics folks is the new requestUsageTimeReport() method on ActivityOptions. This allows you to register a PendingIntent 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 ACTION_CAPTIVE_PORTAL_SIGN_IN, designed for apps to help users sign in (saved credentials, perhaps?). There is a CaptivePortal class 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 a beefed-up TelecomManager. Plus, the 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 getSystemService().

  • MODE_MULTI_PROCESS was deprecated. This was a mode flag used for opening SharedPreferences to allow multiple proceses to read and write those SharedPreferences simultaneously. Mostly, this was to support having components run in separate processes via the android:process attribute. Sharing 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 process.

  • We now have official support for round screens (see isScreenRound() in Configuration). Presumably, this is for Android Wear. Either that, or the Motorola Aura is making a comeback.

  • Curiously, the 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

Older Posts