Earlier this year we launched the Google Play Apps & Games publication on Medium to help developers discover best practices and insights to grow successful apps and games businesses on Google Play. As we draw closer to the end of the year we thought it's a good time to revisit some of our most popular posts according to you – our readers.
It's clear that many of you are excited by the potential of new technology, such as Virtual Reality (VR) and Augmented Reality (AR), and how it could enhance user interaction with your apps and games. You're also concerned with everyday issues including how to keep your APK size manageable, how to acquire new users, and how to monetize games without pushing away your players.
So without further adieu, here's the list of the top 10:
Do you have suggestions for topics we should tackle in 2018? Let us know by tweeting with the hashtag #AskPlayDev and we'll reply from @GooglePlayDev, where we regularly share news and tips on how to be successful on Google Play.
How useful did you find this blogpost?
★ ★ ★ ★ ★
At Google I/O 2017, we announced a redesign of the Android TV's home screen. We expanded the recommendation row concept so that each app can have its own row (or multiple rows) of content on the home screen. Since the release of the new home screen, we have seen increased adoption of the new recommendation channels for Android Oreo in a wide variety of apps.
With more and more apps surfacing high-quality recommendations using the new channels, the legacy recommendation row in the new home screen on Android O will be phased out over the next year.
Currently, when an app creates recommendations with the legacy notification based API the content is added to a channel for that app. The channel may already exist if there was recommended content for it when you upgraded from Android N (or below). If the there is no channel for the app, it will be automatically generated for you. In either case, the user can't add or remove programs from the channel, but they can move, hide, and show the channel. When an app starts to use the new API to add its own channels, the system removes the auto-generated channel and the app takes over control of the display of their content.
Over the next year, we will phase out the automatic generation of channels. Instead of generating multiple channels, one for each app's legacy recommendations, we will insert one channel for all legacy recommendations. This channel will appear at the bottom of the channel list. Users can move or remove it. When a user upgrades to Android O, the previous recommendation row from Android N (and below) becomes a channel at the bottom of the home screen.
If you have not updated your app to post content to the new channels on the home screen, take a look at our documentation, codelab, and sample to get started.
We look forward to more and more apps taking advantage of the new changes in the home screen. We love to hear your feedback, so please visit the Android TV Developer Community on G+ to share your thoughts and ideas.
Android Oreo is stuffed full of security enhancements. Over the past few months, we've covered how we've improved the security of the Android platform and its applications: from making it safer to get apps, dropping insecure network protocols, providing more user control over identifiers, hardening the kernel, making Android easier to update, all the way to doubling the Android Security Rewards payouts. Now that Oreo is out the door, let's take a look at all the goodness inside.
Android already supports Verified Boot, which is designed to prevent devices from booting up with software that has been tampered with. In Android Oreo, we added a reference implementation for Verified Boot running with Project Treble, called Android Verified Boot 2.0 (AVB). AVB has a couple of cool features to make updates easier and more secure, such as a common footer format and rollback protection. Rollback protection is designed to prevent a device to boot if downgraded to an older OS version, which could be vulnerable to an exploit. To do this, the devices save the OS version using either special hardware or by having the Trusted Execution Environment (TEE) sign the data. Pixel 2 and Pixel 2 XL come with this protection and we recommend all device manufacturers add this feature to their new devices.
Oreo also includes the new OEM Lock Hardware Abstraction Layer (HAL) that gives device manufacturers more flexibility for how they protect whether a device is locked, unlocked, or unlockable. For example, the new Pixel phones use this HAL to pass commands to the bootloader. The bootloader analyzes these commands the next time the device boots and determines if changes to the locks, which are securely stored in Replay Protected Memory Block (RPMB), should happen. If your device is stolen, these safeguards are designed to prevent your device from being reset and to keep your data secure. This new HAL even supports moving the lock state to dedicated hardware.
Speaking of hardware, we've invested support in tamper-resistant hardware, such as the security module found in every Pixel 2 and Pixel 2 XL. This physical chip prevents many software and hardware attacks and is also resistant to physical penetration attacks. The security module prevents deriving the encryption key without the device's passcode and limits the rate of unlock attempts, which makes many attacks infeasible due to time restrictions.
While the new Pixel devices have the special security module, all new GMS devices shipping with Android Oreo are required to implement key attestation. This provides a mechanism for strongly attesting IDs such as hardware identifiers.
We added new features for enterprise-managed devices as well. In work profiles, encryption keys are now ejected from RAM when the profile is off or when your company's admin remotely locks the profile. This helps secure enterprise data at rest.
As part of Project Treble, the Android framework was re-architected to make updates easier and less costly for device manufacturers. This separation of platform and vendor-code was also designed to improve security. Following the principle of least privilege, these HALs run in their own sandbox and only have access to the drivers and permissions that are absolutely necessary.
Continuing with the media stack hardening in Android Nougat, most direct hardware access has been removed from the media frameworks in Oreo resulting in better isolation. Furthermore, we've enabled Control Flow Integrity (CFI) across all media components. Most vulnerabilities today are exploited by subverting the normal control flow of an application, instead changing them to perform arbitrary malicious activities with all the privileges of the exploited application. CFI is a robust security mechanism that disallows arbitrary changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.
In addition to these architecture changes and CFI, Android Oreo comes with a feast of other tasty platform security enhancements:
Android Instant Apps run in a restricted sandbox which limits permissions and capabilities such as reading the on-device app list or transmitting cleartext traffic. Although introduced during the Android Oreo release, Instant Apps supports devices running Android Lollipop and later.
In order to handle untrusted content more safely, we've isolated WebView by splitting the rendering engine into a separate process and running it within an isolated sandbox that restricts its resources. WebView also supports Safe Browsing to protect against potentially dangerous sites.
Lastly, we've made significant changes to device identifiers to give users more control, including:
net.hostname
Build.getSerial() API
Android Oreo brings in all of these improvements, and many more. As always, we appreciate feedback and welcome suggestions for how we can improve Android. Contact us at security@android.com.
_____________________________________________________________________
1: Glenn Wilkinson and team at Sensepost, UK, Célestin Matte, Mathieu Cunche: University of Lyon, INSA-Lyon, CITI Lab, Inria Privatics, Mathy Vanhoef, KU Leuven
[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.
targetSdkVersion
In order to provide users with the best Android experience possible, the Google Play Console will require that apps target a recent API level:
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.
minSdkVersion
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.
Today, we are excited to announce Quick Boot for the Android Emulator. With Quick Boot, you can launch the Android Emulator in under 6 seconds. Quick Boot works by snapshotting an emulator session so you can reload in seconds. Quick Boot was first released with Android Studio 3.0 in the canary update channel and we are excited to release the feature as a stable update today.
In addition to this new feature, we also wanted to highlight some of the top features from recent releases. Since the complete revamp of the Android Emulator two years ago, we continue to focus on improving speed, stability and adding a rich set of features that accelerate your app development and testing. With all the recent changes, it is definitely worth updating to the latest version of the Android Emulator to use it today.
Top 5 Features
Additionally, over the last several releases, we have improved CPU and I/O performance while enhancing GPU performance, including OpenGL ES 3.0 support. Looking at a common task such as ADB push highlights the improvements in the Android CPU and I/O pipelines:
For GPU performance, we created a sample GPU emulation stress test app to gauge improvements over time. We found that the latest emulator can render higher frame rates than before, and it is one of the few emulators that can render OpenGL ES 3.0 accurately per the Android specification.
More Features
In addition to these major features, there are a whole host of additional features that we have added to the Android Emulator over the last year that you may not be aware of:
Learn more about the Android Emulator in the Emulator documentation.
Getting Started
All of these features and improvements are available to download and use now with Android Emulator v27.0.2+, which you can get via the SDK Manager in Android Studio. For a fast experience, we recommend creating and running the x86 version of emulator system images, with the latest Android Emulator, Intel® HAXM (if applicable) and graphics drivers installed.
We appreciate any feedback on things you like, issues or features you would like to see. If you find a bug, issue, or have a feature request feel free to file an issue. We are definitely not done, but we hope you are excited about the improvements so far.
Creating robust connections between IoT devices can be difficult. WiFi and Bluetooth are ubiquitous and work well in many scenarios, but suffer limitations when power is constrained or large numbers of devices are required on a single network. In response to this, new communications technologies have arisen to address the power and scalability requirements for IoT.
Low-power Wireless Personal Area Network (LoWPAN) technologies are specifically designed for peer-to-peer usage on constrained battery-powered devices. Devices on the same LoWPAN can communicate with each other using familiar IP networking, allowing developers to use standard application protocols like HTTP and CoAP. The specific LoWPAN technology that we are most excited about is Thread: a secure, fault-tolerant, low-power mesh-networking technology that is quickly becoming an industry standard.
Today we are announcing API support for configuring and managing LoWPAN as a part of Android Things Developer Preview 6.1, including first-class networking support for Thread. By adding an 802.15.4 radio module to one of our developer kits, Android Things devices can communicate directly with other peer devices on a Thread network. These types of low-power connectivity solutions enable Android Things devices to perform edge computing tasks, aggregating data locally from nearby devices to make critical decisions without a constant connection to cloud services. See the LoWPAN API guide for more details on building apps to create and join local mesh networks.
OpenThread makes getting started with LoWPAN on Android Things easy. Choose a supported radio platform, such as the Nordic nRF52840, and download pre-built firmware to enable it as a Network Co-Processor (NCP). Integrate the radio into Android Things using the LoWPAN NCP user driver. You can also expand support to other radio hardware by building your own user drivers. See the LoWPAN user driver API guide for more details.
To get started with DP6.1, use the Android Things Console to download system images and flash existing devices. Then download the LoWPAN sample app to try it out for yourself! LoWPAN isn't the only exciting thing happening in the latest release. See the release notes for the full set of fixes and updates included in DP6.1.
Please send us your feedback by filing bug reports and feature requests, as well as asking any questions on Stack Overflow. You can also join Google's IoT Developers Community on Google+, a great resource to get updates and discuss ideas. Also, we have our new hackster.io community, where everyone can share the amazing projects they have built. We look forward to seeing what you build with Android Things!
Developing for 3D is complicated. Whether you're using a native graphics API or enlisting the help of your favorite game engine, there are thousands of graphics commands that have to come together perfectly to produce beautiful 3D images on your phone, desktop or VR headsets.
GAPID (Graphics API Debugger) is a new tool that helps developers diagnose rendering and performance issues with their applications. With GAPID, you can capture a trace of your application and step through each graphics command one-by-one. This lets you visualize how your final image is built and isolate problematic calls, so you spend less time debugging through trial-and-error.
GAPID supports OpenGL ES on Android, and Vulkan on Android, Windows and Linux.
GAPID not only enables you to diagnose issues with your rendering commands, but also acts as a tool to run quick experiments and see immediately how these changes would affect the presented frame.
Here are a few examples where GAPID can help you isolate and fix issues with your application:
Working with a graphics API can be frustrating when you get an unexpected result, whether it's a blank screen, an upside-down triangle, or a missing mesh. As an offline debugger, GAPID lets you take a trace of these applications, and then inspect the calls afterwards. You can track down exactly which command produced the incorrect result by looking at the framebuffer, and inspect the state at that point to help you diagnose the issue.
Even when a program is working as expected, sometimes you want to experiment. GAPID allows you to modify API calls and shaders at will, so you can test things like:
With GAPID, you can now iterate on the look and feel of your app without having to recompile your application or rebuild your assets.
Whether you're building a stunning new desktop game with Vulkan or a beautifully immersive VR experience on Android, we hope that GAPID will save you both time and frustration and help you get the most out of your GPU. To get started with GAPID and see just how powerful it is, download it, take your favorite application, and capture a trace!
At Google for India this Monday, we announced the final release of Android 8.1 Oreo. Android 8.1 Oreo is another exciting step toward bringing to life our vision of an AI-first mobile platform, for everyone, everywhere.
Android 8.1 introduces support for our new Android Oreo (Go edition) software experience for entry-level devices. Android Oreo (Go edition) brings the best of Android to the rapidly growing market for low-memory devices around the world, including your apps and games.
Android 8.1 also introduces the Neural Networks API, a hardware accelerated machine learning runtime to support ML capabilities in your apps. On supported devices, the Neural Networks API enables fast and efficient inference for a range of key use cases, starting with vision-based object classification.
You can get started with Android 8.1 Oreo (API level 27) today. We're pushing sources to Android Open Source Project now, and rolling out the update to supported Pixel and Nexus devices over the next week. We're also working with our device maker partners to bring Android 8.1 to more devices, including Android Oreo (Go edition) devices, in the months ahead.
As announced at Google I/O 2017, the "Android Go" project is our initiative to optimize the Android experience for billions of people coming online around the world. Starting with Android 8.1, we're making Android a great platform for entry-level devices in the Android Oreo (Go edition) configuration:
We've updated the building for billions guidelines with additional guidance on how to optimize your app for Android Oreo (Go edition) devices. For most developers, optimizing your existing APK or using Google Play's Multiple APK feature to target a version of your APK to low-RAM devices is the best way to prepare for Android Oreo (Go edition) devices. Remember that making your app lighter and more efficient benefits your whole audience, regardless of device.
The Neural Networks API provides accelerated computation and inference for on-device machine learning frameworks like TensorFlow Lite -- Google's cross-platform ML library for mobile -- as well as Caffe2 and others. TensorFlow Lite is now available to developers, so visit the TensorFlow Lite open source repo for downloads and docs. TensorFlow Lite works with the Neural Networks API to run models like MobileNets, Inception v3, and Smart Reply efficiently on your mobile device.
Android 8.1 includes select new features and developer APIs (API level 27), along with the latest optimizations, bug fixes, and security patches. Extend your app with Autofill enhancements, a SharedMemory API, and more. You can also add established Android Oreo features as well, see the Android Oreo site for details.
If haven't already, take a few moments today to test your apps and make sure they offer the experience you want for users upgrading to Android 8.1 Oreo.
Just install your current app from Google Play onto a device or emulator running Android Oreo and test the user flows. The app should run and look great, and handle the Android Oreo behavior changes properly. In particular, pay attention to background location limits, notification channels, and changes in networking, security, and identifiers.
To build with Android 8.1, we recommend updating to Android Studio 3.0, which is now available from the stable channel. On top of the new app performance profiling tools, support for the Kotlin programming language, and Gradle build optimizations, Android Studio 3.0 makes it easier to develop for Android Oreo features like Instant Apps, XML Fonts, downloadable fonts, and adaptive icons.
With the final platform we're updating the SDK and build tools in Android Studio, as well as the API Level 27 emulator system images. We recommend updating to the Android Support Library 27.0.2, which is available from Google's Maven repository. See the version notes for details on what's new.
As always, we're providing downloadable factory and OTA images on the Nexus Images page to help you do final testing on your Pixel and Nexus devices.
When you're ready, you can publish your APK updates targeting API level 27 in your alpha, beta, or production channels. Make sure that your updated app runs well on Android Oreo as well as older versions. We recommend using beta testing to get early feedback from a small group of users and a pre-launch report to help you identify any issues, then do a staged rollout. Head over to the Android Developers site to find more info on launch best practices. We're looking forward to seeing your app updates!
We'll soon be closing the Developer Preview issue tracker, but please keep the feedback coming! If you still see an issue that you filed in the preview tracker, just file a new issue against Android 8.1 in the AOSP issue tracker. You can also continue to give us feedback or ask questions in the developer community.
In recent months, there's a growing trend for handset makers to ship new devices with long screen aspect ratio (stretching beyond 16:9), many of which also sport rounded corners. This attests to the Android ecosystem's breadth and choice. Pixel 2 XL and Huawei Mate 10 Pro are just two of many examples. These screen characteristics could bring a very immersive experience to users and they take notice of apps and games that don't take advantage of the long aspect ratio screen on these new devices. Therefore it is important for developers to optimize for these screen designs. Let's have a look at related support provided by the Android OS.
Most apps using standard UI widgets will likely work out-of-the-box on these devices. Android documentation details techniques for flexibly working on multiple screen sizes. However, some games and apps with custom UIs may run into issues due to incorrect assumptions on certain aspect ratios. We're sharing a few typical issues faced by developers, so you can pay attention to those relevant to you:
If responsive UI is really not suitable for your situation, as a last resort declare an explicit maximum supported aspect ratio as follows. On devices with a wider aspect ratio, the app will be shown in a compatibility mode padded with letterbox. Keep in mind that certain device models provide an override for users to force the app into full-screen compatibility mode, so be sure to test under these scenarios too!
Targets API level 26 or higher: Use android:maxAspectRatio attributes.
android:maxAspectRatio
Targets API level 25 or lower: Use android.max_aspect meta-data. Note that maximum aspect ratio values will be respected only if your activities don't support resizableActivity. See documentation for detail.
android.max_aspect
resizableActivity
System letterboxes an app when the declared maximum aspect ratio is smaller than the device's screen.
Long aspect ratio devices enable even more multi-window use cases that could increase user productivity. Beginning in Android 7.0, the platform offers a standard way for developers to implement multi-window on supported devices as well as perform data drag and drop between activities. Refer to documentation for details.
Testing is crucial. If you don't have access to one of these long screen devices, be sure to test on the emulator with adequate screen size and resolution hardware properties, which are explained in the emulator documentation.
We know you want to delight your users with long screen devices. With a few steps, you can ensure your apps and games taking full advantage of these devices!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
