23 March 2017

5 Tips for launching successful apps and games on Google Play

Posted by Adam Gutterman, Go-To-Market Strategic Lead, Google Play Games

Last month at the Game Developers Conference (GDC), we held a developer panel focused on sharing best practices for building successful app and game businesses. Check out 5 tips for developers, both large and small, as shared by our gaming partners at Electronic Arts (EA), Hutch Games, Nix Hydra, Space Ape Games and Omnidrone.



1. Test, test, test

The best time to test, is before you launch; so test boldly and test a lot! Nix Hydra recommends testing creative, including art style and messaging, as well as gameplay mechanics, onboarding flows and anything else you're not sure about. Gathering feedback from real users in advance of launching can highlight what's working and what can be improved to ensure your game's in the best shape possible at launch.

2. Store listing experiments

Run experiments on all of your store listing page assets. Taking bold risks instead of making assumptions allows you to see the impact of different variables with your actual user base on Google Play. Test in different regions to ensure your store listing page is optimized for each major market, as they often perform differently.

3. Early Access program

Space Ape Games recently used Early Access to test different onboarding experiences and gameplay control methods in their game. Finding the right combination led them to double-digit growth in D1 retention. Gathering these results in advance of launch helped the team fine tune and polish the game, minimizing risk before releasing to the masses.

"Early Access is cool because you can ask the big questions and get real answers from real players," Joe Raeburn, Founding Product Guy at Space Ape Games.

Watch the Android Developer Story below to hear how Omnidrone benefits from Early Access using strong user feedback to improve retention, engagement and monetization in their game.


Mobile game developer Omnidrone benefits from Early Access.

4. Pre-registration

Electronic Arts has run more than 5 pre-registration campaigns on Google Play. Pre-registration allows them to start marketing and build awareness for titles with a clear call-to-action before launch. This gives them a running start on launch day having built a group of users to activate upon the game's release resulting in a jump in D1 installs.

5. Seek feedback

All partners strongly recommended seeking feedback early and often. Feedback tells both sides of the story, by pointing out what's broken as well as what you're doing right. Find the right time and channels to request feedback, whether they be in-game, social, email, or even through reading and responding to reviews within the Google Play store.

If you're a startup who has an upcoming launch on Google Play or has launched an app or game recently and you're interested in opportunities like Early Access and pre-registration, get in touch with us so we can work with you.

Watch sessions from Google Developer Day at GDC17 on the Android Developers YT channel to learn tips for success. Also, visit the Android Developers website to stay up-to-date with features and best practices that will help you grow a successful business on Google Play.


How useful did you find this blogpost?
        


22 March 2017

Diverse protections for a diverse ecosystem: Android Security 2016 Year in Review

Posted by Adrian Ludwig & Mel Miller, Android Security Team

Today, we're sharing the third annual Android Security Year In Review, a comprehensive look at our work to protect more than 1.4 billion Android users and their data.

Our goal is simple: keep our users safe. In 2016, we improved our abilities to stop dangerous apps, built new security features into Android 7.0 Nougat, and collaborated with device manufacturers, researchers, and other members of the Android ecosystem. For more details, you can read the full Year in Review report or watch our webinar.



Protecting you from PHAs


It's critical to keep people safe from Potentially Harmful Apps (PHAs) that may put their data or devices at risk. Our ongoing work in this area requires us to find ways to track and stop existing PHAs, and anticipate new ones that haven't even emerged yet.
Over the years, we've built a variety of systems to address these threats, such as application analyzers that constantly review apps for unsafe behavior, and Verify Apps which regularly checks users' devices for PHAs. When these systems detect PHAs, we warn users, suggest they think twice about downloading a particular app, or even remove the app from their devices entirely.

We constantly monitor threats and improve our systems over time. Last year's data reflected those improvements: Verify Apps conducted 750 million daily checks in 2016, up from 450 million the previous year, enabling us to reduce the PHA installation rate in the top 50 countries for Android usage.

Google Play continues to be the safest place for Android users to download their apps. Installs of PHAs from Google Play decreased in nearly every category:
  • Now 0.016 percent of installs, trojans dropped by 51.5 percent compared to 2015
  • Now 0.003 percent of installs, hostile downloaders dropped by 54.6 percent compared to 2015
  • Now 0.003 percent of installs, backdoors dropped by 30.5 percent compared to 2015
  • Now 0.0018 percent of installs, phishing apps dropped by 73.4 percent compared to 2015
By the end of 2016, only 0.05 percent of devices that downloaded apps exclusively from Play contained a PHA; down from 0.15 percent in 2015.

Still, there's more work to do for devices overall, especially those that install apps from multiple sources. While only 0.71 percent of all Android devices had PHAs installed at the end of 2016, that was a slight increase from about 0.5 percent in the beginning of 2015. Using improved tools and the knowledge we gained in 2016, we think we can reduce the number of devices affected by PHAs in 2017, no matter where people get their apps.

New security protections in Nougat


