When you're working with an Android app that will be used in a variety of markets, localization is an important feature to support the different countries, date formats, number and currency formats that are used around the world. Android has deep support for localization which you can read about in great detail.

In iOS, in order to add support for a language, you add languages to your project properties in an explicit way. In Android, adding support for a language is more implicit -- you simply start localizing resources. This is easy to use but it creates a problem where you might have partial support for a language in place but not be ready to take that support live. Android doesn't offer a means of explicitly listing which languages you wish customers to have access to. This can lead to situations where you have to keep localization resources on a branch or out of source-control or otherwise limit how those files are managed. That's viable but it isn't a great fit for every workflow.

On a recent client project, I did a little work with Gradle to make supported languages more explicit.  I added a list of supported languages in the build.gradle, used resource shrinking with resConfigs and exposed the languages to Java in BuildConfig using buildConfigField:

// Approved Languages
def approvedLanguages = [ "en", "ru" ]
resConfigs approvedLanguages
buildConfigField "String[]", "APPROVED_LANGUAGES", "{\"" + approvedLanguages.join("\",\"") + "\"}"

By exposing the approved languages to Java, it was possible to use it localization code, for instance to only localize dates to languages that are in the supported language list:

public class LocaleUtils {

     public static boolean isSupported(Locale locale) {
        for (String language : BuildConfig.APPROVED_LANGUAGES ) {
            if (locale.equals(locale.getLanguage()))
        for (String language : BuildConfig.APPROVED_LANGUAGES) {
            if (language.equals(locale.getLanguage()))
                 return true;
         }
         return false;
     }

     public static String localizeLocalDate(LocalDate localDate, String format) {
        return localDate.toString(
                DateTimeFormat.forPattern(format).withLocale(getDefaultSupportedLocale()));
        Locale locale = getDefaultSupportedLocale();
        DateTimeFormatter formatter = DateTimeFormat.forPattern(format).withLocale(locale);
        return localDate.toString(formatter);
     }
}

With this in place, we can start working on a new locale, integrating translated strings and graphics in the main line of development and know that they won't be exposed to customers until we're ready. With a little work, we could also use a different list of supported languages on a debug and production build.

Android developers: are you using Kapeli's Dash to read Android docs on a Mac? Want to be able to search for inherited methods without hitting "expand all" first? Request it!

@geoffreywiseman I might change it to auto-expand depending on how many users request it. So far you're the first one.

— Kapeli (@kapeli) September 24, 2015

Ars Technica's "Google's Iron Grip on Android: Controlling open source by any means necessary" is an interesting look at some of the problems that Google faces with Android and some of the strategies they've had to employ along the way.

Google has had to take a very interesting position with Android because they didn't really want to be in the mobile phone business, they just want to protect themselves from the Mobile business changing the business they are in too drastically. Google's business depends on the health of the web, and Google's place in that.

In order to protect their position, Google doesn't want to rely too heavily on the goodwill of others, any more than Apple does, although I don't think that's as ingrained in Google's DNA as Apple's. Android, for Google, is about ensuring that they have a say in the evolution of the mobile phone and mobile device market and how that has an impact on Google. They were willing to give away a fair amount of value in this new market as long as it helped to support Google's existing business.

Exerting enough control over an open-source project to meet your own objectives is a tricky thing, and Android has always had to walk that line carefully by being a hybrid of open and closed source models. Much of the development of new versions of Android is done completely in the dark, with code only being open-sourced near the release date. Portions of the overall Android experience are wholly dependent on proprietary closed-source Google applications and services which are only available to you if you meet certain conditions. You can build an Android device without these, but not without a significant investment in filling these holes.

The emergence of out-and-out-forks that do exactly that has encouraged Google to continue to seek more leverage over the Android ecosystem by moving features into closed-source applications and tying them to Google services, which they can control more completely.

Ars Technica has done a typically solid job of covering those problems and some of the solutions Google has employed, and it's a worthwhile read.

At Google I/O 2013, Google announced the availability of Android Studio, an Android development integrated development environment (IDE) based on IntelliJ IDEA.

Thus far, the primary target of Google's IDE integration efforts have been focused on Eclipse, the predominant Java IDE. Google has Eclipse plugins for GWT and AppEngine, Android, Dart, and possibly other projects I'm forgetting. So it's a bit of a surprise to see Google focusing so much energy on an Android Studio based on IntelliJ IDEA.

Google's being circumspect at this point in terms of how they talk about Android Studio. It's an early access preview. There's no clear language on whether or not ADT is now deprecated, replaced by Android studio, although rumor has it they will support both. Even if Google publicly commits to continuing development on both Android Studio and ADT, will one of the two see the lion's share of the investment? Will one languish while the other flourishes? Only time will tell.

Android Studio is a new set of plugin APIs, a new windowing toolkit (Swing vs. SWT), a new ecosystem, a new set of related plugins to consider integration with. There would be a lot of effort in supporting a new IDE integration for IDEA, even given that JetBrains had already started the work by supporting Android development in the first place. It may confuse new Android developers who now have to choose between two IDE options without identical feature sets. It will create a whole new support channel for people with Android Studio questions. At this point, they're still recommending ADT as the mature choice, but it seems like it won't be long before the decision is less clear-cut.

For a company that's talked repeatedly about putting more wood behind fewer arrows and focusing their efforts, supporting two IDEs for mobile development seems unnecessary, excessive.

So why are they doing this? Are they just so intent on getting developers to Android that they believe they need to support two distinct Java-based IDEs? It doesn't seem likely that there are enough dyed-in-the-wool IDEA supporters who want to build Android apps, but are unwilling to do so in Eclipse to justify the move.

It seems more likely that they have decided to switch horses midstream, and are backing Android Studio over the long haul and supporting ADT for now simply because it's too early to get people to switch and it's expedient and politically sound to wait until Android Studio is overwhelmingly better.

But if that's true, what about the other Eclipse plugins that Google supports? And why switch the build system to Gradle? There are lots of questions, few answers. I am interested to see how this feels in a year or two.

Dave Winer suggests that using iOS has a flip side -- Apple controlling mobile through the App Store:

Right now it's the only open source mobile OS that has a chance against IOS. If there is no alternative to IOS then Apple will have exclusive control over what makes it to market. That is a future none of us should want to live in.  

...

I don't like Google any more than I like Apple. But at least they don't control the channel of apps to users of Android. That's a huge deal. It makes up for a lot of Android's inadequacies. And if Google fucks us, let's find another home.

John Gruber points out that you could argue the Flip Side to Android is your loss of privacy to Google:

But, to quote Neil McCauley, there is a flip side to that coin. Winer’s perspective is that Apple is the bigger threat. A different perspective would be that Google is the bigger threat, and that using Apple products is a way to better protect our privacy and personal information. 

Fear of Apple is about losing control over the software on our computers. Fear of Google is about losing control over our privacy.

These are both good arguments.  Apple's control over the App Store has some positive effects, but it's clear that it puts a lot of power in Apple's hands and they can and will make capricious decisions that we may disagree with.

Google absolutely wants to know as much about you as it can and sell you in aggregate form to advertisers. That's their business, and if you don't like that, then storing most of your personal information on Google's services is probably scary.

I think it's a mistake to link Android only to Google. As has become entirely clear, the open-ness of Android is to be open to the manufacturers and carriers who often close it with respect to its customers. Putting your faith in Android is not merely to trust Google, but to trust Motorola, HTC, Samsung, etc. and Verizon, AT&T, Telus, Rogers, Sprint, T-Mobile, Orange, etc.

Pre-iPhone mobile phones were entirely controlled by the manufacturers and carriers. The iPhone was in many respect a great liberation the mobile phone market. Although Apple retains the same powers that the manufacturers and carriers once did, they attempt and mostly succeed to use those powers to improve your experience as a mobile customer (and secondarily to profit from it), and they keep everyone else's hands outside of the cookie jar.

Putting your faith in Android is putting your faith in the mobile phone ecosystem that kept a stranglehold on your phone for years and years before Apple came along. If you think those people are more trustworthy than Apple, you're probably drinking the Open kool-aid.

If Google used its Android powers to force the carriers to make the software open to their customers, to allow people to install whatever they want without worrying about carrier agreements, to prevent spyware installed by carriers, to encourage phone manufacturers to update to the latest version of Android -- if Google was open to customers then maybe I'd agree.

For me, Dave Winer's argument doesn't hold water. I don't see the value in wresting control away from Apple just to hand the power to a larger and shadier group of companies.

Is Android “Open”? What does that mean? Is that changing? Does it really matter if Android is Open?

It's hard to open a web browser or twitter client these days without running into one or more of these questions, so I'm going to take a deeper dive into Android and Open and see if we can give some meaningful answers to any of these questions.

Is Android Open?

Google Says Android is Open

Android is an open-source project, and right from the beginning, Google positioned it as “the first truly open and comprehensive platform for mobile devices”, “without the proprietary obstacles that have hindered mobile innovation.” Google continues to position itself as open, such as the keynote address of their most recent developer conference, Google I/O 2010: “So if you believe in openness, if you believe in choice, if you believe in innovation from everyone, then welcome to Android.”

What does Open mean for Android?

“Open” is a difficult-to-define concept. It means a lot of different things to a lot of different people, and in any conversation about Open, you can probably guarantee you'll find two people using a different definition and arguing about it. So whenever you're having a conversation about 'Open', it's vital to make sure that there's a definition involved.

Unfortunately, for Android, there's really no such definition. There's no clear, concise and consistent definition of what Google means when it says Android is open. This is bound to cause some confusion, and it has, repeatedly. If you look over all the ways Google has used the word and how they've behaved, it mostly seems to come down to a few things.

Android is an open-source project. You can go to the android web page, download the source, build it, and you've got your very own copy of Android. The license allows you to make changes to that code, allowing you to customize Android for your own needs.

If you're a manufacturer or a carrier, this means you can start with stock android, then customize it for your needs and the needs of your customers, the carriers. You can add a look-and-feel that makes your phone look a little less like the phone made by another manufacturer. You can provide software add-ons specific to a particular carrier or partners of that carrier.

Of course, if you're not a manufacturer and a carrier it gets a little more complicated. You can of course still get the Android source code, but what are you going to do with it? Just having access to the source doesn't mean that Joe User has any hope of tweaking their handset through access to the code.

Finally, Android is typically pretty open to controlled user customization. Google doesn't assume that they know how your phone should work, they allow you widgets and themes, alternate keyboards, and all sorts of customizations that Apple's iPhone does not. This is still pretty limited in its effect, but if Apple's defaults don't work for you, this might be something of real significance to you.

What doesn't Open mean for Android?

Because open means so many different things to so many different people, it's nearly impossible to enumerate all the ways in which someone might not consider Android open, but there are definitely a few limitations that Google has made clear or that have become evident over the course of Android's history.

Carriers and Manufacturers can customize the experience in ways the customer can't change. If a carrier wants a particular application added to your phone in such a way that it cannot be removed, that's something that Android allows them to do. Android is open to the customization of the carriers and manufacturers even if that runs counter to the desires of a given customer, or even customers in aggregate. Wired Magazine says, “In other words, while you might be able to copy and paste the code from Rubins' tweet and take a look at Android yourself, what arrives with actual phone is every bit as tightly controlled as iOS.” TechCrunch's “Android is as Open as the Clenched Fist I'd Like to Punch the Carriers With” argues this point vehemently.

Google writes the vast majority of Android code internally, controls all commits to the public source tree, allowing very few contributed patches, and maintains private repositories that are significantly ahead of what is publicly available and beyond the published roadmap; Stephen Norcott adds, “therefore essential for an OEM to stay competitive.”

Compatibility is required in the form of a compatibility test suite, as well as controlling the use of Google's closed-source Android apps (Gmail, GTalk, Android Market). The restrictions allowing the use of the Android market remain unpublished (“Unfortunately, for a variety of legal and business reasons, we aren't able to automatically license Android Market to all compatible devices.”)

