Every year we look forward to all the nice I/O talks on YouTube regarding Android. However, watching these recordings can be quite time consuming. Here’s a textual summary of what’s new in the Android Development Tools (talk video)
The Android Design Support Library helps you follow the latest and greatest material design specs. The library comes with a couple of material design components like the navigation drawer, floating labels for editing text, floating action buttons, and the snackbar which are all compatible with Android 2.1 and newer.
Android L introduced support for vector drawables. With the new Android Studio 1.3 plus changes to the Android Gradle plugin, you can now let the build system generate raster images from your SVGs or vector drawables for different densities.
Finally, the dev tools team started to rewrite all the visual design editors which should help you approach your design in a more WYSIWYG fashion instead of messing with XML files. More on that below.
Improving the Grade Plugin & Build System
The Android Gradle plugin can be a bit wonky at times, especially if it comes to dependency management. Handling of test dependencies has a lot of corner cases which have now been fixed. Similarly, optional dependencies aren’t really supported by Gradle. Again something the Android Gradle plugin fixes.
The biggest gripe with the Android Gradle plugin are the high build times. The team is tackling that on multiple levels. Jack, short for Java Android Compiler Kit, takes Java source code and directly compiles it to Android’s dex file format. The compiler is based on the Eclispse Java compiler. That cuts out one step, namely compiling Java to JVM byte code before converting to dex. Additionally, Jack supports incremental builds.
Crunching/crushing PNGs is another build step taking a considerable amount of time. The dev tools team improved the performance, citing a decrease in crunching time from 4 seconds to 400ms for 500 PNGs and nine patches.
aapt, the tool that packages all your
.dex and resource files, has also seen improvements. aapt is now incremental as well.
Another factor of build times is considerable overhead from Gradle itself. When Gradle starts building your Android project, it has to create a model describing things like variants (flavor + build type), resolve dependencies for all variants (even if you only assemble one) and execute your custom logic. The dev tools team worked closely with Gradle Ware to improve these steps. Here are the results:
Now, that’s not the whole story. The dev tools team is working on a new Android Gradle plugin based on new APIs Gradle Ware has been working on. These new APIs allow the model to be managed by Gradle directly, letting it do things like caching, parallelization and incremental builds. Here are the results of the new, not yet finished plugin:
These numbers do not include benefits gained from caching, as that is not yet implemented. One slightly concerning downside is that the new plugin will have a new DSL that’s not 100% backwards compatible. The preview of the new plugin will be out in a few weeks, the final release will be live later this year.
The dev tool team is also introducing a new Data Binding Library. This data binding library requires support form the build system, as it generates Java source files from declarative code in various XML files. Both the old and the new Android Gradle plugin support this. More on that below.
Finally, there is now full NDK C/C++ support. That’s based on the native support in Gradle and only available in the new, rewritten Android Gradle plugin. NDK support also comes to Android Studio, which bundles CLion for free. More on that below.
The biggest story around Android testing this year is the newly announced Cloud Test lab. This will allow you to test your app in Google’s test cloud on both virtual devices as well as physical devices. For both, the test lab will support robot app crawlers that don’t require any manually written tests. Think of a monkey being given your app to play around with :). Of course you can also write instrumentation tests yourself.
So far, unit test support was mainly available in form of plain-old JUnit tests which where run on your desktop JVM. While that enabled quicker iteration times on your tests, it’s not possible to test Android specific code without mocking Android libraries (that’s what Roboelectric is for).
To support integration tests on emulators or devices, the dev tool team added support for external test projects. These live next to your app project and reference it and its dependencies for integration tests.
No big news here. The dev tools team mostly worked on stability, correctness and configuration. Android Studio will download and install HAXM and configure it for you. Also, a lot of improvements have been made to the OpenGL ES emulation, which should give better performance and results closer to what you’d see on a device. Fingerprint support as well as a special Android Auto emulator will also be available.
Android Studio C/C++ Support
With NDK support in place for the build system, the dev tools team also collaborated with JetBrains to include their new C/C++ IDE CLion directly into Android Studio. All of this comes free of charge.
This combination allows all the nice things you expect from a JetBrains product: powerful refactoring and code analysis tools, code navigation, semantically find usages and a lot more. The real game changers are two features that will boost native development considerably.
The real awesome news is the tight integration between C/C++ and your Java/JNI code. To let C/C++ talk to Java and vice versa, you need to create a bridge between them. That is done via the Java Native Interface (JNI), essentially a C/C++ API that lets you talk to native code from Java and vice versa. You declare Java methods with the
native qualifier for which you then implement a function on the C/C++ side. That function has to follow special name mangling rules as well as marshalling rules that dictate how values you can pass from Java to native code.
Now, Android Studio helps you do all this in a very simple way. You can declare your Java-side native method, and Android Studio can automatically generate the JNI stub for you. That also includes marshalling of some predefined types like strings and arrays. Even more impressive, both refactoring and find usages work as intended! Refactoring on either file will be reflected on the other side.
JNI development is still quite cumbersome, but these changes will make it a lot more tolerable.
New Support Annotations
Java annotations let you do some magic things at both compile and runtime. The dev tools team added about 13 new annotations that help you avoid specific classes of bugs.
One example is the
@WorkerThread annotation. Methods annotated with this annotation will be automatically checked for code that is only supposed to be called on the UI or main thread. Android Studio will highlight any such errors, like setting the text of a button in a worker thread. The team ha already annotated a large part of the Android runtime library with this annotation so you don’t have to do it yourself.
Another example is the
@RequiresPermission. As with the
@WorkerThread, most of the Android runtime library has already been annotated. In case you use APIs that require a specific permission that’s not yet set in your manifest file, Android Studio will alert you and offer you to insert the permission. With Android M, permissions have been reworked quite a bit. Users may now give or deny permissions at runtime of your app. This means your code actually has to react to a denial of such a permission. Android Studio will automatically insert handling code stubs for this scenario.
Some of these annotations are also used in the debugger to resolve flag values to flag names, or recognize bit encoded colors or resource and view ids.
The documentation for these new annotations doesn’t seem to be live yet. It should pop up soon here.
When developing UIs for Android you’d usually separate your layout and UI structure out into XML files and wire them up with your code and POJOs in Java code. E.g. you’d use
findViewByID()to resolve the corresponding UI view instance in Java once your layout has been loaded.
The data binding library let’s you do this more easily now. Instead of having to manually wire things up, you can declare POJO types, value expression referencing a bound POJO, as well as listeners directly in your layout XML files. This comes close to what XAML provides in the .NET world.
To mediate between your Java classes and your layout, the build system will generate a binding Java class at compile time. This lets you debug these bindings more easily.
You can even make this a two-way process: by letting your POJOs implement the
android.databindings.Observable interface, changes to your POJO will be reflected in the UI and vice versa.
The data binding library is currently in beta and requires Android Studio 1.3.0-beta1 and the latest Android Gradle plugin. Find our more here.
The memory and performance profilers received quite an overhaul. You can now take and retain snapshots of both heap and method traces in Android Studio and use a drill down UI to figure out what’s wrong. The new profilers also feature visual UIs to inspect what’s going on. You also no longer need to manually convert your HPROF files.
What’s really neat is the new drill down for memory snapshots. It uses the the instance debugger view to let you inspect live objects. It also let’s you follow reference chains down to the nearest GC root so you can more easily figure out what’s holding on to your garbage.
Google is in the services business with ads, analytics and so on. Android Studio 1.3 now lets you integrate those services more easily through a set of specialized UIs that let you specify things like API keys and so on. The new functionality will also add the required dependencies, permissions and stub classes to be able to start working with the services as quickly as possible.
New Features in Upcoming Releases
The new visual designers haven’t quite made it into Android Studio 1.3. Never the less, they are quite exciting as they should ease the burden of creating UIs for Android considerably.
The screenshot above shows you the new theme editor. It let’s you visually inspect and modify your theme files. It also shows you a preview of your theme in form of styled UI widgets.
The layout editor is being completely rewritten with a lof of new features. The screenshot above shows you the blue print mode, which lets you focus on the layout of your UIs, sans styling etc. It also integrates the design library and lets you add design components via drag and drop.
The XML preview mode has been extended to be able to display system preferences as well. But the most important new features is full WYSIWG editing of your layout directly within the preview window, including drag and drop from the widget palette.
Sadly, the Q&A time for pretty much all Android talks has been rather short. The only interesting question that has been asked was about Java 8 support in Android. The answer: “that’s a platform issue” 🙂