Last year, we introduced a variety of new protections in Nougat, and continued our ongoing work to strengthen the security of the Linux Kernel.

  • Encryption improvements: In Nougat, we introduced file-based encryption which enables each user profile on a single device to be encrypted with a unique key. If you have personal and work accounts on the same device, for example, the key from one account can't unlock data from the other. More broadly, encryption of user data has been required for capable Android devices since in late 2014, and we now see that feature enabled on over 80 percent of Android Nougat devices.
  • New audio and video protections: We did significant work to improve security and re-architect how Android handles video and audio media. One example: We now store different media components into individual sandboxes, where previously they lived together. Now if one component is compromised, it doesn't automatically have permissions to other components, which helps contain any additional issues.
  • Even more security for enterprise users: We introduced a variety of new enterprise security features including "Always On" VPN, which protects your data from the moment your device boots up and ensures it isn't traveling from a work phone to your personal device via an insecure connection. We also added security policy transparency, process logging, improved wifi certification handling, and client certification improvements to our growing set of enterprise tools.

Working together to secure the Android ecosystem

Sharing information about security threats between Google, device manufacturers, the research community, and others helps keep all Android users safer. In 2016, our biggest collaborations were our monthly security updates program and ongoing partnership with the security research community.

Security updates are regularly highlighted as a pillar of mobile security—and rightly so. We launched our monthly security updates program in 2015, following the public disclosure of a bug in Stagefright, to help accelerate patching security vulnerabilities across devices from many different device makers. This program expanded significantly in 2016:
  • More than 735 million devices from 200+ manufacturers received a platform security update in 2016.
  • We released monthly Android security updates throughout the year for devices running Android 4.4.4 and up—that accounts for 86.3 percent of all active Android devices worldwide.
  • Our carrier and hardware partners helped expand deployment of these updates, releasing updates for over half of the top 50 devices worldwide in the last quarter of 2016.
We provided monthly security updates for all supported Pixel and Nexus devices throughout 2016, and we're thrilled to see our partners invest significantly in regular updates as well. There's still a lot of room for improvement however. About half of devices in use at the end of 2016 had not received a platform security update in the previous year. We're working to increase device security updates by streamlining our security update program to make it easier for manufacturers to deploy security patches and releasing A/B updates to make it easier for users to apply those patches.

On the research side, our Android Security Rewards program grew rapidly: we paid researchers nearly $1 million dollars for their reports in 2016. In parallel, we worked closely with various security firms to identify and quickly fix issues that may have posed risks to our users.

We appreciate all of the hard work by Android partners, external researchers, and teams at Google that led to the progress the ecosystem has made with security in 2016. But it doesn't stop there. Keeping you safe requires constant vigilance and effort. We're looking forward to new insights and progress in 2017 and beyond.

21 March 2017

O-MG, the Developer Preview of Android O is here!

Posted by Dave Burke, VP of Engineering

Since the first launch in 2008, the Android project has thrived on the incredible feedback from our vibrant ecosystems of app developers and device makers, as well as of course our users. More recently, we've been pushing hard on improving our engineering processes so we can share our work earlier and more openly with our partners.

So, today, I'm excited to share a first developer preview of the next version of the OS: Android O. The usual caveats apply: it's early days, there are more features coming, and there's still plenty of stabilization and performance work ahead of us. But it's booting :).

Over the course of the next several months, we'll be releasing updated developer previews, and we'll be doing a deep dive on all things Android at Google I/O in May. In the meantime, we'd love your feedback on trying out new features, and of course testing your apps on the new OS.

What's new in O?

Android O introduces a number of new features and APIs to use in your apps. Here's are just a few new things for you to start trying in this first Developer Preview:

Background limits: Building on the work we began in Nougat, Android O puts a big priority on improving a user's battery life and the device's interactive performance. To make this possible, we've put additional automatic limits on what apps can do in the background, in three main areas: implicit broadcasts, background services, and location updates. These changes will make it easier to create apps that have minimal impact on a user's device and battery. Background limits represent a significant change in Android, so we want every developer to get familiar with them. Check out the documentation on background execution limits and background location limits for details.

Notification channels: Android O also introduces notification channels, which are new app-defined categories for notification content. Channels let developers give users fine-grained control over different kinds of notifications — users can block or change the behavior of each channel individually, rather than managing all of the app's notifications together.

Notification channels let users control your app's notification categories

Android O also adds new visuals and grouping to notifications that make it easier for users to see what's going on when they have an incoming message or are glancing at the notification shade.

Autofill APIs: Android users already depend on a range of password managers to autofill login details and repetitive information, which makes setting up new apps or placing transactions easier. Now we are making this work more easily across the ecosystem by adding platform support for autofill. Users can select an autofill app, similar to the way they select a keyboard app. The autofill app stores and secures user data, such as addresses, user names, and even passwords. For apps that want to handle autofill, we're adding new APIs to implement an Autofill service.

PIP for handsets and new windowing features: Picture in Picture (PIP) display is now available on phones and tablets, so users can continue watching a video while they're answering a chat or hailing a car. Apps can put themselves in PiP mode from the resumed or a pausing state where the system supports it - and you can specify the aspect ratio and a set of custom interactions (such as play/pause). Other new windowing features include a new app overlay window for apps to use instead of system alert window, and multi-display support for launching an activity on a remote display.

