Mark L. Murphy's Blog, page 49

Developer Trust, Revisited

Six months ago, I wrote
a blog post
pointing to a report about the CIA using hacked versions of Xcode to distribute spyware.

Somebody apparently thought that was a cool concept, and
created XcodeGhost to trick developers into distributing malware with their apps.

As with my original post on the subject, just because this problem has
come to light with respect to Apple does not mean that somehow the
Android ecosystem is immune. Android���s mish-mash of ever-changing
tooling may help a bit (security by OMG), but the attack vectors used
for XcodeGhost are certainly available for Android as well.

We need:

More education and effort into ensuring that we are not using
corrupted tools, libraries, and the like

More education and effort into post-build analysis to see if our
APKs have what we think they have (and only what we want), including
more work into streamlining reproducible builds,
particularly with respect to open source projects

Fewer vendors intentionally messing with our APKs
and weakening our ability to confirm that our apps are not
corrupted by the distribution process

I���ll be trying to do some work in this space, but I am not an
Android toolsmith (yet). Responsibility here falls on purveyors of
the key pieces of our toolchain, such as Google and Gradleware.
If anyone working in this space would like to chat,
get in touch.

Welcoming @CommonsWare

I grabbed the @CommonsWare Twitter handle
a few years ago, mostly to prevent anyone else from squatting on it.
However, I was not using it for anything��� until now.

Follow @CommonsWare for:

Announcements of new posts on the CommonsBlog

Book release announcements (though I���ll also retweet these from
@commonsguy)

CWAC library release announcements

Possibly other announcement-y things in the future

As you might have guessed, I am using this account for announcements
related to CommonsWare itself.
The @commonsguy Twitter account
is still in operation, of course, and some things will overlap,
like notices about book updates.

Book Excerpt: Floating Action Mode and ACTION_PROCESS_TEXT

The following is an excerpt from Version 6.8 of
���The Busy Coder���s Guide to Android Development���:

On Android 6.0, if you highlight text, you will see a new floating action mode,
where cut, copy, and paste operations reside:

If you tap that overflow indicator on the action mode, a fly-out menu
will appear��� one that contains arbitrary apps, in addition to system-supplied
options:

In this case, the MNC ���API Demos��� app appears as an option. Choosing
it pops up an activity that has access to the highlighted text from the preceding activity:

Replacing the value in the field and clicking the button puts your replacement text in as a replacement for whatever you had highlighted.

The ���API Demos��� activity in question, that is receiving the text, supports ACTION_PROCESS_TEXT as the Intent action:

<intent-filter >
<action android:name="android.intent.action.PROCESS_TEXT"/>
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="text/plain" />
</intent-filter>

Note that this <intent-filter> also limits the MIME type to be
text/plain, though it is unclear if there are any other valid options
for that MIME type.

EXTRA_PROCESS_TEXT will hold some text, or EXTRA_PROCESS_TEXT_READONLY
will hold it if the text is read-only. The activity will be invoked via
startActivityForResult(). The result Intent can have its own
EXTRA_PROCESS_TEXT value, which will be the replacement text.

Saturday Office Hours

Starting on September 19th, I will be holding office hours chats for
subscribers roughly every other Saturday, in addition to the ~2 hours a
week during weekdays. This will help those people writing Android apps
as a hobby, or ���moonlighting���, or other cases where times on the weekend
will be preferable.

The Saturday sessions will rotate through the same three time slots
(9am, 4pm, 7:30pm US Eastern), though it works out that the first two
happen to both be at the 4pm slot.

