Google Data

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.

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.

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 …

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.

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!

Posted by Larissa Fontaine, Director, Global Head of Apps Business
Development, Google Play

Almost three
years ago, we started the first of an ongoing series of developer events,
called Playtime, dedicated to educating partners on best practices and…

By Jamal Eason, Product
Manager, Android
With the release of Android
Studio 2.2, the time has now come to say goodbye to the Eclipse Android
Developer Tools. We have formally ended their support and development. There’s
never been a better time to swit…

Posted by Dorothy Kelly, Head of Developer Insights, Google Play Developer
Marketing

Core to our mission, we’re always
focused on the user and delivering the best experience possible. This same
principle underlies how Google Play works with develop…

Posted by Kazushi Nagayama, Search Quality Analyst, and Andrew Ahn, Product
Manager

We strive to continuously make Google Play the best platform for enjoying and
discovering the most innovative and trusted apps. Today we are announcing
additional en…

Guest post by Rajiev Timal, Founder of Readfeed

Readfeed was created to help book lovers around the world share and discuss
their favorite reads with each other more easily. Today, we are excited to
officially launch the Readfeed
app on Google Play….

By: Mary Liz McCurdy, Health & Fitness Lead, Google Play

(Originally published on Android Central)

It’s an exciting time to be a health & fitness app developer. With people
shelling out on fitness more than ever before, we’re seeing record high levels
of gym memberships and attendance, the rise of boutique fitness, and an emphasis
on connected devices.

Paramount to this growth is the integration of smart technology. Whether it be
through streaming video, wearables, or mobile apps, technology empowers us with
instant access to high quality workouts, sensor biofeedback, and endless
on-demand inspiration. At Google Play, we’ve seen this growth reflected by the
incredible popularity of health & fitness apps. In fact, this is one of Google
Play‘s fastest growing app categories, boasting the most engaged 30d active
users.

As the resident health & fitness expert on Google Play, I had the opportunity to
speak about what’s driving the category’s growth at the recent Wearables Technology Show. Here are the top
three recommendations I shared with the audience to help coach developers
towards building more valuable app experiences:

#1: Be invisible

#2: Be personal

#3: Be assistive

At the end of the day, changing health and fitness habits is hard. Make it
easier for your users by seamlessly guiding them on what they
personally need to do to achieve their goal. It’s that simple
We encourage you to experiment with these exercises to get your app fit for
the millions of Android users looking to live a healthier, happier life.

Posted by Kacey Fahey, Marketing Programs Manager, Google Play

Interested in growing your app on a global scale? See how two app developers
localized their apps in unique ways to drive revenue and user engagement.

drupe

drupe
is a communications app that utilizes the openness of android to build a truly
native experience delivering highly contextual recommendations to their users
across the world.

Key to achieving international growth, drupe has translated their app in 17
languages, and their store listing page in 28 languages. This led to an increase
in conversion and retention rates. Additionally, when entering India, the team
noticed several user reviews requesting integration with a specific messaging
app widely used in the Indian market. Through a combination of this integration,
adding Hindi language translation, and other new features, drupe saw improved
performance. In six months, daily active users increased 300%, and actions per
average daily user increased 25% in the Indian market.

Noom

Noom
is a health & fitness app that has achieved an 80% increase in international
revenue growth on Android over the past three years by localizing their app with
unique cultural behaviors, cuisines, and local-market coaches.

In addition to translating their app and store listing page, Noom conducted
extensive analysis to determine the right financial model tailored to each
international market. This included evaluation of their competitive landscape
and local health and wellness spending behavior, in addition to running pricing
experiments to determine the optimal offering between subscriptions, IAPs, or a
premium app.

Use the Localization
Checklist to learn more about tailoring your app for different markets to
drive installs and revenue, and to create a better overall user experience.
Also, get the Playbook for
Developers app to stay up-to-date on new features and learn best practices
that will help you grow a successful business on Google Play.

Read the full articles for drupe
and Noom.

Posted by Dave Burke, VP of Engineering

