Posted by Luli Perkins, Developer Relations Program Manager
For the March edition of #AndroidDevJourney, we’re highlighting Android developers from all over the world with many different experiences. Early this year, we launched the #AndroidDevJourney series to highlight our community on our social media accounts. Each Saturday, from January through June, we’ll feature a new developer on our Twitter account.
For a chance to be featured in our April spotlight series, tweet us your story using #AndroidDevJourney.
Tell me about your journey to becoming an Android Developer and how you got started.
Since the age of 14, I was very interested in animations and graphic design. I used to watch advertisement animations or cricket match animations of player profiles on TV and wonder how I could create these. Later that year, when my sister purchased our home's first PC, I started learning Microsoft Paint and later Adobe Flash. I worked on Flash for about 11 years throughout high school, University, and my first three jobs in game development.
Game development was and has been my first love in computer science. But, Android became something special for me. It was NOT love-at-first sight because I hated Android when I first learned about it. I still don't know why. Coming from a poor family background, I got a fully-funded scholarship through Prime Minister ICT R&D Scholarship Program and enrolled in National University of Engineering & Technology (NUST), SEECS Islamabad campus.
In my 3rd semester, Android was at 2.2 Froyo. A company organized a workshop at our campus which was attended by high-level tech folks like CTOs, software architects, and lead engineers. University management decided to send three students to attend that workshop and I was lucky enough to be one of them. In simple words, the whole 3-days workshop was over my head. I was a newbie in C++ programming and didn't know anything about Java. And here I was trying to learn high-level Android.
After the workshop, I decided that Android was not for me. However, the university announced an open programming competition for any technology. But they gave extra points for Android submissions. This was my calling. In greed of those extra points, I took up the challenge. I borrowed the only Android book "Hello Android" from my teacher, Sir Shamyl bin Mansoor, and tried to learn as much as I could. Somehow, I managed to submit my first Android app which I showcased on a borrowed laptop with a very slow emulator of Android 2.2. To my surprise, I won it and got Rs. 100,000 prize money. First thing I bought was an Android phone and my journey started.
I started writing about it in a WordPress blog, organized workshops in different universities, made my final year project a 3D game in Adobe Flash, and AIR deployed on a Samsung Galaxy 10 tablet which had a new Android 4 Holo theme and the great Fragments.
After graduation, I got an opportunity from PacktPub (a book publishing company) to write a full book on Android. This was the best achievement I ever received. I managed to co-author two worldwide published 300+ page books (Learning Android Intents & Mastering Android Game Development) on Android in the following two years.
Having about seven years industry hands-on experience in Android development, I spend a lot of time on writing and sharing my knowledge with the community. I mostly write on my website and on Medium. Besides writing, I have been active in open source and have created some Android libraries like EasyFlipView, Room Explorer, etc.
In 2017, I started doing public speaking again. At first, it was a little tough to manage time while working a full-time job and freelance contracts, but it was worth it. I got more and more active in speaking and gave talks at events like Google IO Extended Karachi & Hyderabad in 2018 and 2019, DevFest 2019 Karachi, Pakistan's first DSC Summit, Kotlin Everywhere 2019, and other local events.
From these events, Sami Kizilbash noticed me and nominated me for becoming a Google Developers Expert. It was a tough time because of a serious medical situation with my father at that time, but a year later in February 2020 I became Pakistan's first Google Developers Expert in Android. I never thought that I would be a GDE in a field like Android. It is a big honor and achievement for me, along with a feeling of responsibility to help the community in a better way now. Android development has been my life fuel, career, brought bread for me and my family and happiness in developing and delivering more than 100 apps. With more than 2.5 billion Android devices today, this is an excellent career choice with high growth and potential for upcoming students and developers.
My GDE journey has been a fantastic one. I have enjoyed every moment of it, all the love I got from Google and fellow GDEs - including Joe Birch who actually inspired me to become GDE, Hasan Abid, Saurabh Arora, and Juhani Lehtimaki, and Saad Hamid who also helped me through the process. In all the chaos of 2020, it was a very talkative year for me, as I did 25+ online talks on Jetpack Compose animations concepts.
What’s one shortcut, tip, or hack you can’t live without?
I simply love how Mnemonic Bookmarks make code navigation so much faster and easier. When you are working on a large codebase, it becomes harder to remember which method was where and what was happening in another Fragment. Simply, press Ctrl + F11 and choose any number or character, let's say 1. Now, when you press Ctrl + 1, Android Studio will bring you back on that exact line.
What's the one piece of advice you wish someone would have given you when you started on your journey?
My journey started from my college days. I got selected as an Applied CS facilitator for Android by Google in my second year of university. Because of this, I had to take sessions and help students complete a set of tasks as part of Bootcamp. In my college days I was not very good at Android, so when the opportunity came I took it upon myself to gain some knowledge of Android and then help people with their tasks. Learning to build apps that would be used by a lot of people helped me choose Android as a career. And that is how my journey to become an Android developer started.
I like to use the Macro shortcut in Android Studio.
As a beginner in any domain, not just Android, please keep asking questions on how to improve and learn from people in the community. Some of them might not answer your queries but a handful of them might. And in this way, you can learn and grow from their experience and when the time is right, you might be able to help someone in the coming future. This is the key to success!
My journey in becoming an Android Developer started in 2010, my second year of university when I had the opportunity to participate in a program called “Entrepreneurial Programming and Research on Mobiles” (EPROM). It was a collaboration between MIT and Nokia, and my university was one of the campuses that ran the program. I did not study computer science, so the program was my first exposure to software development. I learned how to build J2ME apps and got exposure to different mobile technologies at the time.
Shortly after the program, I got a work-study opportunity at iQube Labs, where my mentor - James Fowe, who was building a mobile developer community in Nigeria - sent me a bunch of resources and tasks for me to learn how to build Android apps. The Android OS around 2010 was Android Froyo and that was the operating system on which I ran my “Hello world” on Android. Within the next year, I found myself building actual apps on Android Gingerbread.
I have since worked as an Android Developer in different companies ranging from small to mid-sized startups with millions of users, to publicly traded companies, all across many countries. I’ve had the opportunity of working with very brilliant folks that have contributed to my growth and learning.
My journey is not complete without talking about the developer community. I consider myself a product of the community and that’s why I try to give back every now and then when I have the opportunity.
I started getting involved in the developer community at my university - through various student groups, including my local GDG group then co-organized by Moyinoluwa Adeyemi (an Android GDE). I attended meetups and participated in developer challenges and hackathons.
Becoming a GDE for Android is a career milestone I never saw coming. It started in 2016 when John Kimani (Google DevRel manager for SSA) toured my office and we ran into each other at the door. I wasn’t prepared enough to become a GDE the first time my profile was reviewed, but with feedback, guidance, mentorship and hard work, I became an Android GDE in 2018.
I’m grateful to have had the opportunity to travel to so many countries around the world and meet members of the global Android Developer community. I’ve also given talks at conferences and meetups; including DevFests, Droidcon (Nairobi, Dubai, Berlin, Boston), and 360AnDev, to mention a few, about topics I enjoy - Kotlin, Design Systems, Jetpack Compose, and Developer Productivity Engineering.
That’s such a tough one, but I’ll say my favourite AndroidDev tip right now is: use the Android code search tool - https://cs.android.com - and Android API documentation as often as possible. (See also: https://androidsrc.dev/)
The two resources have helped me in answering the “why is this not working” question and understanding what’s happening under the hood. A lot of times, I need to really understand what the Framework function I’m calling does, and the answer is almost always in the documentation or in the source code.
I’ll give two for the price of one:
From a young age, I’ve always loved science fiction books and movies – I always had a gut feeling that whatever career path I went down, it would have something to do with computers. Programming quickly became my favourite creative outlet – it started with creating websites and apps when I was 11, mainly as a way to enhance my other passions such as drawing and making puzzles for my friends.
I got my first Android phone when I was in high school and immediately knew it would open a whole new world of opportunities for me, so I picked up a few books and found a few online tutorials which got me started with code on my phone running Android 2.1 Eclair.
My first app was a flashcards maker. I needed something like that to help me learn English and I couldn’t find anything online - so I made my own!
Thanks to a few of my passion projects, including a flashcard maker app, I managed to quickly land a job as an Android Engineer while I was still completing my Computer Science degree at university. I then tried working across a few other areas in software engineering, but ultimately, Android was always my favourite and ended up becoming my specialty!
It’s not quite a hack, but I honestly don’t know how I lived before ConstraintLayout became a thing! Oh – and Android Weekly’s mailing list, definitely one of the best ways to get all of the relevant news and tutorials in the Android world delivered directly to you every Monday!
Looking back, I definitely recommend putting effort and being really intentional about seeking out other Android engineers around you. Once I started proactively attending meetups and working with other engineers, my skills and knowledge grew exponentially. Collaborating and bouncing around ideas has always been my favourite way to find creative and innovative solutions to problems I’m working on.
Posted by Dan Galpin
We've added the Oboe C++ audio library to the Android Game SDK. Oboe's support of high-performance, low-latency audio across the widest range of Android devices is the right choice for most game developers.
Single API
On Android devices running Android 8.1 (API level 27) and higher, Oboe takes advantage of the improved performance and features of AAudio while maintaining backward compatibility (using OpenSL ES) with Android 4.1 (API level 16) and higher. Oboe also adds key features on top of the platform APIs to improve the audio developer experience, such as resampling, format conversion, and dynamic latency tuning. It performs audio data transformations, such as channel count conversion, when necessary to improve performance on selected devices, and has workarounds for other device-specific behaviors that improve the robustness of your audio code. In short, Oboe is now the recommended way to write audio code in C/C++ on Android.
Integrating Oboe
There are two primary ways to incorporate Oboe library prebuilts into your project. If you're using the Android Gradle plugin version 4.1.0 or higher along with CMake, and are using or can enable shared STL, enabling Oboe is as easy as adding Oboe to your Gradle dependencies, enabling prefabs, and adding a few lines to your CMakeLists file.
You can also integrate Oboe by statically linking using the Android Game SDK. Begin by downloading the library and checking it into your source control system. You need to be using minSdkVersion of 16 or higher with NDK release 18 or higher. Then, to specify the version of the game SDK to link in that's been compiled for the given ABI, API level, NDK, and STL combination, add a compiler include path in this form:
gamesdk/libs/[architecture]_API[apiLevel]_NDK[ndkVersion]_[stlVersion]_Release Example: gamesdk/libs/arm64-v8a_API24_NDK18_cpp_static_Release
Then add -loboe_static to your linker command. Since you don't need to bundle the liboboe.so shared library, static linking gives you a smaller code footprint. If the ABI, API level, NDK, and STL combination doesn't have a precompiled version available for your settings, you can alternately link against the shared library. We have more guidance, including how to configure CMake for static libraries, in our developer documentation.
-loboe_static
Oboe Basics
To output audio, you begin by creating a stream with the required properties, including a callback that is used when the stream requires new data.
oboe::AudioStreamBuilder builder; builder.setPerformanceMode(oboe::PerformanceMode::LowLatency) ->setSharingMode(oboe::SharingMode::Exclusive) ->setDataCallback(myCallback) ->setFormat(oboe::AudioFormat::Float);
You'll then populate the audio data inside of the callback. If the stream creates successfully, that means you got the requested stream type. If you didn't specify these types, you'll have to query to see what format was returned.
class MyCallback : public oboe::AudioStreamDataCallback { public: oboe::DataCallbackResult onAudioReady(oboe::AudioStream *audioStream, void *audioData, int32_t numFrames) { // We requested AudioFormat::Float auto *outputData = static_cast<float *>(audioData); // TODO: populate audioData here return oboe::DataCallbackResult::Continue; } };
For full details on using Oboe, check out the documentation, code samples and API reference. There's even a codelab which shows you how to build a simple rhythm-based game.
If you have any issues, please file them here. We'd love to hear from you.
Posted by Dave Burke, VP of Engineering
Last month we shared the first preview of Android 12, an early look at the next version of Android. Today we’re bringing you the next milestone build in this year’s release, with more new features and changes for you to try with your apps. Our program of early previews is driven by our core philosophy of openness and collaboration with you, our community. Your input helps us make Android a better platform for developers and users, so keep the feedback coming!
In Android 12 we’re making the OS smarter, easier to use, and better performing, with privacy and security at the core. We’re also working to give you new tools for building great experiences for users, whether they’re using phones, laptops, tablets, TVs, or cars. Some things to look for in today’s release include new rounded corners APIs, improved picture-in-picture APIs, better companion device management, easier effects like blur and color filter, app overlay controls, and more.
There’s a lot to check out in Developer Preview 2 - read on for a few highlights and visit the Android 12 developer site for details and downloads for Pixel. For those already running Developer Preview 1 or 1.1, we’re also offering an over-the-air (OTA) update to today’s release.
Let us know what you think, and thank you to everyone who has shared such great feedback so far.
We’re continuing to focus on giving users more transparency and control while keeping their devices and data secure. In today’s release, we’ve added some new features to check out and test with your apps.
App overlay controls - Android’s system alert window gives apps a way to get users’ attention for important actions by showing an overlay on top of the active app. These windows can interrupt the user, though, so we already require apps to request permission before displaying them. Now in Android 12 we’re giving you control over whether these overlays can be shown over your content. After you’ve declared a new permission, your app can call Window#setHideOverlayWindows() to indicate that all TYPE_APPLICATION_OVERLAY windows should be hidden when your app’s window is visible. You might choose to do this when displaying sensitive screens, such as transaction confirmation flows. More here.
Extended security for lockscreen notification actions - Android 12 adds finer-grained privacy and security controls for notifications displayed on the device lockscreen. You can now configure notification actions so that when triggered from the lockscreen, they will always generate an authentication challenge. This extends the notification visibility controls already available through the notification APIs. For example, this enables a messaging app to require authentication before deleting a message or marking it as read. More here.
You can read more about these and other privacy and security changes here.
We’re working to give you more tools to help you deliver a polished experience and better performance for users. Here are some of the updates in today’s release.
Support for Rounded corners - Many modern devices use screens with rounded corners, giving them a clean modern look, but also introducing some extra considerations for app developers. To deliver a great UX on these devices, developers need to account for the rounded corners and adjust any nearby UI elements to prevent them from being truncated.
To help with this, we’re introducing new APIs to let you query for rounded corners and get their details. A RoundedCorner holds the details for a corner, including its radius, centerpoint, and other data. You can call Display.getRoundedCorner() to get the absolute details for each rounded corner. You can also call WindowInsets.getRoundedCorner() to get the corner details relative to your app’s bounds. With these, you can manage the position of UI elements and content as needed. More here.
Picture in Picture (PIP) improvements - for people using gesture nav, we’ve improved how apps transition to picture-in-picture (PIP) mode on swipe up-to-home. If an app enables auto-PIP, the system now directly transitions the app to PIP mode on up-to-home, instead of waiting for the up-to-home animation to complete. This makes the transition smoother and improves perceived performance. We’ve also improved PIP window resizing for non-video content. Apps can now enable seamless resize to let the system resize the PIP Activity when needed. Android 12 also supports stashing the PiP window by dragging it to the left or right edge of the screen. Also, to make PIP windows easier to manipulate, we’ve updated the tap behaviors. Single-tapping now displays controls, and double-tapping toggles the PIP window size. More here.
Keeping companion device apps awake - For apps that manage companion devices like smartwatches and fitness trackers, it can be a challenge to make sure the app is running and connected whenever an associated companion device is nearby. To make this easier, we’re extending the Companion Device Manager with a new CompanionDeviceService API. Apps that manage companion devices can implement this service to let the system wake the app whenever the associated companion device is nearby. The system keeps the service bound whenever the device is nearby, and notifies the service when the device goes in and out of range or is turned off, to let the app clean up state as needed. Apps can also use a new companion device profile when connecting to a watch, which simplifies enrollment by bundling related permissions into a single grant. More here.
Bandwidth estimation improvements - for developers who need to know the typical bandwidth available to each user so you can tailor their experience, we now provide improved bandwidth estimation. We’ve enhanced the existing bandwidth estimation APIs to let you retrieve an estimate of aggregate throughput per carrier or Wi-Fi SSID, network type, and signal level, for all users on the device. The new estimation is likely to be easier and more accurate than most other estimation methods, give it a try and let us know how it works for you.
Easier blurs, color filters and other effects - In Android 12, we’re making it easier to apply common graphics effects to your Views and rendering hierarchies. You can use RenderEffect to apply blurs, color filters, and more to any RenderNode. You can combine these effects as chain effects (which compose an inner and outer effect in order) or blend them. You can also apply effects directly to Views (leveraging the underlying RenderNode) by calling View.setRenderEffect(RenderEffect).
view.setRenderEffect(RenderEffect.createBlurEffect(radiusX, radiusY, SHADER_TILE_MODE))
Blurring a View with RenderEffect
This allows you to blur the contents of an ImageView without having to get the bitmap data, process the image, create a new Bitmap, and set it back into the ImageView. RenderEffect leverages the existing rendering pipeline to minimize excess calculation.
Give these a try and let use know what you think! More here.
You can also create a frosted glass effect for your window background using a new Window.setBackgroundBlurRadius() API. With this you can set a radius to control the density and scope and the platform applies the blur to the background content within the bounds of your app’s window only. You can also use blurBehindRadius to blur all of the content behind the window to create a depth effect for a floating window.
A dialog window with background blur and blur behind...
We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 12, we’ve made most app-facing changes opt-in to give you more time, and we’ve updated our tools and processes to help you get ready sooner.
With Developer Preview 2, we’re well into the release and continuing to improve overall stability, so now is the time to try the new features and changes and give us your feedback. We’re especially looking for input on our APIs, as well as details on how the platform changes affect your apps. Please visit the feedback page to share your thoughts with us or report issues.
It’s also a good time to start your compatibility testing and identify any work you’ll need to do. We recommend doing the work early, so you can release a compatible update by Android 12 Beta 1. There’s no need to change your app’s targetSdkVersion at this time, but we do recommend using the behavior change toggles to get a preliminary idea of how your app might be affected by opt-in changes in Android 12.
As we reach Platform Stability in August 2021, all of the app-facing system behaviors, SDK/NDK APIs, and non-SDK lists will be finalized. At that point, you can wind up your final compatibility testing and release a fully compatible version of your app, SDK, or library. More on the timeline for developers is here.
App compatibility toggles in Developer Options.
The Developer Preview has everything you need to try the Android 12 features, test your apps, and give us feedback. You can get started today by flashing a device system image to a Pixel 3 / 3 XL, Pixel 3a / 3a XL, Pixel 4 / 4 XL, Pixel 4a / 4a 5G, or Pixel 5 device or using the Android Emulator. If you’ve already installed a preview build to your Pixel device, you’ll automatically get future updates over-the-air for all later previews and Betas. More details on how to get Android 12 are here.
You can also test your apps on Android TV using today’s release and try the all-new Google TV experience. Learn more here and get started with your ADT-3 developer kit.
For complete information, visit the Android 12 developer site.
Posted by Jolanda Verhoef, Developer Relations Engineer
Let your creativity shine in the final week of the #AndroidDevChallenge! Last week we asked you to be fast, but for this final week we ask you to bring your 'A' game. Here’s the challenge:
Create a single-screen weather forecast app. You have until March 23rd, 23:59 PST to submit your entry.1
Your UI must be fully built in Compose. You can use fake weather data.
We will judge your submission on these four categories:
To help implement a beautiful design, check out the Compose documentation on layouts, theming, and graphics. Think of novel uses of animations and gestures. Improve your code quality with architecture and testing. And for overall execution, make sure to read about accessibility.
Your solution must be implemented in a public 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!
The App Submission must, at a minimum, support English language use.
This week you have a chance of winning a Google Pixel 5, the ultimate 5G Google phone! We’ll be giving away one Google Pixel 5 for the winner of each of the four categories, and one for the best of the best submission.2
Community is at the heart of Jetpack Compose and your feedback helps us build a better product:
Please review the link for the full official rules associated with the entry. ↩
If you don’t live in a country where the Pixel 5 is available, when you win we’ll instead send you an electronics gift card valued at US$699. ↩
Posted by Sameer Samat, VP, Product Management
Helping developers build sustainable businesses is a core part of Google Play’s mission. We work with partners every day to understand the challenges they face and help them bring their innovative ideas to life. Getting a new app off the ground and into orbit is not easy! To aid their quest for growth we provide a broad range of support, from powerful marketing tools and actionable data in the Play Console, education via Play Academy, best practices and thought leadership resources, programs such as the Indie Games Festival, Indie Corner, and accelerator programs around the world. We’re always looking for new ways to give them an added boost.
Starting on July 1, 2021 we are reducing the service fee Google Play receives when a developer sells digital goods or services to 15% for the first $1M (USD) of revenue every developer earns each year. With this change, 99% of developers globally that sell digital goods and services with Play will see a 50% reduction in fees. These are funds that can help developers scale up at a critical phase of their growth by hiring more engineers, adding to their marketing staff, increasing server capacity, and more.
While these investments are most critical when developers are in the earlier stages of growth, scaling an app doesn’t stop once a partner has reached $1M in revenue — we’ve heard from our partners making $2M, $5M and even $10M a year that their services are still on a path to self-sustaining orbit. This is why we are making this reduced fee on the first $1M of total revenue earned each year available to every Play developer, regardless of size. We believe this is a fair approach that aligns with Google’s broader mission to help all developers succeed. We look forward to sharing full details in the coming months.
As a platform we do not succeed unless our partners succeed. Android and Google Play have always listened to our developer partners from around the world and we continue to take their input into account as we build and run the ecosystem. We look forward to seeing more businesses scale to new heights on Android, and to further discussions with our developer community to find new ways to support them technically and economically as they build their businesses.
We introduced Tiles in 2019, and since then, Tiles have become one of the most helpful and useful features on Wear OS by Google smartwatches. They are fast to access, convenient, and designed to provide users with swipeable access to the things they need to know and get done right from their wrist. This also gives users control over what information and actions they want to see.
Today, we're excited to announce that the Jetpack Tiles library is in alpha. This library enables developers to create custom Tiles on Wear OS smartwatches. These custom Tiles will become available to users later this Spring when we roll out the corresponding Wear OS platform update.
Tiles can be designed for many use cases, like tracking the user’s daily activity progress, quick-starting a workout, starting a recently played song, or sending a message to a favorite contact. While apps can be immersive, Tiles are fast-loading and focus on the user's immediate needs. If the user would like more information, Tiles can be tapped to open a related app on the watch or phone for a deeper experience.
Tiles are built using Android Studio, as part of your Wear OS application. Start by adding the Wear OS Tiles dependencies:
dependencies { implementation "androidx.wear:wear-tiles:1.0.0-alpha01" debugImplementation "androidx.wear:wear-tiles-renderer:1.0.0-alpha01" }
The first dependency includes the library you need to create a Tile, while the second dependency lets you preview the Tile in an activity.
Next, provide the information to render the Tile using the TileProviderService:
TileProviderService
class MyTileService : TileProviderService() { override fun onTileRequest(requestParams: RequestReaders.TileRequest) = Futures.immediateFuture(Tile.builder() .setResourcesVersion("1") .setTimeline(Timeline.builder().addTimelineEntry( // For more information about timelines, see the docs TimelineEntry.builder().setLayout( Layout.builder().setRoot( Text.builder().setText("Hello world!") ) ) ) ).build()) override fun onResourcesRequest(requestParams: ResourcesRequest) = Futures.immediateFuture(Resources.builder() .setVersion("1") .build() ) }
There are two important parts to this code:
onTileRequest()
TimelineEntry
onResourcesRequest()
Create a simple activity to preview your Tile. Add this activity in src/debug instead of src/main, as this activity is only used for debugging/previewing purposes.
src/debug
src/main
class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val rootLayout = findViewById<FrameLayout>(R.id.tile_container) TileManager( context = this, component = ComponentName(this, MyTileService::class.java), parentView = rootLayout ).create() } }
Now you’re ready to publish your Tile. For more information on how to do that, and to learn more about Tiles, read our new guide and take a look at our sample Tiles to see them in action.
The Jetpack Tiles library is in alpha, and we want your feedback to help us improve the API. Happy coding!
On your marks...Get set… Wait a second! Save the date for the third week of the #AndroidDevChallenge! On March 13th, compete with other developers in your time zone; the fastest Compose skills wins! We loved all the creative submissions of week #1 and #2, but now we’re looking for speed. Here’s your challenge:
Be the fastest to implement a set of designs provided by us. The designs will be posted here when the challenge starts. Submit your entry* as soon as you finish implementing the designs.
We’ll post different designs at 3 different times on the 13th:
We’ll update this blog post at the beginning of each round with the link to the designs.
Your UI must be fully built in Compose, and strictly match all the guidelines specified in the designs. To help you with the implementation, check out the Compose documentation on theming, layouts, and navigation. 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.
For this week’s challenge, we’re giving away a Google Pixel 5, the ultimate 5G Google phone. In fact, we’ll be giving away three Google Pixel 5 phones: one to each developer who is fastest to submit a successfully implemented design for each of the three rounds of challenges.*
*Please review the link for the full official rules associated with the entry. ↩
*If you don’t live in a country where the Pixel 5 is available, when you win we’ll instead send you an electronics gift card valued at US$699.
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.
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
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.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