Subscribers will find these chats on the calendar on the Warescription
site (https://wares.commonsware.com) ��� just click on the
���Office Hours��� entry in the nav bar at the top.

For those of you wondering what the fuss is all about, you might
want to check out the past six years of chat transcripts.
Basically, the chats are there to answer any Android app development
question that I can.

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!

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"?>
<manifest
package="com.commonsware.android.something.something"
xmlns:android="http://schemas.android.com/apk/res/an...

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

<application
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme">

<!-- cool stuff goes here -->

</application>

</manifest>

but this is not:

<?xml version="1.0" encoding="utf-8"?>
<manifest
package="com.commonsware.android.something.something"
xmlns:android="http://schemas.android.com/apk/res/an...

<application
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme">

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

<!-- cool stuff goes here -->

</application>

</manifest>

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:

ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
ADD_VOICEMAIL
BODY_SENSORS
CALL_PHONE
CAMERA
GET_ACCOUNTS
PROCESS_OUTGOING_CALLS
READ_CALENDAR
READ_CALL_LOG
READ_CELL_BROADCASTS
READ_CONTACTS
READ_EXTERNAL_STORAGE
READ_PHONE_STATE
READ_SMS
RECEIVE_MMS
RECEIVE_SMS
RECEIVE_WAP_PUSH
RECORD_AUDIO
SEND_SMS
USE_SIP
WRITE_CALENDAR
WRITE_CALL_LOG
WRITE_CONTACTS
WRITE_EXTERNAL_STORAGE

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.

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.

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.

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:

Random Musings on the M Developer Preview: The Good
Random Musings on the M Developer Preview: the Bad
Random Musings on the M Developer Preview: the Ugly (Part One)
Random Musings on the M Developer Preview: the Ugly (Part Two)

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:

ACCESS_MOCK_LOCATION

ACCESS_SURFACE_FLINGER

AUTHENTICATE_ACCOUNTS

BRICK

CLEAR_APP_USER_DATA

DEVICE_POWER

FORCE_BACK

GET_TOP_ACTIVITY_INFO

HARDWARE_TEST

INJECT_EVENTS

INTERNAL_SYSTEM_WINDOW

MANAGE_ACCOUNTS

MANAGE_APP_TOKENS

READ_HISTORY_BOOKMARKS

READ_PROFILE

READ_SOCIAL_STREAM

READ_USER_DICTIONARY

SET_ACTIVITY_WATCHER

SET_ORIENTATION

SET_POINTER_SPEED

SUBSCRIBED_FEEDS_READ

SUBSCRIBED_FEEDS_WRITE

USE_CREDENTIALS

WRITE_HISTORY_BOOKMARKS

WRITE_PROFILE

WRITE_SMS

WRITE_SOCIAL_STREAM

WRITE_USER_DICTIONARY

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.

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 android.app.assist 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.

Favoring Snackbars Over Security

Another day,
another report of Android security flaws.

In particular,
this flaw
makes for a fine demonstration of what I feel are Google���s messed-up priorities.

Here, we have an app that is not sanitizing its inputs. It has an activity
that accepts a URL via an Intent extra
and (apparently) blindly hands the URL to a
WebView. Net result: an attacker can access any file within that
app���s internal storage,
which is supposed to be private to the app.

Again: this is an app. It���s not part of the framework. Google publishes
this app on the Play Store.

This leads to some interesting questions:

Why is it that we have
tons of documentation about how Google wants GUIs to appear
and very little about how developers should secure their apps?
Are we to interpret this as meaning that Google values
snackbars
over security?

Why can���t we have a Project Schneier, focused on helping developers
to secure their apps? While I will agree that Project Butter (60fps
View-based UIs), Project Svelte (helping with Android One), and
Project Volta (battery and power consumption) are important, one would
hope that security would be right up there with them.

(note: no actual Schneiers were harmed in the creation of this blog post)

Even if Google has a Project Schneier in, say, Android O(MG), will
they actually use it? After all, Project Butter was a few years ago,
and StrictMode came out in 2010,
yet
the framework team apparently does not use StrictMode to test framework code.
Will it be 2020 before
Google would apply their own advice and tools to securing
their own stuff?

When will I see blog posts, videos, conference presentations,
and the like from the Android developer
relations group related to security?

And so on.

I���m not expecting a lot of movement from Google in this area, as I have
long ago given up worrying about what Google does. So I do what
I can to help with Android app security, and I applaud the work that
others do in that same area.

And then, I wait for the next in a series of shoes to fall.