Font resources in XML: Fonts are now a fully supported resource type in Android O. Apps can now use fonts in XML layouts as well as define font families in XML — declaring the font style and weight along with the font files.

Adaptive icons: To help you integrate better with the device UI, you can now create adaptive icons that the system displays in different shapes, based on a mask selected by the device. The system also animates interactions with the icons, and uses them in the launcher, shortcuts, Settings, sharing dialogs, and in the overview screen.

Adaptive icons display in a variety of shapes across different device models.

Wide-gamut color for apps: Android developers of imaging apps can now take advantage of new devices that have a wide-gamut color capable display. To display wide gamut images, apps will need to enable a flag in their manifest (per activity) and load bitmaps with an embedded wide color profile (AdobeRGB, Pro Photo RGB, DCI-P3, etc.).

Connectivity: For the ultimate in audio fidelity, Android O now also supports high-quality Bluetooth audio codecs such as LDAC codec. We're also adding new Wi-Fi features as well, like Wi-Fi Aware, previously known as Neighbor Awareness Networking (NAN). On devices with the appropriate hardware, apps and nearby devices can discover and communicate over Wi-Fi without an Internet access point. We're working with our hardware partners to bring Wi-Fi Aware technology to devices as soon as possible.

The Telecom framework is extending ConnectionService APIs to enable third party calling apps integrate with System UI and operate seamlessly with other audio apps. For instance, apps can have their calls displayed and controlled in different kinds of UIs such as car head units.

Keyboard navigation: With the advent of Google Play apps on Chrome OS and other large form factors, we're seeing a resurgence of keyboard navigation use within these apps. In Android O we focused on building a more reliable, predictable model for "arrow" and "tab" navigation that aids both developers and end users.

AAudio API for Pro Audio: AAudio is a new native API that's designed specifically for apps that require high-performance, low-latency audio. Apps using AAudio read and write data via streams. In the Developer Preview we're releasing an early version of this new API to get your feedback.

WebView enhancements: In Android Nougat we introduced an optional multiprocess mode for WebView that moved the handling of web content into an isolated process. In Android O, we're enabling multiprocess mode by default and adding an API to let your app handle errors and crashes, for enhanced security and improved app stability. As a further security measure, you can now opt in your app's WebView objects to verify URLs through Google Safe Browsing.

Java 8 Language APIs and runtime optimizations: Android now supports several new Java Language APIs, including the new java.time API. In addition, the Android Runtime is faster than ever before, with improvements of up to 2x on some application benchmarks.

Partner platform contributions: Hardware manufacturers and silicon partners have accelerated fixes and enhancements to the Android platform in the O release. For example, Sony has contributed more than 30 feature enhancements including the LDAC codec and 250 bug fixes to Android O.

Get started in a few simple steps

First, make your app compatible to give your users a seamless transition to Android O. Just download a device system image or emulator system image, install your current app, and test -- the app should run and look great, and handle behavior changes properly. After you've made any necessary updates, we recommend publishing to Google Play right away without changing the app's platform targeting.

Building with Android O

When you're ready, dive in to O in depth to learn about everything you can take advantage of for your app. Visit the O Developer Preview site for details on the preview timeline, behavior changes, new APIs, and support resources.

Plan how your app will support background limits and other changes. Try out some of the great new features in your app -- notification channels, PIP, adaptive icons, font resources in XML, autosizing TextView, and many others. To make it easier to explore the new APIs in Android O, we've brought the API diff report online, along with the Android O API reference.

The latest canary version of Android Studio 2.4 includes new features to help you get started with Android O. You can download and set up the O preview SDK from inside Android Studio, then use Android O's XML font resources and autosizing TextView in the Layout Editor. Watch for more Android O support coming in the weeks ahead.

We're also releasing an alpha version of the 26.0.0 support library for you to try. This version adds a number of new APIs and increases the minSdkversion to 14. Check out the release notes for details.

Preview updates

The O Developer Preview includes an updated SDK with system images for testing on the official Android Emulator and on Nexus 5X, Nexus 6P, Nexus Player, Pixel, Pixel XL and Pixel C devices. If you're building for wearables, there's also an emulator for testing Android Wear 2.0 on Android O.

We plan to update the preview system images and SDK regularly throughout the O Developer Preview. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Downloads and instructions are here.

As we get closer to a final product, we'll be inviting consumers to try it out as well, and we'll open up enrollments through Android Beta at that time. Stay tuned for details, but for now please note that Android Beta is not currently available for Android O.

Give us your feedback

As always, your feedback is crucial, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We've moved to a more robust tool, Issue Tracker, which is also used internally at Google to track bugs and feature requests during product development. We hope you'll find it easier to use.

Introducing Android Native Development Kit r14

Posted by Dan Albert, Android NDK Tech Lead

Android NDK r14


The latest version of the Android Native Development Kit (NDK), Android NDK r14, is now available for download. It is also available in the SDK manager via Android Studio.

