With billions of Android devices in use around the world and millions of apps available on the Play Store, it might seem difficult to drive change across the entire ecosystem, but the Accessibility Developer Infrastructure team is doing just that.
Every time a developer uploads an APK or app bundle to the open or closed tracks, Play tests this upload on various device models running different versions of Android and generates a pre-launch report to inform the developer of issues.
One year ago, the team added accessibility suggestions to the report based on industry best practices and Google’s own experience. These tests check for common issues that can make an app harder to use by people with disabilities. For example, they check that buttons are large enough to be comfortable for people to press, and that text has enough contrast with the background to be easier to read.
Since launching in July 2018, more than 3.8 million apps have been tested and over 171 million suggestions have been made to improve accessibility. Along with each suggestion, the developer gets detailed information about how to implement it. Every developer, from a one-person startup to a large enterprise, can benefit from the accessibility suggestions in the pre-launch report.
We are already seeing the real-world impact of these efforts. This year at Google I/O, the number of developers signing up for in-person accessibility consultations was four times the number from 2018. Googlers staffing these sessions reported that the developers had specific questions that were often based on the suggestions from the pre-launch report. The focused questions allowed the Googlers to give more actionable recommendations. These developers found that improving accessibility isn't just the right thing to do, it also makes good business sense by increasing the potential market for their apps.
Accessibility tests in the pre-launch report are just one way Google is raising awareness about accessibility in the global developer community. We partnered with Udacity to create a free online course about web accessibility, released our Accessibility Scanner for Android on the Play Store, and published iOS Accessibility Scanner on GitHub, allowing iOS developers to easily instrument apps to accessibility tests. Together, these efforts support Google's mission to organize the world's information and make it universally accessible and useful.
Learn more about developing with accessibility in mind by visiting the Android Developer Guidelines and the Google Developer Documentation Style Guide.
Today we're releasing the source code for the official Google I/O 2019 Android app.
This year's app substantially modified existing functionality and added several new features. In this post, we’ll highlight several notable changes.
Android Q out of the box
Android Q introduced an option for fully gestural navigation, allowing the user to navigate back and to the home screen using only gestures. To support gesture navigation, app developers need to do two things:
The Google I/O 2019 app was one of the first apps to support fully the gestural navigation. For more details, check out this series of blog posts about gesture navigation and the commit in the Google I/O app repository that extended the content to draw edge-to-edge.
To support the dark theme, you must set the app’s theme to inherit from a dark theme.
<style name="AppTheme" parent="Theme.AppCompat.DayNight"> OR <style name="AppTheme" parent="Theme.MaterialComponents.DayNight">
You also need to avoid hard-coded colors or icons. You should use theme attributes (such as ?android:attr/textColorPrimary) or night-qualified resources (such as colors defined both in the res/values/colors.xml and res/values-night/colors.xml) instead. Check out the Google I/O talk about Dark Theme & Gesture Navigation for more details or the series of commits (1, 2, 3) in the Google I/O 2019 app repository for how we achieved implementing the dark theme in a real app.
?android:attr/textColorPrimary
res/values/colors.xml
res/values-night/colors.xml
Schedule UI in dark theme
Improved schedule screen
The new schedule UI is a single stream, allowing the app to render only visible content and users to easily jump to another conference day by choosing a day at the top of the UI. Check out the series of commits (1, 2) for how we revamped the schedule UI.
Navigation component
We introduced Navigation component to simplify this year’s app into a Single Activity app and observed the following benefits:
Check out the getting started guide for how you can start introducing the Navigation component in your app and the series of commits (1, 2, 3, 4) in the Google I/O 2019 app repository for the usage in a real app.
All transitions in the navigation editor
Full Text Search with Room
For this year’s app we added a search feature for users to quickly find sessions, speakers, and codelabs. To accomplish this, we used the Full Text Search feature of the Room Jetpack component. Whenever the conference data is fetched from the server, we update the session, speaker, and codelab data in the Room tables, which have corresponding FTS mapping tables. When a user starts typing in the search box, the search term is used to query the session title and description, speaker names, and codelab title. The search results are shown almost instantly, which allows the search results to be updated with each character typed in the search field. The user can then tap on a search result to navigate to see the details on the session, speaker, or codelab. Check out the series of commits (1, 2, 3, 4) for how we achieved the Full Text Search feature.
Searching for a session and a speaker
Lots of improvements
These were the biggest changes we made to the app, but we improved a lot of little things as well. We added the new Home UI, allowing the app to tell the user time relevant information during the conference and the Codelab UI, which gave users more information about codelabs at I/O and how to participate in them.
Home UI and Codelabs UI
We also introduced Firebase Remote Config to toggle the visibility of each feature by updating the boolean values in the Remote Config without updating the app and removed the hard-coded values that were used for representing start and end time of each event in the Agenda UI.
Go explore the code
If you’re interested go checkout the code and let us know what you think. If you have any questions or issues, please let us know via the issue tracker on GitHub.
Posted by Kacey Fahey, Google Play Developer Marketing
Nexon Korea Company has published several games across PC, mobile, and console. With the launch of their mobile game FAITH, a MMORPG released exclusively in Japan, they wanted to promote the game before launch and find a way to capture early consumer demand that would help boost early installs at launch.
Nexon ran a pre-registration campaign on Google Play with a multi-channel marketing campaign driving players to pre-register and receive an exclusive pre-registration reward. Their campaign used consistent creative assets throughout TV commercials, YouTube influencer campaigns, social media, performance marketing campaigns, and more. Offering a pre-registration reward provided an incentive and benefit for players who pre-registered on Google Play during the month-long campaign leading up to launch.
“It was very easy to run, since the steps to activate the campaign were very clear and simple. All we needed to do was prepare the store assets and APK, then set them up in the Google Play Console,” said Hyomin Kim, Head of Platform Partnerships at Nexon Korea Corporation. Their exclusive pre-registration reward of 300 diamonds (in-game currency) was set up as a unique managed product as part of the campaign. At launch, Google Play provides the reward to all players who pre-registered, allowing Nexon to consume and grant the reward to players in-game using the Google Play Billing API. Not only did this create additional value for users, but it allowed Nexon to identify those who pre-registered in-game so they could measure the cohort’s performance after launch. Once the game became available on launch day, everyone who pre-registered on Google Play received a notification to install.
Nexon reported they had historically seen around 50% of Google Play pre-registrations convert to installs. By offering a pre-registration reward for FAITH, they increased their conversion rate by 20%. And not only that, the campaign drove other strong performance metrics with players who pre-registered for FAITH on Google Play having almost 50% higher day 60 retention than those who did not pre-register. This audience has also shown stronger monetization behavior, with over 70% higher ARPDAU than non-pre-registrants.
“Google Play pre-registration is now a ‘must-do’ strategy when Nexon launches games. From our previous experience, Google Play pre-registration is one of the most effective pre-registration platforms amongst all the channels we utilize, especially for organic impressions and installation conversion,” said Kim.
All app and game developers can run pre-registration campaigns and offer a pre-registration reward. Get started today!
Posted by Allen Huang and Rohan Shah, Product Managers on Android UI
One of the biggest changes in Android Q is the introduction of a new gesture navigation. Just to recap - with the new system navigation mode - users can navigate back (left/right edge swipe), to the home screen (swipe up from the bottom), and trigger the device assistant (swipe in from the bottom corners) with gestures rather than buttons.
By moving to a gesture model for system navigation, we can provide more of the screen to apps to enable a more immersive experience.
We wanted to give folks an inside look at how we’ve approached this challenge, the rationale, and some of the trade-offs as well. There is some nerding out on design around gestures ahead, but hopefully it provides some insight into our process and how we balance the developer and OEM ecosystem in service of users. If you’re looking for more detail on how to handle these changes as an app developer, check out Chris’s “Going edge-to-edge” article series.
One of the amazing things about Android is the opportunity for app developers and Android partners to try new, innovative approaches on the phone.
In the last 3 years, we’ve seen gesture navigation patterns proliferate on handheld devices (though gestures have been around as early as 2009!).
This trend was led by innovative Android partners and Android apps trying some very cool ideas (for example: Fluid NG, XDA).
When we started researching this more, we honed in on the user benefits:
It wasn’t all roses though - we also saw issues with many of the gesture modes:
But most of all, we realized that there was a larger issue of fragmentation when different Android phones had different gestures, especially for Android developers.
Over the last year, we worked with partners like Samsung, Xiaomi, HMD Global, OPPO, OnePlus, LG, Motorola, and many others to standardize gesture navigation going forward. To ensure a consistent user and developer experience, the Android Q gestures will be the default gesture navigation for new Q+ devices.
Understanding that these gestures don’t work for every user, especially those with more limited dexterity and mobility, three-button navigation will continue to be an option on every Android device.
We started with research to understand how users held their phones, what typical reach looked like, and what parts of the phone users used the most. From there, we built many prototypes that we tested across axes like desirability, speed-of-use, ergonomics, and more. And we put our ultimate design through a range of studies - how quickly users learned the system, how quickly users got used to the system, how users felt about it.
A unique element of Android navigation since the very beginning is the Back button. It is appreciated by many users that find Android easier to navigate and learn (despite many debates on what the “correct” behavior is) -- and it's used a lot! In fact, 50% more than even Home. So one of our design goals was to make sure the back gesture was ergonomic, dependable, and intuitive -- and we prioritized this goal above other less frequent navigation such as drawers and recents.
Looking at the reachability charts below, we designed our two core gestures (Back and Home) to coincide with the most reachable/comfortable areas and movement for thumbs.
Phone screen heatmaps showing where users can comfortably do gestures, holding the phone in only one hand
As mentioned, we built prototypes of many different gesture models, comparing user ratings and timed user tasks on what ultimately became the Q model to several other navigation paradigms. Here’s a few graphs showing the results of our testing:
Comparison of user ratings for ergonomics and one-handed use across different navigation modes (higher is better)
Comparison of average time required to complete Home/Back tasks across various navigation modes (lower is better)
Comparison of average time required to complete Overview/Recents-based tasks across various navigation modes (lower is better)
Users, on average, performed tasks involving Home and Back more quickly than most other models - even faster than they did with buttons. The model did, however, come at the cost of being able to quickly access Overview/Recent apps, which users go to less than half as often as the Home screen.
From a more qualitative perspective, users viewed the Q model as more one-handed and reachable, although buttons were still viewed as more ergonomic for more users.
Although we arrived at the side swipe as the gesture for back that best balanced many tradeoffs, it is important to note that there were hard decisions, particularly in how that gesture impacted apps.
For example, we found that ~3-7% of users (depending on the Google app) swipe to open the App Navigation Drawer - the rest of our users push the hamburger menu to invoke the drawer. This drawer swipe gesture is now overloaded with back and some users will need to adapt to using the hamburger menu. This was a tough choice but given the prolific use of back we optimized for what worked best there.
Because it’s never a goal to change out behavior on users, we tried several ways to enable users to distinguish the drawer gesture from the Back gesture. However, all these paths led to users pulling in the drawer when they were trying to go Back and having less confidence that Back would work.
Beyond drawers, gestures are a big change for people and it took on average 1-3 days to adapt - in particular, users struggled with patterns like swiping right or left on a carousel and triggering Back.
In qualitative studies, we found that after an initial break-in period of 1-3 days, users became fluent and could consistently distinguish between these two gestures. The majority of users did not want to switch back to 3 button nav (even though that remains an option).
Additional research showed that there is a clear adjustment phase for users to get used to a new system navigation (across many different navigations). In our Q model, we found that usage of Back goes down for the first 1-3 days. After that period, the average # of Back presses/day ends up being the same as 3-button and our P navigation.
With gestural navigation, we are aiming to move forward and standardize the user experience on Android. The model we landed on is the optimal one for most users, but it also means that some of the gestures conflict with existing app gestures, necessitating developer adjustments to how users interact with your apps. We take our responsibility to Android developers seriously and want to help you in this process.
There are three key steps to support gesture navigation:
We’ve just published the first article in our “Going edge-to-edge” series on Medium, detailing those steps in turn. The final article in the series will cover some of the common scenarios we’ve seen, and how you can best support them in your apps.
Thank you all for the feedback -- all of your comments and interactions have helped us improve the gesture navigation experience in Android Q and, more broadly, help make Android better each day.
Posted by Dave Burke, VP of Engineering
We’re just a few weeks away from the official release of Android Q! As we put the final polish on the new platform, today we’re rolling out Beta 6, the last Beta update. Now is the time to make sure your apps are ready, before we bring the official release to consumers. Take this opportunity to finish up your testing and publish your app updates soon to give users a smooth transition to Android Q.
You can get Beta 6 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 5, you'll automatically get Beta 6 soon. Partners participating in the Android Q Beta program will also be updating their devices over the coming weeks -- visit their sites to learn more. To get started with Android Q, visit developer.android.com/preview.
Watch for more information on the official Android Q release coming soon!
Today’s Beta 6 update includes the latest Android Q system images for Pixel and Android Emulator, the final API 29 SDK, and updated build tools for Android Studio. Beta 6 includes all of the features, system behaviors, and developer APIs that you’ll find in the final platform, so it gives you everything you need to get your apps ready. For users, Beta 6 includes many new fixes and optimizations -- take a look at the release notes for details.
We've made further refinements to Gesture Navigation in Beta 6 based on user feedback. First, to ensure reliable and consistent operation, there's a 200dp vertical app exclusion limit for the Back gesture. Second, we've added a sensitivity preference setting for the Back gesture. Watch for more details coming soon in our blog post series on optimizing for gesture navigation.
With the consumer release coming soon, we’re asking all Android developers to update your current apps for compatibility as soon as possible.
Here’s how to do it:
We realize that supporting these changes is an investment for you too, so thanks to all of you who have prioritized the work to get your apps ready for Android Q!
Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.
We recommend these for every app:
We recommend these if relevant for your app:
These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.
As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users and then do a staged rollout to production.
It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.
To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.
Please continue to share your feedback and requests in our issue tracker. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.
A big thank you to our developer community for your participation in our recent Reddit AMA on r/androiddev! It’s always great to hear what’s important to you and we hope we were able to help!
Posted by Tom Grinsted, Product Manager, Google Play
At this year’s Google I/O, we announced a slate of new features to help you take your business further with Google Play. Launching today, these changes include several improvements designed to help you make better decisions about your business by providing clearer, more actionable data.
We know the right data is critical to help you improve your app performance and grow your business. That’s why we’re excited to share a major update that enables you to better measure and analyse your core statistics — the most fundamental install and uninstall metrics by user and device. We’ve also enhanced the Statistics page on the Play Console to show change over time, enable more granular configurations, and, coming soon, exclusive benchmarks for core stats!
More granular configurations are now available on the Statistics page to help you better understand your acquisition and churn.
More accurate and more expansive than before, the new metrics will help you better understand your acquisition and churn. For the first time, we are including data on returning users and devices - something that we understand is critical to many developers' growth strategies.
We’re also including new install methods (such as pre-installs and peer-to-peer sharing) and the ability to aggregate and dedupe over periods that suit your business needs. With these new updates, you can perform analyses that weren’t possible before, such as how many people re-installed your app last month.
Here’s what else is new:
As a result of these updates, you will notice a few changes to your metrics. Old metrics names will be deprecated, but you can configure new metrics that map to the old ones with this cheat sheet. And don’t forget to use the ‘save report’ feature on the stats page so you can easily return to any configurations you find particularly helpful!
Don’t forget to use the ‘save this report’ feature on the stats page to easily return to any configurations you find particularly helpful.
Other metrics like active user and active device will see a step-change as the new definitions are more expansive and include previously under-counted data.
Some new metrics map onto older ones. Where this happens, all historic data will be automatically included. But in other cases new metrics will only be generated from launch day. For unique devices or users, weekly metrics will start to appear two weeks after launch, monthly metrics once there’s a single full month’s data, and quarterly metrics once there’s a full quarter’s data.
We know it’s a lot to take in at once, so make sure to bookmark the cheat sheet for helpful tips as you navigate the transition and explore your new metrics. Additionally, our Decision-Making with the Google Play Console session from Google I/O and our Play Academy training are other great resources to help you get up to speed. Check out these updates in the Google Play Console today — we hope you find them useful. Your comments help to shape the future of Google Play, so please continue to let us know what you think.
How useful did you find this blog post?
★ ★ ★ ★ ★
Last November, we released Fast Pair with the Jaybird Tarah Bluetooth headphones. Since then, we’ve engaged with dozens of OEMs, ODMs, and silicon partners to bring Fast Pair to even more devices. Last month, we held a talk at I/O announcing 10+ certified devices, support for Qualcomm’s Smart Headset Development Kit, and upcoming experiences for Fast Pair devices.
Fast Pair makes pairing seamless across Android phones - this year, we are introducing additional features to improve Bluetooth device management.
• Find My Device. Fast Pair devices will soon be surfaced in the Find My Device app and website, allowing users to easily track down lost devices. Headset owners can view the location and time of last use, as well as unpair or ring the buds to locate when they are in range.
• Connected Device Details. In Android Q, Fast Pair devices will have an enhanced Bluetooth device details page to centralize management and key settings. This includes links to Find My Device, Assistant settings (if available), and additional OEM-specified settings that will link to the OEM’s companion app.
Compatible Devices
Below is a list of devices that were showcased during our I/O talk:
Interested in Fast Pair?
If you are interested in creating Fast Pair compatible Bluetooth devices, please take a look at:
Once you have selected devices to integrate, head to our Nearby Devices console to register your product. Reach out to us at fast-pair-integrations@google.com if you have any questions.
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
