Mark L. Murphy's Blog, page 79

Android Programming Tutorials Version 4.0 Released

Subscribers now have access to the latest release of Android Programming Tutorials, known as Version 4.0.

Other than a few minor errata fixes and confirming it works on Android 3.2, this is unchanged from the Version 3.9 "release candidate" for the 4th Edition in print. If you already have downloaded Version 3.9, there's no huge need to rush out and download Version 4.0.

The 4th Edition of this book in print should be published late this month.

This book should next be updated late this year (or perhaps drifting into early next year) for compatibility testing with Ice Cream Sandwich, cleaning up some older coding practices (dropping Android 1.x support as a side effect, most likely), and perhaps another tutorial or two.

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.

Tuning Android Applications Version 0.3 Available

Tuning Android Applications Version 0.3 is now available for subscribers.

This update adds ~35 pages of partial coverage of dealing with memory-related issues. It focuses on the Memory Analyzer (MAT) utility: how to get it, how to collect a heap dump, and how to use MAT to try to track down leaks. There is much more to be added in this area of the book, such as strategies for avoiding memory leaks, which will be added in a future version.

This update also adds a few clarifications to the CPU and bandwidth sections from the previous version, with more updates in these areas to come.

The next update — Version 0.4 — will have partial coverage of battery consumption, with a focus on the Qualcomm MDP devices and Trepn. I expect to have this out by late September or early October.

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.

Pondering the Amazon Tablet

TechCrunch has a report from MG Siegler about his experiences playing with the soon-to-be-released Amazon 7" tablet. Let's assume for the moment that everything he cites is correct. What does this mean for the average Android developer?

First, this device will not qualify for the Android Market, as it will not have Honeycomb or the required buttons for HOME, BACK, etc. TechCrunch has indicated that the device does not have any of the Google applications on it, which also tends to fit devices that do not meet the terms of the Compatibility Definition Document. Any app that assumes the existence of things like the Calendar, Gmail, and so forth may fail on this device.

We also will not know if the device passes the Compatibility Test Suite, unless Amazon makes a statement to that effect or somebody else gives it a whirl. This further clouds Android app compatibility. However, since the only apps available to the device will be from the Amazon Appstore, only those developers who will have dived into that marketplace will have to worry about immediate compatibility concerns.

Assuming that Amazon is vetting their own Appstore content to confirm it runs well on this tablet, and assuming the claimed $250 price point holds true, this device is likely to sell very well. That's around the price point of the first couple of generations of Kindle when they first came out, and this tablet will be an all-around more capable unit (albeit with a traditional backlit LCD instead of e-ink). Assuming Amazon promotes it to the same level they did with the Kindle, a couple of million tablets sold by the end of the year would seem well within reach.

This poses a challenge for Android developers: do you target this device or not? Akin to those experimenting with shipping apps for the Barnes & Noble NOOK, you have the advantage of less competition in the market, making your apps that much more likely to be discovered. However, compared to your average Android device, there may be greater compatibility concerns, increasing the cost to you for getting on these devices. There is no right or wrong answer here — it's whatever you think will deliver you the right results.

TechCrunch indicates that:

You bring up a lower navigation menu by tapping the screen once. This can take you back home, etc.

It remains to be seen how this will interact with applications that already support touch events. My hope is that the article's author is slightly off in his statement, and that there's some particular part of the screen you tap or something else to more clearly differentiate between "give me the HOME button" and other touch events.

The article's author thinks that the Kindle-ized OS on these tablets is based off of "some version of Android prior to 2.2". That's a tad on the old side. Many "big ticket" capabilities added since then would not be relevant (e.g., NFC) due to what the hardware has. However, there are lots of smaller things, from setPackage() on Intent for "narrowcasting", to DownloadManager for more reliable large-file retrievals, that would be nice to have. Also, since users are less likely to be trading in tablets, the way they might be replacing Eclair-based phones, this will increase the longetivity of an older Android, until Amazon elects to ship some sort of upgrade. Also, this probably would be the most popular large-screen device on such an older Android, which is a combination many developers will not have encountered before.

So, keep your eyes out for this device in the coming weeks. We will see how many of the claims made in the article are indeed accurate. From there, those of you not in the Appstore can make the decision of whether to dive in on this tablet, and those of you in the Appstore hopefully get nicely discounted hardware to play with… :-)