Google controls the Android trademark and branding. They require you to use their location services, not someone else's. There's an anti-fragmentation agreement, the details of which are largely unknown, but which may be moving towards a more central role. Quoting Stephen Northcott again, “In short, it's either the Google way or the highway. If you want to branch off Android you're completely on your own and you need resources of the size of China Mobile.”

Joe Hewitt's tweet on the subject strikes to the heart of it, “Rubin bickering with Jobs is a farce, because both refuse to share the one thing that matters: control.”

Why doesn't Google define Open for Android?

Why is Android's definition of Open not more clear? It's hard to say. I could argue cynically that Google prefers to wrap themselves in the mantle of 'open', and get all the positive attributions of the word, ignoring the fact that not all of them are a good fit. I suspect it's more likely that defining 'open' for any context is difficult and prone to causing arguments, so they've simply avoided doing so.

Does it Matter?

Who Cares if Android is Open?

It seems clear that some portion of consumers with Android phones have them precisely because they feel Android is a more 'open' platform. It's also clear that Android's version of Open Source doesn't always live up to the expectations of open-source advocates (see Joe Hewitt's commentary, for instance). If Google seems to be stepping further away from 'Open' with Android, those people might not see the value in Android handsets, or, worse, feel betrayed.

Similarly, if handset manufacturers got into the business of making Android devices because they felt like they were partners in the platform, not constrained by the whims of a software manufacturer they didn't control, they might feel as if that's no longer true. The manufacturers risk being commodities, easily replaceable, companies that make devices more strongly associated with Google. They might start looking for alternatives, either by building their own operating systems or by leading a revolt against Google on Android (start by replacing the Google Android Market with the Amazon Appstore, which now comes preloaded on the HTC Merge; continue by replacing the Google Search Engine with Bing and keep on going).

