Android changed a lot since its first release, for both users and developers. Some changes were about user interface, others about software architecture and design, but all have a something in common, we can learn a lot about the decisions Google engineers and executives made.

Google Play Services

There was a rumor about a GPhone being developed by Google between 2005 and 2007.

What Google really did was buy and then develop Android, a mobile operating system and platform, along with the founding of the Open Handset Alliance, a consortium of companies devoted to advancing open standards for mobile devices. Eventually Android’s source was released by Google under open source licenses.

Since its inception it was clear the close relationship between Android and Google, as one of the early presentations promptly showed the Contacts app opening an address in a map, a Google Map.

So the Android operating system is free for use by any manufacturer, but if they want to pre-install those cool Google Apps, they should agree on Google’s terms (I will talk about this controversial topic later).

In 2012 Google released Google Play Services. Both an app, background service and client library (closed source and proprietary package) that provides access to Google-powered services (e.g. Maps) for Android devices. This would make rollouts faster than waiting for manufacturers and carriers to release Android OS updates.

From a developer point of view, do you remember how you used to get a device’s location? You probably used Location Services from the android.location package. If you need to do that today, it’s highly likely that you will use Google Play Services Location API which package is com.google.android.gms.location.
So what’s happening there? Google provides services to make more accurate and fast location detections and needs you to use the Google Play Services library to access them. If the client side code needs any enhancements, Google is able to make updates faster than ever (those updates are pushed silently through Play Store).

Is there any possible bad side of this? If you intended to make your app for any Android fork (which does not have Play Services, such as the Amazon Fire Phone) your code won’t work. And seeing the market share you may decide to drop the idea of a release in that market (Or you may make a no Google version of your app, which will cost in terms of time and effort).

Lessons learned?

Do your best for your business. Is it possible to encapsulate your services, make rollouts faster and developers lives easier in your platform? Do it. Each Play Services release makes APIs such as Play Games, Location API, Maps, Cloud Messaging better.
Flip side of the coin, beware of your dependencies. Are you making games targeting huge markets like China? In some of those markets, Android phones without Google Apps is the norm, so you may do your version adapted to that, maybe using Chinese services or ecosystems (imagine alternative app stores, games scoreboards, etc).

More about android forks, Google Play Services and Google licensing terms.

Material Design

Being a long time user of the platform, I can say that Android UI used to be many steps behind iOS. Worse animations, not so much harmony in color palettes and (not to blame Android itself) different apps with different UI approaches.
All this changed with the definition of Material Design, new guidelines from Google for both Android and the Web. Seeing the specs everything looked great and promising, focusing on effective design, material surfaces, user actions and motion.

Developers realized that many goodies were not yet provided by any official library or framework, making designers and developers to implement handmade versions of Material Design components (or some shared libraries by other fellow devs), such as the Snackbar, the Floating Action Button to name some.

Eventually Google released most components but we still wait for some official implementation to get Delightful Details animations in our apps (now Creative Customization). (There are some non official alternatives)

Lessons learned about this huge change?

Embrace change, even if that involves defining new rules and changing almost everything in your project. Android needed a UI refresh and Material Design did it. Almost any Android developer had to change their app’s UI and many realized (or measured) that it was for good.

WebView

Many Android apps use WebView to display HTML content. But through the years it was a source of problems for both developers and users. In some cases what could be done on those WebViews was kind of limited because of the ever evolving nature of browsers. So you may have had problems playing html5 videos on your WebViews because those were not supported yet in your version.

The root of these problems were that the WebView, being an Android API class, was determined by the current version of the operating system. Knowing how slow is the general process of updating the Android OS version we could realize that many devices around were providing out-of-date WebViews.

Many projects came around to solve this problem, like Crosswalk, which mission or motto is:

Enable the most advanced web innovations with the Crosswalk Project web runtime to develop powerful Android and Cordova apps.

Seemed quite right and worked far better than any stock WebView, but the problem was that each app using Crosswalk had all its code inside (imagine, an entire web engine in your app for just a neat WebView you wanted to show).

In Android 5.0 Lollipop, Google solved those problems making it possible to update WebView independently of the Android OS. So any enhancements and bugfixes Chromium gets, will fix the System WebView as well.

What can we learn from the Android System WebView other than using it knowing that it will be kept updated across devices?

Whenever you use or provide a technology in a fast pace environment (in this example HTML5 browsers), try your best to make it possible to release at a proper rate
Google did it by separating the WebView implementation from the Operating System (even though there is a base implementation in any Android device) and by providing updates through Play Store.

Permissions

Since its beginnings iOS apps have been different than their Android counterparts. During the installation process the user did not have to make any choice about permissions, so those apps would eventually ask for permissions when necessary (well, at least under developer criteria). Many ways have been discussed to approach this ). We are talking about permissions to access your Location, Calendar, Photos, and other private information.

In Android it was necessary for the user to accept all permissions required by the app at the moment of install. Some apps suspiciously required more permissions than apparently they needed (some of them confirmed malware). Others like Facebook Messenger asked for many permissions that it would legitimately use but made some users dubious about installing it.

There where some ways to handle permissions one by one, with rooted phones, with a hacky way to get it on un-rooted phones, or with a hidden permissions manager called App Ops in Android 4.3.

What about a much more ‘native’ way to do so? Android 6.0 (API level 23) introduced a new way to manage permissions. Users now grant permissions while the app is running not when they install the app. Also users can now revoke permissions in the app Settings menu as their iOS counterparts.

From a user point of view, now it is possible to control at some extent what an app can access. From a developer point of view, well, targeting API level 23 now involves wrapping many features up with request & handling permission code, making the code a bit illegible and without forgetting about the correct UX approach.

What can we learn about this permissions change?

This is all about timing, at first, when Android needed users and developers, it was a clever choice to ease it out for both users and developers. But things change, user awareness raises, virus and spyware apps appear, so better to make your platform more secure, even though it will require a bit more work from developers. (Staying open-minded, some think this is a mistake with no benefit for users).

---

 

That was a list of changes that taught me how to be a better engineer. There are more changes that did the same to me, like how emulators improved (especially third party ones like Genymotion), Android Studio replacing Eclipse, ART and the introduction of the JobScheduler to name a few.

Do you remember other cool and worthy changes in the Android platform during its history?