So what's new in r14? The full changelog can be seen here, but the highlights include the following:
  • Updated all the platform headers to unified headers (covered in detail below)
  • LTO with Clang now works on Darwin and Linux
  • libc++ has been updated. You can now use thread_local for statics with non-trivial destructors (Clang only)
  • RenderScript is back!

Unified Headers

We've completely redone how we ship platform header files in the NDK. Rather than having one set of headers for every target API level, there's now a single set of headers. The availability of APIs for each Android platform is guarded in these headers by #if __ANDROID_API__ >= __ANDROID_API_FOO__ preprocessor directives.

The prior approach relied on periodically-captured snapshots of the platform headers. This meant that any time we fixed a header-only bug, the fix was only available in the latest version aside from the occasional backport. Now bugfixes are available regardless of your NDK API level.

Aside from bugfixes, this also means you'll have access to modern Linux UAPI headers at every target version. This will mostly be important for people porting existing Linux code (especially low-level things). Something important to keep in mind: just because you have the headers doesn't mean you're running on a device with a kernel new enough to support every syscall. As always with syscalls, ENOSYS is a possibility.

Beyond the Linux headers, you'll also have modern headers for OpenGL, OpenSLES, etc. This should make it easier to conditionally use new APIs when you have an older target API level. The GLES3 headers are now accessible on Ice Cream Sandwich even though that library wasn't available until KitKat. You will still need to use all the API calls via dlopen/dlsym, but you'll at least have access to all the constants and #defines that you would need for invoking those functions.
Note that we'll be removing the old headers from the NDK with r16, so the sooner you file bugs, the smoother the transition will go.

Caveats

The API #ifdef guards do not exist in third-party headers like those found in OpenGL. In those cases you'll receive a link time error (undefined reference) rather than a compile time error if you use an API that is not available in your targeted API level.

Standalone toolchains using GCC are not supported out of the box (nor will they be). To use GCC, pass -D__ANDROID_API__=$API when compiling.

Enabling Unified Headers in Your Build

To ease the transition from the legacy headers to the unified headers, we haven't enabled the new headers by default, though we'll be doing this in r15. How you opt-in to unified headers will depend on your build system.

ndk-build


In your Application.mk:

    APP_UNIFIED_HEADERS := true
You can also set this property from the command-line like this:

    $ ndk-build APP_UNIFIED_HEADERS=true

If you're using ndk-build via Gradle with externalNativeBuild, specify the following configuration settings in build.gradle:

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          ndkBuild {
            ...
            arguments "APP_UNIFIED_HEADERS=true"
          }
        }
      }
    }

CMake

When configuring your build, set ANDROID_UNIFIED_HEADERS=ON. This will usually take the form of invoking CMake with cmake -DANDROID_UNIFIED_HEADERS=ON $OTHER_ARGS.

If you're using CMake via Gradle with externalNativeBuild, you can use:

    android {
      ...
      defaultConfig {
        ...
        externalNativeBuild {
          cmake {
            ...
            arguments "-DANDROID_UNIFIED_HEADERS=ON"
          }
        }
      }
    }

Standalone Toolchains

When creating your standalone toolchain, pass --unified-headers. Note that this option is not currently available in the legacy script, make-standalone-toolchain.sh, but only in make_standalone_toolchain.py.

Experimental Gradle Plugin

Coming soon! Follow along here.

Custom Build System?

We've got you covered. Instructions on adding support for unified headers to your build system can be found here.

For additional information about unified headers, see our docs and the tracking bug. If you're looking ahead to future releases, the most up-to-date version of the documentation is in the master branch.

16 March 2017

Android Developer Story: LinkedIn uses Android Studio to build a performant app

Posted by Christopher Katsaros, Developer Marketing, Android


LinkedIn is the world's largest social network for professionals. LinkedIn has 10 apps on Google Play, including the flagship LinkedIn app, which provides all of the same features users find on the web, so users can do things like browse and send messages to their professional network with an improved user experience.

For LinkedIn, and other teams with a large number of developers adding code to a project, making sure that everyone pays attention to areas that affect performance is vital for the quality of their app. That's why the the LinkedIn mobile team uses Android Studio to build high quality Android apps.

Watch Pradeepta Dash, Engineering Manager for Infrastructure at LinkedIn, as well as Drew Hannay, Tech Lead for the Android Infrastructure team, talk about how Android Studio helps everyone on their team stay focused on these topics while getting new engineers quickly up and running:


The top Android developers use Android Studio to build powerful, successful apps for Google Play; you can learn more about the official IDE for Android app development, and get started for yourself.

Get more tips and watch more success stories in the Playbook for Developers app.

How useful did you find this blogpost?
        


15 March 2017

Grow your app or game business on Google Play with new best practices


Posted by Dom Elliott, Developer Marketing, Google Play


We've updated the Android Developers website with some useful information about Google Play and the Google Play Developer Console for new and existing developers alike.
Visit the site to understand more about:

The updated business guide to succeeding on Google Play is full of best practices and success stories from other developers grouped into five objectives. Here are a few new articles to check out:
Head to the best practice guide to check out more of the articles. We'll continue to post useful best practices and success stories here on the blog and to the guide so you can read them on the web or in the Playbook app. To stay up-to-date with our news and tips, opt in to emails from Google Play in the Developer Console (or subscribe here if you don't have a developer account).