Does Open make or break Android?

Does Android succeed fully or in part because it is Open, or is that simply an unrelated fact? To what extent does Google's openness with Android affect its continued success? It's easy to argue, as Stephen O'Grady does, that Apple's iPhone proves that it's entirely possible to get traction in the mobile marketplace while using a closed ecosystem. Of course, Android is positioned differently than iOS, and unless Google's willing to drop the Open Handset alliance and start treating the manufacturers as Apple does Foxconn, then Google needs some cooperation from other companies.

Ultimately, it's the relationship with the manufacturers and carriers that Google needs to cultivate. If possible, it would be great if Google could avoid excessively irritating open-source advocates, some of whom buy Android phones, but I think Android would continue to be viable, even successful, if every open-source advocate refused to buy their devices. Android can succeed with or without 'open.' Using O'Grady's words, “it is difficult to build the case that Android's governance will read on its outlook.”

While 'open' is one way to pitch your operating system to the manufacturers, I think “free” (as in beer) and “good” goes a long way, particularly if you continue to allow the manufacturers to differentiate themselves, albeit perhaps in a more controlled manner than they have been.

Is Android getting Less Open?

Is Android changing to become less open? You could argue that point, and many currently are. The source code for Honeycomb, Android 3.0, has not yet been released, Google is moving to exert more control and reduce fragmentation. Some even argue that this amounts to a bait-and-switch where Google gains traction for Android by offering openness, only to snatch more control as soon as it's too entrenched to be easily discarded.

