30 November 2016

Updated Udacity Android course prepares students for the Associate Android Developer Certification

Posted by Jocelyn Becker, Senior Program Manager, Android Training

As one of our most popular Udacity courses, the Developing Android Apps course was recently updated to ensure developers have the resources to build high quality apps. This course, which has already helped more than half a million developers learn to build Android apps, has been through the car wash and come out sparkling clean and updated.

Google and Udacity have worked together to update the course to include the very latest changes in Android and Android Studio, including how to use the new Constraint Layout editor, and how to use Firebase Job Dispatcher. Learn best practices for building Android apps using Android 7.0 (Nougat) while keeping your apps backwards compatible in older versions, learning at your own pace in your own time.

You sent us feedback that some of the lessons were a little difficult to get through, so we've restructured the lessons and added smaller apps for you to build as you progress through the course. So not only will you build the Sunshine weather app as a complete, integrated application that spans the entire course, but you'll also create an app in each lesson to help you learn individual concepts.

Build a To Do app and add new tasks as you learn how to build a ContentProvider.

This course brings back Android experts Dan Galpin and Reto Meier from Google, and Lyla Fujiwara from Udacity, and introduces new faces from Google and Udacity.

Start learning now at https://www.udacity.com/course/ud851.

Combined package for Developing Android Apps course and Associate Android Developer Certification

This updated course teaches the skills that are tested by the Associate Android Developer certification exam. Udacity is offering a package that combines the updated Developing Android Apps course with a voucher for the Associate Android Developer certification exam. If you pass this exam, you will earn the Associate Android Developer Certification and show that you are competent and skilled in tasks that an entry-level Android developer typically performs. Enroll in Udacity's Fast Track to get prepared and take the Associate Android developer exam at: https://www.udacity.com/course/nd818.

Learn tips from Memrise to increase in-app conversions with pricing experiments

Posted by Tamzin Taylor, Partner Development Manager at Google Play, & Kristina Narusk, Head of Production at Memrise

Getting people to install your app is one thing, getting them to sign up to your paid offering is quite another. It's important to understand the complete journey your users take from installing your app to paying for something. Once you do, you can experiment on the flow to try and increase conversions. Memrise has found great success in experimenting on their language learning app to increase the number of paying users.

Four experiments Memrise use to improve conversions

Memrise makes languages fun with a number of different learning modes you can play to help increase your vocabulary in a chosen language. You can download the app for free and play some of the modes or take advantage of their premium subscription offering called 'Memrise Pro' which offers new game modes and additional features like offline learning. Memrise recently ran a number of conversion experiments with the main objective of increasing the Average Revenue Per Daily Active User (ARPDAU). These experiments tested multiple user experience and pricing experiment scenarios.

1. A/B test how messaging different user benefits can impact conversion

What they did: Memrise wanted to know what motivation and call to action would convert the most users to buy a Pro subscription from a locked game mode in the app. To do this, they ran an A/B test with two similar designs, featuring different reasons for the user to upgrade, and compared the results to their original upgrade messaging.


                       


Test A: Focus on ‘difficult’ words with an orange background.
Test B: Focus on ‘favorite’ words with a pink background.

Results: Test A performed the best. Conversion to Pro in Test A was 28% higher than in Test B. Pro mode usage was subsequently 9.7% higher in Test A compared to Test B too.

Next steps: After seeing how test A won the experiment, Memrise applied this creative across the board. Subscribers driven by that particular mode increased as a percentage of all subscriptions in the app by 16%. Memrise plans to run additional A/B tests at others points of conversion in the app to see if they can increase the results even further. They'll also try different text for the call to actions.

2. Test whether adapting to local price points results in sustainable uplift

In 2015, Google Play launched new minimum local price levels in countries around the world. To take advantage of the new price points, Memrise tested lowering localised prices in certain markets to better match purchasing power. Prices were an average of 6 times lower during this experiment.

Results: After 30 days, Memrise saw the following changes in conversions to paid users:


๐Ÿ‡น๐Ÿ‡ท
Turkey
180%
๐Ÿ‡ง๐Ÿ‡ท
Brazil
182%
๐Ÿ‡ท๐Ÿ‡บ
Russia
99%
๐Ÿ‡ฒ๐Ÿ‡ฝ
Mexico
115%
๐Ÿ‡ฎ๐Ÿ‡ณ
India
5.1%
๐Ÿ‡ฎ๐Ÿ‡ฉ
Indonesia
152%
๐Ÿ‡ฐ๐Ÿ‡ท
South Korea
120%
๐Ÿ‡น๐Ÿ‡ญ
Thailand
70%
๐Ÿ‡ฒ๐Ÿ‡พ
Malaysia
27%

