With the standardization of both command-line and Eclipse builds on having third-party JARs in the libs/ directory of the project, developers no longer needed to monkey with the build path in Eclipse. In fact, changing the build path in Eclipse would tend to cause more problems than it solved.

However, there’s a bug in the R22 version of the ADT Plugin for Eclipse that does require a one-time modification to your build path:

1. Right-click on the project in Eclipse’s Package Explorer and choose Build Path > Configure Build Path from the context menu

2. Switch to the “Order and Export” tab

3. Check the “Android Private Libraries” entry in the list, if it is not already checked

You will need to do this for all projects that have JARs in libs/, though I would recommend that you do it for every one of your projects, just so that you don’t forget about this months from now, add a JAR, and wonder why things are broken. Specifically, by “broken”, I mean that you get a bunch of NoClassDefFoundError messages at runtime.

Also, be sure to apply this fix to any Android library projects you are using (e.g., ActionBarSherlock), otherwise you may get “class hierarchy is inconsistent” errors.

Note that if you are using Maven, this step is not required, apparently. Quoting Xav Ducrohet:

Unless you’re using Maven to build using the m2Eclipse in which case Maven setups those dependencies itself and the container should not be exported.

There is an R22.0.1 in the works that should address this, though whether they will be able to address it for existing projects (as well as new projects) is unclear.

Also, I owe Streets of Boston a beer, as it was his adt-dev post that helped spearhead letting everyone know about this problem and fix.

—May 23, 2013

There are three ways in which Google delivers new APIs to Android developers:

• New SDKs, tied to new versions of Android

• Add-on JARs or library projects, such as the Android Suppor package

• Google Play Services

In the latter case, while we still need to add an Android library project to our app, some (if not most) of the business logic is in the Play Services app, with the library simply providing a local API wrapper around the IPC to that other app.

It is obvious from Google I|O 2013 that Google is going to place new emphasis on the latter two modes of distribution. This is not to say that the Android OS will not advance – far from it. However, whereas we used to get all new capabilities via new SDK releases, more of those capabilities will be delivered independently of OS updates.

As usual, this is a double-edged sword.

Part of the stated rationale for this is to reduce fragmentation a bit. Anything added to a traditional library – such as the new DrawerLayout in the Android Support package – can be added by developers to apps running on a range of OS versions. Anything added to Google Play Services can be pushed by Google to whatever devices they choose, whenever they want.

In this respect, Google is trying to adopt an architecture a bit more like Firefox OS’s, where the true “firmware” controlled by device manufacturers is thin, with framework code distributed separately on top of it. The objective is to minimize the number of true firmware updates, allowing for more rapid innovation at the framework level, while not requiring the end-to-end ecosystem control seen with iOS.

And this would be wonderful, except for one small problem: Google Play Services is proprietary and is controlled purely by Google. That has many ramifications, including:

1. We do not know what the code does. Part of the interest in Android has been its open source nature, for everything from cobbling together workarounds for bugs to vetting the privacy and security. This is far less possible with a closed-source Google Play Services.

2. Google controls which devices get Google Play Services and when. Hence, Google will be the one to decide when older devices no longer get Play Services updates, not the users, and not the developers. Also, Google can push updates whenever they want, and those updates will immediately affect apps that use Play Services… and those updates may include bugs.

3. Google Play Services is not freely distributable. It, like the rest of Google’s proprietary app suite, is only available to licensees. Hence, you will not find Google Play Services on devices like Amazon’s Kindle Fire. You will not find Google Play Services in ROM mods, unless they either have somehow managed to license it or they are distributing it outside of any license.

(and if some ROM mod maintainer has successfully licensed this code, somebody let me know, as I have tried licensing it for use with a ROM mod and Google ignored me)

And, closely related to the previous issue, developers who wish to support non-Play Android devices will either need to eschew the abilities from Google Play Services, write workarounds, or reimplement them.

Google’s counter-argument – that Google Play Services would only contain code that would have been proprietary anyway – does not pass the smell test IMHO. After all, all code ever written would have been proprietary anyway, had somebody not elected to release it as open source. Even for places where the code already existed in proprietary form (e.g., the fused location provider, apparently culled from Google Maps), the rewrite to allow that code to be used by third parties would have changed it enough that the fact that it started as proprietary should have no effect on decisions going forward. And particularly in the case of the fused location provider, I have difficulty believing that there are reasons that justify having it in Google Play Services instead of the Android Support package.

Ken Kinder recently wrote a blog post about migrating from Google services, where he opened up with:

Looking back on Larry Page’s tenure as CEO, I don’t know if it’s a coincidence but it seems reasonable to believe that, unlike Eric Schmidt, Page does not believe in open standards or an open Internet.

I’m not yet ready to append “or open source” to that statement, but I am getting worried.

—May 22, 2013