Honeycomb isn't Open

Android 3.0, Honeycomb, is appearing on Android tablets, yet Google has not yet open-sourced the code behind it, explaining:

To make our schedule to ship the tablet, we made some design tradeoffs,” says Andy Rubin, vice-president for engineering at Google and head of its Android group. “We didn't want to think about what it would take for the same software to run on phones. It would have required a lot of additional resources and extended our schedule beyond what we thought was reasonable. So we took a shortcut.

One could argue that if Google were to open the source code, they could issue the same warnings, and let potential adopters make their own decision, but that Google isn't willing to trust them to make that decision correctly:

While we're excited to offer these new features to Android tablets, we have more work to do before we can deliver them to other device types including phones. Until then, we've decided not to release Honeycomb to open source

Since Andy Rubin provided a definition of 'open' for Android — that you can download and build Android from source code — you can argue (as does the Register) that by that very definition, Android 3.0, Honeycomb, isn't open.

Despite the stir that holding Honeycomb back has caused, this is not a particularly new development for Android, similar complaints go back to at least 2008; Google often develops Android behind closed doors, and gives access to those private repositories sparingly, only releasing the code to the open-source Android project later. This might be the most visible occurrence, but it's certainly not the first.

Anti-Fragmentation isn't Open

Although Google has had anti-fragmentation measures in place before, recent news strongly suggests that they're going to be much more strict in their enforcement, requiring manufacturers to seek Google's approval. The implication seems to be that Google will be encouraging the manufacturers to deliver devices that are much closer to the stock Android experience than has previously been the case:

Playtime is over in Android Land. Over the last couple of months Google (GOOG) has reached out to the major carriers and device makers backing its mobile operating system with a message: There will be no more willy-nilly tweaks to the software. No more partnerships formed outside of Google's purview. From now on, companies hoping to receive early access to Google's most up-to-date software will need approval of their plans. And they will seek that approval from Andy Rubin, the head of Google's Android group.

The Bait and Switch

If Android threw on the mantle of Open to get traction, and has now thrown it off to wield the cudgel of anti-fragmentation, is this really just a bait-and-switch manoeuvre? John Gruber thinks so:

So here's the Android bait-and-switch laid bare. Android was “open” only until it became popular and handset makers dependent upon it. Now that Google has the handset makers by the balls, Android is no longer open and Google starts asserting control.

Not everyone agrees. Seth Weinstraub (Fortune) and Chris Lindsey (Chris Conundrum) argue that you can't complain about fragmentation on the one hand and then complain that anti-fragmentation measures make Android not open on the other:

See the problem? They complain about an issue (fragmentation or a good tablet and phone operating system), but when a solution is put in place, they complain about the solution and tell you why their iPhones/iPads are so much better.

It's not hard to see that there's a conflict inherent in Google's position. It can't do all the things it wants to do well, because being truly open almost always results in fragmentation, and trying to control fragmentation is likely to put your openness at risk. Google can't help but contradict itself. The android open source project page still claims:

We wanted to make sure that there was no central point of failure, so that no industry player can restrict or control the innovations of any other.

And in 2010, Rubin, speaking to PC Magazine, said:

If I were to release an operating system that I claimed was open and that forced everybody to make [phones] all look the same and all support very narrow features and functionality, the platform wouldn't win. It wouldn't win because the OEMs have a lot of value to bring and the carriers have a lot of value to bring, and they need a vehicle by which to put their interesting differentiating features on these things.

And yet, Google seems to be trying to control the innovations of the manufacturers, trying to make the phones look closer to one another.
Essentially, Google's trying to find a middle-ground between fragmentation on one side and openness on the other. Google has let the manufacturers have their way so far, and has decided they need to exert a little control to fight off fragmentation while still retaining as much openness as they can. It's a hard path to follow, and I don't expect Google to get it right every time, but I do think there's a number of ways that Google could make life easier on themselves.

What Should Google Do?

Google is seemingly caught between a rock and a hard place. Seth Weinstraub says that Google can't catch a break. If they let manufacturers deliver the custom experience they want to deliver, then Android is “fragmenting” and everyone complains that the handset manufacturers don't update their handsets. If they try and rein in the fragmentation, then Android “isn't open.” They have a few choices, some of which aren't compatible with the others.

Work with Manufacturers

The manufacturers remain important to the success of the Android ecosystem. Google needs to keep these relationships strong and healthy. Don't worry too much about the media, particularly the tech media, and even the public as long as HTC, Motorola, Samsung etc are all on board. If those companies keep turning out strong Android devices, the carriers and the public will continue to buy them.