Next steps: The change in price affected the subscription dynamics with more users taking advantage of Memrise's in-app discounted offer in most countries. The offer was for annual subscribers only and has led to a positive effect on LTV. One insight from the experiment was that Indian users prefered to have the option to subscribe in weekly or monthly increments and not just annually. Memrise is still tracking carefully to see whether the discounted subscription pricing will lead to an increase in conversions.

3. Test when and how often you offer free trials to see if that affects conversion rate
Memrise occasionally offers users, who aren't Pro subscribers, a free trial of one of the Pro game modes while cycling through the various free modes. After the free trial session, users are presented with an offer to subscribe. Memrise experimented with the offer's timing making it appear more frequently while users were cycling through normal free sessions Instead of after every 49th session, users saw the unlocked mode after every 21st session.

                

An example of a free trial of a Pro mode.
After completing a free trial, users see a discounted subscription offer.
Results: Offering a free trial more frequently paid off. The conversion rate increased by 50% while all other conversion rates remained the same.

Next steps: Memrise maintained the more frequent offer cadence and has seen revenue growth as a result.

4. Test whether seasonal discounts result in more conversions Memrise launched a 'Back to School' campaign presenting all users with a discounted annual plan offer for a week in September 2016. The aim was to convert more users and generate higher value users from annual subscription plans.


Results: Memrise saw two effects from the seasonal offer. As a result of only presenting an annual period and removing weekly and monthly, 20% fewer users per day converted to Pro. However, because more people were taking an annual subscription than a shorter subscription, the average revenue per day increased by 32% justifying the change.

Next steps: Memrise plans to test different offers in the future with a combination of subscription offerings. They'll also focus offers in countries like Turkey and Mexico, where they saw the biggest increase in conversions.

Keep experimenting and take advantage of new features to improve the user experience and increase conversions

At Playtime San Francisco, we announced that introductory pricing for subscriptions would be coming soon and the feature is now live. By continually testing messaging, pricing, offers, and free trials or discounted trials, you could increase the conversions in your app and your ongoing revenue just like Memrise. Learn more about Google Play in-app billing subscriptions and get the Playbook for Developers app 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?



29 November 2016

Keeping it real: Improving reviews and ratings in Google Play

Posted by Andrew Ahn, Product Manager and Buddhika Kottahachchi, Product Manager

The Play Store contains the largest catalog of apps in the world. As our users make decisions about the apps they'd like to install, we want to ensure Play provides a trustworthy experience.

Recently, we announced our improvements in fighting fraudulent and spam app installs. In continuing our efforts to combat spammy behavior, we've also improved the ways we identify and remove fake reviews and ratings. With this enhanced capability we are now able to identify and remove more fake reviews and ratings with greater accuracy.

In the vast majority of cases, no action is needed. If you are working with someone else to promote your app (e.g., third-party marketing agencies), we advise you to check-in and ensure that their promotion techniques use legitimate practices, and adhere to the Google Play Developer Policy. The basic rule of thumb for reviews and ratings is that they should come from genuine users, and developers should not attempt to manipulate them in any form (e.g., fake, paid, incentivized).

We will continue making such enhancements to our systems that will further help protect the integrity of Google Play, our developer community, and ultimately our end users.

Android Developer Story: Le Monde increases subscriptions with Google Play Billing

Watch Edouard Andrieu, Director of Mobile, and Ahcene Amrouz, Product Manager for Mobile, explain how La Matinale has a 6% higher subscription conversion on Android than on other platforms thanks to tools like Google Play Billing.

Learn more how to add an introductory price to your subscription, and get the News Publisher Playbook to stay up-to-date with more features and best practices to help you find success for your news apps on Google Play.


How useful did you find this blogpost?

23 November 2016

Your next growth market: Realizing the potential of MENA

Posted by Mohammad El-Saadi, BD, Google Play

We know that many developers want to take advantage of growth opportunities in new regions, but are held back by not knowing the most important areas to focus on. That's why we wanted to share stories from our partners in the Middle East and North Africa (MENA). It's a fast growing region for Google Play, and one that already represents a sizable revenue opportunity. They've shared their experiences, and some key things to focus on if you're thinking of launching in the region.

Middle East and North Africa overview

