Code Downloads for "Introducing Android Development with Ice Cream Sandwich" Available Here

We've added the source code downloads for the minibook, Introducing Android Development with Ice Cream Sandwich, to the downloads page. The code includes the fix for previously mentioned errata.

Download it now to use with your copy of the ebook.

Errata for "Introducing Android Development with Ice Cream Sandwich"

We recently completed a very short, very small book project: "Introducing Android Development with Ice Cream Sandwich." It's a minibook that was targeted to release with Ice Cream Sandwich. As such, the testing and development timeline was incredibly short and truncated, and devices are still not available to everyone who wants them worldwide.

Right off, we've had a reader point out one issue:

In Chapter 1, when adding the code to play an audio file from a remote URL, Android 4 (Ice Cream Sandwich) now requires and enforces the Internet permission. We've tested on previous SDK versions and, indeed, this permission was not enforced on any prior platform versions. In this case, we completely agree that it should have been -- the sample application has been using Internet data without needing to request a permission since Android 1.0-but now it needs this permission.

Luckily, the LogCat output makes this crystal clear:


12-04 15:08:15.674: D/MediaPlayer(605): Couldn't open file on client side, trying server side
12-04 15:08:15.684: W/ServiceManager(36): Permission failure: android.permission.INTERNET from uid=10044 pid=605
12-04 15:08:15.684: E/MediaPlayerService(36): Request requires android.permission.INTERNET
12-04 15:08:15.684: E/MediaPlayer(605): Unable to to create media player

The Android documentation has been updated to state, at the class level, that MediaPlayer requires the INTERNET permission when used with network based content. As it should. What isn't stated is if older SDKs will eventually be updated to enforce this permission or not. Right now, we only see this permission being enforced when running the application on API Level 14, which, right now, is less than 1% of all devices in the field. 

We apologize for any inconvenience or confusion this issue has caused. The update will also be applied to the full book, Android Wireless Application Development: Volume 1: Android Essentials: Third Edition (or, as we like to call it, AWAD3EV1). We will also update the code available on this website to reflect the permission policy change. 

Kindle Fire: ADB Connections and USB Debugging

Amazon Appstore on Kindle

Amazon's Kindle Fire is looking to be one of the hottest non-Google Mobile Services Android devices to date.  If you've got one, you may have quickly noted that you can't necessarily immediately connect it up via ADB. A quick search returns all kinds of various solutions.

Turns out, Amazon also documents the solution. In fact, they have entire section in their developer FAQ on the Kindle Fire. The linked PDF, Connecting Your Kindle Fire To ADB, has all of the steps necessary and a linked driver will help Windows 7 users.

If you already had your application on Amazon's Appstore and it works on Kindle Fire, users are probably already downloading it. 

Late Night Dessert: Ice Cream Sandwich Arrives

Android 4.0, Ice Cream Sandwich Mascot

Android developers were treated to a late night dessert last night. At least those in North America. The Ice Cream Sandwich and Galaxy Nexus announcements were at 10pm in our local time zone.

What was announced? There were actually several different areas of the announcement. First, there is a new device coming: the Galaxy Nexus. Second, the Android 4.0 SDK is out -- download it now if you haven't already. Third, several new user features for Android were announced and demonstrated in the context of the Galaxy Nexus.

Beyond those basic announcements, though, came the release of Android SDK Tools R14, Eclipse plug-in R14, updated -- and renamed -- compatibility package. The compatibility package is now on release 4, and is called the support package. All come with updates. The SDK Tools may be the most interesting. The Android Open Source Tools blog has been highlighting recent changes, many of which look exciting.

What wasn't announced? There was no word on Google TV -- is it still slated for Honeycomb, or will it jump to Ice Cream Sandwich and when -- we don't know. There was no word on when older devices -- tablets and phones -- will get Ice Cream Sandwich, Android 4.0, firmware. Or even if they will (we assume they will).

