Mark L. Murphy's Blog, page 80

BOOT_COMPLETED Regression

Back on June 30, a developer posted a possible issue with the BOOT_COMPLETED broadcast. I think the question got caught up in moderation, and it showed up on the android-developers list yesterday. I ran some tests and can confirm the core symptom: BOOT_COMPLETED will not work out of the box on Android 3.1 until the user uses your app.

For those of you just tuning in, Android sends around a BOOT_COMPLETED broadcast around the time the home screen appears. You can register to receive that, assuming you hold the appropriate permission. Mostly, this should be used for registering AlarmManager schedules.

What I confirmed is that if you install an application that registers a BOOT_COMPLETED receiver, and simply restart the Android 3.1 device, the receiver does not get control at boot time. The original person reporting the problem indicates that the user has to start up an activity in that application first (e.g., from the launcher) before Android will start delivering BOOT_COMPLETED Intents to that application.

I do not find this change that surprising. Google has long said that users should launch an activity from the launcher first, before that application can go do much. That's why your app does not receive the ACTION_PACKAGE_INSTALLED broadcast, for example. Preventing BOOT_COMPLETED from being delivered until the first activity is launched is a logical extension of the same argument.

However, it is a regression.

I expect that most apps will be OK. For example, if your boot receiver is there to establish an AlarmManager schedule, you also needed to establish that schedule when the app is first run, so the user does not have to reboot their phone just to set up your alarms. That pattern does not change – it's just that if the user happens to reboot the phone, it will not set up your alarms, until the user runs one of your activities.

However, if your application relied upon BOOT_COMPLETED working without user intervention (e.g., you have no activities, only an app widget), you may encounter problems.

I have filed an issue, to either fix the bug (if this is supposed to work as before) or to fix the bug (if this is merely a documentation issue). DO NOT STAR THE ISSUE unless you want to be notified of updates. DO NOT COMMENT ON THE ISSUE to argue whether or not the current behavior is OK; only comment if you have additional evidence that pertains to the behaviors cited. Many people think that the Android public issue tracker is some sort of blog comment stream and therefore feel inclined to post "me too!" comments or rants about how Google is teh evil. The Android public issue tracker is mostly a one-way dead-letter drop for problems — if you want to hold discussions about it, pick someplace else more appropriate, such as the android-developers or android-discuss Google Groups.

The Busy Coder's Guide to Advanced Android Development Version 2.0 Released

The Busy Coder's Guide to Advanced Android Development Version 2.0 is now available for subscribers.

This release mostly makes some minor improvements to the NFC chapter (places to get tags, moving the NFC I/O to a background thread, etc.) and a few errata fixes.

More importantly, it sets the stage for releasing the 2nd Edition of the book in print.

Tuning Android Applications Version 0.1 Available

Tuning Android Applications Version 0.1 is now available for subscribers.

This is a new title, available in beta form to subscribers. The objective is to get it to a 1.0 edition by January 2012.

This book, when completed, will have five parts:

CPU

Battery

Memory

Bandwidth

Storage

Each part will outline the performance issues in that area, how to measure them, and how to try to resolve them. Each part will have one "focus on" chapter with a relatively deep dive into a technique, plus another chapter covering other approaches.

This 0.1 release has the CPU part almost completed, mostly missing an example of the Loader framework.

Note that the release of this book marks the end of Android Beyond Java, which is now officially retired. All of the material in that book has been migrated to other books, with the NDK coverage moving into this new book.

If you have questions regarding the use of the sample code, please post a question on StackOverflow tagged with commonsware and android. Be sure to indicate what book example you are having issues with, and be sure to include source code and stack traces if you are encountering crashes.

Broadcast Regression Confirmed

In a previous post, I cited evidence that the BOOT_COMPLETED broadcast will not work out of the box on Android 3.1 until the user uses your app.

It's actually somewhat bigger than that.

In the issue that I filed seeking clarification, Ms. Hackborn indicated:

Starting with 3.1 when applications are installed they are in a "stopped" state so they will not be able to run until the user explicitly launches them. Pressing Force Stop will return them to this state.