MENA is a diverse region in terms of disposable income, access to connectivity, and smartphone penetration. However, it is possible to broadly group MENA into two types of market:

Growth markets

  • Examples: Saudi Arabia, United Arab Emirates (UAE), Kuwait and the rest of the Gulf Cooperation Council (GCC).
  • Very high smartphone penetration (on par with top western european markets),
  • Large disposable income
  • Robust growth in spend on mobile apps and games

Emerging markets

  • Examples: Morocco, Egypt and Iraq.
  • Large populations
  • Significant growth in smartphone (primarily Android) adoption.

Opportunities

Localization

If you want to be successful in MENA, localization is key. In Saudi Arabia 19 of the top 20 grossing apps & games have their Google Play Store listing localized and the majority of those have their actual app/game localized as well. By localizing to Arabic, mobile app and game developers have found great success in the region.

When Singapore-based Wego.com localized to Arabic, they achieved over 200% YoY growth in MENA, grew their app rating from 3.5 to over 4.5 among Arab travelers and increased Arab users' retention rates by 200%. Today, MENA represents over 65% of their users.

To do localization well, here are a few things to consider:

  • Localize your store listing into Arabic including your video, screenshots and text. If you are targeting specific countries within MENA consider using local dialects, otherwise use formal Arabic. Consider using Store Listing Experiments to optimize your listing for local audiences.
  • If applicable, flip your app/game UI to be right-to-left.
  • Beware of common issues when localizing to Arabic: Arabic letters appearing disjointed or showing up in reverse order and the ordering of words getting mixed up when sentences contain both Latin and Arabic words
  • Localize pricing by showing appropriate local currency and rounding. Note that different countries in MENA have different currencies and affordability/willingness to pay.
  • Plan around major local events such as the holy month of Ramadan, when after fasting from dawn to sunset, families and loved ones gather for meals, laughs and stories. We've found that during this month usage of apps and games increases significantly in MENA.
  • Provide local customer support
  • Be culturally sensitive in your communication and content - avoid stereotypes and keep in mind the relatively conservative nature of users in the region
  • Leverage the power of YouTube to reach your audiences in MENA. Saudi Arabia for instance is the second largest market for YouTube globally in terms of views per capita.

Refer to our Localization Checklist for some best practices when localizing for any language.

Gaming

Gaming is a high growth and revenue opportunity in MENA. Most countries in the region have a median age of 30 or lower, smartphone growth will continue to grow at double digits, which makes gaming a key segment for users in the region. Today's local top grossing charts and dominated by Midcore strategy games. Interestingly, GCC countries have some of the highest Average Revenue Per Paying User rates globally.

International titles, including Clash of Clans, Clash Royale, Mobile Strike and Clash of Kings, have performed incredibly well in the region. In addition, titles specifically targeting MENA have also seen tremendous success. Revenge of the Sultans, by ONEMT, from China, has been the top grossing title across several MENA countries for many months. Similarly, when IGG.com launched the Arabic version of Castle Clash, they grew revenue from MENA by 58% within 4 months.

As the market evolves, there is also a huge opportunity for other genres (such as RPG, FPS, and sports) which are not present at scale in the region yet.

Google Play in MENA

We continue to invest in making sure that users are able to pay for their favorite apps and games by launching locally relevant payment methods in MENA. Today, we have carrier billing available with the major networks in Saudi Arabia, UAE and Kuwait. We plan to expand coverage in more countries, including Qatar and Bahrain, in the future.

We are also committed to increasing the quality and availability of Arabic apps and games for MENA users, which is why we launched our Now in Arabic collection featuring apps and games that have recently localized to Arabic. This collection will be regularly updated. If you're interested in being included, submit your localized app/game.

22 November 2016

Final update to Android 7.1 Developer Preview

Posted by Dave Burke, VP of Engineering

Today we're rolling out an update to the Android 7.1 Developer Preview -- the last before we release the final Android 7.1.1 platform to the ecosystem. Android 7.1.1 includes the developer features already available on Pixel and Pixel XL devices and adds optimizations and bug fixes on top of the base Android 7.1 platform. With Developer Preview 2, you can make sure your apps are ready for Android 7.1.1 and the consumers that will soon be running it on their devices.

As highlighted in October, we're also expanding the range of devices that can receive this Developer Preview update to Nexus 5X, Nexus 6P, Nexus 9, and Pixel C.

