Yesterday Google surprised a number of people by launching the developer beta of the next release of Android, which is codenamed Android N. Normally the beta version of Android comes to developers during Google I/O in May, but in a way it makes sense for Google to release it to developers a few months earlier so they can receive feedback and discuss common questions and concerns during the event.

The early release isn't the only change with this new beta version of Android. In the past I've often complained about Google's poor handling of developer betas. They've always been too monolithic for my liking, with only two or three betas being released to developers before the final version. There was also the problem with installation. While I am not averse to using the Unix shell, there is no reason that a developer should have to use adb via the command line to install a developer beta of Android. It should be done via an update directly from the device, or by some software tool with a proper graphical interface that can be run on your computer. It didn't help that the update packages often failed to work which required you to decompress it and flash each file one by one.

With Android N, Google has recognized and resolved these problems by providing a simple way for developers to opt in to the program via a web interface. Once you opt in, your device almost instantly receives a notification prompting you to install an over the air (OTA) update which will install the Android N beta. This is much more user friendly, and it has the added bonus of making it easier for users to opt in which gives Google more usage and diagnostic data to work with. Because the OTA isn't just making changes to the existing OS it is quite large, with it being just under 1GB on the Pixel C and Nexus 6, and 1.1GB on the Nexus 5X.

In this article I'll just be taking a look at some of the most notable features of Android N, including Multi-Window mode, changes to notifications, and improvements to energy and memory optimizations.

Multi-Window

Split screen multitasking isn't something new in the tablet space. Microsoft was really the first of the major players to implement it all the way back with Windows 8, although the optimal tablet implementation was mostly restricted to Modern UI apps, with traditional Windows applications having supported a different form of multitasking since long before the advent of the modern tablet simply due to how desktop operating systems with windowing work. More recently, Apple introduced split screen multitasking in iOS 9 on the iPad Air 2, along with two other forms of multitasking for older devices in the form of slide over apps and picture in picture views. These features made their way to the iPad Mini 4 and iPad Pro as well, with the latter offering an experience that essentially gave you two full sized tablet applications side by side. Up until this point Android users were left in the cold, with no way to multitask and existing applications that really just worked like big phone apps.

Android N comes with an optimal but not novel split screen implementation; which Google refers to as Multi-Window mode. It's actually pretty much the same way as iOS handles it, although there are some obvious changes that go along with the differences between iOS and Android. Triggering the multitasking mode is slightly different based on where you are in the UI. The initial case is when you’re just on the home screen. In this case, you need to open the multitasking switcher and hold the existing application for a moment until two shaded areas appear on the left and right sides of the screen. You can then drag the window to one of these sides, which then scales it to fill half of the screen, and puts the multitasking switcher on the other half so that you can select another app to fill that section.

By default, you get a 50/50 split, but you can adjust it to a split where either the left or right application takes up roughly 2/3 of the display, with the other app occupying the remainder. This is similar to how iOS allows for a 50/50 split or an application pinned on the right side, but it gives you more flexibility by allowing you to pin a smaller app on the left side. I actually appreciate this, as there are circumstances where I really want my primary app on the right side on an iPad, which isn’t an option due to there only being two multitasking views.

Some people may wonder why Google didn’t just allow for any arbitrary split. I think there are two reasons for this. The first is that the majority of the time the user will simply want a 50/50 split or to just pin a chat app on the side while working mostly inside another app which occupies most of the display. The existing options cover those cases completely. The second issue is that developers have to be able to tell the operating system a minimum width that they require to lay out their app properly. Because this width would be different from application to application depending on what sort of app it is, there’s no way to enforce consistency with what split is allowed, and users would get confused by why they aren’t allowed to split the screen the same way as with different apps, or why the split ratio had to suddenly adjust itself when they changed what secondary application was open.

The second issue that I outlined above is actually something that I’ve already seen before. I encountered it constantly on the Galaxy Tab S2 which uses Samsung’s multitasking and allows you to set absolutely absurd ratios where the smaller application couldn’t possibly present any useful information. Ultimately, you have to strike a balance between flexibility and consistency, and with Google and Apple having converged upon a similar solution despite the enormous differences between how they handle application layouts, I think it’s clear that offering a few possible layouts can cover almost all cases that a user needs, and the flexibility of allowing an arbitrary split isn’t worth the additional developer effort and inevitable bugs just to satisfy the few cases where the user wants to adjust the ratio a bit more.

