☰
🔍
☰
🔍
19 Δεκεμβρίου 2017
[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.
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:
Many of these changes only apply to apps that explicitly declare their support
for new API behaviors, through the 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;
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:
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 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 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 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.
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 I/O 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
Google Play