If you have a supported device that's enrolled in the Android Beta Program, you'll receive an update to Developer Preview 2 over the coming week. If you haven't enrolled your device yet, just visit the site to enroll your device and get the update.

In early December, we'll roll out Android 7.1.1 to the full lineup of supported devices as well as Pixel and Pixel XL devices.

What's in this update?

Developer Preview 2 is a release candidate for Android 7.1.1 that you can use to complete your app development and testing in preparation for the upcoming final release. In includes near-final system behaviors and UI, along with the latest bug fixes and optimizations across the system and Google apps.

It also includes the developer features and APIs (API level 25) already introduced in Developer Preview 1. If you haven't explored the developer features, you'll want to take a look at app shortcuts, round icon resources, and image keyboard support, among others -- you can see the full list of developer features here.

With Developer Preview 2, we're also updating the SDK build and platform tools in Android Studio, the Android 7.1.1 platform, and the API Level 25 emulator system images. The latest version of the support library (25.0.1) is also available for you to add image keyboard support, bottom navigation, and other features for devices running API Level 25 or earlier.

For details on API Level 25 check out the API diffs and the updated API reference on the developer preview site.

Get your apps ready for Android 7.1

Now is the time to optimize your apps to look their best on Android 7.1.1. To get started, update to Android Studio 2.2.2 and then download the API Level 25 platform, emulator system images, and tools through the SDK Manager in Android Studio.

After installing the API Level 25 SDK, you can update your project's compileSdkVersion to 25 to build and test against the new APIs. If you're doing compatibility testing, we recommend updating your app's targetSdkVersion to 25 to test your app with compatibility behaviors disabled. For details on how to set up your app with the API Level 25 SDK, see Set up the Preview.

If you're adding app shortcuts or circular launcher icons to your app, you can use Android Studio's built-in Image Asset Studio to quickly help you create icons of different sizes that meet the material design guidelines. You can test your round icons on the Google APIs emulator for API Level 25, which includes support for round icons and the new Google Pixel Launcher.

Android Studio and the Google APIs emulator let you quickly create and test your round icon assets.

If you're adding image keyboard support, you can use the Messenger and Google Keyboard apps included in the preview system images for testing as they include support for this new API.

Scale your tests using Firebase Test Lab for Android

To help scale your testing, make sure to take advantage of Firebase Test Lab for Android and run your tests in the cloud at no charge during the preview period on all virtual devices including the Developer Preview 2 (API 25). You can use the automated crawler (Robo Test) to test your app without having to write any test scripts, or you can upload your own instrumentation (e.g. Espresso) tests. You can upload your tests here.

Publish your apps to alpha, beta or production channels in Google Play

After you've finished final testing, you can publish your updates compiled against, and optionally targeting, API 25 to Google Play. You can publish to your alpha, beta, or even production channels in the Google Play Developer Console. In this way, push your app updates to users whose devices are running Android 7.1, such as Pixel and Android Beta devices.

Get Developer Preview 2 on Your Eligible Device

If you have an eligible device that's already enrolled in the Android Beta Program, the device will get the Developer Preview 2 update over the coming week. No action is needed on your part. If you aren't yet enrolled in program, the easiest way to get started is by visiting android.com/beta and opt-in your eligible Android phone or tablet -- you'll soon receive this preview update over-the-air. As always, you can also download and flash this update manually.

As mentioned above, this Developer Preview update is available for Nexus 5X, Nexus 6P, Nexus 9, and Pixel C devices.

We're expecting to launch the final release of the Android 7.1.1 in just a few weeks Starting in December, we'll roll out Android 7.1.1 to the full lineup of supported preview devices, as well as the recently launched Pixel and Pixel XL devices. At that time, we'll also push the sources to AOSP, so our device manufacturer partners can bring this new platform update to consumers on their devices.

Meanwhile, we continue to welcome your feedback in the Developer Preview issue tracker, N Preview Developer community, or Android Beta community as we work towards the final consumer release in December!

Calling European game developers, enter the Indie Games Contest by December 31

Originally posted on Google Developers blog

Posted by Matteo Vallone, Google Play Games Business Development

To build awareness of the awesome innovation and art that indie game developers are bringing to users on Google Play, we have invested heavily over the past year in programs like Indie Corner, as well as events like the Google Play Indie Games Festivals in North America and Korea.

As part of that sustained effort, we also want to celebrate the passion and innovation of indie game developers with the introduction of the first-ever Google Play Indie Games Contest in Europe. The contest will recognize the best indie talent in several countries and offer prizes that will help you get your game noticed by industry experts and gamers worldwide.