Now that ICS is out and known, what are you expected from whatever J (probably not a trademark name, like we've seen rumored) dessert is chosen for the next major release?

Win a Copy of the Second Edition of SAMS Teach Yourself Android Application Development in 24 Hours!

STY:AAD:i24H:2E

There's still time! You've got until September 8th to enter to win a copy of our beginner Android development book over at the Android Police website! Just post a comment about an app idea you've got and you'll get a chance to win one of five copies of SAMS Teach Yourself Android Application Development in 24 Hours, Second Edition!

We look forward to reading your comments and good luck!

(Note: This particular contest appears to available to anyone in the world!)

This book is our most recent in the SAMS series and is for beginners compared to our more advanced title, Android Wireless Application Development (2nd Edition) (Developer's Library).

Several New Android Updates

Android API Level 13 is
Android 3.2 is
Honeycomb

The Android team has posted several new updates in the last few days. The most obvious, which was already rolling out to consumer devices, is the Android 3.2 SDK. This is API Level 13 and is the most recent incremental update to Honeycomb. It's main new features revolve around expanded screen compatibility support. New resource qualifiers are available to developers and official support is in place for devices with screen resolutions of 1024x600 (most frequently found on 7" tablets).

The Android NDK was updated to release 6. This adds support for the x86 Application Binary Interface (ABI). Although it doesn't say as much, we're assuming this is in advance of broad availability of Android applications for Google TV devices, many of which are on Intel x86 platforms (such as the Logitech Revue, which is built around an Intel Atom processor).

The Compatibility Package has been updated to Release 3. This release marks a change from previous releases in that it now has both API Level 4 compatibility classes, several classes that are no longer exclusively for compatibility, but rather add new, useful features for developers. This includes versions of these classes for API Level 13, such that those classes behave more appropriately on the new Honeycomb release (we assume).

This has left us wondering about the future of the Compatibility Package. We've found it incredibly useful and one of the best ideas out of the Android team for adding higher level features that could be implemented on old platforms. What we're wondering is if this will become a pattern? Instead of adding a new, higher level, feature to the base API and then adding compatibility classes, will they start adding such classes directly to the Compatibility Package and now to the the base API? This would ultimately result in more efficient APIs on all SDK levels.

Either way, the Compatibility Package continues to be a very important piece of the Android picture.

Which of these updates is most interesting to you? What new opportunities do they allow for you as application developers. We love to know what you're working on!

Important Android Update Coming: Developers Must Take Action

The Google Android Developer's blog recently posted about a change to Honeycomb. This change is the ability for users to be able to choose to stretch your app or scale your app. This option will be enabled unless you, the developer, specifically sets support for xlarge screens:

<supports-screens android:xlargeScreens="true" />

Or you set the minSdkVersion or targetSdkVersion to API Level 11 or higher. 


If neither of these is true, the user will be give the option to scale your app in a way that may make it look much worse. If you are already doing the right thing with respect to supporting various screen sizes, the scaling mode will make your app look worse. This is because the scaling mode emulates an MDPI normal sized screen. That is, your app will become a pixelated version of what it looks like on the venerable G1. 


Is this what you want? Probably not. You must update your application to avoid this situation, but only if you do not already have xlarge screen support or API Level 11 or higher listed as a target or minimum SDK version.


The update to enable this on some devices rolled out yesterday. Get to it!


Need more resources on how to handle multiple device resolutions?

• Android Wireless Application Development, Second Edition, Chapter 25
• Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition, Hour 20
• Create Flexible Android UIs with Fragments
• Android Tablet Development Tips and Tricks
• Android Compatibility: Diversity: Supporting Diverse Devices, Smart Developer, Issue #3

Motorola Atrix 4G: Connecting to a Mac

Motorola Atrix 4G

When we first got our Atrix 4G test device, we were momentarily dismayed when it didn't just show up in ADB for testing. We had set the USB to debugging mode, all of our other devices connect and work without any trouble. Was this some at&t thing we'd missed?

Luckily, it wasn't. Our Mac is running 10.6.6, which apparently introduced an incompatibility with ADB 1.0.26. Supposedly other configurations just work. We have this configuration, and so can't comment on the others.

Luckily, there's a very simple solution:

None or USB Mass Storage

When the device is connected, choose the "USB connection" item from the notifications, then pick either "USB Mass Storage" or "None." Voila! The phone appears in ADB! Motorola Phone Portal and Windows Media Sync apparently don't work so well with whatever the combination of Mac OS 10.6.6 and ADB 1.0.26 do.

Reader Feedback: Using Your Personal Device for Development

We had an interesting comment come in from a reader recently. In our books, work, and discussions with developers and clients, we always strongly recommend testing applications on real hardware -- as much real hardware as you can feasibly get your hands on.

Why? Won't the Android code just run everywhere?

Sure, the code will run everywhere. The results, however, will not be consistent. It doesn't mean that your app will run properly or as you expect it to. This can be due to different device SDK versions, bugs in your own code, unexpected device differences (such as strange screen resolutions or manufacturer features that modify behavior slightly), and simply device firmware bugs.

Back to the reader comment:

"... because there was no mention if it would have any impact on the device.  What I mean is, will it reload all the device programs and possibly mess up my phone?"

This is a great question. Having done mobile development -- and used personal devices for testing, in addition to piles of test-only devices -- for over a decade, we often forget about such basic things. Once upon a time we worried about such issues - typically we worried most about "bricking" our phones, or causing them to become unusable.

The simple answer with Android is no, writing and deploying apps won't mess up your personal device. Well, no more so than you could mess up your device by installing someone else's poorly written app. The more complex answer is that it could, but it depends on what you're doing. If you're just loading your own applications and running them, even on the debugger, that alone won't cause problems. If you're doing something tricky with your code, going beyond the bounds of the SDK, or other lower level items, you could cause resets, instability, and even data loss -- but simply due to bugs in your code.

One caveat here is that at no time in our books or articles do we recommend rooting your device, which opens it up to higher chances of causing damage. Rooting your device gives you access to underlying systems and services that are made unavailable to developers for good reason. Yes, there can be reasons to root your device, but those who pursue this do so at their own risk. Our general feeling is that testing with rooted devices is not useful, because the majority of users in the world don't root their devices, and that's the environment our apps will run on and therefore the environment our apps should be tested on.

We do recommend backing up your data. For instance, if you're writing an app that reads and writes to the device images and you have a bunch of family photos on the device that you haven't backed up, do so. Same goes for working with contacts, etc. Maybe one of your apps accidentally deletes everything during testing. That wouldn't be any fun, would it? Therefore, your biggest vulnerability when using a personal device is the data, not the device itself.

Further, you can still use your device for purchasing items off the app stores: Android Market, Amazon appstore, and any others you'd like. Again, using a device for development does not require rooting that device, so you can still purchase books and movies that are sometimes blocked on rooted devices.

Finally, even the carriers/operators won't know or care. It's not really any different than loading apps from alternate markets. If you're developing an application that uses a ton of data over cellular connections, you might need to make sure you have a data plan that includes a lot of bandwidth, or unlimited usage, to avoid hefty fees.

Ultimately, our own personal devices are the ones we test or demo apps on the most because they are always with us and are the most convenient. We don't have to sift through boxes of cables and devices if we're using our personal devices.

Win a Copy of Our Advanced Android Book!

There's still time! You've got until July 8th to enter to win a copy of our advanced Android development book over at the Android Police website! Just post a comment about an app idea you've got and you'll get a chance to win one of five copies of Android Wireless Application Development, Second Edition!

We look forward to reading your comments and good luck!

(Note: This particular contest appears to available to anyone in the world!)

This book is our most recent in the Developer's Library series and is more advanced than our upcoming title, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition.

Pre-Order Second Edition of Sam's Teach Yourself Android Application Development in 24 Hours Now!

Our next book, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition, is available for pre-order from Amazon. Buy it now and be amongst the first to receive it.

We've made extensive changes throughout the entire book, updating it based on feedback from readers -- including many who have commented on this blog -- as well as incorporating updates and changes to the Android SDK and tools. We appreciate all feedback; keep it coming!

We expect this book to hit shelves sometime mid- to late-August. Amazon is showing a date of August 25, while InformIT is showing a date of August 15.

We hope you enjoy it and learn from it.

Win a Copy of Android Wireless Application Development, Second Edition

Mobiletuts+ is giving away five free autographed copies of Android Wireless Application Development, Second Edition. Find out how to enter to win one of them over on Mobiletuts+.

This book is our most recent in the Developer's Library series and is more advanced than our upcoming title, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition.

(Note: This is only available to US residents, where allowed by law.)

Placeholder: Details Forthcoming

This is a placeholder post.

When the reason for this post goes live, this post will be updated with all that you need to know. There is probably a better way to do this. At that time, comments will be turned on, too. ;)

Reader Feedback: Analysis of an Exercise

At the end of each "Hour" in the Sam's Teach Yourself Android Application Development in 24 Hours book, there are exercises. We originally designed these exercises to be items people could try to extend their knowledge above and beyond what was learned verbatim in the chapter, given some hints and practice using the the Android documentation that is critical to become familiar with.

Here we present one such exercise that occurs in one of the first real coding hours and present our thought process for determining the solution. Hopefully this will help readers who may be struggling with the difficulty of the exercises. That said, we have also determined, based upon reader feedback, that a handful of exercises in the book are perhaps unfairly difficult. For the next edition of the book, many of these will be replaced or labelled as challenge exercises.

Walk-Through of an Exercise

This is from Hour 7 on page 125, if you'd like to follow along. As it's the end of the chapter, you already would have downloaded the code to work along with in the chapter. If not, it's available right here.

"Exercise #1: Modify the LayoutAnimationController in the QuizSplashActivity class to apply animations of each child view within a TableRow control in random order by using the setOrder() method with a value of 2 (random)."

Key Phrase #1: "Modify the LayoutAnimationController in the QuizSplashActivity"

Thought Process, Step 1: This tells me we're dealing with something to do with the LayoutAnimationController. Luckily, we just covered that on page 122, where we gave this following code:

Animation spinin = AnimationUtils.loadAnimation(this, R.anim.custom_anim);
LayoutAnimationController controller = new LayoutAnimationController(spinin);
TableLayout table = (TableLayout) findViewById(R.id.TableLayout01);
for (int i = 0; i < table.getChildCount(); i++) {
    TableRow row = (TableRow) table.getChildAt(i);
    row.setLayoutAnimation(controller);
}

Thought Process, Step 2: The code goes in QuizSplashActivity. Since I'm in Hour 7, I've been implementing this activity for the Splash Screen for most of the chapter.

Key Phrase #2: "to apply animations of each child view within a TableRow control"

Thought Process, Step 3: So far so good. The code is already doing that. We found the code in the section labelled, "Animating All Views in a Layout."

Key Phrase #3: "in random order"

Thought Process, Step 4: Hmm, I don't know how to do that. Let me read on, finishing the sentence...

Key Phrase #4: "using the setOrder() method with a value of 2 (random)."

Thought Process, Step 5: Oh, that's how! OK, hold on. I have two options: I could look up this method in the Android SDK docs, or just write it based on what was said in the exercise and see what happens. (Note: We prefer you look it up, like a good student, but experimentation doesn't hurt anything, either.) But perhaps we're lazy so... Let me just add that one line of code to the end of the initial listing, which will now look like:

Animation spinin = AnimationUtils.loadAnimation(this, R.anim.custom_anim);
LayoutAnimationController controller = new LayoutAnimationController(spinin);
TableLayout table = (TableLayout) findViewById(R.id.TableLayout01);
for (int i = 0; i < table.getChildCount(); i++) {
    TableRow row = (TableRow) table.getChildAt(i);
    row.setLayoutAnimation(controller);
}
controller.setOrder(2); // THIS IS THE ONE NEW LINE OF CODE, THE SOLUTION TO EXERCISE #1

Run the app and see what happens.... Hey! That's pretty neat. Each time I run it, the animations happen in a different order and sometimes some of them happen at the same time.

Tip: Speeding Up Your Android Emulator Launch

The latest version of the Android emulator comes with a feature called "snapshots." It needs to be enabled as a feature of each AVD. Luckily, this version also includes the ability to edit existing AVDs.

First, enable the feature:

Enabling Snapshots

Second, when launching the AVD, choose to load from the snapshot and save the snapshot. When a snapshot isn't found, the AVD boots up from scratch. As we all know, this takes quite a long time even on very fast machines.

Enable Snapshot options

Now, when you exit, the system will store off a snapshot of the state of the AVD. This takes a little while, depending on how much RAM is assigned to the AVD. After saving the state once, the AVD will now launch very quickly - usually in just a couple of seconds.