A couple of weeks ago we announced that a developer preview of Android 7.1 Nougat was on the way. You can get started with this new release today by downloading the SDK and tools. To get the 7.1 release on your eligible device, enroll your device in the Android Beta program. If your device is already enrolled, you’ll receive the update automatically.

What’s in the Developer Preview?

The Android 7.1 Developer Preview gives you everything you need to test your app on the new platform or extend it with new features like app shortcuts and image keyboard support. It includes an updated SDK and tools, documentation and samples, as well as emulators and device system images for running your apps on supported devices.

We’re continuing the model we used in N and earlier releases, and with Android 7.1 being an incremental release there are a few differences to highlight:

• Since 7.1 has already launched on Pixel, we’re delivering the initial Developer Preview at beta quality for the Nexus lineup of devices. The goal is to tease out any device-specific issues.
• We’ve finalized the new APIs as API Level 25
• We’ve opened up publishing on Google Play for apps targeting the new API level, so you can update your apps soon as you are ready.

After the initial preview release, we plan to deliver an update in November followed by the final public release to the Android Open Source Project (AOSP) in December. Initially available on Nexus 5X, Nexus 6P, and Pixel C devices, we’ll extend the Developer Preview to other devices in November.

Get your apps ready for Android 7.1

To get started, update to Android Studio 2.2.2 and download API Level 25 platform, emulator system images and tools. The final API Level 25 SDK is available for download through the SDK Manager in Android Studio.

Once you’ve installed 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.

The Google APIs Emulator System images shipped with the Android API Level 25 SDK include support for round icons and the new Google Pixel Launcher. The Google API system image allows you to test how your app’s circular app icons look in devices that support circular icons. Also, if you are developing live wallpapers, you can also use the the new system images with the Android Emulator to test the enhanced preview metadata in Android 7.1.

To help you add 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.

Along with the API Level 25 SDK, we have also updated the Android Support Library to 25.0.0. The new version lets you add image keyboard support with compatibility back to API level 13. It also introduces BottomNavigationView widget, which implements the bottom navigation pattern from the material design guidelines.

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

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

Since the Android 7.1 APIs are final, you can publish updates compiling with, and optionally targeting, API 25 to Google Play. You can now publish app updates that use API 25 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.

How to Get Android 7.1 Developer Preview on Your Eligible Device

If you are already enrolled in the Android Beta program, then your eligible enrolled devices will get the Android 7.1 Developer Preview update right away, no action is needed on your part. If you aren’t yet enrolled in Android Beta, the easiest way to get started is to visit android.com/beta and opt-in your eligible Android phone or tablet — you’ll soon receive this (and later) preview updates over-the-air. If you have an enrolled device and do not want to receive the update, just visit Android Beta and unenroll the device. You can also download and flash this update manually.

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

Posted by Lily Sheringham, Google Play team

Today we have released a new video ‘10 tips to stay on the right side of Google Play policy’. The video provides 10 best practices to help you develop and launch apps and games which follow Google Play’s Developer Program Policies.

It accompanies the recently published News video series and is part of our 10 tips for success on Google Play video series.

Watch the video to learn how to review your app, to ensure you have appropriate content and the rights to use it, how to handle user data, and more. Also, find out how to stay up to date with policy updates and get support from our policy team.

You can also find more resources on Google Play policies in the Developer Policy Center, and also get the new Playbook for Developers app to learn more best practices to find success on Google Play.

Posted by Lily Sheringham, Google Play team

Inovidea Magna Global, is the developer of PicMix, a photo and video editing app, which has now evolved into an interest based social media platform powered by content discovery and social commerce. It has 27 million users worldwide, 65% of which are outside of its home market in Indonesia.

Hear Calvin Kizana, CEO, and Sandy Colondam, Co-founder, explain how they used Google Play tools, such as Store Listing Experiments and Material Design, to create a high quality app which appeals to a global audience.

Learn more about store listing experiments and find out how to get started with Material Design. Also, get the Playbook for Developers app and stay up-to-date with more features and best practices that will help you grow a successful business on Google Play.