How useful did you find this blogpost?
        


14 March 2017

Future of Java 8 Language Feature Support on Android

Posted by James Lau, Product Manager 

At Google, we always try to do the right thing. Sometimes this means adjusting our plans. We know how much our Android developer community cares about good support for Java 8 language features, and we're changing the way we support them.

We've decided to add support for Java 8 language features directly into the current javac and dx set of tools, and deprecate the Jack toolchain. With this new direction, existing tools and plugins dependent on the Java class file format should continue to work. Moving forward, Java 8 language features will be natively supported by the Android build system. We're aiming to launch this as part of Android Studio in the coming weeks, and we wanted to share this decision early with you.

We initially tested adding Java 8 support via the Jack toolchain. Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted. Thank you for trying the Jack toolchain and giving us great feedback. You can continue using Jack to build your Java 8 code until we release the new support. Migrating from Jack should require little or no work.

We hope the new plan will pave a smooth path for everybody to take advantage of Java 8 language features on Android. We'll share more details when we release the new support in Android Studio.

13 March 2017

Detecting and eliminating Chamois, a fraud botnet on Android

Posted by Security Software Engineers—Bernhard Grill, Megan Ruthven, and Xin Zhao



Google works hard to protect users across a variety of devices and environments. Part of this work involves defending users against Potentially Harmful Applications (PHAs), an effort that gives us the opportunity to observe various types of threats targeting our ecosystem. For example, our security teams recently discovered and defended users of our ads and Android systems against a new PHA family we've named Chamois.

Chamois is an Android PHA family capable of:
  • Generating invalid traffic through ad pop ups having deceptive graphics inside the ad
  • Performing artificial app promotion by automatically installing apps in the background
  • Performing telephony fraud by sending premium text messages
  • Downloading and executing additional plugins

Interference with the ads ecosystem

We detected Chamois during a routine ad traffic quality evaluation. We analyzed malicious apps based on Chamois, and found that they employed several methods to avoid detection and tried to trick users into clicking ads by displaying deceptive graphics. This sometimes resulted in downloading of other apps that commit SMS fraud. So we blocked the Chamois app family using Verify Apps and also kicked out bad actors who were trying to game our ad systems.
Our previous experience with ad fraud apps like this one enabled our teams to swiftly take action to protect both our advertisers and Android users. Because the malicious app didn't appear in the device's app list, most users wouldn't have seen or known to uninstall the unwanted app. This is why Google's Verify Apps is so valuable, as it helps users discover PHAs and delete them.

Under Chamois's hood

Chamois was one of the largest PHA families seen on Android to date and distributed through multiple channels. To the best of our knowledge Google is the first to publicly identify and track Chamois.
Chamois had a number of features that made it unusual, including:
  • Multi-staged payload: Its code is executed in 4 distinct stages using different file formats, as outlined in this diagram.

This multi-stage process makes it more complicated to immediately identify apps in this family as a PHA because the layers have to be peeled first to reach the malicious part. However, Google's pipelines weren't tricked as they are designed to tackle these scenarios properly.
  • Self-protection: Chamois tried to evade detection using obfuscation and anti-analysis techniques, but our systems were able to counter them and detect the apps accordingly.
  • Custom encrypted storage: The family uses a custom, encrypted file storage for its configuration files and additional code that required deeper analysis to understand the PHA.
  • Size: Our security teams sifted through more than 100K lines of sophisticated code written by seemingly professional developers. Due to the sheer size of the APK, it took some time to understand Chamois in detail.

Google's approach to fighting PHAs

Verify Apps protects users from known PHAs by warning them when they are downloading an app that is determined to be a PHA, and it also enables users to uninstall the app if it has already been installed. Additionally, Verify Apps monitors the state of the Android ecosystem for anomalies and investigates the ones that it finds. It also helps finding unknown PHAs through behavior analysis on devices. For example, many apps downloaded by Chamois were highly ranked by the DOI scorer. We have implemented rules in Verify Apps to protect users against Chamois.
Google continues to significantly invest in its counter-abuse technologies for Android and its ad systems, and we're proud of the work that many teams do behind the scenes to fight PHAs like Chamois.

We hope this summary provides insight into the growing complexity of Android botnets. To learn more about Google's anti-PHA efforts and further ameliorate the risks they pose to users, devices, and ad systems, keep an eye open for the upcoming "Android Security 2016 Year In Review" report.

02 March 2017

Android Studio 2.3

By Jamal Eason, Product Manager, Android

Android Studio 2.3 is available to download today. The focus for this release is quality improvements across the IDE. We are grateful for all your feedback so far. We are committed to continuing to invest in making Android Studio fast & seamless for the millions of Android app developers across the world.