Prizes for the finalists and winners:

  • An open showcase held at the Saatchi Gallery in London
  • YouTube influencer campaigns worth up to 100,000 EUR
  • Premium placements on Google Play
  • Tickets to Google I/O 2017 and other top industry events
  • Promotions on our channels
  • Special prizes for the best Unity game
  • And more!

Entering the contest:

If you're based in Czech Republic, Denmark, Finland, France (coming soon), Germany, Iceland, Israel, Netherlands, Norway, Poland (coming soon), Romania, Spain, Sweden, Turkey, or UK (excl. Northern Ireland), have 15 or less full time employees, and published a new game on Google Play after 1 January 2016, you may now be eligible to enter the contest. If you're planning on publishing a new game soon, you can also enter by submitting a private beta. Check out all the details in the terms and conditions. Submissions close on 31 December 2016.

The process:

Up to 20 finalists will get to showcase their games at an open event at the Saatchi Gallery in London on the 16th February 2017. At the event, the top 10 will be selected by the event attendees and the Google Play team. The top 10 will then get the opportunity to pitch to a jury of industry experts, from which the final winner and runners up will be selected.

Even if someone is NOT entering the contest:

Even if you're not eligible to enter the contest, you can still register to attend the final showcase event in London on 16 February 2017, check out some great indie games, and have fun with various industry experts and indie developers. We will also be hosting a workshop for all indie games developers from across EMEA in the new Google office in Kings Cross the next day, so this will be a packed week.

Get started:

Enter the Indie Games Contest now and visit the contest site to find out more about the contest, the event, and the workshop.

21 November 2016

Google Play services and Firebase for Android will support API level 14 at minimum

Posted by Doug Stevenson, Developer Advocate

Version 10.0.0 of the Google Play services client libraries, as well as the Firebase client libraries for Android, will be the last version of these libraries that support Android API level 9 (Android 2.3, Gingerbread). The next scheduled release of these libraries, version 10.2.0, will increase the minimum supported API level from 9 to 14 (Android 4.0.1, Ice Cream Sandwich). This change will happen in early 2017.

Why are we discontinuing support for Gingerbread and Honeycomb in Google Play services?

The Gingerbread platform is almost six years old. Many Android developers have already discontinued support for Gingerbread in their apps. This helps them build better apps that make use of the newer capabilities of the Android platform. For us, the situation is the same. By making this change, we will be able to provide a more robust collection of tools for Android developers with greater speed.

What this means for your Android app that uses Google Play services or Firebase:

You may use version 10.0.0 of Google Play services and Firebase as you are currently. It will continue to work with Gingerbread devices as it has in the past.

When you choose to upgrade to the future version 10.2.0, and if your app minimally supports API level 14 or greater (typically specified as "minSdkVersion" in your build.gradle), you will not encounter any versioning problems. However, if your app supports lower than API level 14, you will encounter a problem at build time with an error that looks like this:

Error:Execution failed for task ':app:processDebugManifest'.
> Manifest merger failed : uses-sdk:minSdkVersion 9 cannot be smaller than version 14 declared in library [com.google.android.gms:play-services:10.2.0]
        Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage

Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use Google Play services 10.2.0 and later, you can choose one of the following options:

1. Target API level 14 as the minimum supported API level.

This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 14. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.

A very small percentage of all Android devices are using API levels less than 14. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.

If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 10.0.0. This is described below.

2. Build multiple APKs to support devices with an API level less than 14.

Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the components of Play Services you're using:

productFlavors {
    legacy {
        minSdkVersion 9
        versionCode 901  // Min API level 9, v01
    }
    current {
        minSdkVersion 14
        versionCode 1401  // Min API level 14, v01
    }
}

dependencies {
    legacyCompile 'com.google.android.gms:play-services:10.0.0'
    currentCompile 'com.google.android.gms:play-services:10.2.0'
}

In the above situation, there are two product flavors being built against two different versions of the Google Play services client libraries. This will work fine if only APIs are called that are available in the 10.0.0 library. If you need to call newer APIs made available with 10.2.0, you will have to create a compatibility library for the newer API calls so that they are only built into the version of the application that can use them:

  • Declare a Java interface that exposes the higher-level functionality you want to perform that is only available in current versions of Play services.
  • Build two Android libraries that implement that interface. The "current" implementation should call the newer APIs as desired. The "legacy" implementation should no-op or otherwise act as desired with older versions of Play services. The interface should be added to both libraries.
  • Conditionally compile each library into the app using "legacyCompile" and "currentCompile" dependencies.
  • In the app's code, call through to the compatibility library whenever newer Play APIs are required.

