The latest Android and Google Play news for app and game developers.
Posted by Madan Ankapura, Product Manager, Android
This is the first in a series of blog posts that outline strategies and guidance in Android with regard to power.
Your users care a lot about battery -- if it runs out too quickly, it means they can't use your apps. Being a good steward of battery power is an important part of your relationship with the user, and we're continuing to add features to the platform that can help you accomplish this.
As part of our announced Play policy about improving app security and performance, an app's target API level must be no more than one year older than the current Android release. Keeping the target API level current will ensure that apps can take advantage of security and performance enhancements offered in the latest platform releases. When you update your app's target API level, it's important that you evaluate your background and foreground needs, which could have a significant impact on power & performance.
Past releases of Android included a number of features that helped manage battery life better, like:
In Android 9 Pie, we made further improvements based on these three principles:
This means that the OS needs to be smarter and adapt to user preferences while improving the battery life of the device. To address these needs, we have introduced App Standby Buckets, Background Restrictions, and improved Battery Saver. Please test your app with these features enabled on a device running Android 9 Pie.
Battery Saver and Doze operate on a device-wide level, while Adaptive Battery (app standby buckets powered by a Deepmind ML model) and background restrictions operate on a per-app basis. The diagram below helps understand when a scheduled work will run.
As you update your apps to target Oreo or above, please review this checklist and follow the below table for background work
Note: when the WorkManager API becomes stable, we will be recommending WorkManager for most of these use cases
We recommend the following strategy given the importance for app developers to invest in the right design patterns and architecture:
Similarly, other OS primitives like alarms, network, and FCM messages also have constraints that are described in the developer documentation on power-management restrictions. You can learn more about each of these features via Google I/O presentation, DevByte and additional power optimization developer documentation.
We will be publishing a series of design pattern guidances in the upcoming weeks. Stay tuned.
Acknowledgements: This series of blog posts is in joint collaboration with Android Framework and DevRel teams.
Posted by Peter Armitage, Software Engineer, Google Play
Releasing a new version of your app is an exciting moment when your team's hard work finally gets into the hands of your users. However, releasing can also be challenging - you want to keep your existing users happy without introducing performance regressions or bugs. At Google I/O this year, we talked about staged releases as an essential part of how Google does app releases, allowing you to manage the inherent risks of a new release by making a new version of your app available to just a fraction of your users. You can then increase this fraction as you gain confidence that your new version works as expected. We are excited that starting today staged releases will be possible on testing tracks, as well as the production track.
We will take a closer look at how staged releases work, and how you can use them as part of your release process.
The first benefit of a staged release is that it only exposes a fraction of your users to the new version. If the new version contains a bug, only a small number of people will be inconvenienced by it. This is much safer than releasing a new version to all of your users at once.
Another benefit is that if you discover a bug, you can halt the rollout, preventing any new users from downloading that version. Instead, they will receive the previous version.
These capabilities should relieve a lot of the uncertainty of rolling out a new version. And that will allow you to do it more often. We encourage releasing versions of a server more often because it reduces the number of changes between each release, allowing you to more easily test and troubleshoot. The same principle applies to apps, though there will be a delay before most of your users upgrade to the latest version.
Let's look at a typical release process for an app with 100,000 users.
Some apps are just starting out, and although there's no QA team, it's still worth testing the app on a few different devices before releasing it. Instead of having a track for employees, the developer has added their friends and family, who can contact them if they see an issue.
When an app gets larger and uses the open testing track, it may have 5,000 testers. These testers won't give public feedback on the Play store, but will be able to give feedback to the developer directly. If this app has 1 million users, they may first release to 1%, before going to 10%, then 100%.
Once an app becomes very popular, it could have over 100,000 testers. In that case the developer is now able to do a staged release on their testing track.
Bugs happen, and if you discover a problem with your new version you may want to halt the release. This will stop users from getting the new version, either by upgrading or installing for the first time. However, those who have already got the new version will not downgrade.
If the issue was not in the app itself, but on a server that the app communicates with, it may be best to fix the issue in the server, then resume the release. Resuming it allows some fraction of your users to access the new version again. This is the same set of users that were able to download the release before it was halted.
If the issue was in the app, you will have to fix it and release a new version. Or alternatively, you may choose to rebuild the previous version with a higher version code. Then you can start a staged release to the same set of users that the previous release went to.
Staged releases are supported in v3 of the Play Console API on all tracks. Mark a release as "inProgress" and set a fraction of the population to target. For instance, to start a staged release to 5%:
{ "releases": [{ "versionCodes": ["99"], "userFraction": 0.05, "status": "inProgress" }] }
Alternatively, if you release using the UI, it will suggest a fraction.
We hope you find these features useful and take advantage of them for successful updates with Google Play. If you're interested in some of the other great tools for distributing your apps, check out the I/O 2018 sessions, and learn more about test tracks and staged updates.
How useful did you find this blogpost?
★ ★ ★ ★ ★
Posted by Hoi Lam, Lead Developer Advocate, Wear OS by Google
Today we announced that we are evolving the design of Wear OS by Google to help you get the most out of your time - providing quicker access to your information and notifications. Notifications can come from the automatic bridging of the phone's notification or be generated by a local Wear app running on the watch. Whether you are a phone developer, a Wear app developer, or both, there are a few things you will need to know about the new notification stream.
Until now, each notification took up the entire screen in Wear OS. Although this provided more space to include things like inline action, it also meant it took a long time for the user to go through all their notifications. The new notification stream is more compact, and can display multiple notifications on the same screen. This means users can process their notification streams more quickly.
setColor
setDisplayIntent
setHintDisplayActionInline
As always, the current best practices for notification still apply. In particular, for messaging apps developers, we strongly encourage the use of MessagingStyle notification and enabling on-device Smart Reply through setAllowGeneratedReplies.
setAllowGeneratedReplies
We will start rolling these changes out in the next month, so watch for updates on your Wear OS by Google smartwatch!
The Media Controller Test (MCT) app is a powerful tool that allows you to test the intricacies of media playback on Android, and it's just gotten even more useful. Media experiences including voice interactions via the Google Assistant on Android phones, cars, TVs, and headphones, are powered by Android MediaSession APIs. This tool will help you verify your integrations. We've now added a new verification testing framework that can be used to help automate your QA testing.
The MCT is meant to be used in conjunction with an app that implements media APIs, such as the Universal Android Music Player. The MCT surfaces information about the media app's MediaController, such as the PlaybackState and Metadata, and can be used to test inter-app media controls.
The Media Action Lifecycle can be complex to follow; even in a simple Play From Search request, there are many intermediate steps (simplified timeline depicted below) where something could go wrong. The MCT can be used to help highlight any inconsistencies in how your music app handles MediaController TransportControl requests.
Previously, using the MCT required a lot of manual interaction and monitoring. The new verification testing framework offers one-click tests that you can run to ensure that your media app responds correctly to a playback request.
To access the new verification tests in the MCT, click the Test button next to your desired media app.
The next screen shows you detailed information about the MediaController, for example the PlaybackState, Metadata, and Queue. There are two buttons on the toolbar in the top right: the button on the left toggles between parsable and formatted logs, and the button on the right refreshes this view to display the most current information.
By swiping to the left, you arrive at the verification tests view, where you can see a scrollable list of defined tests, a text field to enter a query for tests that require one, and a section to display the results of the test.
As an example, to run the Play From Search Test, you can enter a search query into the text field then hit the Run Test button. Looks like the test succeeded!
Below are examples of the Pause Test (left) and Seek To test (right).
The MCT now also works on Android TV! For your media app to work with the Android TV version of the MCT, your media app must have a MediaBrowserService implementation. Please see here for more details on how to do this.
On launching the MCT on Android TV, you will see a list of installed media apps. Note that an app will only appear in this list if it implements the MediaBrowserService.
Selecting an app will take you to the testing screen, which will display a list of verification tests on the right.
Running a test will populate the left side of the screen with selected MediaController information. For more details, please check the MCT logs in Logcat.
Tests that require a query are marked with a keyboard icon. Clicking on one of these tests will open an input field for the query. Upon hitting Enter, the test will run.
To make text input easier, you can also use the ADB command:
adb shell input text [query]
Note that '%s' will add a space between words. For example, the command adb shell input text hello%sworld will add the text "hello world" to the input field.
adb shell input text hello%sworld
The MCT currently includes simple single-media-action tests for the following requests:
For a technical deep dive on how the tests are structured and how to add more tests, visit the MCT GitHub Wiki. We'd love for you to submit pull requests with more tests that you think are useful to have and for any bug fixes. Please make sure to review the contributions process for more information.
Check out the latest updates on GitHub!
Posted by Tom Grinsted, Product Manager, Google Play
We've updated the Play Console acquisition reports to give new insights into what users do on the Play Store to discover your app. It's a great way to super-charge your App Store Optimization (ASO) and onboarding experience.
One of the things every developer wants to know is how people discover their app or game. User acquisition reports in the Google Play Console are a great way to understand this. For many apps and games, a stand-out source is Organic traffic — it's usually the largest or second largest source of store listing visits and installs.
Organic traffic is made up of people who come to your store listing while exploring or searching the Play Store. These visitors might find your app in a seasonal collection, from featuring, or while searching for a specific use case or term.
Until recently, this traffic has been bundled together with no breakdown of data into user behavior. With our latest updates we have changed this by introducing new and exclusive acquisition insights to the Google Play Console. These enable you to understand what people in the Play Store do to discover your app or game. They reveal how many people discover your app through exploring the store, and how many search to find your app, and even the search terms they use!
App Store Optimization (ASO) is vital to driving your organic traffic and this update enables you to do this with more data and better understanding.
When you visit the user acquisition report, the first change you'll notice is that organic traffic is broken down. This breakdown means you can see how people arrive at your store listing by searching or exploring (actions that aren't search like browsing the homepage, visiting a category list, or viewing related apps).
This change has been of immediate benefit to developers, enabling their growth teams to optimize acquisition strategies. For example, Scopely found that:
"Isolating [explore] from search and then a deeper dive into search gives the whole organic picture. It allows us to focus on acquisition areas that really matter." Dorothee Pinlet, VP Partnerships, Scopely
From the new search row, you can click-through to see the aggregate number of people using different search terms to find your store listing, and which of those lead to the most installs. This breakdown is a view into the Play Store that has not been available before.
Our pilot partners, who helped us refine the feature ahead of launch, were very happy with how this data has helped them make more informed decisions.
Evernote found that the breakdown:
"... offers surprising and actionable insights about the effectiveness of search terms in driving installs and retained users." May Allen, Product Manager, Evernote
Some partners changed their in-app onboarding experience to highlight features that reflected the search terms that were driving installs, to better meet user expectations. While others evaluated if their influencer marketing was having an impact by looking for their advocates' names in the search results after adding them to descriptions.
This change means that your total reported visits and installs are likely to increase as of July 30, 2018. This increase is because previews will be counted as listing views, previously they were included in the category "Installs without store listing visits".
The developers who had the opportunity to test Organic breakdowns have given feedback that they loved them. They've also been kind enough to share some insights into how they plan to use the data. Perhaps these thoughts on how to use the data will spark some ideas for your business.
Some developers will be using this new data to evaluate their acquisition strategies by looking at the breakdown between explore and search. They will use this breakdown to evaluate the impact of exploring behaviors, especially around times when the app has been featured on the Play Store.
Using the information about popular search terms, several developers plan to change their app or game's Google Play listing to reflect user interests better. This change involves adjusting the descriptions and screenshots to tie more directly into the top search terms.
Others plan to use the insight provided by search term information to optimize their in-app onboarding. Here they plan to make sure that the onboarding talks about the features related to the most popular searches people made when discovering their app or game, highlighting and reinforcing the benefits.
Our team is always thinking about the tools we can build to help you optimize the discovery and installation of your app or game from the Play Store. Organic breakdowns is just one of these tools, a new way to help drive your success. Ultimately, your success is what we work towards. Organic breakdowns give you a more comprehensive picture of how people discover you on the Play Store so you can optimize your store presence, turning more visits into installs, and more installs into engaged users.
How useful did you find this blog post?
Posted by Dave Kleidermacher, VP, Head of Security - Android, Chrome OS, Play
At Google I/O 2018, in our What's New in Android Security session, we shared a brief update on the Android security updates program. With the official release of Android 9 Pie, we wanted to share a more comprehensive update on the state of security updates, including best practice guidance for manufacturers, how we're making Android easier to update, and how we're ensuring compliance to Android security update releases.
As we noted in our 2017 Android Security Year-in-Review, Android's anti-exploitation strength now leads the mobile industry and has made it exceedingly difficult and expensive to leverage operating system bugs into compromises. Nevertheless, an important defense-in-depth strategy is to ensure critical security updates are delivered in a timely manner. Monthly security updates are the recommended best practice for Android smartphones. We deliver monthly Android source code patches to smartphone manufacturers so they may incorporate those patches into firmware updates. We also deliver firmware updates over-the-air to Pixel devices on a reliable monthly cadence and offer the free use of Google's firmware over-the-air (FOTA) servers to manufacturers. Monthly security updates are also required for devices covered under the Android One program.
While monthly security updates are best, at minimum, Android manufacturers should deliver regular security updates in advance of coordinated disclosure of high severity vulnerabilities, published in our Android bulletins. Since the common vulnerability disclosure window is 90 days, updates on a 90-day frequency represents a minimum security hygiene requirement.
Product security factors into purchase decisions of enterprises, who often consider device security update cadence, flexibility of policy controls, and authentication features. Earlier this year, we introduced the Android Enterprise Recommended program to help businesses make these decisions. To be listed, Android devices must satisfy numerous requirements, including regular security updates: at least every 90 days, with monthly updates strongly recommended. In addition to businesses, consumers interested in understanding security update practices and commitment may also refer to the Enterprise Recommended list.
We've also been working to make Android easier to update, overall. A key pillar of that strategy is to improve modularity and clarity of interfaces, enabling operating system subsystems to be updated without adversely impacting others. Project Treble is one example of this strategy in action and has enabled devices to update to Android P more easily and efficiently than was possible in previous releases. The modularity strategy applies equally well for security updates, as a framework security update can be performed independently of device specific components.
Another part of the strategy involves the extraction of operating system services into user-mode applications that can be updated independently, and sometimes more rapidly, than the base operating system. For example, Google Play services, including secure networking components, and the Chrome browser can be updated individually, just like other Google Play apps.
Partner programs are a third key pillar of the updateability strategy. One example is the GMS Express program, in which Google is working closely with system-on-chip (SoC) suppliers to provide monthly pre-integrated and pre-tested Android security updates for SoC reference designs, reducing cost and time to market for delivering them to users.
Recently, researchers reported a handful of missing security bug fixes across some Android devices. Initial reports had several inaccuracies, which have since been corrected. We have been developing security update testing systems that are now making compliance failures less likely to occur. In particular, we recently delivered a new testing infrastructure that enables manufacturers to develop and deploy automated tests across lower levels of the firmware stack that were previously relegated to manual testing. In addition, the Android build approval process now includes scanning of device images for specific patterns, reducing the risk of omission.
In 2017, about a billion Android devices received security updates, representing approximately 30% growth over the preceding year. We continue to work hard devising thoughtful strategies to make Android easier to update by introducing improved processes and programs for the ecosystem. In addition, we are also working to drive increased and more expedient partner adoption of our security update and compliance requirements. As a result, over coming quarters, we expect the largest ever growth in the number of Android devices receiving regular security updates.
Bugs are inevitable in all complex software systems, but exploitability of those bugs is not. We're working hard to ensure that the incidence of potentially harmful exploitation of bugs continues to decline, such that the frequency for security updates will reduce, not increase, over time. While monthly security updates represents today's best practice, we see a future in which security updates becomes easier and rarer, while maintaining the same goal to protect all users across all devices.
Google Play Instant enables people to experience your game or app natively without having to go through a full installation process. Removing the friction of installing is a great way to increase engagement, conversions, and lifetime value of your users.
Today, we've made it easier to build instant games and apps by removing the URL requirement. Previously, in order to publish an instant game you had to create a web destination for it. The website also had to be connected to the instant game through intent filters and digital asset links verification.
Now, it is no longer required to add URL-based intent filters to your instant game. People will be able to access the instant experience through a 'Try Now' button in the Play Store or Play Games apps, via deep link API, and in the future through the app ads.
While being particularly helpful for games which often don't have a corresponding website, the new URL-less functionality is available to both game and app developers.
Game developers using Unity or the latest Cocos Creator can take advantage of URL-less instant games by simply leaving the URL fields blank in the setup process.
However, if you have your own game engine or have built your game from scratch in C++, check the AndroidManifest to make sure it has the following intent filter declaration:
<intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter>
Starting with Android Studio 3.2, you can create a new instant game, or convert your existing game, without associating a URL with it. In fact, this is now the default behavior. Here is a run through the process:
You should see an instant game on your attached device. Instant runtime found and launched the entry point activity in your game with the ACTION_MAIN and CATEGORY_LAUNCHER intent filter.
Once you are ready to publish the sample instant game:
Once you publish your instant game, people can access it via a 'Try Now' button in Play Store within 24 hours or sooner. You can also send traffic to your instant game using the deep link API:
market://details?id=MY.PACKAGE.NAME&launch=true&referrer=myreferrer
MY.PACKAGE.NAME refers to applicationId that you have replaced in app/build.gradle file.
MY.PACKAGE.NAME
With the launch of Android App Bundle we are excited to further simplify the developer experience for Google Play Instant. In the coming months we are making it possible to deliver your app's or game's dynamic features instantly from the same bundle as your installable app or game. Stay tuned!
Check out more information on Google Play Instant, or feel free to ask a question on Stack Overflow, or report an issue to our public tracker.
Play Console