We are most excited about the quality improvements in Android Studio 2.3 but you will find a small set of new features in this release that integrate into each phase of your development flow. When designing your app, take advantage of the updated WebP support for your app images plus check out the updated ConstraintLayout library support and widget palette in the Layout Editor. As you are developing, Android Studio has a new App Link Assistant which helps you build and have a consolidated view of your URIs in your app. While building and deploying your app, use the updated run buttons for a more intuitive and reliable Instant Run experience. Lastly, while testing your app with the Android Emulator, you now have proper copy & paste text support.

What's new in Android Studio 2.3

For more detail about the features we added on top of the quality improvements Android Studio 2.3, check out the list of the new features below:
Build
  • Instant Run Improvements and UI Changes: As a part of our focus on quality, we have made some significant changes to Instant Run in Android Studio 2.3 to make the feature more reliable. The Run action will now always cause an application restart to reflect changes in your code that may require a restart, and the new Apply Changes action will attempt to swap the code while your app keeps running. The underlying implementation has changed significantly to improve on reliability, and we have also eliminated the startup lag for Instant Run enabled apps. Learn more.
New Instant Run Button Actions
  • Build Cache: Introduced but disabled by default in Android Studio 2.2, Build Cache is an underlying build optimization for faster builds in Android Studio. By caching exploded AARs and pre-dexed external libraries, the new build cached leads to faster clean builds. This is a user-wide build cache that is now turned on by default with Android Studio 2.3. Learn more.
Design
  • Chains and Ratios support in Constraint Layout: Android Studio 2.3 includes the stable release of ConstraintLayout With this release of ConstraintLayout, you can now chain two or more Android views bi-directionally together to form a group on one dimension. This is helpful when you want when you want to place two views close together but want to spread them across empty space. Learn more.
Constraint Layout Chains

ConstraintLayout also supports ratios, which is helpful when you want to maintain the aspect ratio of widget as the containing layout expands and contracts. Learn more about ratios. Additionally, both Chains and Ratios in ConstraintLayout can support programmatic creating with ConstraintSet APIs.

Constraint Layout Ratios

  • Layout Editor Palette: The updated widget palette in the Layout Editor allows you to search, sort and filter to find widgets for your layouts, plus gives you a preview of the widget before dragging on to the design surface. Learn more.

Layout Editor Widget Palette

  • Layout Favorites: You can now save your favorite attributes per widget in the updated Layout Editor properties panel. Simply star an attribute in the advanced panel and it will appear under the Favorites section. Learn more.

Favorites Attributes on Layout Editor Properties Panel
  • WebP Support: To help you save space in your APK, Android Studio can now generate WebP images from PNG assets in your project. The WebP lossless format is up to 25% smaller than a PNG. With Android Studio 2.3, you have a new wizard that converts PNG to lossless WebP and also allows you to inspect lossy WebP encoding as well. Right-click on any non-launcher PNG file to convert to WebP. And if you need to edit the image, you can also right-click on any WebP file in your project to convert back to PNG. Learn more.
WebP Image Conversion Wizard

  • Material Icon Wizard Update: The updated vector asset wizard supports search and filtering, plus it includes labels for each icon asset. Learn more.
Vector Asset Wizard

Develop
  • Lint Baseline: With Android Studio 2.3, you can set unresolved lint warnings as a baseline in your project. From that point forward, Lint will report only new issues. This is helpful if you have many legacy lint issues in your app, but just want to focus on fixing new issues. Learn more about Lint baseline and the new Lint checks & annotations added in this release.
Lint Baseline Support
  • App Links Assistant: Supporting Android App Links in your app is now easier with Android Studio. The new App Links Assistant allows you to easily create new intent filters for your URLs, declare your app's website association through a Digital Asset Links file, and test your Android App Links support. To access the App Link Assistant go to the following menu location: ToolsApp Link Assistant. Learn more.
App Links Assistant
  • Template Updates: By default, all templates in Android Studio 2.3 which use to contain RelativeLayout, now use ConstraintLayout. Learn more about templates and Constraint Layout. We have also added a new Bottom Navigation Activity template, which implements the Bottom Navigation Material Design guideline.

New Project Wizard Templates
  • IntelliJ Platform Update: Android Studio 2.3 includes the IntelliJ 2016.2 release, which has enhancements such as an updated inspection window and a notifications system. Learn more.
Test
  • Android Emulator Copy & Paste: Back by popular demand, we added back the Copy & Paste feature to the latest Emulator (v25.3.1). We have a shared clipboard between the Android Emulator and host operating system, which will allow you to copy text between both environments. Copy & Paste works with x86 Google API Emulator system images API Level 19 (Android 4.4 - Kitkat) and higher.

Copy & Paste support in Android Emulator

  • Android Emulator Command Line Tools: Starting with Android SDK Tools 25.3, we have moved the emulator from the SDK Tools folder into a separate emulator directory, and also deprecated and replaced the "android avd" command with a standalone avdmanager command. The previous command line parameters for emulator and "android avd" will work with the updated tools. We have also added location redirects for the emulator command. However, if you create Android Virtual Devices (AVDs) directly through the command line you should update any corresponding scripts. If you are using the Android Emulator through Android Studio 2.3, these change will not impact your workflow. Learn more.

To recap, Android Studio 2.3 includes these new features and more:

Develop
Build
Design
Test

Learn more about Android Studio 2.3 by reviewing the release notes.

Getting Started

Download
If you are using a previous version of Android Studio, you can check for updates on the Stable channel from the navigation menu (Help → Check for Update [Windows/Linux] , Android Studio → Check for Updates [OS X]). You can also download Android Studio 2.3 from the official download page. To take advantage of all the new features and improvements in Android Studio, you should also update to the Android Gradle plugin version to 2.3.0 in your current app project.
We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter.

01 March 2017

Getting Santa Tracker Into Shape


Posted by Sam Stern, Developer Programs Engineer

Santa Tracker is a holiday tradition at Google.  In addition to bringing seasonal joy to millions of users around the world, it's a yearly testing ground for the latest APIs and techniques in app development.  That's why the full source of the app is released on Github every year.


In 2016, the Santa team challenged itself to introduce new content to the app while also making it smaller and more efficient than ever before.  In this post, you can read about the road to a more slimmer, faster Santa Tracker.

APK Bloat

Santa Tracker has grown over the years to include the visual and audio assets for over a dozen games and interactive scenes.  In 2015, the Santa Tracker APK size was 66.1 MB.


The Android Studio APK analyzer is a great tool to investigate what made the 2015 app so large.

Screenshot from 2017-02-01 11:59:09.png


First, while the APK size is 66.1 MB, we see that the download size is 59.5MB! The majority of that size is in the resources folder, but assets and native libraries contribute a sizable piece.


The 2016 app contains everything that was in the 2015 app while adding four completely new games.  At first, we assumed that making the app smaller while adding all of that would be impossible, but (spoiler alert!) here are the final results for 2016:

Screenshot from 2017-02-01 12:06:23.png


The download size for the app is now nearly 10MB smaller despite the addition of four new games and a visual refresh. The rest of this section will explore how we got there.

Multiple APK Support on Google Play with APK Splits

The 2015 app added the "Snowdown" game by Google's Fun Propulsion Labs team.  This game is written in C++, so it's included in Santa Tracker as a native library.  The team gave us compiled libraries for armv5, armv7, and x86 architectures.  Each version was about 3.5MB, which adds up to the 10.5MB you see in the lib entry for the 2015 APK.


Since each device is only using one of these architectures, two thirds of the native libraries could be removed to save space - the tradeoff here is that we’ll publish multiple APKs.  The Android gradle build system has native support for building an APK for each architecture (ABI) with only a few lines of configuration in the app's build.gradle file:

ext.abiList = ['armeabi', 'armeabi-v7a', 'x86']
android {
   
   // ...
   splits {
       abi {
           // Enable ABI splits
           enable true
           // Include the three architectures that we support for snowdown
           reset()
           include(*abiList)
           // Also build a "universal" APK that will run on any device
           universalApk true
       }
   }
}


Once splits are enabled, each split needs to be given a unique version code so that they can co-exist in the Play Store:

// Generate unique versionCodes for each APK variant: ZXYYSSSSS
//   Z is the Major version number
//   X is the Minor version number
//   YY is the Patch version number
//   SSSS is information about the split (default to 0000)
// Any new variations get added to the front
import com.android.build.OutputFile;
android.applicationVariants.all { variant ->
   variant.outputs.each { output ->
       // Shift abi over by 8 digits
       def abiFilter = output.getFilter(OutputFile.ABI)
       int abiVersionCode = (abiList.indexOf(abiFilter) + 1)
       // Merge all version codes
       output.versionCodeOverride = variant.mergedFlavor.versionCode + abiVersionCode
   }
}


In the most recent version of Santa Tracker, we published versions for armv5, armv7, and x86 respectively.  With this change in place, 10.5MB of native libraries was reduced to about 4MB per variant without losing any functionality.

Optimize Images

The majority of the Santa Tracker APK is image resources. Each game has hundreds of images, and each image comes in multiple sizes for different screen densities. Almost all of these images are PNGs, so in past years we ran PNGCrush on all of the files and figured our job was done.  We learned in 2016 that there have been advancements in lossless PNG compression, and Google's zopfli tool is currently the state of the art.


By running zopflipng on all PNG assets we losslessly reduced the size of most images by 10% and some by as much as 30%. This resulted in almost a 5MB size reduction across the app without sacrificing any quality. For instance this image of Santa was losslessly reduced from 10KB to only 7KB.  Don't bother trying to spot the differences, there are none!


Before (10.2KB)
After (7.4KB)
santa-before.png
santa-before-zopfli.png


Unused Resources

When working on Santa Tracker engineers are constantly refactoring the app, adding and removing pieces of logic and UI from previous years. While code review and linting help to find unused code, unused resources are much more likely to slip by unnoticed.  Plus there is no ProGuard for resources, so we can't be saved by our toolchain and unused images and other resources often sneak into the app.


Android Studio can help to find resources that are not being used and are therefore bloating the APK.  By clicking Analyze > Run Inspection by Name > Unused Resources Android Studio will identify resources that are not used by any known codepaths.  It's important to first eliminate all unused code, as resources that are "used" by dead code will not be detected as unused.