As a result, when applications are first installed, they are totally ignored by the system until and unless the user manually launches something: clicking on a launcher activity or adding an app widget, most likely.

Developers who had been relying upon getting some sort of system broadcast without user intervention will need to adjust their apps for Android 3.1.

As I wrote in the previous post:

I expect that most apps will be OK. For example, if your boot receiver is there to establish an AlarmManager schedule, you also needed to establish that schedule when the app is first run, so the user does not have to reboot their phone just to set up your alarms. That pattern doesnot change – it's just that if the user happens to reboot the phone, it will not set up your alarms, until the user runs one of your activities.

UPDATE: To clarify the above quote, once the user runs the app for the first time (and does not Force Stop it), everything behaves as before — a reboot will cause BOOT_COMPLETED broadcasts to be received and so on. However, if the user installs the app, until and unless they run the app manually, no broadcasts will be received. And if the user force-stops the app, until and unless they run the app manually, no broadcasts will be received.

This change is not terribly shocking, as it ratchets up the security another notch by limiting ways malware can run without user knowledge. While it does not offer perfect security — the malware can still install its own copy of an Angry Birds launcher icon and hope users screw up — it is an improvement.

IMHO, the biggest issue is that this change went out unannounced and undocumented.

UPDATE: A Twitter follower pointed out that this change was documented in the 3.1 release notes, which I had missed.

Touchqode: How Not to Write a License

In the Android Market listing for the touchqode app, we find this curious paragraph:

Please stop trolling about the license - there is NOTHING that gives us intelectual [sic] property to files edited by touchqode. You can review it at http://touchqode.com/licences/touchqo...

I presume that they have received some complaints. This is not surprising, as this license is awful. Whoever touchqode hired to write this license should be ashamed.

It starts off OK, if overbearing — it's as if the authors are really trying to convince the prospective user not to use the app.

Things start to get a bit wobbly around bullet #10, where the authors are trying to force users to agree to unseen, unlisted, and unknown "third party licenses".

However, where it really goes off the rails comes with the opening of bullet #12:

All intellectual property remains the property of touchqode.

All intellectual property? Really? Touchqode owns the formula to Coke? Touchqode owns the patents related to Java? Touchqode owns my emails to my mother?

I think not. Admittedly, I cannot speak with authority regarding the first two, but I feel quite confident about my latter assertion.

And other bullet points are similarly bizarre, such as:

13 says that you grant touchqode a patent license to any patent pertaining to any "feedback, comments, or suggestions" that you provide to them that might touch on some patent you own

15 says that touchqode is not bound by its own agreement

17 basically says that the application might not be usable in the United States, among other places, because "local laws or regulations prohibit limiting liability or limiting guaratees", and their license does not contain the standard disclaimers regarding warranty

Tactically, if you are going to have somebody draft a custom software license, compare the result with other similar licenses, and make sure they line up reasonably well.

Strategically, understand that a EULA, particularly a click-wrap one, is a marketing brochure as much as it is a legal document. It is through this license that the seller is telling the prospective client the nature of their relationship. A hostile license turns away client. And this license is certainly hostile in tone and intention.

Or, to put it another way: if people are complaining to you about the license, please consider that perhaps it might not be "trolling".

BACK Means Back

One of these days, I'm going to stop following StackOverflow, just because it saddens me so much.

Today's head-exploding example is "I need to override the back button to launch a context menu".

People. This isn't a hard concept. When it comes to sex, "no" means no. When it comes to UX, BACK means back.