In Reto Meier’s 2013 Google I|O presentation, he referred to a concept he called the “uncanny app valley”. While most incarnations of the “uncanny valley” refer to UI, his “uncanny app valley” refers to permissions and general creepiness. Mr. Meier had a slide in his presentation depicting a generalized creepiness chart, complete with a valley representing a creepy app, and with an upslope to the right showing apps that know a lot about you but, in Mr. Meier’s eyes, are not creepy at all. In particular, Google Now was his example of a non-creepy app.

I found that to be a curious example, considering that I went to the level of disabling Google Search on my Galaxy Nexus just to get rid of Google Now, as it is entirely too creepy for my taste.

The truth of the matter is that there is no universal creepiness curve. Different people will have different attitudes towards privacy. Some will not worry a whit about it, aiming for maximum app capability. Others will find Google Now and similar apps to be too invasive.

Branding will have a lot to do with it as well. Apps from brands that users trust will be more likely to escape the “uncanny app valley” than will apps from unrecognized developers or brands that are not trustworthy. So, for example, I am willing to give Evernote a lot of permissions that I do not give out otherwise. At the same time I am still hunting for a decent Twitter client that does not ask for the sun, moon, and stars from a permission standpoint. I have greater trust in Evernote than I do in Twitter, and I have greater trust in Twitter’s own apps than I do closed-source high-permission Twitter clients from other developers.

(Murphy’s Law, of course, suggests that Evernote will get acquired by somebody I distrust at some inopportune moment…)

Hence, while Mr. Meier advocates things like location tracking to help apps deliver “magic”, that may not be in your best interests. Each additional permission that you request serves as a filter, with some percentage of your potential audience electing not to install your app due to that permission. How big that percentage is will vary, based upon permission, branding, available substitute apps, and so forth.

Savvy developers will consider allowing users to “dial in” the amount of privacy they are willing to give up, by delegating privacy-invading permissions to plugins. Since Google has demonstrated no interest in allowing users to control permissions individually per app (and since only so many people run ROM mods that offer this), plugins are a likely approach for keeping your main app light on permissions, yet allowing users to opt into additional functionality with only a bit more work on their part. Cutting the work for developers to support this sort of plugin model is on my ever-popular to-do list…

Certainly, “magic” is an app implementation metaphor of some value. However, if giving your app “magic” means raising privacy and security concerns in prospective users, consider how you can best mitigate those concerns, either by adopting a plugin model, or trying to balance exactly how “magical” your app becomes.

—May 19, 2013

It’s been less than 24 hours since the Android Studio “early access preview” was released, and IMHO way too many people are trying it, based on the flood of questions coming into StackOverflow.

IMHO, to be using Android Studio today, you either need to:

• Be a current user of IntelliJ IDEA, so that you know how the basic IDE should work and can see where IDEA ends, Android Studio begins, and on which side any particular problems with Android Studio lie, or

• Be a very expert software developer, with experience in a variety of IDEs, above and beyond a year or more of Android programming experience

If you do not fit into one of those two buckets, leave Android Studio alone for the time being.

If you want to start getting a feel for what Android Studio will do for you, try out IntelliJ IDEA. The open source Community Edition already has a fair bit of Android development integration, just not as much as Android Studio will eventually offer. Later on, when you are fairly comfortable with IDEA, Android Studio hopefully will have matured enough that it will be worth your experimentation.

If you are an IntelliJ user, or are a seasoned veteran, and you want to start experimenting with Android Studio, be my guest. Just bear in mind that this is a 0.1 release, and as Xav and Tor mentioned in the Google I|O presentation, Android Studio is broken in many places. More so than is normal in Android, the expression “your mileage may vary” applies. You might consider trying the IDEA 13 early access preview first, as I get the impression that Android Studio is based upon it, so if IDEA 13 is giving you grief, Android Studio is likely to give you yet more grief.

—May 16, 2013

I am sure that the first thing that crossed your mind when you heard the announcement of Android Studio is “when will that balding guy be covering it in his book?”

Well, OK, maybe that wasn’t the first thing that crossed your mind, but it sure as $BLEEP was the first thing that crossed my mind.

Over the next several months, I’ll add some chapters covering Android Studio and the new Gradle-based build system, in a new trail in the book.

Once Android Studio is “for realz” — meaning that Google drops the “early access preview” label and starts pointing people to it in earnest — I will work on “mainstreaming” Android Studio and the Gradle-based build system coverage, notably in the tutorials. The set of chapters I write originally will remain for a while, aiming at people migrating to these new tools from Eclipse and/or the classic build system. Other chapters will be added covering advanced topics related to the new build system. However, since I have no real idea how rapidly Android Studio will move from 0.1 to “for realz”, I do not know how quickly this “mainstreaming” will occur.

Another wrinkle will be if they start shipping support for the new build system in Eclipse before Android Studio hits “for realz” status. In that case, I may wind up rolling out the new coverage in stages, updating the tutorials and such first for the new build system, then updating it later for Android Studio.

Unfortunately, this will take a lot of time, time that’s going to come out of advancing the book in other areas as quickly as I’d like. I apologize in advance for that.

—May 15, 2013