After a few cycles of analysis with Android Studio's helpful tools, we were able to find dozens of unused files and eliminate a few more MB of resources from the app.

Memory Usage

Santa Tracker is popular all around the world and has users on thousands of unique Android devices.  Many of these devices are a few years old and have 512MB RAM or less, so we have historically run into OutOfMemoryErrors in our games.


While the optimizations above made our PNGs smaller on disk, when loaded into a Bitmap their memory footprint is unchanged.  Since each game in Santa Tracker loads dozens of images, we quickly get into dangerous memory territory.


In 2015 six of our top ten crashes were memory related. Due to the optimizations below (and others) we moved memory crashes out of the top ten altogether.

Image Loading Backoff

When initializing a game in Santa Tracker we often load all of the Bitmaps needed for the first scene into memory so that the game can run smoothly.  The naive approach looks like this:


private LruCache<Integer, Drawable> mMemoryCache;
private BitmapFactory.Options mOptions;
public void init() {
 // Initialize the cache
 mMemoryCache = new LruCache<Integer, Drawable>(240);
 // Start with no Bitmap sampling
 mOptions = new BitmapFactory.Options();
 mOptions.inSampleSize = 1;
}
public void loadBitmap(@DrawableRes int id) {
   // Load bitmap
   Bitmap bmp = BitmapFactory.decodeResource(getResources(), id, mOptions);
   BitmapDrawable bitmapDrawable = new BitmapDrawable(getResources(), bmp);
   
   // Add to cache
   mMemoryCache.put(id, bitmapDrawable);
}


However the decodeResource function will throw an OutOfMemoryError if we don't have enough RAM to load the Bitmap into memory.  To combat this, we catch these errors and then try to reload all of the images with a higher sampling ratio (scaling by a factor of 2 each time):

private static final int MAX_DOWNSAMPLING_ATTEMPTS = 3;
private int mDownsamplingAttempts = 0;
private Bitmap tryLoadBitmap(@DrawableRes int id) throws Exception {
   try {
       return BitmapFactory.decodeResource(getResources(), id, mOptions);
   } catch (OutOfMemoryError oom) {
       if (mDownSamplingAttempts < MAX_DOWNSAMPLING_ATTEMPTS) {
           // Increase our sampling by a factor of 2
           mOptions.inSampleSize *= 2;
           mDownSamplingAttempts++;
       }
   }
   throw new Exception("Failed to load resource ID: " + resourceId);
}


With this technique low-memory devices will now see more pixelated graphics, but by making this tradeoff we almost completely eliminated memory errors from Bitmap loading.

Transparent Pixels

As mentioned above, an image's size on disk is not a good indicator of how much memory it will use. One glaring example is images with large transparent regions.  PNG can compress these regions to near-zero disk size but each transparent pixel still demands the same RAM.


For example in the "Dasher Dancer" game, animations were represented by a series of 1280x720 PNG frames.  Many of these frames were dominated by transparency as the animated object left the screen.  We wrote a script to trim all of the transparent space away and record an "offset" for displaying each frame so that it would still appear to be 1280x720 overall. In one test this reduced runtime RAM usage of the game by 60MB! And now that we were not wasting memory on transparent pixels, we needed less downscaling and could use higher-resolution images on low-memory devices.

Additional Explorations

In addition to the major optimizations described above, we explored a few other avenues for making the app smaller and faster with varying degrees of success.

Splash Screens

The 2015 app moved to a Material Design aesthetic where games were launched from a central list of 'cards'. We noticed that half of the games would cause the card 'ripple' effect to be janky on launch, but we couldn't find the root cause and were unable to fix the issue.


When work on the 2016 version of the app we were determined to fix the game jank launch. After hours of investigation, we realized it was only the games fixed to the landscape orientation that caused jank when launched.  The dropped frames were due to the forced orientation change. To create a smooth user experience, we introduced splash screens in between the launcher Activity and game Activities.  The splash screen would detect the current device orientation and the orientation needed to play the game being loaded and rotate itself at runtime to match.  This immediately removed any noticeable jank from game launches and made the whole app feel smoother.

SVG

When we originally took on the task of reducing the size of our resources, using SVG images seemed like an obvious optimization.  Vector images are dramatically smaller and only need to be included once to support multiple densities.  Due to the 'flat' aesthetic in Santa Tracker, we were even able to convert many of our PNGs to tiny SVGs without much quality loss. However loading these SVGs was completely impractical on slower devices, where they would be tens or hundreds of times slower than a PNG depending on the path complexity.


In the end we decided to follow the recommendation limiting vector image sizes at 200x200 dp and only used SVG for small icons in the app rather than large graphics or game assets.

Conclusions

When we started building Santa Tracker 2016 we were faced with a daunting problem: how can we make the app smaller and faster while adding exciting new content? The optimizations above were discovered by constantly challenging each other to do more with less and considering resource constraints with every change we made. In the end we were able to incrementally make the Santa Tracker app as healthy as it has ever been ... our next job will be helping Mr. Claus work off all that extra cookie weight.