However, the exit is no longer super speedy and often triggers "Not Responding" type messages. If you always want to return to exactly where you left off, this is how it will work. Overall, the behavior is much faster. However, if you want it to come up clean each time, just make sure the first time you boot it's clean, then exit to save the snapshot. Now, when you launch the AVD, only check load from snapshot, but make sure save to snapshot is unchecked.

Don't save over old snapshot

Now, the system will just load the AVD from the one snapshot you created and not save the state each time you exit. This means super speedy launches into a cleanly booted emulator as well as super speedy exits since the snapshot doesn't have to be saved each time.

You'll start to feel like you don't need to keep the emulators running all the time. You also won't necessarily go looking for a phone each time just to save the emulator boot-up time. (You'll still go after the phone or tablet when debugging for performance or with code bases that are otherwise slow on the emulator or other such reasons.)

How much difference does it actually make? Here are some test results running on a 6 core 3 GHz desktop with 8GB of RAM and a relatively speedy SSD:

• Cold launch of Android 3.0 emulator to a usable state: 4 minutes 35 seconds
• Snapshop launch of same Android 3.0 AVD: 8 seconds

That cuts the emulator launch time by 97%. Put another way, the cold launch takes 34 times longer. Taking these steps is well worth the minimal additional effort.


Happy Android Coding!