After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.

17 November 2016

Pixel Security: Better, Faster, Stronger

Posted by Paul Crowley, Senior Software Engineer and Paul Lawrence, Senior Software Engineer

Encryption protects your data if your phone falls into someone else's hands. The new Google Pixel and Pixel XL are encrypted by default to offer strong data protection, while maintaining a great user experience with high I/O performance and long battery life. In addition to encryption, the Pixel phones debuted running the Android Nougat release, which has even more security improvements.

This blog post covers the encryption implementation on Google Pixel devices and how it improves the user experience, performance, and security of the device.

File-Based Encryption Direct Boot experience

One of the security features introduced in Android Nougat was file-based encryption. File-based encryption (FBE) means different files are encrypted with different keys that can be unlocked independently. FBE also separates data into device encrypted (DE) data and credential encrypted (CE) data.

Direct boot uses file-based encryption to allow a seamless user experience when a device reboots by combining the unlock and decrypt screen. For users, this means that applications like alarm clocks, accessibility settings, and phone calls are available immediately after boot.

Enhanced with TrustZone® security

Modern processors provide a means to execute code in a mode that remains secure even if the kernel is compromised. On ARM®-based processors this mode is known as TrustZone. Starting in Android Nougat, all disk encryption keys are stored encrypted with keys held by TrustZone software. This secures encrypted data in two ways:

  • TrustZone enforces the Verified Boot process. If TrustZone detects that the operating system has been modified, it won't decrypt disk encryption keys; this helps to secure device encrypted (DE) data.
  • TrustZone enforces a waiting period between guesses at the user credential, which gets longer after a sequence of wrong guesses. With 1624 valid four-point patterns and TrustZone's ever-growing waiting period, trying all patterns would take more than four years. This improves security for all users, especially those who have a shorter and more easily guessed pattern, PIN, or password.

Encryption on Pixel phones

Protecting different folders with different keys required a distinct approach from full-disk encryption (FDE). The natural choice for Linux-based systems is the industry-standard eCryptFS. However, eCryptFS didn't meet our performance requirements. Fortunately one of the eCryptFS creators, Michael Halcrow, worked with the ext4 maintainer, Ted Ts'o, to add encryption natively to ext4, and Android became the first consumer of this technology. ext4 encryption performance is similar to full-disk encryption, which is as performant as a software-only solution can be.

Additionally, Pixel phones have an inline hardware encryption engine, which gives them the ability to write encrypted data at line speed to the flash memory. To take advantage of this, we modified ext4 encryption to use this hardware by adding a key reference to the bio structure, within the ext4 driver before passing it to the block layer. (The bio structure is the basic container for block I/O in the Linux kernel.) We then modified the inline encryption block driver to pass this to the hardware. As with ext4 encryption, keys are managed by the Linux keyring. To see our implementation, take a look at the source code for the Pixel kernel.

While this specific implementation of file-based encryption using ext4 with inline encryption benefits Pixel users, FBE is available in AOSP and ready to use, along with the other features mentioned in this post.

10 November 2016

Understanding APK packaging in Android Studio 2.2

Posted by Wojtek Kaliciล„ski, Android Developer Advocate

Android Studio 2.2 launched recently with many new and improved features. Some of the changes are easy to miss because they happened under the hood in the Android Gradle plugin, such as the newly rewritten integrated APK packaging and signing step.

APK Signature Scheme v2

With the introduction of the new APK Signature Scheme v2 in Android 7.0 Nougat, we decided to rewrite how assembling APKs works in the Android Gradle plugin. You can read all about the low-level technical details of v2 signatures in the documentation, but here's a quick tl;dr summary of the info you need as an Android app developer:

  • The cryptographic signature of the APK that is used to verify its integrity is now located immediately before the ZIP Central Directory.
  • The signature is computed and verified over the binary contents of the whole APK file, as opposed to decompressed file contents of each file in the archive in v1.
  • An APK can be signed by both v1 and v2 signatures at the same time, so it remains backwards compatible with previous Android releases.

Why introduce this change to how Android verifies APKs? Firstly, for enhanced security and extensibility of this new signing format, and secondly for performance - the new signatures take significantly less time to verify on the device (no need for costly decompression), resulting in faster app installation times.

