Posted by Edward Cunningham, Product Manager, Android
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
- 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
- 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
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 (Android
- Runtime permissions (Android
- User-added CAs not trusted by default for secure connections (Android
- Apps can’t access user accounts without explicit user approval (Android
Many of these changes only apply to apps that explicitly declare their support
for new API behaviors, through the
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;
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
will advance. Within one year following each Android dessert release, new apps
and app updates will need to target the corresponding API level or
Existing apps that are not receiving updates are unaffected. Developers remain
free to use a
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 Project
Treble to help the latest releases reach devices faster. Get started
building apps that target Android 8.1 Oreo
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 are able to run on
devices without 32-bit support. Apps that include a 32-bit library will need to
have a 64-bit alternative – either within the same APK or as one of the multiple
APKs published. 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 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 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.
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
2017 and at 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?
Android Developers Blog