If you’re already in an application Google has added a quick but not incredibly obvious way of opening the multitasking drawer in a split view. If you simply tap the button to open it, you’ll be greeted by the standard app switcher and you’ll need to go through the process of dragging one app to the right and one to the left. This actually ends up being more time consuming than the iOS implementation, and Google clearly had that in mind when they added the second method which involves holding down the multitasking button while you’re inside another app. This automatically pushes the open application to the left and brings up the switcher so you can select an app to go on the right. It’s actually the fastest way of accessing multitasking that I’ve seen on a tablet, and I’m quite impressed with how Google has clearly aimed to make multitasking quickly accessible. Holding the button while using two apps quickly dismisses the app on the right side and the left app will return to filling the entire display.

Of course, the big question is how well the multitasking actually works in practice. Obviously this is a developer beta, and I’m not going to fault Google or any other third party developers for bugs. In fact, it has actually worked much better than I expected. As of right now it looks like pretty much any application will work with multitasking, with the exception of some exclusive full screen apps like games. Based on Google’s developer documentation it appears that apps built with a version of the SDK lower than Android N will be forcibly put into multitasking mode, with a popup telling the user that the app may behave unexpectedly. Once developers start targeting Android N they can specify whether their app can work with split screen mode or not.

Naturally, every app I’ve tried except for some of Google’s own has told me that the app doesn’t support multitasking. Despite that, they’ve all worked quite well. Twitter, Chrome, and Hangouts all work very well. Skype has been uncooperative when you put it as the smaller window, but for a feature that just came into existence today it’s impressive how well things are working. The fact that these applications already scale to different displays gives Android a big advantage over iOS, as there’s no need to redo your entire app layout to enable split screen mode, and many existing apps already work fairly well with no changes at all.

My only concern with split screen mode is that it takes away a lot of the incentive for developers to make proper tablet UIs, which is already something that Google and other Android developers don’t bother to do. It’s appealing from an effort perspective to rationalize not doing it because users will just use apps in a split screen layout where the app has to look like it does on a phone anyway. There are many apps which are well suited to a full screen view, and I hope that we’ll still see a change in the attitude toward tablet apps on Android even in light of the split screen mode in Android N. It already looks like a fantastic implementation of multitasking, and I’m excited to see how it improves as Google irons out the bugs and developers build apps with support for it in mind.

Additional Features

While Multi-Window mode is arguably the biggest user-facing change to come to Android in a long time, Android N comes with a number of small but highly appreciated changes. The first of these is speeding up the animations throughout the system. Animations like bringing up the keyboard, opening apps, and switching views have been made much quicker without any noticeable loss in fluidity. It makes the entire system feel so much faster, and I think you could argue that UI navigation in Android already felt a bit quicker than iOS or Windows phone to begin with.

Google has also made some notable changes to the notification drawer. You can now expand and collapse notifications and there's now an API available to bundle many notifications together which is helpful for messaging apps that may end up sending repeated notification payloads to a device. It's a really helpful feature because it avoids the problems of bundling all notifications into one, as well as the problems of displaying a notification for each and every message that arrives. You can even reply to notifications right from the notification shade. I've had mixed results with this. I tried it with Hangouts which is what Google does in their screenshots, but it opened the odd input field that you see in the screenshot on the left above. Skype however worked flawlessly, so it looks like there's some work to be done on the app side and potentially at the OS level to fix some bugs.

In the video above you can see an example of all the new notification related features. Still images really don't do justice to the way the cards expand and contract. It all fits in really well with Google's Material Design aesthetic, and all of the interactions feel very smooth and responsive. You can expand grouped notifications to see a summary of each individual one, and then expand that one even further to view more of the message and get quick access to actions like replying or archiving.

On the topic of the notification shade, there's now official support for editing the quick toggles in the shortcut section. You can also access your first five toggles from the top of the shade, which is a great usability improvement. Like the notification expansion this also has a really great animation. When UI elements take full advantage of Material Design the results are honestly really impressive, and they go a long way in making Android feel much more lively and fluid. The ability to quickly access certain toggles like the flashlight is a great improvement too, as it puts them only a single swipe away instead of the previous model which required you to first swipe to open the notification drawer and then swipe again to get to your shortcuts.

