Mark L. Murphy's Blog, page 60

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

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

This is a relatively modest release, with ~50 pages of new material.

Mostly, that new material is wrapping up the Gradle for Android coverage, with discussion of Gradle-based testing and advanced Gradle tips. I will be adding more to the Gradle material over time, but it will tend to be incremental, except if there are major advancements in the Gradle for Android plugin itself that warrant a new chapter.

This update also:

Updates the SMS coverage to better take into account the now-public APIs from Android 4.4

Adds more coverage to Maps V2, ContentProvider, WebView, and advanced notifications

Updates coverage of Android libraries, to cover greenrobot’s EventBus 2.2.0

Fixes lots of bugs

Version 5.6 should be out in ~6 weeks.

As always, if you have questions or concerns with your update, contact me.

New Subscriber Benefit: StackOverflow Bump

First, let me be the approximately 10,394th person to welcome you to 2014!

(note: this number may be significantly higher for you if you are reading this post in the archives)

(note #2: this number may be significantly lower for you if you are reading this in 2015 or beyond (and, BTW, how are the flying cars?))

I have rolled out some new stuff for subscribers out on the Warescription site, and I’ll be posting about those this week. The first new item is the StackOverflow Bump service.

StackOverflow has over 400,000 questions, many with answers, and new ones pour in daily. Your question could get lost in the shuffle, particularly if you get an early poor answer.

If you have an active Warescription, and you have posted an android question to StackOverflow that does not yet have an acceptable answer, you can paste in the URL to the question into a form on your Warescription page and ping me to take a peek at it.

The key, though, is making sure that the StackOverflow process itself is working, at least as well as it can. Hence, only certain android questions qualify:

The question must be at least 24 hours old, to allow the broader StackOverflow community a chance to handle the question.

If there are answers on the question, but you do not believe that those answers truly answer your question, you need to have posted comment(s) to that effect. In particular, point out where the answer departs from your expectations.

If there are questions posed to you in comments, seeking clarification on your question, you need to have replied to those, either by a follow-up comment, an edit to your question, or both.

The question cannot be closed or deleted, as I have no means of helping with those, anyway.

I will attempt to chime in on your question within a day or two of your submitting the Bump request. I may not be able to answer it, particularly if it is in areas outside my expertise (e.g., OpenGL). Hence, the Bump service is not a guarantee of an answer; it is, at most, a guarantee of getting my attention.

Note that you do not have to offer a StackOverflow bounty to qualify for my Bump service, though you may wish to consider offering a bounty to get more community attention, particularly if I am unable to help.

If you have any questions regarding this service, or run into problems with it, drop me a line.

Sanitize All The Extras!

Earlier this year, I blogged about not having an accidental API.

Google themselves were caught out for having an accidental API, in the form of App Ops. Originally, this was a simple accidental API, in that they exported an activity for app ops. However, they had a more subtle accidental API, now revealed to be a more general security flaw related to the use of Intent extras. For those of you, like me, who were wondering about the new isValidFragment() we had to implement on PreferenceActivity, it relates to this problem.

Tactically, do not export a PreferenceActivity.

Strategically:

Do not export activities unless you want third parties to invoke them

Make sure that your extras make sense, on all of your activities, as for exported activities, those extras are part of your API

PreferenceActivity supports extras to load specific PreferenceFragments into the activity. This is used heavily by the Settings app, to allow apps to drive straight into particular screens (actually fragments). Unfortunately, there was no logic in PreferenceActivity to ensure that only those fragments that were supposed to be externally reachable were loaded via these extras — hence, the addition of isValidFragment(). So, a properly-crafted Intent can open any exported PreferenceActivity and launch any PreferenceFragment from it, in the absence of such defenses.

Usually, this would not be a security risk on its own, but if the fragments are also looking at extras, to configure their own behavior, being able to reach any fragment means that some fragments that were written assuming they were only internally reachable might be at risk. The article I linked to above cites one example, related to changing the device’s lock screen PIN or pattern.

As a reminder, an activity is exported if either:

The <activity> has android:exported="true", or

The <activity> has an <intent-filter> and does not also have android:exported="false"

The latter approach is an anti-pattern, as it can cause confusion with choosers, since non-exported activities will appear in a chooser if the activities match on the <intent-filter>. Generally speaking, only have activities with an <intent-filter> if they actually are to be used by third-party apps, such as the home screen, and get rid of <intent-filter> from everything else.

For those activities that you do export, typically via <intent-filter>, sanitize all the extras!. These are inputs, no different than parameters you might have on some method that a third party could call. Apply defensive programming techniques to make sure that the extras fit valid values (and combinations of values, where applicable) before using them.

Webinar Wednesday: Two More Betas

Yesterday’s webinar on external display support using DisplayManager went fairly well and helped me understand a bit more about the characteristics of the dozeo meeting space.

I have scheduled two more editions of this webinar, for those of you who perhaps missed the first one:

8 January at 8pm Eastern

15 January at 8am Eastern

As with the first beta, these will be reprising the “External Display Support Using DisplayManager” presentation that I delivered at Samsung DevCon a bit over a month ago. If you were unable to attend that event, and would like to learn more about how your app can send separate content to an external display (TV, monitor, projector, etc.), feel free to sign up!

There are ten free seats available for each of these beta tests.

You will need a PC or Mac with Adobe Flash 11.5 support. For Linux users, this pretty much means that you need to use Google’s Chrome browser (note: not Chromium). You can run a system check to confirm that you will be compatible. Audio will be handled through the webinar app, so you will not need a dial-in number. We will handle questions through the webinar’s chat area and optionally via microphone (if you have one).

To learn more or sign up:

If you have any questions regarding the webinars, feel free to contact me.

Tell Your Ad Network: "SSL, Please"

The Washington Post is reporting that the NSA, through a program code-named HAPPYFOOT, “intercepts traffic generated by mobile apps that send a smartphone’s location to advertising networks”.

If the NSA is doing this, we should assume that other parties have, or soon will have, similar capabilities. And some of those parties will not necessarily be friends of your app’s users.

If you are using an advertising network, or other similar third-party code, ask them when they will be using SSL for encrypting their communications from your app back to their servers. Clearly, not enough ad networks are doing this, otherwise the FOOT would not be quite so HAPPY.

The MENU Key Is Dead. Again.

A quick bit of history for those of you relatively new to Android development: all Android 1.x and 2.x devices had a MENU key, used to bring up the options menu. With Android 3.0 and the advent of the system/navigation bar, device manufacturers no longer needed keys for HOME, BACK, and MENU. And, the action bar incorporated a ”…” affordance for accessing the overflow, for items that would have been in the options menu and were not promoted to be toolbar buttons in the action bar itself.

(BTW: “affordance” is UI-speak for “thingy”)

Confusion began when we started having devices that had a MENU key and Android 3.0+. A few Android 2.x devices were upgraded to Android 4.0, and hundreds of millions of Android devices, from manufacturers like Samsung and HTC, shipped with Android 4.x and a MENU key.

To accommodate this, the device would report whether it had a “permanent menu key”, and the action bar would choose whether to show the ”…” affordance based upon the existence of this key. Devices with a MENU key would not get the ”…”, but instead would use the MENU key to display the overflow.

This irritated many developers, for much the same reason as why the MENU key irritated those developers back in Android 1.x/2.x: the existence of a menu was not very discoverable. Many users would eventually realize that tapping the MENU key might uncover useful stuff, but not all users would make this connection. However, now developers could see an obvious alternative, in the form of the ”…” affordance, and so they sought ways to trick the action bar into showing the ”…” even on devices that had a MENU key.

And that was how the world worked… up until Android 4.4.

An unannounced change in Android 4.4 is that the ”…” affordance should now always be shown in the action bar. The MENU key, if it exists, will still work, showing the overflow. Ideally, it shows the overflow as dropping down from the ”…”, though that is not required. And the Compatibility Definition Document for Android 4.4 more forcefully suggests that the MENU key is obsolete.

Personally, I had not noticed this behavior, as none of the Nexus devices have a MENU key and I have been minimizing my use of the Android 4.4 emulator, as it is presently ARM-only. Hence, I had not been testing in MENU-key-equipped Android 4.4 environments, and so I missed this change. I am deeply indebted to whoever chimed in on the issue I filed seeking some consistency and provided the link to the Git commit where the MENU key change was added.

Developers may want to have consistency in the behavior of their app going back to previous versions of Android. The standard code snippet people have been using to trick the action bar into showing the ”…” is:

try {
ViewConfiguration config = ViewConfiguration.get(this);
Field menuKeyField = ViewConfiguration.class.getDeclaredField("sHasPermanentMenuKey");

if (menuKeyField != null) {
menuKeyField.setAccessible(true);
menuKeyField.setBoolean(config, false);
}
}
catch (Exception e) {
// presumably, not relevant
}

Personally, I still would not use it. While some users have not discovered the MENU key, many have. While you may be getting complaints from some users, you are unlikely to be getting positive feedback (“hey, thanks for supporting the MENU key!”), and so over-reacting to the complaints amounts to selection bias. And by introducing this hack, you may wind up with the same number of complaints, now questioning why you have two different versions of the same menu (one in the ”…” drop-down, one from the MENU key). That being said, since the direction of Android is now to use the ”…” affordance for all devices, I cannot quibble with developers who wish to have that behavior occur on older Android versions.

Webinar Wednesday: First Beta

I will be offering live webinars starting in 2014, and I will be hosting a few “beta” Webinars first, to test my chosen Webinar service and the general approach towards presenting these webinars.

The first such beta will be reprising the “External Display Support Using DisplayManager” presentation that I delivered at Samsung DevCon a bit over a month ago. If you were unable to attend that event, and would like to learn more about how your app can send separate content to an external display (TV, monitor, projector, etc.), feel free to sign up! This first beta test is limited to five attendees, though I will open up more seats for future webinars.

This one-hour webinar is being held on 11 December at 2pm Eastern Time. Future beta tests, plus the “for realz” Webinars, will be held at various times of the day. I will try “spanning the globe, to bring you a constant variety of” Android development topics, at times that are convenient for you.

You will need a PC or Mac with Adobe Flash 11.5 support. For Linux users, this pretty much means that you need to use Google’s Chrome browser (note: not Chromium). You can run a system check to confirm that you will be compatible. Audio will be handled through the webinar app, so you will not need a dial-in number. We will handle questions through the webinar’s chat area and optionally via microphone (if you have one).

To learn more or sign up:

If you have any questions regarding the webinars, feel free to contact me.

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

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

This release is mostly to clear up various production issues with the books, after I switched over to new book generation tools:

The handful of messed-up images, like Figure 1 and Figure 2, are fixed

The EPUB works with Google Play Books again

The APK has the chapters in the right order in the ViewPager

I sincerely apologize for those flaws.

As previously announced, I have removed the Maps V1 chapter, so if you are using Maps V1, be sure to keep your copy of Version 5.3 to refer back to that chapter.

I replaced it with a chapter on Gradle dependencies: JARs, sub-projects, library projects, AARs, artifacts, and the like. I want to add more to this chapter in the next release, such as more case studies.

Version 5.5 of the book should come out in late January, with more Gradle, Android 4.4, and wearables coverage.

App Ops Developer FAQ Updated

News broke yesterday that App Ops is back in Android 4.4.

I can confirm that it does indeed work, with much the same behavior as we saw with Android 4.3, albeit with a slightly different way of launching it. A hat tip to Gabriele Mariotti for the launching info.

I have updated my App Ops Developer FAQ with the latest information.

Warescription Referral Program Beta

I am seeking beta testers for a Warescription referral program.

Under this program, you get credit added to your own Warescription if others purchase Warescriptions via a custom URL. Specifically, any month in which somebody purchases via your referral URL, you get a month added to your own Warescription.

Right now, this is a closed beta. If you are interested in joining the beta, email referral@commonsware.com and provide me your Warescription user ID, and I can supply you with more information. I will update this post when I have enough beta participants.

Note that the referral program is only open to those with an already-active Warescription. I hope to open this program up to anyone with an active Warescription in January.