Tip: Installed Application Not Installed Error

Have you ever loaded up an application, ready to debug, but then seen a message along the lines of, "Application Not Installed" display? This usually has an accompanying LogCat error:

ActivityManager: java.lang.SecurityException: Permission Denial: starting Intent

The cause and solution are very simple:

• This error is most likely caused by a duplicate Activity class entry in the manifest file. 

 <activity  
   android:name=".MainActivity"  
   android:label="@string/app_name">  
   <intent-filter>  
     <action  
       android:name="android.intent.action.MAIN" />  
     <category  
       android:name="android.intent.category.LAUNCHER" />  
   </intent-filter>  
 </activity>  
 <!-- lots of stuff -->  
 <activity  
   android:name="MainActivity"></activity>  

The solution should be clear by now:

• Remove the duplicate tag from the AndroidManifest.xml file 
• Build the application again
• Reload the application

This is quite the opposite of forgetting to add an Activity class to the manifest file. And, yet, it leads to a failure just the same. Proper maintenance of the manifest file is important. It's not a file to mess around with.

Happy Android Coding!

Contacts Contract: Intro and Getting Started

If you've been using Android awhile, and have used the Contacts feature at all, you may have noticed that when you push your SDK forward a few versions, many of the calls are now listed as deprecated.

This is because the Android project revamped how the contacts system works in Android 2.0 (API Level 5). The updated system is much more flexible, while also taking a bit more code to use properly. Over at Mobiletuts+, we wrote an article quite a while back that has a quick overview of using the new APIs in context of using the contact picker. Android Essentials: Using the Contact Picker demonstrates how the queries are now often broken up due to increase in the number of internal tables used (or, that's mostly likely the cause).

You can also directly view the open source code for this tutorial.

Tip: New Layout Editor Exceptions

Does your Android Eclipse layout editor look like Figure 1? Does it show "Missing theme." or perhaps an error in the logs (perhaps something to do with "com.android.ide.eclipse.editors.layout.LayoutEditor")? These are frequent occurrences on the very latest Android SDK Tools.

Figure 1
Layout Editor errors
 (Click for large view)

If you're having these types of issues, the solution may be simple. See that empty dropdown on the far right? Perhaps it's not empty, but shows the Android version? Yeah, the one highlighted in Figure 2 shown below... Click on this dropdown and pick one of the options.

Figure 2
Layout Editor Drop Down
(Click for large view)

Does your layout editor now look like Figure 3? If so, you're all set. If not, you'll need more than just this tip.

Figure 3
Layout Editor, no errors
(Click for large view)

Why the new dropdown? We believe that it will show what a layout should look like on various versions of Android platform. So, presumably, you'll want to pick your Target SDK most of the time and if, during testing, you find a problem outside the target SDK, this drop down may help speed up layout debugging.

Happy Android Coding!

New Feature: Book Code Downloads

Many readers have found it difficult to access the book code downloads from the official publisher site. After some discussion with our editor, we are pleased to inform you that we now have them hosted separately and available for easy, direct download. (No login should be needed and certainly no verification that you own the book. But you already bought it, right? :) )