While Google probably can't convince the manufacturers to stop thinking about controlling their own destiny by building their own operating system, a great experience with Android will probably keep the in-house operating system on the back burner, as a plan B. The manufacturers really just want to sell phones, and if building an operating system is too painful and too costly when compared to what Android offers, they just won't bother.

Simpler Messages

“Open” is complicated. It means a lot of things to a lot of different people and discussing it leads to arguments. It's also true that the vast majority of the phone-buying public doesn't care about open. It's a good idea for Google to fall on the side of open, to have Android be the phone of choice for advocates of open (of various stripes), but it shouldn't be the defining message of Android.

It's time for Google to figure out what Android stands for and how to communicate that simply and clearly, both to the technical and 'open' audiences and to the public as a whole. I don't think that “Open” is, or should be, a big part of that.

Embrace Open

If Android being Open is a really big deal for Google, then embrace it, go all the way.

Make sure that every developer can see the changes you're making that are six months out, let alone major releases that are already in the hands of consumers. Share your source code with everyone, don't keep private repositories. Encourage developers to contribute code, loosen up commit rights. Put your roadmap in the open. Let handset manufacturers do what they want with the interface, no matter how terrible it really is. Let Android be a beacon for 'open' and try and solve the rest of your problems in some other way that doesn't restrict the openness of Android.

This will let you continue to frame Android as the open alternative to iOS, and take the high ground. It'll appeal to a certain segment of your technical customers, and presumably to the carriers and manufacturers. It might cut into your profits if the manufacturers cut deals to put Bing on your phones, but that's the price of open.

Partner with an Open Manufacturer

If Google were to replace open, they should find a manufacturer who's really willing to partner with them, over the long term, on being open. The manufacturer could deliver stock Android phones, work on the public codebase with Google, making visible improvements to Android as a whole, deliver OTA updates to their handsets as soon as is feasibly possible and generally promote the experience of Android. If you can prove to the public that stock Android is better than the manufacturer-differentiated version, then other carriers will follow suit, and even if you can't, you'll encourage customers who do care about open-ness and fragmentation to put their money where their mouth is.

Shut Up about Open

Google could simply shut up about 'Open'. It could use tightly-controlled language, continuing to refer to the Android project as open-source, but not trumpeting its benefits, nor framing Android vs. IOS in the terms of 'open' and 'closed'. At this stage, it's questionable whether or not continuing to frame Android as 'open' is beneficial or harmful. Stephen O'Grady writes:

Google's outspoken defense of the project's governance has predictably set high expectations for source code availability and the ability to participate. The benefits of this approach are debateable: leverage of the term open appears to offer marginal soft benefits in mobile against a hard cost of negative public relations and developer sentiment.

If Google were to back away from the positioning of Android as 'Open', taming down the way they talk about Android without changing their behaviour significantly, it would slowly lead to people complaining less about Android's lack of openness — they would be harder-pressed to pit Google's behaviour against its words. There would always be some who'd complain about Android's openness, just as there are people who complain that Apple's iPhone is proprietary, but if Google were to shut up about 'Open', this would quieten to a vocal minority.

When even the BBC suggests that being open is the first step on that path to malware, you have to question whether or not it's worth Google's trouble to champion openness. Quoting Jonny Evans (Computerworld):

It really is time to cease the "Android is open" mantra.

In Summary

To be honest, I don't think Google will do any of these things. I think they're going to keep trying to walk the fine line, talking the open talk, but having trouble walking the open walk as much as they'd like to. I think they're likely to make some ground on the fragmentation side while continuing to develop behind closed doors, refusing to loosen their grip on commit access, and generally making a bit of a mess of things.

I think this will result in a regular ebb and flow in news about Android and how they are or aren't open, little controversies like the Honeycomb source not being released and new efforts to control fragmentation.

I also think Android will continue to do well in spite of all this, because despite all of the above, I don't think that being strictly open is fundamental to Android's success.

But if somewhere in these three thousand words, I was able to clarify for or persuade some of you, then I'm glad I wrote it.