(let's ignore the "use context menu as arbitrary UI construct" anti-patten for the moment)

Now, BACK may not mean "destroy the current activity", which is the default behavior. It might need to be adjusted for the particulars of an activity, such as how the fragment system allows the user to reverse FragmentTransactions via the BACK button. Or, perhaps BACK might mean "dismiss the popup the user triggered previously".

But, regardless, BACK means back.

Pressing the BACK button should take the user logically to whatever preceded it without hesitation. At most, it might trigger a confirmation dialog, if the user was in an activity and did a lot of data entry and might have accidentally bumped BACK. But that's a relatively rare case.

There is no selection involved with "back" — it is whatever logically preceded it. Pressing BACK is not a request from the user to "take me someplace" — it is a request from the user to take the user back, period. If you want to offer navigation to other places, use an action bar and put navigation buttons in it, or use the options menu. Pressing BACK should not be popping up some sort of selection dialog, let alone a context menu.

I feel fairly confident that if, in an iOS app, you tried popping up a selection list when the user tapped the on-screen "Back" button, that you would be rejected from the App Store for violating the Apple Human Interface Guidelines. Perhaps Amazon will start rejecting apps for screwball stuff like this, the way they reject apps that block the main application thread.

I really wish that the Android Market had hooks for third-party non-profit testing services to help validate app quality. Such services would issue badges for those who meet UX guidelines, pass certain security and privacy tests, etc. That way, Google would not have to do the "heavy lifting" of the actual testing, but would merely pass along the results of the tests to prospective users, much like how appliance manufacturers use Underwriters Laboratories to certify that their gadgets are unlikely to spontaneously combust. Such badges could go a long way towards steering developers to "do the right thing".

So, override onBackPressed() if you need to, but ensure that whatever you implement, BACK means back.

Gmail Gone, and the Risk of Undocumented APIs

The latest version of the Gmail application for Android 2.3.5 apparently has android:protectionLevel="signature" on its content provider, meaning that third-party applications will no longer be able to read messages straight from the on-device Gmail app.

This will undoubtedly cause much wailing and gnashing of teeth, some of which has already started.

OTOH, you've been warned for some time that relying upon undocumented APIs is risky behavior. Whether it's a simple authority change (as happened to the Calendar content provider in the 2.x timeframe) or locking it down entirely as occurred here, these are all well within Google's rights. Google has been telling you repeatedly, through blog posts and Google Groups and StackOverflow that undocumented APIs are unreliable. I've emphasized this countless times in StackOverflow answers and comments, to the point where I've considered programming a keyboard macro just to save me some typing time.

If you find yourself hard-wiring in com.google or com.android or content:// somewhere, make sure that what you're using is documented and supported via the Android SDK. Just because it is reachable by various means does not indicate that it is safe and stable for use.

Now, if you want to debate whether Google should have a documented and supported Gmail API, that's certainly a worthwhile discussion to have. I'm personally skeptical on the Gmail front, but I'd argue there should be standard and supported providers for stuff unique to the device, like SMS, that cannot be accessed by other APIs (e.g., getting to the user's Google Calendar by the Google Calendar GData API).

Android Programming Tutorials Version 3.9 Released

Subscribers now have access to the latest release of Android Programming Tutorials, known as Version 3.9. EPUBs and Kindle editions are ready as I write this, and about half the PDFs are ready, with the balance ready in an hour or so.

This update adds 60 or so pages, almost exclusively dedicated to Eclipse-specific instructions for accomplishing the tutorials.

The original instructions are still there. However, pointers to Eclipse graphical editors for the manifest, layouts, and various other resources are also included. Particular emphasis was placed on the drag-and-drop work to create the UI.

The Eclipse coverage is not without its warts. In the interests of time, I kept the original instructions intact and just created parallel Eclipse instructions. Alas, some of the UI choices do not work well with the current edition of the drag-and-drop tools. So, there are a few places where Eclipse users will still need to mess with the XML. Sometime in the 4.x versions, I will redo select portions of the UI to allow for better drag-and-drop generation.

The book jumped to Version 3.9 largely due to an issue with Amazon.com. For unknown reasons, they are not working as well with my prior printing house and distributor for print editions. As a result, the 3rd Edition of this title shows up as "ships in 2-3 weeks", even though it should actually ship much faster than that. I have to switch printers to rectify this, and that is easier to do when I update the print version itself. So, in late September, this book will move to Version 4.0, with a 4th Edition coming out in print shortly thereafter.

If you encounter any issues with the samples in the book, please post your problems to StackOverflow with the commonsware tag, and I'll get back to you ASAP.