Google TV Emulator: Seemingly Pointless

Al Sutton tweeted recently:

If the @googletvdev #Android SDK add-on stays limited to Linux at release time I think we can kiss goodbye a lot of developer interest.

I agree: the Google TV emulator implementation that has shipped as part of the SDK add-on preview seems pointless.

Why?

First, it requires Linux. Right there, a lot of developers will dismiss it outright, because they do not use Linux themselves. Personally, I'm writing this on a Linux machine, so this requirement does not bother me, but I know from first-hand experience that I am seriously in the minority in Android development.

Second, it not only requires Linux, but it requires Linux running on a machine that supports hardware virtualization. While many CPUs do (e.g., Intel Core i7), there are many developers doing Android development on less-capable hardware.

Third, it not only requires Linux and a compatible CPU/BIOS, but it requires a Linux distro with KVM enabled. Ubuntu, for example, does not ship with KVM enabled for the desktop. Ubuntu uses KVM for servers, not desktops, and I can only find KVM information for the current Ubuntu (Natty Narwhal) for enabling it on a server. In fact, I cannot find any desktop distro that explicitly supports KVM — if anyone knows of one, please let me know. Few developers will already have their development machine set up to run a GUI-enabled server distro, where KVM might be more readily available.

Fourth, it not only requires Linux, a compatible CPU/BIOS, and a Linux distro with KVM enabled, but you can't use other virtualization solutions on the same machine (e.g., must disable VirtualBox). So, for example, I can't use it on my development machine, because while I can probably solve all the other problems with sufficient hammering, VirtualBox is significantly more important to me than is the Google TV emulator.

This effectively means that nearly 100% of Android developers wishing to use the emulator will need to purchase a new computer. And, for those without Linux experience, they'll have to learn a new OS.

The result is that nearly 100% of Android developers will ignore Google TV or will buy a Google TV device if/when one becomes available in their market. Hence, the emulator is seemingly pointless from the standpoint of developers.

I'm happy to be proven wrong, and if you have successfully gotten the Google TV emulator going, drop me a line. Eventually, I'll toss Ubuntu Server on a spare machine to see if I can get it going, perhaps even giving a live Ubuntu distro a try to see if it is practical to use that to temporarily convert a machine into a Google TV emulator.

I can certainly understand why Google might want to avoid VirtualBox, given that it is an Oracle product nowadays. But, why not VMWare? Players are free, last I checked. Google TV runs on x86, so the lack of ARM support isn't an issue (and, besides, KVM doesn't do ARM anyway). This would not only solve the KVM limitation but would allow developers on Windows and OS X to play as well.

So, I agree with Al. If this is the be-all and end-all of Google TV emulation, it'll be a non-starter for way too many Android developers, to the detriment of the platform. Hopefully, this is just a stop-gap.

MTP, External Storage, and Your App

NOTE: This post originally appeared on the Appaholics blog as a guest post

Some changes in Android 3.x may impact your application, if you are writing content to external storage and want users to be able to access those files on their desktops or notebooks.

Android 3.0 switched the means by which users mount external storage and make it available to their desktop or notebook. Previously, Android used USB Mass Storage Mode, the same protocol used by USB thumb drives and the like. This is why when the external storage was unavailable when a host machine had it mounted — USB Mass Storage Mode was not designed for intelligent storage devices.

Android 3.0 now uses the Media Transfer Protocol as the way external storage gets mounted. Much of what has been written about this has focused on the user experience, such as needing third-party software to use MTP on OS X and Linux.

However, there is a more subtle shift that is important to developers: the MTP contents are not based on the literal contents of external storage. Instead, MTP contents are based on what files have been scanned by MediaScannerConnection. If you write a file to external storage, until and unless that file is scanned by MediaScannerConnection, it will not be visible to users over MTP.

External storage is scanned on a reboot and possibly on a periodic basis. Users can manually force a scan via utilities like SDRescan. However, the best answer is for you to use scanFile() on MediaScannerConnection to update the media database after you close your file. This will make your file immediately available to the user.

Previously, we only needed MediaScannerConnection for actual "media", such as MP3 files or MP4 videos. Now, we need it for everything, if we want to give the user immediate results.