The consequence of this new signing scheme, however, is that there are new constraints on the APK creation process. Since only uncompressed file contents were verified in v1, that allowed for quite a lot of modifications to be made after APK signing - files could be moved around or even recompressed. In fact, the zipalign tool which was part of the build process did exactly that - it was used to align ZIP entries on correct byte boundaries for improved runtime performance.

Because v2 signatures verify all bytes in the archive and not individual ZIP entries, running zipalign is no longer possible after signing. That's why compression, aligning and signing now happens in a single, integrated step of the build process.

If you have any custom tasks in your build process that involve tampering with or post-processing the APK file in any way, please make sure you disable them or you risk invalidating the v2 signature and thus making your APKs incompatible with Android 7.0 and above.

Should you choose to do signing and aligning manually (such as from the command line), we offer a new tool in the Android SDK, called apksigner, that provides both v1 and v2 APK signing and verification. Note that you need to run zipalign before running apksigner if you are using v2 signatures. Also remember the jarsigner tool from the JDK is not compatible with Android v2 signatures, so you can't use it to re-sign your APKs if you want to retain the v2 signature.

In case you want to disable adding v1 or v2 signatures when building with the Android Gradle plugin, you can add these lines to your signingConfig section in build.gradle:

v1SigningEnabled false
v2SigningEnabled false

Note: both signing schemes are enabled by default in Android Gradle plugin 2.2.

Release builds for smaller APKs

We took this opportunity when rewriting the packager to make some optimizations to the size of release APKs, resulting in faster downloads, smaller delta updates on the Play Store, and less wasted space on the device. Here are some of the changes we made:

  • Files in the archive are now sorted to minimize differences between APK builds.
  • All file timestamps and metadata are zeroed out.
  • Level 6 and level 9 compression is checked for all files in parallel and the optimal one is used, i.e. if L9 provides little benefit in terms of size, then L6 may be chosen for better performance
  • Native libraries are stored uncompressed and page aligned in the APK. This brings support for the android:extractNativeLibs="false" option from Android 6.0 Marshmallow and lets applications use less space on the device as well as generate smaller updates on the Play Store
  • Zopfli compression is not used to better support Play Store update algorithms. It is not recommended to recompress your APKs with Zopfli. Pre-optimizing individual resources such as PNG files in your projects is still fine and recommended.

These changes help make your releases as small as possible so that users can download and update your app even on a slower connection or on less capable devices. But what about debug builds?

Debug builds for installation speed

When developing apps you want to keep the iteration cycle fast - change code, build, and deploy on a connected device or emulator. Since Android Studio 2.0 we've been working to make all the steps as fast as possible. With Instant Run we're now able to update only the changed code and resources during runtime, while the new Emulator brings multi-processor support and faster ADB speeds for quicker APK transfer and installation. Build improvements can cut that time even further and in Android Studio 2.2 we're introducing incremental packaging and parallel compression for debug builds. Together with other features like selectively packaging resources for the target device density and ABI this will make your development even faster.

A word of caution: the APK files created for Instant Run or by invoking a debug build are not meant for distribution on the Play Store! They contain additional instrumentation code for Instant Run and are missing resources for device configurations other than the one that was connected when you started the build. Make sure you only distribute release versions of the APK which you can create using the Android Studio Generate Signed APK command or the assembleRelease Gradle task.

09 November 2016

Adding TV Channels to Your App with the TIF Companion Library

Posted by Nick Felker and Sachit Mishra, Developer Programs Engineers

The TV Input Framework (TIF) on Android TV makes it easy for third-party app developers to create their own TV channels with any type of linear media. It introduces a new way for apps to engage with users with a high-quality channel surfing experience, and it gives users a single interface to browse and watch all of their channels.

To help developers get started with building TV channels, we have created the TV Input Framework Companion Library, which includes a number of helper methods and classes to make the development process as easy as possible.

This library provides standard classes to set up a background task that updates the program guide and an interface that helps integrate your media player with the playback controller, as well as supports the new TV Recording APIs that are available in Android Nougat. It includes everything you need to start showing your content on your Android TV's live TV app.

(Note: source from android-tv-sample-inputs sample)

To get started, take a look at the sample app and documentation. The sample demonstrates how to extend this library to create custom channels and manage video playback. Developers can immediately get started with the sample app by updating the XMLTV file with their own content or dynamically creating channels in the SampleJobService.

You can include this library in your app by copying the library directory from the sample into your project root directory. Then, add the following to your project's settings.gradle file:

include ':library'

In your app's build.gradle file, add the following to your dependencies:

compile project(':library')

Android TV continues to grow, and whether your app has on-demand or live media, TIF is a great way to keep users engaged with your content. One partner for example, Haystack TV, recently integrated TIF into their app and it now accounts for 16% of watch time for new users on Android TV.

Check out our TV developer site to learn more about Android TV, and join our developer community on Google+ at g.co/androidtvdev to discuss this library and other topics with TV developers.

07 November 2016

CMake and ndk-build support in Android Studio 2.2

Posted by Kathryn Shih, Android Product Manager

In addition to supporting the experimental Gradle plugin, Android Studio 2.2 enables you to build C/C++ components of Android projects using CMake and ndk-build.

The Android Studio team plans to continue to support the experimental Gradle plugin. This will eventually replace the current Gradle plugin, providing additional tightly-integrated benefits to C/C++ developers such as smarter dependency management. So if you're interested in someday having the smartest possible interface between your IDE and your build system, you shouldn't ignore the experimental plugin.

CMake and ndk-build are useful alternatives to Gradle in several cases:

  • Projects that are already using CMake or ndk-build, such as legacy Eclipse ndk projects
  • Projects that are unable to assume the risk of using an experimental plugin for their C/C++ builds
  • Projects that will share a C/C++ build system across multiple platforms
  • C/C++ projects that need to use advanced features currently unavailable in experimental Gradle such as NEON support

For new projects, we recommend using CMake or experimental Gradle. For new Android projects with limited C++, we recommend trying the experimental Gradle plugin. For projects with substantial amounts of C++, or where you want the maximally stable build configuration, we recommend using a CMake build. Android Studio intends CMake to be a permanently supported solution.

While we think that there are substantial advantages to having a single build system able to handle all parts of an Android application, stabilizing the experimental plugin is not an option for us because it relies on Gradle APIs that are still a work in progress. Until the Gradle APIs are stabilized, the experimental plugin will keep changing, particularly in its Domain Specific Language, and will be strictly tied to a very specific version of Gradle itself.

Note that the the old, undocumented ndkCompile integration is deprecated. If you are using it, you need to move away from it as we'll remove it completely in the near future. We recommend migrating to gradle+cmake via our migration guide.

Migrating from Eclipse to Android Studio

We no longer support the Eclipse ADT. To get started migrating, download and install Android Studio. For most projects, migration is as simple as importing your existing Eclipse ADT projects in Android Studio with the File → New→ Import Project menu option. For more details on the migration process, check out the migration guide.

Feedback and Open Source Contributions

We're dedicated to making Android Studio the best possible integrated development environment for building Android apps, so if there are missing features or other challenges preventing you from using Android Studio, we want to hear about it [please take our survey]. You can also file bugs or feature requests directly with the team, and let us know via our Twitter or Google+ accounts.

Android Studio is an open source project, available to all at no cost. Check out our Open Source project page if you're interested in contributing or learning more.

03 November 2016

Test on Android 7.1 Developer Preview in Firebase Test Lab

By Ahmed Mounir Gad, Product Manager, Firebase Test Lab

To deliver the best user experience right out of the gate, Firebase Test Lab for Android allows you to test your apps and ensure their compatibility with multiple device configurations, across OS versions, screen orientations, and locales. With a single click, you can run your tests on hundreds of device configurations in Google Cloud and receive your results quickly.

Today, we’re excited to announce the availability of the Android 7.1 Developer Preview on Firebase Test Lab virtual devices. In addition to testing the Android 7.1 Developer Preview on your physical Android Device with the Android Beta program, or on your local Android Emulator, you can use the Firebase Test Lab to scale your app testing to hundreds of Android virtual devices.

You can also use Firebase Test Lab to perform your own testing. If you don’t have any test scripts, Robo test is ideal for doing your basic compatibility testing on the new platform. It crawls your app in an attempt to find crashes. You can also use the Espresso Test Recorder in Android Studio to record your own instrumentation tests without writing any code.

From now until the end of December (12/31/2016), Firebase Test Lab will be offered at no charge on the Firebase Blaze plan for all virtual devices, to help you ensure the compatibility of your app with the Android 7.1 Developer Preview release, as well as with other Android releases.

Prepare your app for API level 25, then go to the Firebase Test Lab console to run your first test.

Happy testing!

Robo tests uncovering a crash on Android 7.1 Developer Preview for the Flood-It! app.