Improving app security and performance on Google Play for years to come

Posted by Edward Cunningham, Product Manager, Android

[Edit: Updated post on Dec 21 to clarify that when the
64-bit requirement is introduced in August 2019, 32-bit support is not going
away. Apps that include a 32-bit library just need to have a 64-bit version
too.]

Google Play powers billions of app installs and updates annually. We
relentlessly focus on security and performance to ensure everyone has a positive
experience discovering and installing apps and games they love. Today we're
giving Android developers a heads-up about three changes designed to support
these goals, as well as explaining the reasons for each change, and how they
will help make Android devices even more secure and performant for the long
term.

• In the second half of 2018, Play will require that new apps and app updates
  target a recent Android API level. This will be required for new apps in
  August 2018, and for updates to existing apps in
  November 2018. This is to ensure apps are built on the latest
  APIs optimized for security and performance.
  
• In August 2019, Play will require that new apps and app
  updates with native libraries provide 64-bit versions in addition to their
  32-bit versions.
  
• Additionally, in early 2018, Play will start adding a small amount of
  security metadata on top of each APK to further verify app authenticity. You do
  not need to take any action for this change.

We deeply appreciate our developer ecosystem, and so hope this long advance
notice is helpful in planning your app releases. We will continue to provide
reminders and share developer resources as key dates approach to help you
prepare.

Target API level requirement from late 2018

API behavior changes advance the security and privacy protections of Android –
helping developers secure their apps and protecting people from malware. Here
are a few such changes from recent platform versions:

• Implicit intents for bindService() no longer supported (href="https://developer.android.com/about/versions/android-5.0-changes.html#BindService">Android
  5.0)
  
• Runtime permissions (href="https://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-runtime-permissions">Android
  6.0)
  
• User-added CAs not trusted by default for secure connections (href="https://developer.android.com/about/versions/nougat/android-7.0.html#default_trusted_ca">Android
  7.0)
  
• Apps can't access user accounts without explicit user approval (href="https://developer.android.com/about/versions/oreo/android-8.0-changes.html#aaad">Android
  8.0)

Many of these changes only apply to apps that explicitly declare their support
for new API behaviors, through the href="https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#target">targetSdkVersion
manifest attribute. For example, only apps with a targetSdkVersion of 23
(the API level of Android 6.0) or higher give the user full control over what
private data – such as contacts or location – the app can access via runtime
permissions. Similarly, recent releases include user experience improvements
that prevent apps from accidentally overusing resources like battery and memory;
href="https://developer.android.com/about/versions/oreo/background.html">background
execution limits is a good example of this type of improvement.

In order to provide users with the best Android experience possible, the Google
Play Console will require that apps target a recent API level:

• August 2018: New apps required to target API level 26
  (Android 8.0) or higher.
  
• November 2018: Updates to existing apps required to target
  API level 26 or higher.
  
• 2019 onwards: Each year the targetSdkVersion requirement
  will advance. Within one year following each Android dessert release, new apps
  and app updates will need to target the corresponding API level or
  higher.

Existing apps that are not receiving updates are unaffected. Developers remain
free to use a href="https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#min">minSdkVersion
of their choice, so there is no change to your ability to build apps for older
Android versions. We encourage developers to provide backwards compatibility as
far as reasonably possible. Future Android versions will also restrict apps that
don't target a recent API level and adversely impact performance or security. We
want to proactively reduce fragmentation in the app ecosystem and ensure apps
are secure and performant while providing developers with a long window and
plenty of notice in order to plan ahead.

This year we released Android Oreo, the most secure and best performing version
of Android yet, and we introduced href="https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html">Project
Treble to help the latest releases reach devices faster. Get started
building apps that target Android 8.1 Oreo
today.

64-bit support requirement in 2019

Platform support for 64-bit architectures was introduced in Android 5.0. Today,
over 40% of Android devices coming online have 64-bit support, while still
maintaining 32-bit compatibility. For apps that use native libraries, 64-bit
code typically offers significantly better performance, with additional
registers and new instructions.

In anticipation of future Android devices that support 64-bit code only, the
Play Console will require that new apps and app updates with native libraries
provide 64-bit versions in addition to their 32-bit versions. This can be within
a single APK or as one of the multiple APKs published.

We are not removing 32-bit support. Google Play will continue to support 32-bit
apps and devices. Apps that do not include native code are unaffected.

This change will come into effect in August 2019. We're providing advance notice
today to allow plenty of time for developers who don't yet support 64-bit to
plan the transition. Stay tuned for a future post in which we'll take an
in-depth look at the performance benefits of 64-bit native libraries on Android,
and check out the href="https://developer.android.com/ndk/guides/arch.html">CPUs and
Architectures guide of the NDK for more info.

Security metadata in early 2018

Next year we'll begin adding a small amount of security metadata on top of each
APK to verify that it was officially distributed by Google Play. Often when you
buy a physical product, you'll find an official label or a badge which signifies
the product's authenticity. The metadata we're adding to APKs is like a Play
badge of authenticity for your Android app.

No action is needed by developers or users. We'll adjust Play's maximum APK size
to take into account the small metadata addition, which is inserted into the href="https://source.android.com/security/apksigning/v2">APK Signing Block
and does not alter the functionality of your app. In addition to enhancing the
integrity of Play's mobile app ecosystem, this metadata will enable new
distribution opportunities for developers in the future and help more people
keep their apps up to date.

Looking ahead

2017 has been a fantastic year for developers who have seen growth and success
on Google Play. We've been hard at work on features (including those announced
at href="https://android-developers.googleblog.com/2017/05/whats-new-in-google-play-at-io-2017.html">I/O
2017 and at href="https://android-developers.googleblog.com/2017/10/playtime-2017-find-success-on-google.html">Playtime)
to help you improve your app quality and business performance. With these
features and the upcoming updates, we hope to see the Android and Play ecosystem
continue to thrive in 2018 and beyond.

How useful did you find this blogpost?

★ ★ ★ ★ ★