Google updates Android Studio: IDE like multi-display support and a split-view designer

Hands On Google has updated Android studio with support for multiple virtual displays, a new split view for the layout designer, and view binding to make it easier to interact with GUI components.

“As more devices are available that have multiple displays, it is important to test your app on a variety of multi-display configurations,” says the announcement of Android Studio 3.6. Google likely has in mind Microsoft’s dual-screen Surface Duo, expected later this year.

Multi-display support is a feature of the emulator, and you can now define up to 4 virtual displays, provided you choose Android 10 or higher, via a new Displays option in the emulator’s advanced controls. The emulator has also been enhanced with Google Maps integration.

The emulator supports up to four virtual displays

Android Studio has a visual GUI designer based on Android Jetpack and its XML-based layouts. In the new update, there is a Split view that lets you have the visual designer shown alongside the XML code. There is also a new colour picker.

Hooking up code to your GUI is now easier, using view binding, which automatically generates classes to give you programmatic access to the GUI and to handle events. This is an alternative to the common technique of using findViewById to get a reference to GUI objects in Java code. In order to use this, you enable the viewBinding element in the Gradle build configuration. The advantage of view binding is that the view ID and type is checked at compile time.

Could you not do this before with data binding? You could, however view binding does not need any annotation of the layout file, but happens automatically. You still need data binding for some features.

Google Maps is embedded into the emulator to assist with location-based apps

There are a bunch of other new features, including resumable downloads for SDK files, leak detection in the memory profiler, and deobfuscation for compiled DEX (Dalvik Executable) files in the APK analyser, used for inspecting the compiled application package.

Android Studio is based on IntelliJ IDEA from JetBrains, a well-liked Java IDE, and the new version is the first to be based on IDEA 2019.2, which has updates of its own. Android Studio does lag behind IntelliJ IDEA: the current version is 2019.3 with 2020.1 coming in April.

Hands on with Android Studio

Android Studio has plenty of nice features, but setting up and updating an Android development environment can be prickly. Keen to try the new Android Studio, we ran the update from the IDE (Help – check for updates). In our case it was not smooth. Somehow Android and Gradle, the build tool, had become configured to use different versions of the Java Development Kit, resulting in warnings "Android Studio and Gradle are using different locations for the JDK". The Dart plugin then declared itself "incompatible with the current Android Studio version".

These issues were overcome with various updates and tweaking of configuration files. There was an issue with an existing Flutter project, which will no longer compile. Another annoyance is that when getting updated Android SDK components, the installer insisted that Intel HAXM (Hardware Assisted Execution) was required. HAXM is Intel's hypervisor, which used to be required in order to run the Android emulator with hardware acceleration. This is no longer the case, and since Windows 10 April 2018 update, you can run the Android emulator with Hyper-V, provided you enable the feature called Windows Hypervisor Platform (this is distinct from Hyper-V itself).

Google's Android team still seem keen for you to use HAXM where possible – but unfortunately the two cannot co-exist. Hyper-V is useful for other things, such as Docker containers and Windows Subsystem for Linux 2, so it is common for developers to want to use the Android Emulator with Hyper-V. The solution is to cancel the HAXM installation when offered.

Android Studio is keen to install Intel HAXM even though it messes up Hyper-V

Android itself is a tricky platform to work with, partly because of the many different versions of the OS out on different devices. When you start a new Android project, the wizard helpfully tells you how many devices are likely to be able to run your application depending on the SDK you choose. It is a dilemma: specify a recent SDK and limit the market? Or specify an old SDK and miss out on new features? The oldest SDK now supported is API 14 (Ice Cream Sandwich), from 2011. Go for API 21 (Lollipop), from 2014, and you get 85 per cent of devices according to the wizard. API 26 (Oreo) from 2017 gets you just 6.0 per cent.

Android Studio is easier to use than Eclipse but with the complexities of Android and numerous dependencies, it is not the most developer-friendly of platforms.

Fuchsia and Flutter the future?

Google has a couple of projects which may improve the developer experience on its mobile platform. One is Flutter, a cross-platform framework which targets Android, iOS and web applications. Flutter uses Android Studio, though there is also an option to use Visual Studio Code. Flutter uses the Dart language.

A related project is Fuchsia, a new operating system about which Google has said little in public, but which is quite well advanced in development. Fuchsia uses Flutter for the majority of its user interface. A language policy document states that C, C++ and Dart will be the only languages supported for "end-developers". Google may have good reasons for reducing its dependence on Java.

Nothing is certain when it comes to Fuchsia, but it does show the possibility of big changes are coming for developers targeting Google's mobile platform. Android will be with us forever, but by using Flutter, developers could both support Android and be a native app on Fuchsia.

The Reg thinks we could be looking at an announcement at Google IO in May. ®