On a related note, it may be that Android 3.0 or 3.1 would filter MTP and not show the contents of directories that contain .nomedia files, applying the same rules that filter those out of things like the Music app. By Android 3.2 — at least based on light testing with the XOOM — that filtering has been lifted. MTP shows everything, while .nomedia still filters out content from installed media-consuming applications.

Beginning Android: Keep Going?

My original book, The Busy Coder's Guide to Android Development, is an important part of the nearly-2,000-page Warescription. I do not update it quite as often as other books, simply because more of what I am writing nowadays really belongs in other books in my series. However, as an introductory guide, I will be updating The Busy Coder's Guide to Android Development for the forseeable future.

Periodically, this title has been republished by Apress under the Beginning Android moniker. Apress takes an edition of my base book, makes some modifications to it, and publishes it under their own title, cover, and brand. Their book gets into bookstores and Safari, whereas The Busy Coder's Guide to Android Development is only available via the Warescription.

Beginning Android is a hassle at best. It distracts me from other work. I receive no real benefit from having Apress publish it nowadays. Due to some history between Apress and me, I will never really be happy with Beginning Android. And Apress' desire for aggressive timetables hampers the quality not only of their book, but also of the corresponding edition of The Busy Coder's Guide to Android Development.

All else being equal, I would like to discontinue Beginning Android, or at least my involvement with it.

However, I would like your opinion on that.

Due to contractual obligations, Beginning Android is the only way that The Busy Coder's Guide to Android Development will be available in print. There are plenty of other print books available on Android, including some that are as good if not better than my own. My sense is that the world will not miss having mine in print, but I may not have a clear perspective on it.

I would really like to know if:

You see any particular value in The Busy Coder's Guide to Android Development being available in print form via Apress in its current state (plus additions for Eclipse GUI building, Ice Cream Sandwich, etc.).

You see anything that I could do with that book, keeping in the spirit of an introductory guide, that would make it even more useful when Apress prints it.

If you have an opinion, tweet me (@commonsguy) or drop me a line, so I can take your thoughts into account.

Thanks!

Tuning Android Applications Version 0.2 Available

Tuning Android Applications Version 0.2 is now available for subscribers.

This update adds ~36 pages on bandwidth consumption, including a short example of how to use TrafficStats. This coverage is a bit weak — I want to incorporate some examples of budget-based bandwidth shaping in a later update. And if somebody out there has had success in using Wireshark for traffic analysis of Android devices on WiFi, drop me a line, as I'd like to pick your brain.

This update also adds a few clarifications to the CPU coverage from the previous version, with more updates in this area to come.

The next update — Version 0.3 — will have partial coverage of memory and battery consumption. In particular, the "Focus On" chapters for memory (HPROF files and MAT) and battery (the Qualcomm MDP devices and Trepn) should be completed. This is targeted for release before droidcon UK in early October, if for no other reason than I have a presentation on Traceview and MAT at that event… :-)

At that point, this title will go into update hibernation until early 2012, as I return my attention to The Busy Coder's Guide to Android Development and The Busy Coder's Guide to Advanced Android Development, adding in coverage of Ice Cream Sandwich (ICS) when it is released, putting in more Honeycomb coverage (loaders and property animations), and so on. Those will be some fairly massive updates, particularly for how ICS takes the Honeycomb-style UI and crams it into a phone form factor. Hence, I am expecting a couple of revisions to those titles during the balance of 2011, which, along with a "skunkworks" project you'll hear about eventually, will consume most of my available time.

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.

Musings on Motorola Mobility

Well, now, this is an interesting morning.

For those of you just tuning in, Google has announced plans to acquire Motorola Mobility.\ While we typically refer to this simply as "Motorola", bear in mind that the long-time US firm named "Motorola" split into two pieces a year or so ago. Motorola Solutions is a separate firm, handling two-way radios and other technology.

Google has indicated that it will operate Motorola Mobility as an independent subsidiary… though the precise definition of "independent" remains to be seen.

What does this mean? Here are some off-the-cuff thoughts:

You might react and think "well, all the other manufacturers will dump Android". However, bear in mind that most other manufacturers have Android as part of a product line portfolio, also employing other licensed mobile operating systems (e.g., Windows Phone) or their own home-grown operating system (e.g., Samsung and bada). I can see some of those device manufacturers perhaps considering a slight shift in the weight they put behind Android compared to other options, but if Google reassures them that "independent" really means "independent", I would expect few to truly dump Android. In many respects, the alternatives they have really are not up to Android's caliber, at least in terms of available third-party applications.

That being said, I do suspect that this will somewhat slow Android's growth, which was already likely to slow just due to sheer math (you can't grow market share indefintely, since 100% is the ceiling). Microsoft may benefit, as firms might be more inclined to consider Windows Phone as part of their own product line portfolio. And if HP decides to license WebOS, that too might have a somewhat more productive result than I would have expected before.

Also, if other Android device manufacturers perceive that they are "second-class citizens" compared to Motorola Mobility in terms of getting Googly assistance, that too many drive device manufacturers to put a tad more emphasis on alternatives.

On the legal front, Google is now moving towards the center stage in the myriad patent disputes going on. One imagines they will use Motorola Mobility's patent portfolio to more aggressively defend against Apple's recent moves, for example. It's sad that this is necessary, but, c'est la vie.

For developers, it will be interesting to see what happens with MOTODEV Studio for Android (Motorola Mobility's extensions to the official ADT) and whether that proceeds apace, is folded into the ADT itself, or something else. The look of Motorola Mobility devices might shift — as AndroidGuys tweeted, "Could this be the end of MOTOBLUR?". And I sincerely hope that this results in a win for the MOTODEV team, as Motorola Mobility has been far and away the most active of all the device manufacturers in helping developers with Android. Alas, I am nervous, as Google's track record for providing this kind of help to rank-and-file developers has been… mixed.

All in all, the next 12 months is likely to be that much more interesting given the events of the last 12 hours.

Warning: Activity Intent Extras Can Be Public

A participant in today's office hours online chat pointed out something to me that I had not realized before: Intent extras can be publicly visible to other applications. Specifically, the Intents associated with recent tasks are visible, and hence their extras can be accessed.

When you long-press on the HOME key, you are displaying a dialog box of the recent tasks. The data behind that dialog is available via getRecentTasks() on ActivityManager (which, in turn, you get via getSystemService() on any handy Context). The big piece of data in a RecentTaskInfo object is baseIntent, described as "the original Intent used to launch the task". All data on this Intent is readable by any application that holds the GET_TASKS permission.

Hence, in any situation where you are starting an activity that might start a new task, you need to be very careful about your Intent extras. Like many developers, I had considered Intent extras to be private, only visible to sender and recipient… but in this specific case, that is not true. Passing authentication credentials (e.g., bank PINs) via activity Intent extras, therefore, is not safe.

However, this is limited to tasks, so Intent objects used with startService() and sendBroadcast() are not stored in getRecentTasks(), at least based on the testing I performed today.

About Binder Caching

There was a debate earlier in the week on the android-developers Google Group regarding the behavior of onBind() in a service. While the original question was whether two clients can both be bound to a remote service (answer: yes), a sidebar developed regarding onBind() and caching.

Something I had not realized, until Kostya Vasilyev pointed it out, is that Service caches the object returned by onBind() for a given Intent. In other words, the second and subsequent times that a running Service is bound to, onBind() will not be called, if the Intent used each time is equivalent. Here, "equivalent" means that the action, data (Uri), categories, and MIME type are identical.

If, however, you use different Intent structures, such as different action strings, that will result in onBind() being called multiple times, one for each distinct Intent.

This is important for remote service binding. The contract between your Service and third-party developers is not really the Service itself, but a specific Binder structure, described via AIDL. Ideally, you should use an <intent-filter> with a custom action string as your public stable name for that Binder/AIDL structure, so you can refactor class implementations without breaking the effective public API. However, if you decide that you need a new Binder (e.g., add new methods), you can use a different action string, and have onBind() return the right Binder based on the received action. This way, you can support both old and new versions of your Binder/AIDL API simultaneously.

If onBind() caching was oblivious to the changes in Intent, then this would not work — the first onBind() call would return whatever Binder it needed, and everybody else would wind up with that same Binder, like it or not. However, I can confirm that onBind() caching does respect the Intent contents, and so the multiple-action-string pattern should work just fine.