My only complaint about quick toggles is the fact that in the always accessible bar Google continues to just display a battery icon that only gives me a vague idea of what my charge is. If you open the menu you see the percentage, but it hides itself for some unknown reason when you collapse the menu. If you're going let the user always have a battery displayed there you should put a percentage instead of the same inaccurate and frankly useless icon that's in the status bar. Apart from that continued annoyance, the new notification shade features are great improvements. Hopefully this will encourage OEMs to stop messing with the behavior of the notification shade, as Google has basically addressed all required features here and there's not really anything to improve on.

Improving Energy and Memory Usage

With every release of Android Google introduces new APIs, and adjusts existing ones. It's always important for developers to keep up to date with these changes, as they can alter or break existing application behavior, and in general it's good practice to adopt new features relating to reducing memory and energy usage.

With Android N, Google has made some notable changes to Doze and Project Svelte, which are their initiatives to reduce energy and memory usage respectively. If you've already adapted your app for Doze these changes will come automatically, and if you haven't you don't technically need to since Doze manages all apps on Android 6.0 and above, but the new changes may cause issues with notifications and other background work if you haven't adapted your apps.

The major change to Doze in Android N is that it also activates even when a phone is not stationary. Previously Doze would activate when three conditions were met. The screen had to be off, it had to be running on battery power, and it had to be stationary. This is still the case for the most aggressive optimizations, which include disabling wakelocks, alarms, GPS, and WiFi, but it's now also the case that the phone will disable network access and defer syncs and background jobs even when the phone is moving. This means that Android devices will now enter this state just by being locked in your pocket. As usual there are maintenance windows where applications can perform background tasks and send or receive data over the network, but the fact that your phone will automatically disable network access and defer background work simply while it's in your pocket will undoubtedly bring gains in battery life.

As for Project Svelte, Google is letting developers know that certain implicit broadcasts are being removed. A broadcast is essentially a message sent by the OS that notifies applications of some change in state, such as a device connecting to WiFi or being removed from a charger. The two broadcasts removed in Android N related to changing from WiFi to cellular networking, and to taking photos and videos. According to Google, many applications wait on these broadcasts and upon receiving them would wake up to process them. Having many background apps waking up at the same time to process a common event like changing from cellular to WiFi presents a real concern for energy and memory usage, and so it makes sense that Google would be removing them.

Other Changes For Developers

Along with some of the more major features that I've talked about so far, there are some changes coming in Android N that developers should look out for and, if necessary, update their apps to accommodate. One that may pose issues for some applications is the new display size setting, which allows users to modify their virtual dpi to make UI elements larger or smaller. Users can't zoom in past a minimum width of 320dp, which is the horizontal space available on a Nexus 4.

Above you can see the impact of the display size setting. It's definitely an important feature for accessibility, as it goes beyond just making text smaller or larger. I don't suspect that the UI scaling will be a problem for most developers, but if you've been specifying the size of any elements using actual pixel dimensions for some reason it may cause issues. Google's best practices also note that apps will need to ensure that they reload assets such as bitmaps as necessary when the user changes the display zoom setting.

Google has also deprecated one permission and added another in Android N. The GET_ACCOUNTS permission is deprecated, and the OS will ignore apps requesting it that are built targeting Android N. There's also ACTION_OPEN_EXTERNAL_DIRECTORY, which is a new permission that applications can use to create folders for data storage without having to ask for full storage permissions. Keeping with Android's new permission model introduced in Marshmallow, the user will have to explicitly grant permission for this at the time it's requested.

With Android N comes a move to OpenJDK 8 as the Java platform implementation. With that, Google is noting that some behavior has changed, and developers relying on alternative implementations should be aware. Developers will likely be happy to see features like lambda expressions which can simplify much of the code for anonymous inner classes, along with other forms of functional expressions and some of the other features that were added in Java 8.

Finally, Google is reminding developers to stop using private APIs and native libraries that aren't part of the Android NDK. Devices will now put up an error message when this is detected, and I've already encountered Skype causing them on the Pixel C.

