Today I had the pleasure of attending the second day of AnDevCon Santa Clara. It’s my second time at this conference and it was just as interesting and intense as before.
Although advertised as a secret, the topic turned out to be obvious: the new Nexus phones (5x and 5p), the features of Android M and the features of the Android Studio 2.0 preview.
But first, a glance at the magnitude of the Android phenomenon: 1.4 billion active devices. In a world of 7.3 billion people that’s impressive.
The M features I didn’t know about are
- the data binding framework – available in the support library for all relevant Android versions (down to Android 2.1 / API 7)
- app linking allowing browser URLs to trigger app deep-linking. Now I know why when I browse Amazon on my Nexus 6p it gives me the option to open the item inside the Amazon app instead of the browser.
- the removal of the ApacheHttp client from the public API (but not the JARs, to maintain binary backward compatibility) and its replacement with the standard java.net.HttpURLConnection.
The presenters started out by saying that there won’t be a better time to switch to Android Studio: the ADT plugins for Eclipse has been deprecated and won’t receive any new features. Google now funnels all its IDE efforts into making Android Studio better. Android Studio is no longer experimental; it’s mainstream.
The 2.0 release (based on IntelliJ IDEA 1.5 Community Edition) is primarily a performance release to speed up development time significantly while not sacrificing its architectural values. One of the selling points of Android Studio 1.0 was the switch to a modern IDE independent build system: Gradle. This was in stark contrast with the more complicated Eclipse build that is tedious to run in a headless mode and isn’t capable of using a dependency repository like Nexus (Maven’s Nexus repos, not the Android phones 🙂 ).
The performance optimizations gravitate around instant run. There is now a method hotswap. As with any hotswap implementation, no data initialization is performed (e.g. singletons can be problematic). The way hotswap is implemented is by sending delta classes to the Android VM which are called by the using prebuilt method hooks of the first method version.
For resources, any of them which was modified is sent to the running app in full. An optimization to send only resource deltas is being worked on. Android manifest changes require an app restart.
The emulator is still based on qemu but apparently has improved speed. I’ll compare that to the gold standard (Genymotion) shortly.
A sad note is that even in the age of 1 billion+ Android devices, the screen casting of an Android device to a computer is a rare feat. It’s telling that even the Google team used a camera although the device was one of their own (Nexus 9):
As I entered the exhibits hall the first thing to notice was the fundamental shift in Android hardware: Qualcomm area to the left and the Intel area to the right. Both had the largest floor-plan and Intel was there to tell everybody that they mean business. Indeed, in an Android hardware landscape dominated by ARM and Qualcomm more and more Android phones and tablets are now powered by Intel Atom x86 chipsets. Hardware vendor and architecture diversity are a great thing for any ecosystem.
Sony showed a cool demo of Android TV. It was nice to see the typically annoying and out of place TV menu be merged into the settings section of the Android TV OS. Obviously the hardware running Android isn’t upgradeable as all TV manufacturers want is people to upgrade their TVs as often as their phones (every couple of years). I guess the market will decide if this strategy will be sustainable or whether Android hardware upgradeability will be demanded by customers.
I saw a demo of Intel XDK which is an integration effort of Apache Cordova and other open source projects to create a development environment for hybrid apps.
Finally it was cool to see Thales there. It’s an Android powered flight entertainment system of which I’ve heard before. This shows the true power of Android: third parties are free and empowered to explore new use cases for Android without neither depending on nor needing the blessing of its creator.
Obviously there were some more exhibitors, but these stood out to me.
Intel Multi-OS Engine
This is an early access technology from Intel so they didn’t even bother giving it a proper name. So we’ll use what we have: Intel Multi-OS Engine.
It’s a port of ART to iOS linked to the app which adds 9-40 MB to the app’s disk footprint, depending on how much of the API is used by the app. Remember that ART was introduced in Android 5 as an ahead-of-time DEX compiler replacing Dalvik (which uses JIT) as the default Android VM.
I know that Both the Apple AppStore and the Android PlayStore forbid any apps with self-modifying binary code at runtime. Since this is exactly what JIT does, no VM with JIT is allowed on these app stores. That’s also the reason why Oracle’s ARM JVM for Android and iOS does not have JIT and consequently is hopelessly (as in Java 1.0 level) slow.
Thinking of this approach, there’s a problem with linking the JVM to the app though. An average user can easily have 100+ third party apps installed. Let’s say each has a 20 MB overhead for the linked VM. This will effectively use 2 GB of storage just for the runtime. This is a problem. Then the initial download will require around 2 GB of data just for the 100+ VMs linked to the app. Then each new app version will download the VM again and again. Thinking of this a bit more, it’s actually a huge problem.
Some technical details are that the Android Studio project has a companion Xcode project. The framework exposes Java bindings to the iOS API. It uses retrolambda to offer Java 8 language features in Android since the native language support there is still at the Java 7 language level.
Two questions come to my mind.
1. What’s Apple’s incentive of shipping this with iOS and helping the Android ecosystem? It’s the perfectly round number (0).
2. What’s Intel’s motivation behind this investment? Fair, they want to increase Android’s market share and increase the market share of their x86 Atom chipsets in the world currently dominated by ARM licensees. I still don’t get why having such a VM would help them in that direction.
Java bytecode compiler to iOS native code. They ship a plugin for Android Studio which then creates an Xcode project linked to the current Android project. RoboVM has a Java API for the iOS API with a 100% coverage (their claim) and they commit to shipping the same day Java APIs for any new public iOS APIs.
The development model for iOS is to create the UI in Xcode which link to the controllers with outlets and actions. As soon as you write your Java controller with iOS API it becomes visible in Xcode’s interface builder.
It’s a commercial product with a subscription model. The source code is available only for enterprise licensors.
In a Bind? Android’s binder in depth
Another highly technical session by Jonathan Levin. At the 2014 AnDevCon SF I attended his session on the Dalvik and ART internals. Both were really enlightening and stimulating my curiosity to study more the internals of Android. It’s another benefit of Android: the most important parts are fully open source, they run on the by far the most popular OS kernel (Linux) and so you can dig as deep as you desire. Compared to the closed ecosystem of iOS, this is heaven on Earth for any engineer.
Binder is Android’s interprocess communication system. Compared to plain sockets based IPC it offers discovery, authorization, message structure (defined as an AIDL) and parcels as the serialization mechanism.
It is not intended for sending large amounts of data between processes. It’s way too slow and inefficient for that. Thus the default data size upper limit is a conservative 800 KB. For anything larger than that the recommended data sharing strategy is via anonymous shared memory: allocate a memory segment in ashmem, create a file descriptor (fd) to it and then send the fd to the other process via binder. That other process will then be able to read the data directly. It’s pointer passing vs. data copying.
Binder has graduated into the mainline Linux kernel starting with version 3.19: https://en.wikipedia.org/wiki/OpenBinder. So it no longer is an Android exclusive IPC technology and this brings Android’s architecture closer to that of Linux.
As a side note, Binder was initially developed as part of BeOS and as the developers moved on to Palm, HP and then Google, it followed them. Once at Google, Binder found its way into Android.
Those are quite a few layers. Jonathan then went on showing us the code for all the layers.
Back to base
This was another good AnDevCon day. It’s always interesting to see the completely different dynamics of a technology in full growth. It’s a dire contrast to the typical Java conference.
Looking forward to dig deeper into these learnings and in particular I’m preparing a post on cross-platform mobile development.