Android Apps on ChromeOS: What Devs Need to Know for the Best User Experience

Google I/O 2016 brought many exciting announcements this year. If you’ve missed them, make sure to check our articles which recap announcements geared towards developers and those aimed at users.

We wanted to cover one particularly interesting I/O session in more details, though: “Bring Your Android App to Chrome OS”, presented by Luis Héctor Chávez, an engineer in the Chrome OS team. While we’ve already covered the announcement from a user’s viewpoint, we also wanted to provide a recap of this I/O session aimed at developers.

The motivation behind this feature is rather clear: getting Android apps on Chrome OS is a good way for developers to get more users, while providing Chromebook users with more apps. It’s a win-win situation… assuming it doesn’t take more time than it’s worth (spoiler alert: it’s actually pretty easy!).

Previous Options

Supporting both Android and Chrome OS was not an easy task in the past, and developers basically had two options at first:

• The first was to write a Chrome OS app, which would result in two separate code bases (a huge task for the initial port and double the work for future updates).
• The second was to use HTML5 apps. While this would make it easy to run on Chrome OS and Android, it wouldn’t feel native on the latter and wouldn’t be able to take full advantage of the Android platform.

Since late 2014, using the App Runtime for Chrome (ARC) also became an option. However, it was still a rather involved process: file system access was restricted and could cause problems for some apps, not all Google Play Services were supported, extra work was required to use certain features such as in-app payments, and developers still had to publish their app separately on the Chrome web store.

The Chrome OS team has therefore been working on a better solution for developers.

The New Approach

Chrome OS will soon have a new sandboxing mechanism that will allow users to run Android apps directly while maintaining a high level of security, performance and compatibility. This is done by running the whole Android system (initially Android Marshmallow). Android apps will also support multi-window (though not quite the same as Android N’s — more info in a bit), and users will be able to change their size, maximize and minimize them.

In order to give developers time to prepare and for further testing, this feature will initially be disabled by default and will be available in the Chrome OS development channel in June, the beta channel in August, and the stable channel in September.

Initially supported devices are the Acer Chromebook R11/C738T, Asus Chromebook Flip and the Google Chromebook Pixel (2015). You can check the full list here.

What developers need to do is simple: your apps should show up directly in the Play Store on Chrome OS in most cases, without requiring you to do any changes to your code (except to tweak the experience on Chrome OS, of course). In fact, there are no new APIs for you to learn or use to support Chromebooks.

Just-in-time binary translation is also provided so that ARM apps can run on x86 Chromebooks with no extra work required from your part.

Your Android apps will work like Chrome OS apps: your apps are integrated in the launcher/shelf, notifications will show up like native notifications, and clipboard and sign-in info are shared between the two OSes. The hardware and input methods also just work with no extra effort from your part. It just works. Seamlessly.

Best Practices to Follow for Developers

That being said, there are some best practices you’ll want to follow to make sure your apps show up on all supported Chromebooks, and run well on them.

• Remember that Chromebooks come with a keyboard and a trackpad, which means you’ll want to test your apps with a keyboard+mouse setup and try to optimize the user’s experience. For example, you might want to add hotkeys support in productivity apps, or offer better control schemes in games.
• Not all Chromebooks have a touchscreen. By default, Android apps require one — but your app probably does not actually need touch features. Make sure to declare that the touchscreen feature is not required in your AndroidManifest.xml:

  <uses-feature android:name="android.hardware.touchscreen"
                required="false" />
  

  Without this change, your app will not appear in the Play Store on Chromebooks without touch support.

• The same applies to other hardware features. Chromebooks have no GPS for instance, but they can still provide a coarse location via WiFi which might be enough for your app. Don’t require hardware that might not be available unless it’s actually needed.
• Some software features are not available on Chrome OS:
  • android.software.input_methods
  • android.software.app_widget
  • android.software.live_wallpaper
  • android.software.home_screen
• Other features are also unsupported as Chrome OS is the device manager:
  • android.software.device_admin
  • android.software.managed_user
• For the above three points: remember that your app will not show up on the Chrome OS Play Store if it requires an unsupported feature.
• Multi-window support is not the same as Android N’s (yet! The Android implementation in Chrome OS will eventually be updated from M to N). Instead, Chrome OS will simply make your app switch between layouts it most likely already supports: landscape (similar to the Nexus 7), portrait (similar to the Nexus 5) and maximized (your app just fills up the whole screen).
  • No changes to the activity life cycle model are made: only one app can have focus at a time, but multiple apps can be visible at once. Make sure to start/resume rendering when your app gains focus (in Activity#onResume())`__), and pause rendering when it loses focus (in Activity#onPause()) in order to conserve battery. Of course, for some apps, you’ll want to make sure you’re doing the opposite instead. An obvious example is video playback apps, where you wouldn’t want playback to stop when your app loses focus but is still visible.
  • The Low Memory Killer will take into account the Z-order, killing apps that are further in the background first if necessary.

  

  • Window controls are offered to the user, allowing them to switch between the different layouts.
    • If necessary, declare the correct android:screenOrientation activity attribute in your manifest to only use supported orientations.
    • You’ll also want to make sure you’re handling runtime changes correctly, especially screenWidthDp, screenHeightDp and densityDpi. Remember that changing orientation will be like changing the device, so the width and height won’t simply flip — they’ll be totally different values. If you’re handling orientation changes yourself, don’t forget to invalidate and load the correct resources after the orientation changes, since you’re effectively changing devices and might therefore have to use different size-specific resources (e.g. tvdpi to xhdpi).
    • Launching a new task (Intent#FLAG_ACTIVITY_NEW_TASK) means it’ll render in a new window. Don’t launch activities in a new task if you don’t want that.
    • Respect onPause as discussed above.
• If possible, implement support for Backup & Restore. This is not necessary but will provide a better experience to users.
• Keep in mind that Chromebooks can be shared between multiple users (e.g. for educational purposes: a Chromebook might be shared by several students), and be mindful of the local storage you use. An account (along with its local storage) might be deleted at some point, for instance.

---

Last but not least, even though Chrome OS will ship with Marshmallow initially, it’s still a good idea to be ready for N, as that will bring more usability features such as resizeable activities, cross-app drag&drop and a mouse cursor API.

Luis shared some useful resources to prepare for that (before finishing the session with a demo):

• What’s new in Android N Google I/O session (you can also check our recap instead).
• Multi-Window mode Google I/O session, which we’ve also covered on XDA.
• Official N Developer Preview documentation.
• Official documentation for Android apps on Chromebooks.

from xda-developers http://ift.tt/1WUp6zR
via IFTTT

.