In addition to providing a new source for downloading the files, we have also provided a single download for all of the code for each book.

The download link is convenient found right next to the Home link above, under "Book Code Downloads."

Happy Android Coding!

Discounted Android Books for Purchase

Don't think you'll win a free (signed) copy of Sam's Teach Yourself Android Application Development in 24 Hours from Mobiletuts+? Already have the Sam's book or the first edition of Android Wireless Application Development, but haven't gotten around to buying the second edition?

Well, InformIT is offering up a discount for the second edition of Android Wireless Application Development -- 40% off with the coupon code ANDROID until March 15, 2011. That's a little better than the regular Amazon price. :)

Honeycomb Preview Now Available

Earlier today, I was just telling someone how we lesser mortals almost never get SDKs much in advance of hardware anymore. Well, we just got one: the Honeycomb SDK preview.

And, besides the preview, the SDK tools and plugins have been updated. Sounds like good stuff. Now to go digest it all for an afternoon snack.

Even if you can't use the new SDK, don't forget to update your tools.

After you've digested it, let us know your favorite new features!

Free Android Development Books!

Mobiletuts+ is offering up several signed copies of Sam's Teach Yourself Android Wireless Application Development in 24 Hours. For Free! You could be a winner!

So head on over there and give it a shot if you haven't taken the dive yourself already. Check out Mobiletuts+ for great Android tutorials, many written by yours truly.

Phrasebook Map Intents: Redux

Maps 5.0 at 1024x600 (click)
Zoomed all the way out at z=2

As part of a review of some of our applications we've created as part of articles, we revisited the Phrasebook app found on Google Code. Written with Android 2.2 in mind, the application still runs fine on both Android 2.3 and with Tablet displays (e.g. 1024x600).

However, one strange issue did come up: the geo URLs for the addition of launching maps from Android SDK Quick Tip: Launching Maps In-App don't all work as expected with Maps 5.0. The default one, the world link, used:

geo:0,180?z=1

Sending this actually causes Maps 5.0 to crash. It works fine in Maps 4.2 and 4.7 (available in Emulator 2.2 and 2.3, respectively). The fix? Change z to 2. This is odd, because 1 is documented by Google to show the whole world. (Though, there is a note that the geo URI is still under development. The linked-to document is from 2007, though.) We clearly see in the above screenshot that there are no levels of zoom farther out now.

Next, we wanted to test the rest of the queries to see if any others were affected. Here they are, and the results:

"geo:0,0?q=Belgium": Success
"google.streetview:cbll=46.813812,-71.207378&cbp=1,99.56,,1,-5.27&mz=21": Success
"geo:0,0?q=Matterhorn&z=8": Success
"geo:0,0?q=Coffee Shops near Paris, France":Success

So, it's reasonable to expect the only thing to now avoid are zoom levels of 1. The fix has been pushed up to the repository.

This experience is a great example of the sort of maintenance applications can take. Not only should they be tested on devices with new firmware and SDK versions, but any other applications that they rely on also need to be updated and tested against. Maps 5.0 is not yet found within an emulator, so this testing requires a handset with Maps 5.0 on it.