Posted by Don Turner - Android Developer Relations Engineer
This article takes a look at what's changed in the Android ecosystem for audio developers recently, the audio latency of popular Android devices, and discusses Android's suitability for real-time audio apps.
Over the past four years we have taken a number of actions that have improved audio latency.
These actions, coupled with a renewed focus from device manufacturers on audio latency, have led to significant improvements in the device ecosystem. The average latency of the most popular Android phones has dropped to under 40ms, which is well within the range required for real-time applications.
device popularity source: appbrain.com
Digging into the data we can see that in 2017 there was a significant difference between the highest and lowest values (222ms).
Compare that to the data for 2021. The range has reduced by a factor of 8 to just 28ms, providing a far more consistent audio experience. This is more impressive when you consider that there are now multiple OEMs on the most-popular list, compared to only a single manufacturer in 2017. In addition, many of the devices on the list are not high-end flagship models.
Up to now I've been referring to round-trip audio latency. Round-trip latency involves three components in the audio chain: audio input, audio processing and audio output.
Many real-time audio apps generate audio from screen tap events rather than relying on input audio. These kinds of apps are sensitive to "tap-to-tone" latency - the time taken from tapping on the screen to hearing a sound. The latency introduced by tapping the touch screen is anywhere from 10-35ms, with 20ms being fairly typical on modern Android devices.
To estimate tap-to-tone latency given round-trip latency, you can subtract the audio input latency (typically 5ms), and add the touch latency (typically 20ms). In other words, add 15ms to the round-trip latency. Given the numbers above, this means the average tap-to-tone latency of the most popular android phones is also well under that required for most real-time audio applications.
Despite the significant reductions in audio latency across the Android ecosystem our work is nowhere near complete. 20ms round-tip latency is required for Android professional audio apps, and 10ms remains the long term goal. And at this time some less popular devices still have high audio latency. However, if you have been holding back on developing an Android app because of audio latency, it might be time to reconsider.
To get started, check out the Oboe getting started guide or video tutorials.
OboeTester
WALT
appbrain.com
superpowered.com/latency
gsmarena.com
juce.com/maq
various internal data sources
Posted by Neethi Thomas, Dafna Gal and Ashnil Dixit, Google Play
At Google Play, we’re committed to giving Android developers access to the largest possible market for your apps and games. Google Play already supports free and paid apps in over 165 markets. We had previously lowered minimum prices developers can set for their products for 20 markets like India and Brazil. Today, we’re happy to announce that we have reduced the minimum price limit for products in 20 more markets across Latin America, EMEA, and APAC.
With these new lower limits, you can now set prices in the range of 10-30 cents US equivalent in most of these markets. These ultra-low price points, or “sub-dollar” prices, allow you to reach new potential buyers by adjusting your pricing to better reflect local purchasing power and demand. It also gives you more flexibility to set your global pricing strategy and gives more users the opportunity to enjoy monetized experiences in your apps and games.The minimum price limit for paid apps, in-app products, and subscriptions has been lowered in these new markets: Bangladesh, Bulgaria, Bolivia, Costa Rica, Czech Republic, Denmark, Croatia, Hungary, Jordan, Kazakhstan, Lebanon, Sri Lanka, Myanmar, Pakistan, Paraguay, Romania, Serbia, Thailand, Tanzania and Vietnam.
Additional markets where sub-dollar pricing is available: Brazil, Chile, Colombia, Egypt, India, Indonesia, Malaysia, Mexico, Nigeria, Peru, Philippines, Poland, Russia, Saudi Arabia, South Africa, Turkey and UkraineTo adjust your prices in Google Play Console, please see our Help Center article. The full list of price ranges can be found here.
Best practices for sub-dollar pricing
Since the feature was introduced in 2015, Android developers have been using sub-dollar pricing to expand their paying user base in creative ways. Here are a few ways you can use sub-dollar pricing to help grow your own business:
There are many ways to use sub-dollar and localized pricing and the suggestions listed above are just a starting point. We’re excited to see how you’ll use our features to grow your business.
Posted by Florina Muntenescu, Developer Relations Engineer
3...2...1… Time for another challenge! Welcome to the second week of the #AndroidDevChallenge! We loved seeing your creative submissions in week #1 so we can’t wait to see what you’ll build in week #2. Here’s your challenge:
Create a working, single screen countdown timer. You have until March 9th, 23:59 PST to submit your entry.1
Your UI must be fully built in Compose. To help you with the implementation, check out the Compose documentation on state and animation. For some hands-on learning try out the Compose pathway, with codelabs covering several topics useful for completing this challenge.
Your solution must be implemented in a GitHub repository. Make a copy of this Github repository template and follow the instructions in the README. The template contains a basic Hello World! in Compose and a continuous integration setup.
Hello World!
Our second week's prize is a work of art, where the Composing is a collaboration with you! The first 500 people to successfully complete this challenge will receive a Jetpack Compose poster and a set of Android pencils, your own stress relieving coloring experience. Plus, you'll get a limited edition Jetpack Compose comic strip poster, charting how Team Jetpack saves the galaxy from bad UI.
Week #2 prize: a Jetpack Compose poster pack
Community is at the heart of Jetpack Compose and your feedback helps us build a better product:
1 Please review the link for the full official rules associated with the entry.
Posted by Tom Grinsted, Product Manager, Google Play
Today in Google Play Console, we’ve launched a suite of new metrics* and unique comparative benchmarks. Using these, you can evaluate your app or games’ engagement and monetization trends against up to 250 different peersets, helping you make better, more informed decisions about your product roadmaps and opportunities.
Whether you want to prioritize new features to drive engagement, experiment with pricing, or drive up retention, we hear from all developers that they need great data and insights to help make the best investments.
While some larger developers can compare data from across their portfolios, this isn’t always possible — for instance, when entering a new territory, if you don’t publish directly comparable apps, or if you only publish one or two games in the first place. In these types of cases, how do you know if your app or game’s performance is good and where you can be better?
With this launch, we’re here to help all developers better contextualize and understand their performance. Here’s what’s new:
New engagement and monetization metrics
In partnership with experts in mobile apps and games growth, we’ve introduced a new set of engagement and monetization metrics based on best practices in evaluating app and game performance. These include:
In total, we’re launching 15 new normalized metrics with benchmarks, and making the absolute numerators and denominators available to query, too. They can all be found in the new “Compare to peers” tab in the Statistics page*. For convenience, we’ve included other key normalized metrics, like store listing conversions, here too.
Track your performance with peerset comparison
To power your decision-making and help you discover areas of opportunity, all of these new normalized metrics are launching with peerset comparison performance as standard. You’ll be able to track your metrics over time and compare up to 250 different types of apps and games such as “Match-3 games,” “Audiobooks,” or “Comics.”
Compare your performance to peers on the Statistics page in Google Play Console.
Country filters allow you to customise these insights to suit your business needs. For instance, you’ll be able to see if games similar to yours are driving more revenue from users in Japan, or if your team’s latest feature drop means that you’re outperforming other similar apps in terms of loyalty in India.
During our development process, we tested this suite of new insights with select partners. As well as useful in shaping our approach, their feedback has been positive:
Guy Ulmer, Plarium Global Ltd.
To help you make the most of these new metrics and insights, we’ve launched a new course on Play Academy to get you up to speed. You can also check out our masterclass webinars about super-powering your growth.
Strong privacy protections for users and developers
The data powering these new metrics comes from users who have agreed to share their app activity with Google, and is modeled to better represent the whole population. The data simply records if an app is opened in the foreground. Users have control over their data and can opt out of sharing it, or delete individual events, in myactivity.google.com.
Additionally, these new developer metrics are our first to use differential privacy - an advanced technique that provides increased privacy protections across datasets. You can find out more about this approach in our technical blog.
Just like previous benchmark launches, all of the peer comparison metrics come with protections for developer privacy. The data is generated from a large number of apps and games, and the peer groups, driven by Play Store’s advanced tagging system, do not share the performance of individual apps. So although you can find high-quality, reliable, useful peerset comparisons we've worked to obscure the performance of any individual competitor’s app from the peersets you see, and obscure your apps' performance in peersets too.
More to come
This is the first launch of a multi-year project to bring more helpful insights and active recommendations to Google Play Console. The largest mobile app developers often use growth consultants to help inform their long-term strategic product decisions. We’re dedicated to bringing this kind of help and expertise to all Play developers via the console. So look out for more launches over next year!
*Please note you need a Google Play Console account to access these links.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Eric Bahna, Product Manager
In January, we enabled the Google Play Store to accept open testing submissions of navigation, parking, and charging apps. It’s great to see many of you developing Android Auto apps and sending us feedback through the issue tracker. Thank you for helping us improve the platform so we deliver better in-car experiences together! Drivers have been sending positive feedback, too, as new apps launch to open testing, like Chargemap.
Chargemap in Android Auto
Today, we’ve reached the next milestone: the Android for Cars App Library is available in Jetpack as androidx.car.app 1.0.0-beta01! The move to Jetpack makes the library open source, gives you more visibility into our feature development, and provides API consistency with other Jetpack libraries. We’ve updated the developer guide and design guidelines to cover androidx.car.app. Test your app with Android Auto 6.1, or later, then you can publish your app to open testing in the Google Play Store. androidx.car.app includes all functionality of the closed source library (com.google.android.libraries.car), and then some! For example, we added a new GridTemplate, which is useful when users rely primarily on images to make their selections.
androidx.car.app 1.0.0-beta01
androidx.car.app
com.google.android.libraries.car
Examples of the new GridTemplate in androidx.car.app
On September 1, 2021, the closed source Android for Cars App Library (com.google.android.libraries.car.app) will no longer be available and the Google Play Store will not accept submissions that use com.google.android.libraries.car.app. Our development focus from now, including new features, is on androidx.car.app. We encourage you to migrate now and we’ve created a migration guide that makes it easy. Migration usually takes less than a day, in our experience with early access partners.
com.google.android.libraries.car.app
We’re working hard to stabilize androidx.car.app and prepare the Google Play Store for production submissions. Production submissions will require androidx.car.app and you can get your app ready by using it in open testing today.
Luli Perkins, Developer Relations Program Manager
Our second edition of #AndroidDevJourney is here! At the beginning of this year we launched the #AndroidDevJourney to share the stories of members of our community through our social platforms. Each Saturday, from January through June, we’ll feature a new developer on our Twitter account.
For a chance to be featured in our March spotlight series, tweet us your story using #AndroidDevJourney.
Tell me about your journey to becoming an Android Developer and how you got started.
In 2012 I was working as a contractor for the NSW government here in Australia as a Java J2EE web developer. I'd been in that role for 11 years, building web apps for students and teachers. However, in 2012 the government decided that contractors were expensive and let us all go. So while in my hand-over period I'd read about some kids who were writing Android apps and making lots of money doing so. The Android Market was new and so any app uploaded got a large audience, and since I already knew Java it seemed like switching from a web developer to a mobile developer might be a smart career move. So I purchased a new phone, the HTC Legend and spent the next 2 weeks learning everything I could about Android apps. It was the first time I could run software I'd written on a device made by someone else that I could carry around with me. It was a very exciting time where any app idea seemed possible.
When my contract finally ended, I managed to get a new job working for a mobile development agency and started working on Android apps for their clients. In order to learn more about Android app development, I started to attend the local Android meetups and Google Developer Group events, listening to speakers (mostly from Google) and trying to improve my skills as an Android developer.
In 2013 I was offered the opportunity to become the organiser of the Sydney GDG and it was that year that I also attended my first Google I/O (I've been every year since). One of the hard parts about being a GDG organiser is finding speakers, so occasionally if there were no speakers, or if a speaker dropped out at the last minute, I would step in and give a talk instead. 2013 was also the year I decided to move on from the mobile agency I was working at, and I spent the next 5 years working as a freelance contractor, working with clients such as eBay, the Sydney Opera House, and one of the large banks in Australia. Being the organiser of GDG Sydney and a regular speaker at the meetups meant finding work was quite easy.
In 2016 because of all the speaking I was doing I was approached to join the Google Developer Experts program, at this time I was doing regular talks at both the GDG Sydney and Android meetup events every couple of months. When I joined the GDE program, I handed over my GDG responsibilities to some friends, who still run it to this day. As part of the GDE program I've been lucky enough to attend many Google I/O events, and I've also had the opportunity to speak at conferences all over the world, including DroidCon Boston, Mobile Era in Oslo, DevFest Melbourne, DroidCon Singapore, Chicago Roboto and many others. Having the chance to speak to so many people all over the world has been very rewarding, and I've made many friends.
In 2019 I joined the company where I work today - mx51, I'm the lead Android developer designing and building apps that run on payment terminals, which also integrate with Point of Sales systems. I'm still a GDE but with the 2020 madness the ability to speak at in-person events was severely hindered. I hope that in-person events will start again soon and that I can continue my journey as a GDE.
What’s one shortcut, tip, or hack you can’t live without?
Android development is constantly changing and advancing, so there is always something new to learn. My tip would be to always be learning, there are lots of ways to do this, subscribe to the Android Developers YouTube channels and Medium publications. Follow Googlers and Google Developer Experts on Twitter for new tips and posts. Subscribe to the Android Weekly newsletter for an overview of new libraries and blog posts, and attend your local GDG chapter and Meetups. Not only are these great ways to learn new aspects of Android development, but with meetups they're a great place to meet other Android developers, share successes, and ask for advice on problems.
What's the one piece of advice you wish someone would have given you when you started on your journey?
When I started out as an Android developer, I could never have dreamed about being a Google Developer Expert, travelling the world and speaking at large events. It took me a long time to learn that it's ok not to know the answers to people's questions. If at an event someone asks something you don't know, it's ok to say so. You can always say that you'll find out later and get back to them. There is no need to make up a wrong answer on the spot and lead someone off course. People are often scared that a topic they're presenting might not be the best or greatest way to do something, and they fear looking stupid. If a person in the audience suggests a better way that shouldn't be a worry, 1) you learnt something, 2) everyone else learnt something and 3) there may be scenarios where your solution is better and a discussion can be had. So my advice would be, when speaking don't fear questions but embrace the opportunity to help someone immediately, or later, or perhaps discover something new yourself.
I dabbled in Android development in college with the student mobile development group, but it wasn't until I was a few years in web development I made the real switch over. Back in my web dev days, I joined the Kotlin community, where I felt immediately welcome. Shortly after, I moved to Chicago a few years back when I heard there was a Kotlin community in the tech scene.
Getting up to speed with Android at a professional level is a whole different game, and I've been lucky to find the overlapping Kotlin/Android community both locally and globally. Android development has accelerated my career technically and professionally, yet the world is so deep and vast within the sandbox of Android development.
Already being an active enthusiast with Kotlin, it only felt natural to switch to Android, and I've never looked back. Since then, I've been working scalable and complex Android applications, and contributing with some technical writing along the way. I'm currently co-writing with my colleague, Pierre Laurence, on “Programming Android with Kotlin: Achieving Structured Concurrency with Coroutines with O'Reilly”, and I'm excited to have it come out sometime this year.
For larger projects, it's sometimes hard to locate the file you're looking at in your Project view. You can use the target symbol ⊕ to get a highlight the file you're currently on in Android Studio.
Only install LeakCanary when, and only when, you and your team is ready for that conversation 😁
My journey as a developer started as a child. As a kid, I was obsessed with robots. I remember my dad bought me a Lego set called Lego Mindstorm, which was basically a robotics set with sensors and motors, plus it was also programmable. After graduating high school, I enrolled in the US Army as an Aviation Maintenance Repairer. After 6 years, I was honorably discharged then enrolled in college at Fordham University. In 2014, I received a Bachelor of Science in Computer Science. About 2 years later, I met my now wife, and together we started building EatOkra as a way for us to find black-owned restaurants in Brooklyn, NY. As we introduced the application to new people, they shared it with their network; before we knew it, many people were asking us to cover more areas in the south.
Learn how to ask the right questions.
One piece of advice I wish I took more seriously was to not build an application using beta technology. EatOkra's MVP was created using a beta version of a software framework. It started out good but then as they made updates, at times, I ended up having to wait months for certain issues to get fixed. I also had to completely stop and restart the app with an entirely new code base because the company decided to change how they architected the code. I learned a lot but it was painful to navigate.
My journey started a couple of years ago (I was still in college) when I saw the Android Developer Udacity course. There was no nano degree back in the day. So once I saw it, I started building some apps for myself. From there, I applied for my first job as a junior developer in a big consulting firm. Then I started seeing more courses and started following a lot of people at Twitter, like Sam Edwards and Joe Birch (both GDE). The community made me grow and learn. A couple of years later I got my first team and I began delivering speeches at conferences and keeping up my Medium blog on the side. The community offers me feedback and knowledge, and especially a place to learn. My first conference was with WomenWhoCode.org here in Mexico. They opened a place for me without any experience. The same happened with Google Developers Groups here in Mexico City.
I became a Lead Engineer during my second job and I began doing worldwide conferences. I asked for feedback from Sam Edwards and Carlos Muñoz (also GDEs in Colombia) and they told me not to worry because I would amazingly and they encouraged me to keep doing it.
I got a really nice offer to start from scratch here as a Mobile Platform engineer in Mexico City with a huge fintech Startup (Konfio.mx). This is my current job, which means I am in the architectural office where we choose new ideas and new processes and pretty much service all the areas in the company.
I started creating a group of series to teach people some specific topics that I noticed were not deeply addressed. I also started getting involved in Kotlin Multiplatform and then I was reached out to by two GDE that nominated me to become GDE, Walmyr Carvalho, and Sam Edwards. They offered me feedback about my latest talks, podcast, and series and I was accepted at the end of 2020. Right now, I'm trying to learn more and deliver more talks and blog posts to the community.
My special hack as an Android Developer is to use Wireless Debugging in the lastest Android Studio for physical devices. It is my favorite part because I don't need to use any cables and the setup is super easy!
My advice is that learning is a process, things change and all of this must be welcome because we are addressing the evolution of the platform as we code. Also, read everything you can because people in the community are amazing and they love to teach! Open an account on Twitter, because there are a lot of people giving tips in less than 180 characters.
The Android Developer community prides itself in its inclusivity and welcomes developers from all backgrounds and stages of life. If you’re feeling inspired and want to learn more about how to become a part of our community, here are a few resources to help get you started.
Dive into developer.android.com
Follow us on Twitter
Subscribe to our YouTube channel
The Google Developer Groups program gives developers the opportunity to meet local developers with similar interests in technology. A GDG meetup event includes talks on a wide range of technical topics where you can learn new skills through hands-on workshops.
Join a chapter near you here.
Founded in 2014, Google’s Women Techmakers is dedicated to helping all women thrive in tech through community, visibility and resources. With a member base of over 100,000 women developers, we’re working with communities across the globe to build a world where all women can thrive in tech.
Become a member here.
The Google Developers Experts program is a global network of highly experienced technology experts, influencers and thought leaders who actively support developers, companies and tech communities by speaking at events, publishing content, and building innovative apps. Experts actively contribute to and support the developer and startup ecosystems around the world, helping them build and launch highly innovative apps.
Learn more about the program here.
Java is a registered trademark of Oracle and/or its affiliates.
Posted by Nick Grayson, Product Manager
Android works best when it helps developers create apps that people love. That’s why we are dedicated to providing useful APIs like Activity Recognition which, with the user’s permission, can detect user’s activities (such as whether a user is biking or walking) to help apps provide contextually aware experiences.
So much of what we do relies on a good night's rest. Our phones have become great tools for making more informed decisions about our sleep. And by being informed about sleep habits, people can make better decisions throughout the day about sleep, which affects things like concentration and mental health.
In an effort to help our users stay informed about their sleep, we are making our Sleep API publicly available.
The Sleep API is an Android Activity Recognition API that surfaces information about the user’s sleep. It can be used to power features like the Bedtime mode in Clock.
This sleeping information is reported in two ways:
The API uses an on-device artificial intelligence model that uses the device’s light and motion sensors as inputs.
As with all of our Activity Recognition APIs, the app must be granted the Physical Activity Recognition runtime permission from the user to detect sleep.
Developers spend valuable engineering time to combine sensor signals to determine when the user has started or ended activities like sleep. These detection algorithms are inconsistent between apps and when multiple apps independently and continuously check for changes in user activity, battery life suffers.
The Sleep API is a simple API that centralizes sleep detection processing in a battery-efficient manner. For this launch, we are proud to collaborate with Urbandroid, the developer of the popular alarm app, Sleep As Android
Sleep as Android is a swiss army knife for getting a better night’s rest. It tracks sleep duration, regularity, phases, snoring, and more. Sleep Duration is one of the most important parameters to watch for ensuring a good night’s rest. The new Sleep API gives us a fantastic opportunity to track it automatically in the most battery efficient way imaginable. - Sleep as Android Team
- Sleep as Android Team
The Sleep API is available for developers to use now as part of the latest version of Google Play Services.
This API is one step of our efforts to help our users get a better night's rest. We look forward to working more on this API and in this area in the future.
If you are interested in exploring or using this API, check out our API Documentation.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