Initial Impressions

Though I suspect it's not a popular opinion, I have long felt that the software design ecosystem for Android tablets has been stuck in a rut since the early days, and as a result users have struggled to find good, modern applications that really excel at the tablet experience. Android N can't magically bring proper tablet interfaces to all Android apps, but the Multi-Window support is a big help in improving the situation. With split windows in use, on a standard tablet you're really dealing with a screen segmented into two areas, and this is where a phone layout works pretty well. With that in mind, it does help to address the problems that Android tablets currently face, but I do hope that developers will continue to maintain existing tablet UIs, and that new developers will take the time to create ones. I don't know if Google's internal app development groups are prepared for this, but I have faith in the larger Android's developer community.

It's worth noting that the Multi-Window mode technically also works on phones. That said, unless you have a 6.8" phone (which is practically a tablet), I don't think the feature is very useful, but it's there. Even on the Nexus 6 there's just not enough screen space, and I would never use it myself. That said, while I was initially ttempted to recommend that Google just remove the feature on phones, on reflection it doesn't really hurt anyone to have it there for users that want it. On top of that, leaving it to tablets alone may cause some developers to just not support the feature entirely.

Google also has an advantage with Android apps already being designed to support many resolutions and aspect ratios. Several apps that I tried already worked with the split screen mode, and developers aren't going to have to rebuild their UIs like they did when Apple introduced split screen multitasking on iOS. In fact, it's most certainly the case that there are more apps that work with Android N's multitasking than there are that work with multitasking on the iPad, and considering that the feature just launched today in a beta OS I'd say that's a big win for Google and for Android.

If I were to make any recommendations for Google, it would be to make it a bit more obvious to the user that you can hold down the multitasking button inside an app to instantly get into split view mode. I happened to come across it because I figured that Google would have implemented some sort of quick access method, but it's not obvious enough for your average user. In addition, I think the current method of simply filling the view with the background color as you adjust the ratio between apps is not very aesthetically pleasing. These apps still aren't really designed to adjust their UI in real time, and although it's somewhat lame to just blur it out like Apple does on iOS, it looks better than watching the UI frantically try to fill the space.

Quick toggles are easier to access in Android N

As for Google's other changes, I think they're in line with what we've come to expect. After Lollipop, Google was able to step back and focus on the lower level problems with their platform, particularly regarding efficiency. The improvements to Doze will certainly have an impact on energy usage, and blocking apps from waking up in large numbers whenever the phone goes on or off of WiFi is a smart move. I expect that we'll see continued improvement of this sort in future Android releases, as problems with energy management are potentially the biggest problem plaguing the platform right now, with performance and usability having been mostly sorted out. These releases also provide a way for Google to make small improvements to areas like notifications and their built in applications to make the user experience a lot better through many little changes.

On that note, I'm sure many of our more technical readers are interested in being part of the beta. I'm very happy that Google has taken the necessary steps to make the process of enrolling in the program much easier for developers and users. Right now the supported devices include the Pixel C, Nexus 9, Nexus 5X, Nexus 6, Nexus 6P, and Nexus Player. To enroll your device in the beta you can visit this link and your device will quickly notify you that an update is available. It does need to be reiterated that this is a developer beta and a true beta at that - it's not a large-stage end-user beta - but I would encourage enthusiasts who do enroll to consider sending some feedback to Google about what they like and what could be improved, as that's ultimately what these beta programs are all about.

One last thing to note is Google's incentive for developers to test their apps on tablets so they can ensure proper Multi-Window support. For a limited time developers can sign up here to get a promo code which will knock 25% off the cost of the Google Pixel C. With Google recently having patched the most serious bugs on the Pixel C, for $375 it's a pretty good tablet and a very good device for doing application testing considering the fact that the Android N beta only works on two tablets. Interested developers can sign up here, and Google is seemingly taking people on faith that they really do intend to use the unit for development as it only involves entering your email address.

With Android N being in its early stages, I must say that I'm impressed with the stability and usability of the features that Google has added. With Google IO on the horizon we'll certainly be hearing more about what's coming in Android N, and I'm very excited about the direction Google is headed in.