Tag Archives: mobile

Join us online from 23-27 October for Passkeys Week

Posted by Milica Mihajlija, Technical Writer

Passkeys are a safer and simpler alternative to passwords that works on all modern browsers and platforms. They enable signing into online accounts by using a device screen lock–with a fingerprint, facial recognition, PIN or a pattern.

More and more online services are adding passkey support every day. On 10 October, 2023, Google accounts made passkeys the default sign in method for all devices that support it.

To accelerate our way into a passwordless future, from 23-27 October we are hosting Passkeys Week–an online event where you can learn everything you need to know to successfully implement passkeys. Use #PasskeysWeek to participate in the conversation and spread the word about your products that support passkeys.

Keep an eye on @ChromiumDev and @AndroidDev, where we'll share new learning materials, including blog posts, case studies and pathways to earn passkeys badges on your Google Developer Profile.

On 25 October at 10 AM PDT, we’ll host a live Q&A session on Google for Developers YouTube channel where you can get all your questions about passkeys answered by passkeys engineers from Google. Bookmark this link or click "Notify me" to get alerted when the livestream is about to start:

The recording will also be available on the channel after the event — we hope you will tune in.

Save the date for Firebase’s first Demo Day!

Posted by Annum Munir, Product Marketing Manager

This article was originally posted on the Firebase blog.

For the past six years, we have shared the latest and greatest updates to Firebase, Google’s app development platform, at our annual Firebase Summit – this year, we wanted to do something a little different for our community of developers. So, in addition to the Flutter Firebase festival that just wrapped up, and meeting you all over the world at DevFests, we’re thrilled to announce our very first Firebase Demo Day, happening on November 8, 2023!

What is Demo Day?

Demo Day will be a virtual experience where we'll unveil short demos (i.e. pre-recorded videos) that showcase what's new, what's possible, and how you can solve your biggest app development challenges with Firebase. You’ll hear directly from our team about what they’ve been working on in a format that will feel both refreshing but also familiar.

What will you learn?

You’ll learn how Firebase can help you build and run fullstack apps faster, harness the power of AI to build smart experiences, and use Google technology and tools together to be more productive. We’ve been working closely with our friends from Flutter, Google Cloud, and Project IDX to ensure the demos cover a variety of topics and feature integrated solutions from your favorite Google products.

How can you participate?

Since Demo Day is not your typical physical or virtual event, you don’t need to worry about registering, securing a ticket, or even traveling. This is one of the easiest ways to peek at the exciting future of Firebase! Simply bookmark the website (and add the event to your calendar), then check back on Wednesday, November 8, 2023 at 1:00 pm EST to watch the videos at your own pace and be inspired to make your app the best it can be for users and your business.

In the meantime, we encourage you to follow us on X (formerly Twitter) and LinkedIn and join the conversation using #FirebaseDemoDay. We’ll be sharing teasers and behind-the-scenes footage throughout October as we count down to Demo Day, so stay tuned!

Tune in for another episode of #TheAndroidShow on October 19!

Posted by the Android team

In just a few days, on Thursday, October 19 at 10AM PT, we’ll be kicking off another episode of #TheAndroidShow, live on YouTube and on developer.android.com! In this episode, we’ll be showing how we’re making it faster and easier to build excellent apps across devices with live technical demos and more, plus a live fireside Q&A with the Android team!


Across the show, we’ll be covering the latest in Android development, including a look at the new Pixel watch and the world of wearables, gathering the Android team to demo tools and libraries to build for foldables, large screen devices, with Compose, Android 14, Studio Bot, and more.

You'll hear the latest from the developers and engineers who build Android, including a conversation with Android’s Dave Burke.

Send us your burning questions using #AskAndroid

In this episode of #TheAndroidShow, we’ll also be hosting a live Q&A from the Googleplex in California, where we've assembled a team of experts ready to answer your questions live. Then, tune in on October 19 to see if your question is answered live, on the air!

#TheAndroidShow is your conversation with the Android developer community, this time hosted by Nick Butcher and Annyce Davis. You'll hear the latest from the developers and engineers who build Android. Don’t forget to tune in live on October 19 at 10AM PT, live on YouTube and on developer.android.com!

Android 14 is live in AOSP

Posted by Dave Burke, VP of Engineering

Today we're releasing Android 14 and pushing the Android 14 source to the Android Open Source Project (AOSP). Android 14 is designed to improve your productivity as developers while enhancing performance, privacy, security, and customization for users.

Android 14 is rolling out to select Pixel devices starting today, and will be available later this year on some of your favorite devices from Samsung Galaxy, iQOO, Nothing, OnePlus, Oppo, Realme, Sharp, Sony, Tecno, vivo and Xiaomi.

Thank you for taking the time to take Android 14 for an early spin though our developer preview and beta programs, sharing your feedback, and making sure your apps deliver a great experience on Android 14. Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

This post covers a selection of Android 14 changes that have the most developer impact. For a complete list of all of the Android 14 changes, visit the Android 14 developer site.

Performance and Efficiency

A big focus of Android 14 was on improving the performance and efficiency of the platform.

Freezing cached applications

Prior to Android 14, cached applications were allowed to run somewhat unconstrained. In Android 14, we freeze cached applications after a short period of time, giving them 0 CPU time. In Android 14 Beta populations, we see that cached processes consume up to 50% less CPU cycles as compared to Android 13 public devices. Thus, background work is disallowed outside of conventional Android app lifecycle APIs such as foreground services, JobScheduler, or WorkManager.

Optimized broadcasts

To keep frozen applications frozen longer (i.e. not get CPU time), we adjusted how apps receive context-registered broadcasts once they go into a cached state; they may be queued, and repeating ones, such as BATTERY_CHANGED, may be merged into one broadcast.

Faster app launches

With cached app and broadcast optimizations In Android 14, we were able to increase long-standing limits on the maximum number of cached applications in the platform, leading to a reduction in cold app starts that scales by the RAM present on the device. On 8GB devices, the beta group saw 20% fewer cold app starts, and on 12GB devices it was over 30% fewer. Cold startups are slow compared to warm startups and they are expensive in terms of power. This work effectively improves both power usage and overall app startup times.

Reduced memory footprint

Improving the Android Runtime (ART) has a huge impact on the Android user-experience. Code size is one of the key metrics we look at; smaller generated files are better for memory (both RAM and storage). In Android 14, ART includes optimizations that reduce code size by an average of 9.3% without impacting performance.

Customization

Customization is at the core of Android's DNA, and Android 14 continues our commitment to enabling Android users to tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling – Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%. A non-linear font scaling curve is automatically applied to ensure that text that is already large enough doesn’t increase at the same rate as smaller text. Learn more here.

Image showing the differences between font with no scaling at 100% on the left, standard scaling at 200% in the middle, and non-linear scaling at 200% on the right

Per-app language preferences – You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language. Starting with Android Studio Giraffe and AGP 8.1, you can configure your app to support Android 13's per-app language preferences automatically.

Regional preferences – Regional preferences enable users to personalize temperature units, the first day of the week, and numbering systems.

Grammatical Inflection – The Grammatical Inflection API allows you to more easily add support for users who speak languages that have grammatical gender. To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

New media capabilities


Ultra HDR for images - Android 14 adds support for 10-bit high dynamic range (HDR) images, with support for the Ultra HDR image format. The format is fully backward-compatible with JPEG, allowing apps to seamlessly interoperate with HDR images.

Zoom, Focus, Postview, and more in Camera Extensions - Android 14 upgrades and improves Camera Extensions, allowing apps to handle longer processing times, enabling improved images using compute-intensive algorithms like low-light photography on supported devices.

Lossless USB audio - Android 14 devices can support lossless audio formats for audiophile-level experiences over USB wired headsets.

New graphics capabilities

Custom meshes with vertex and fragment shaders - Android 14 adds support for custom meshes, which can be defined as triangles or triangle strips, and can, optionally, be indexed. These meshes are specified with custom attributes, vertex strides, varying, and vertex/fragment shaders written in AGSL.

Hardware buffer renderer for Canvas - Android 14 introduces HardwareBufferRenderer to assist in using Android's Canvas API to draw with hardware acceleration into a HardwareBuffer, which is particularly helpful when your use case involves communication with the system compositor through SurfaceControl for low-latency drawing.

Developing across form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors including a taskbar supporting enhanced multitasking, large-screen optimized system apps and notification UI, activity embedding, enhanced letterboxing, improved media projection, and more. Our app quality guidance for large screens along with additional learning opportunities around building for large screens and foldables can help optimize your app across all Android surfaces, while the large screen gallery contains design patterns and inspiration for social and communications, media, productivity, shopping, and reading apps.

Improving your productivity

Android 14 contains many updates focused on making your development experience more consistent, fun, and productive. Many of these updates are being made available on older platform releases using a combination of Google Play system updates, Jetpack libraries, and Google Play services, so you can reach more users with them.

OpenJDK 17 Support - Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that ship with Android 14. Learn more here.

Credential Manager and Passkeys support - Credential Manager is a new Jetpack API that supports multiple sign-in methods, such as username and password, passkeys, and federated sign-in solutions (such as Sign-in with Google) in a single API, simplifying your integration. Using Google Play services, Credential Manager is supported back to Android 4.4 (API level 19). Read more here.

Health Connect - Health Connect is a user controlled on-device repository for user health and fitness data that makes it easier than ever to support an integrated health and fitness experience across apps and connected devices. Health Connect is part of the Android platform and receives updates via Google Play system updates without requiring a separate download, and is available to older devices as an app on the Google Play store. Read about Health Connect and more in What's new in Android Health.

Superior system sharesheets - To make it easy to give your app's users a rich, consistent, sharing experience, the system sharesheets in Android 14 are configurable with custom actions and improved ranking.

More consistent and reliable foreground services- We've collaborated with hardware manufacturers such as Samsung to create both a more consistent developer experience and a more reliable user experience. To this end, Android 14 has a new requirement to declare foreground service types and request type-specific permissions and we have Google Play policies to enforce appropriate use of these APIs. We've also added a new user-initiated data transfer job type, making the experience of managing large user-initiated uploads and downloads smoother by leveraging JobScheduler's constraints (e.g. network constraints such as unmetered WiFi).

User experience

Predictive Back - Android 14 introduces new Predictive Back system animations – cross-activity and cross-task – to join the back-to-home animation introduced in Android 13. The system animations remain behind a developer option to allow time for additional polish and for more apps to opt-into Predictive Back; Material and Jetpack Predictive Back animations are available to users today.

Privacy and security

 
Data sharing updates – Users will see a new section in the location runtime permission dialog that highlights when an app shares location data with third parties, where they can get more information and control the app’s data access.

Partial access to photos and videos – When your app targeting SDK 34 requests any of the visual media permissions introduced in SDK 33 (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO), Android 14 users can now grant your app access to only selected photos and videos. To adapt your app to this change, we recommend following our recent best practices.

Background activity launching – Android 10 (API level 29) and higher place restrictions on when apps can start activities when running in the background. To further reduce instances of unexpected interruptions, apps targeting Android 14 need to grant privileges to start activities in the background when sending a PendingIntent or when binding a service.

Block installation of apps targeting older SDK versions – To protect against malware that targets older API levels to bypass security and privacy protections, apps with a targetSdkVersion lower than 23 cannot be installed on Android 14.

Runtime receivers – Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Secure full screen Intent notifications – Since full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, Android 14 limits the apps granted this permission on app install to those that provide calling and alarms only. Your app can now launch the settings page where users can grant the permission.

Safer dynamic code loading – Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Safer implicit intents – For apps targeting Android 14, creating a mutable pending intent with an implicit intent will throw an exception, preventing them from being able to be used to trigger unexpected code paths. Apps need to either make the pending intent immutable or make the intent explicit. Learn more here.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in until your app targets SDK version 34 to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

Easier testing and debugging of changes – To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.

image of app compatibility toggles in Developer Options
App compatibility toggles in Developer Options.

Get your apps, libraries, tools, and game engines ready!

Now is the time to finish your final compatibility testing and publish any necessary updates to ensure a smooth app experience.

If you develop an SDK, library, tool, or game engine, it's even more important to release any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please make sure to let your developers know if updates are needed to fully support Android 14.

Testing your app involves installing your production app onto a device running Android 14; you can use Google Play or other means. Work through all the app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Each release of Android contains changes to the platform that improve privacy, security, and the overall user experience, and these changes can affect your apps. Here are some top changes to test:

Remember to exercise libraries and SDKs that your app is using in your compatibility testing. You may need to update to current SDK versions or reach out to the developer for help.

Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes that apply when your app targets Android 14 and use the compatibility framework to help detect issues quickly.

Get started with Android 14

If you have a supported Pixel device, and are not enrolled in the Android Beta program, you will receive the public Android 14 OTA update as it becomes available (it may take a week or longer as this is a phased rollout dependent on device type and carrier). If you are currently enrolled in the Android Beta program running Android 14, you likely have received and installed the beta of the next Android 14 quarterly platform release (QPR1).

System images for Pixel devices are available here for manual download and flash, and you can get the latest 64-bit Android Emulator system images via the Android Studio SDK Manager. If you're looking for the Android 14 source, you'll find it here in the Android Open Source Project repository under the Android 14 branches.

For the best development experience with Android 14, we recommend that you use the latest release of Android Studio Hedgehog. Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility – learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes – Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.
  • Update your app with the Android SDK Upgrade Assistant – Android Studio Hedgehog now filters and identifies the specific Android 14 API changes that are relevant to your app, and walks you through the steps to upgrade your targetSdkVersion with the Android SDK Upgrade Assistant.
Screengrab of Android SDK Upgrade Assistant on Google Pixel Fold

Thank you again for participating in our Android developer preview and beta program! We're looking forward to seeing how your apps take advantage of the updates in Android 14.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Kakao Games increased FPS stability to 96% through Android Adaptability

Posted by Dohyun Kim, Developer Relations Engineer, Android Games

Finding the balance between graphics quality and performance

Ares: Rise of Guardians is a mobile-to-PC sci-fi MMORPG developed by Second Dive, a game studio based in Korea known for its expertise in developing action RPG series and published by Kakao Games. Set in a vast universe with a detailed, futuristic background, Ares is full of exciting gameplay and beautifully rendered characters involving combatants wearing battle suits. However, because of these richly detailed graphics, some users’ devices struggled to handle the gameplay without affecting the performance.

For some users, their device would overheat after just a few minutes of gameplay and enter a thermally throttled state. In this state, the CPU and GPU frequency are reduced, affecting the game’s performance and causing the FPS to drop. However, as soon as the decreased FPS improved the thermal situation, the FPS would increase again and the cycle would repeat. This FPS fluctuation would cause the game to feel janky.

Adjust the performance in real time with Android Adaptability

To solve this problem, Kakao Games used Android Adaptability and Unity Adaptive Performance to improve the performance and thermal management of their game.

Android Adaptability is a set of tools and libraries to understand and respond to changing performance, thermal, and user situations in real time. These include the Android Dynamic Performance Framework’s thermal APIs, which provide information about the thermal state of a device, and the PerformanceHint API, which help Android choose the optimal CPU operating point and core placement. Both APIs work with the Unity Adaptive Performance package to help developers optimize their games.

Android Adaptability and Unity Adaptive Performance work together to adjust the graphics settings of your app or game to match the capabilities of the user’s device. As a result, it can improve performance, reduce thermal throttling and power consumption, and preserve battery life.

Moving image of gameplay from Ares: Rise of Guardians

Results

After integrating adaptive performance, Ares was better able to manage its thermal situation, which resulted in less throttling. As a result, users were able to enjoy a higher frame rate, and FPS stability increased from 75% to 96%.

In the charts below, the blue line indicates the thermal warning level. The bottom line (0.7) indicates no warning, the midline (0.8) is throttling imminent, and the upper line (0.9) is throttling. As you can see in the first chart, before implementing Android Adaptability, throttling happened after about 16 minutes of gameplay. In the second chart, you can see that after integration, throttling didn’t occur until around 22 minutes.

Graph showing high graphic quality setting measuring thermal headroom against thermal warning level in frames-per-second

Graph showing enabled android adaptability measuring thermal headroom against thermal warning level in frames-per-second

Kakao Games also wanted to reduce device heating, which they knew wasn’t possible with a continuously high graphic quality setting. The best practice is to gradually lower the graphical fidelity as device temperature increases to maintain a constant framerate and thermal equilibrium. So Kakao Games created a six-step change sequence with Android Adaptability, offering stable FPS and lower device temperatures. Automatic changes in fidelity are reflected in the in-game graphic quality settings (resolution, texture, shadow, effect, etc.) in the settings menu. Because some users want the highest graphic quality even if their device can’t sustain performance at that level, Kakao Games gave them the option to manually disable Unity Adaptive Performance.

Get started with Android Adaptability

Android Adaptability and Unity Adaptive Performance is now available to all Android game developers using the Android provider on most Android devices after API level 30 (thermal) and 31 (performance Hint API). Developers are able to use the Android provider from the Adaptive Performance 5.0.0 version. The thermal APIs are integrated with Adaptive Performance to help developers easily retrieve device thermal information and the performance Hint API is called every Update() automatically without any additional work.

Learn how Android Adaptability and Unity Adaptive Performance can help you stabilize your game’s FPS and reduce thermal throttling.

Celebrating 25 years of Google Search: developer trends and history

Posted by Google for Developers

This month, Google Search turns 25. A lot has changed over the last quarter of a century when it comes to the development space, but one thing has remained a constant - whether you’re stuck on a problem, reading documentation, learning about new technology, or figuring out the best tech stack for your project, Search has been a helpful tool in getting your questions answered.

What you searched for is a strong signal when it comes to developer trends across web, mobile, cloud, and AI over the years. Let’s take a look at some of the interesting things you’ve looked up* – and some funny queries too – because everyone loves a good retrospective.

*Note: Google Trends data goes as far back as 2004.


Building a better web

After the internet dot-com bubble popped in 2000–2001, the web continued to advance and the internet exploded. Web development responded by enabling designers to incorporate multimedia into web pages. Cascading Style Sheets (CSS) (released in 1997) and Flash video (1996-2017) changed the way web pages looked and moved, and streaming changed the way people consumed video. However, the basic interface and structure of the web page remained the same. With the variety of browsers that came to market, JavaScript frameworks and libraries rose along since it can be run everywhere with both CSS and HTML. All these shifts led to some fun searches.

How to center a div

You can’t think of web development without CSS. And it turns out, “how to center a div” has been searched for from the beginning - it’s also provided the internet with a wealth of memes over the years.

JavaScript libraries

JavaScript is a front-end programming language that is used to add interactivity and dynamic behavior to web pages. It is one of the most popular programming languages in the world, and it is essential for building modern web applications. But at some point, most developers have to ask themselves what kind of JavaScript they should use. Vanilla? A framework? A library?

Starting in 2007 there was an uptick of searches for jQuery, which peaked in 2013 and started to fall after that. Meanwhile, developers started to show more interest in React and Angular right around the same time as jQuery’s peak. By April of 2018 they all had a similar volume of searches, and soon after React took over, followed by Angular. Nigeria searched for React the most, while Japan preferred jQuery, and Ecuador preferred Angular. Nowadays, the choice of JavaScript framework is the subject of a lot of controversy - what's your favorite? Share your thoughts with us.

Graph showing search term volume for “React”,” jQuery”, and “Angular” from 2004-present day
Search term volume for “React”,” jQuery”, and “Angular” from 2004-present day


The rise of mobile

As the web improved, so did mobile. Phones went from cellular to smart. The app economy blossomed. Due to low infrastructure and financial restraints, many emerging markets in Asia, Africa, and Latin America skipped the desktop era in favor of mobile to get their information and entertainment. Mobile development –Android in particular– kicked into high gear as a response.

Android development

Starting in 2007, Android was released as a developer platform before devices were on the market, along with the first Android Developer Challenge which launched to support and recognize developers who build great applications. In 2008, the Android OS was released and open sourced, along with T-Mobile’s G1 as the first smartphone to run Android. That same year, the Android Market was released, allowing developers an easy way to distribute apps to the Android community. In 2012, the marketplace got rebranded to Google Play. All of this momentum helped add to the frenzy, but searches really took off starting in 2012.

Graph of search term volume for “Android development” from 2007-2012
Search term volume for “Android development” from 2007-2012

Mobilegeddon

Even web developers couldn’t escape the importance of mobile in its heyday. By 2010, “mobile-first” and “responsive design” became best practices for the web in order to support mobile traffic. As a response to the clear indication that mobile wasn’t going anywhere, by 2015, Google’s search ranking algorithm changed to favor content that is mobile-friendly. Dubbed ‘Mobilegeddon’ by Chuck Price in a post written on Search Engine Watch, developers quickly searched for the term and adjusted their best practices such as responsive and mobile-first design. By 2017, mobile traffic accounted for approximately half of web traffic worldwide before permanently surpassing it in 2020.


Moving to the cloud

Over the last 25 years, cloud development has evolved from a niche technology to a mainstream solution for organizations of all sizes. Being free from managing infrastructure and operations provides a number of advantages like cost savings, speed, and scalability. In the early days, it was mainly used for hosting static websites and applications. But as technology matured, it became increasingly popular for a wider range of applications, including IoT, big data, real-time data, and ML in addition to more modern development practices like containers, microservices, and security.

Cloud computing

As development continued to modernize, developers, IT, and operations figured out fairly quickly that managing infrastructure and servers was painful and expensive. In response, many cloud environment providers launched between 2002-2010, including Google Cloud Platform.

Graph of search term volume for “cloud computing” from 2004-2012
Search term volume for “cloud computing” from 2004-2012

Cloud databases

Cloud services extend to storage, databases, and so much more – a necessity as technology becomes more robust, supporting large amounts of data in real time from IoT devices or use cases like ML and large language models. While there were searches for the term “cloud database” as far back as 2004, it spiked in 2017, coinciding with Google Cloud’s Cloud Spanner. And with the latest renaissance of AI technology, it’s pretty likely that this search term will keep going up in the coming months and years.


Present day innovations

Disruptive developer technology like artificial intelligence and machine learning are infused in development today. From AI-assisted coding to solving problems leveraging big data, AI is permeating our lives. So it’s no wonder developers are searching for some key terms.

Artificial intelligence, machine learning, and more

While some applications of AI, ML, deep learning, large language models (LLMs) are new, most of the terms aren’t. Even in 2004, AI and ML were search terms of interest. In 2015, most of these terms started to pick back up and continue to trend upwards, with a sheer spike in interest in 2022. That same year, ‘generative AI’ was formally introduced to the world. Python is the most searched coding language closely associated with AI, becoming the most popularly searched language in 2019, finally surpassing Java.

Graph of search term volume for “artificial intelligence”, “machine learning”, “deep learning”, and “generative AI” from 2004-present day
Search term volume for “artificial intelligence”, “machine learning”, “deep learning”, and “generative AI” from 2004-present day

Looking ahead

While some aspects of development have gotten progressively cleaner, more modern, and more lightweight - there’s now more choice and complexity when it comes to your tech stack. So it’s no wonder “why is my code not working” spiked in both the early days and today. At Google, we’ll do our best to help streamline and simplify technology to help you build smarter and ship faster with new technology like Project IDX, Android Studio Bot, and coding for Bard.

Graph of search term volume for “why is my code not working?” from 2004-present day
Search term volume for “why is my code not working?” from 2004-present day

It’s inspiring to see what you have done with the answers to your questions, whether you’re trying to solve specific problems, learning new skills or best practices, figuring out what technology you want to use, or dreaming up your next big idea. We look forward to seeing what the next 25 years bring.

Follow more developer trends and insights on Google for Developers across YouTube, LinkedIn, and Instagram.

Latest ARTwork on hundreds of millions of devices

Posted by Serban Constantinescu, Product Manager

Wouldn’t it be great if each update improved start-up times, execution speed, and memory usage of your apps? Google Play system updates for the Android Runtime (ART) do just that. These updates deliver performance improvements, the latest security fixes, and unify the core OpenJDK APIs across hundreds of millions of devices, including all Android 12+ devices and soon Android Go.

ART is the engine behind the Android operating system (OS). It provides the runtime and core APIs that all apps and most OS services rely on. Both Java and Kotlin are compiled down to bytecode executed by ART. Improvements in the runtime, compiler and core API benefit all developers making app execution faster and bytecode compilation more efficient.

While parts of Android are customizable by device manufacturers, ART is the same for all devices and Google Play system updates enable a path to modular updates.

Modularizing the OS

Android was originally designed for monolithic updates, which meant that OS components did not need to have clear API boundaries. This is because all dependent software would be built together. However, this made it difficult to update ART independently of the rest of the OS. Our first challenge was to untangle ART's dependencies and create clear, well-defined, and tested API boundaries. This allowed us to modularize ART and make it independently updatable.

Illustration of a racecar with an engine part hovering above the hood. A curved arrow points to where this part should go

As a core part of the OS, ART had to blaze new trails and engineer new OS boundaries. These new boundaries were so extensive that manually adding and updating them would be too time-consuming. Therefore, we implemented automatic generation of those through introspection in the build system.

Another example is stack unwinding, which reports the functions last executed when an issue is detected. Before modularizing the OS, all stack unwinding code was built together and could change across Android versions. This made the transition even more challenging, since there is only one version of ART that is delivered to many versions of Android, we had to create a new API boundary as well as design it to be forward-compatible with newer versions of the ART APEX module on devices that are no longer getting full OS updates.

Recently, for Android 14, we refactored the interface between the Package Manager, the service that determines how to install and update apps, and ART. This moves the OS boundary from the ART dex2oat command line to a well-defined interface that enables future optimizations, such as finer-grained control over the compilation mode.

ART updatability also introduced new challenges. For example, the collection of Java libraries, referred to as the Boot Classpath, had to be securely recompiled to ensure good performance. This required introducing a new secure state for compilation during boot as well as a fallback JIT compilation mode.

On older devices, the secure compilation happens on the first reboot after an ART update. On newer devices that support the Android Virtualization Framework, the compilation happens while the device is idle, in an enclave called Isolated Compilation – saving up to 20 seconds of boot-time.

Testing the ART APEX module

The ART APEX module is a complex piece of software with an order of magnitude more APIs than any other APEX module. It also backs a quarter of the developer APIs available in the Android SDK. In addition, ART has a compiler that aims to make the most of the underlying hardware by generating chipset-specific instructions, such as Arm SVE. This, together with the multiple OS versions on which the ART APEX module has to run, makes testing challenging.

We first modularized the testing framework from per-platform release (e.g. Android CTS) to per module. We did this by introducing an ART-specific Mainline Test Suite (MTS), which tests both compiler and runtime, as well as core OpenJDK APIs, while collecting code coverage statistics.

Our target is 100% API coverage and high line coverage, especially for new APIs. Together with HWASan and fuzzing, all of the tests described above contribute to a massive test load that needs to be sharded across multiple devices to ensure that it completes in a reasonable amount of time.

Illustration of modularized testing framework

We test the upcoming ART release every day by compiling over 18 million APKs and running app compatibility tests, and startup, performance, and memory benchmarks on a variety of Android devices that replicate the diversity of our ecosystem as closely as possible. Once tests pass with all possible compilation modes, all Garbage Collector algorithms, and supported OS versions, we begin gradually rolling out the next ART release.

Benefits of ART Google Play system updates

By updating ART independently of OS updates, users get the latest performance optimizations and security fixes as quickly as possible, while developers get OpenJDK improvements and compiler optimisations that benefit both Java and Kotlin.

As shown in the graph below, the runtime and compiler optimizations in the ART 13 update delivered real-world app start-up improvements of up to 30% on some devices.

Graph of average app startup time showing startup time in milliseconds with improvement up to 30% across 12 weeks on devices running the latest ART Google Play system update

ART updates allow us to frequently deploy fixes with little additional effort from our ecosystem partners. They include propagating upstream OpenJDK fixes to Android devices as quickly as possible, as well as runtime and compiler security fixes, such as CVE-2022-20502, which was detected by our automated fuzzing tests.

For developers, ART updates mean that you can now target the latest programming features. ART 13 delivered OpenJDK 11 core language features, which was the fastest-ever adoption of a new OpenJDK release on Android devices.

What’s next

In the coming months, we'll be releasing ART 14 to all compatible devices. ART 14 includes OpenJDK 17 support along with new compiler and runtime optimizations that improve performance while reducing code size. Stay tuned for more details on ART 14!

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Choosing the right storage experience

Posted by Yacine Rezgui - Developer Relations Engineer

The upcoming stable release of Android 14 is fast approaching. Now is a great time to test your app with this new release’s changes if you haven’t done so already. With Platform Stability, you can even submit apps targeting SDK 34 to the Google Play Store.

Android 14 introduces a new feature called Selected Photos Access, allowing users to grant apps access to specific images and videos in their library, rather than granting access to all media of a given type. This is a great way for users to feel more comfortable sharing media with apps, and it's also a great way for developers to build apps that respect user privacy.

Image in four panels showing Select Photos Access being used to share media from the user's on-device library
To ease the migration for apps that currently use storage permissions, apps will run in a compatibility mode. In this mode, if a user chooses “Select photos and videos” the permission will appear to be granted, but the app will only be able to access the selected photos. The permission will be revoked when your app process is killed or in the background for a certain time (similar to one time permissions). When the permission is once again requested by your app, users can select a different set of pictures or videos if they wish. Instead of letting the system manage this re-selection, it’s recommended for apps to handle this process to have a better user experience.

Image in four panels showing media reselection being used to update user's choice of which media to be shared

Choosing the right storage experience

Even when your app correctly manages media re-selection, we believe that for the vast majority of apps, the permissionless photo picker that we introduced last year will be the best media selection solution for both user experience and privacy. Most apps allow users to choose media to do tasks such as attaching to an email, changing a profile picture, sharing with friends, and the Android photo picker's familiar UI gives users a consistent, high-quality experience that helps users grant access in confidence, allowing you to focus on the differentiating features of your app. If you absolutely need a more tightly integrated solution, integrating with MediaStore can be considered as an alternative to the photo picker.


Android photo picker

Image of My Profile page on a mobile device

To use the photo picker in your app, you only need to register an activity result:

// Using Jetpack Compose, you should use rememberLauncherForActivityResult instead of registerForActivityResult // Registers a photo picker activity launcher in single-select mode val pickMedia = registerForActivityResult(PickVisualMedia()) { uri -> // Callback is invoked after the user selects a media item or closes the photo picker if (uri != null) { Log.d("PhotoPicker", "Selected URI: $uri") } else { Log.d("PhotoPicker", "No media selected") } }

The photo picker allows customization of media type selection between photos, videos, or a specific mime type when launched:

// Launch the photo picker and let the user choose images and videos. pickMedia.launch(PickVisualMediaRequest(PickVisualMedia.ImageAndVideo)) // Launch the photo picker and let the user choose only images. pickMedia.launch(PickVisualMediaRequest(PickVisualMedia.ImageOnly)) // Launch the photo picker and let the user choose only videos. pickMedia.launch(PickVisualMediaRequest(PickVisualMedia.VideoOnly)) // Launch the photo picker and let the user choose only images/videos of a // specific MIME type, like GIFs. pickMedia.launch(PickVisualMediaRequest(PickVisualMedia.SingleMimeType("image/gif")))

You can set a maximum limit when allowing multiple selections:

// Registers a photo picker activity launcher in multi-select mode. // In this example, the app lets the user select up to 5 media files. val pickMultipleMedia = registerForActivityResult(PickMultipleVisualMedia(5)) { uris -> // Callback is invoked after the user selects media items or closes the // photo picker. if (uris.isNotEmpty()) { Log.d("PhotoPicker", "Number of items selected: ${uris.size}") } else { Log.d("PhotoPicker", "No media selected") } }

Lastly, you can enable the photo picker support on older devices from Android KitKat onwards (API 19+) using Google Play services, by adding this entry to your AndroidManifest.xml file:

<!-- Prompt Google Play services to install the backported photo picker module --> <service android:name="com.google.android.gms.metadata.ModuleDependencies" android:enabled="false" android:exported="false" tools:ignore="MissingClass"> <intent-filter> <action android:name="com.google.android.gms.metadata.MODULE_DEPENDENCIES" /> </intent-filter> <meta-data android:name="photopicker_activity:0:required" android:value="" /> </service>

In less than 20 lines of code you have a well-integrated photo/video picker within your app that doesn’t require any permissions!


Creating your own gallery picker

Creating your own gallery picker requires extensive development and maintenance, and the app needs to request storage permissions to get explicit user consent, which users can deny, or, as of Android 14, limit access to selected media.

First, request the correct storage permissions in the Android manifest depending on the OS version:

<!-- Devices running up to Android 12L --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32" /> <!-- Devices running Android 13+ --> <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" /> <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" /> <!-- To handle the reselection within the app on Android 14+ (when targeting API 33+) --> <uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />

Then, the app needs to request the correct runtime permissions, also depending on the OS version:

val requestPermissions = registerForActivityResult(RequestMultiplePermissions()) { results -> // Handle permission requests results // See the permission example in the Android platform samples: https://github.com/android/platform-samples } if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { requestPermissions.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_VISUAL_USER_SELECTED)) } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { requestPermissions.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VIDEO)) } else { requestPermissions.launch(arrayOf(READ_EXTERNAL_STORAGE)) }

With the Selected Photos Access feature in Android 14, your app should adopt the new READ_MEDIA_VISUAL_USER_SELECTED permission to control media re-selection, and update your app’s UX to let users grant your app access to a different set of images and videos.

When opening the selection dialog, photos and/or videos will be shown depending on the permissions requested: if you're requesting the READ_MEDIA_VIDEO permission without the READ_MEDIA_IMAGES permission, only videos would appear in the UI for users to select files.

// Allowing the user to select only videos requestPermissions.launch(arrayOf(READ_MEDIA_VIDEO, READ_MEDIA_VISUAL_USER_SELECTED))

You can check if your app has full, partial or denied access to the device’s photo library and update your UX accordingly. It's even more important now to request these permissions when the app needs storage access, instead of at startup. Keep in mind that the permission grant can be changed between the onStart and onResume lifecycle callbacks, as the user can change the access in the settings without closing your app.

if ( Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU && ( ContextCompat.checkSelfPermission(context, READ_MEDIA_IMAGES) == PERMISSION_GRANTED || ContextCompat.checkSelfPermission(context, READ_MEDIA_VIDEO) == PERMISSION_GRANTED ) ) { // Full access on Android 13+ } else if ( Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE && ContextCompat.checkSelfPermission(context, READ_MEDIA_VISUAL_USER_SELECTED) == PERMISSION_GRANTED ) { // Partial access on Android 14+ } else if (ContextCompat.checkSelfPermission(context, READ_EXTERNAL_STORAGE) == PERMISSION_GRANTED) { // Full access up to Android 12 } else { // Access denied }

Once you verified you have access to the right storage permissions, you can interact with MediaStore to query the device library (whether the granted access is partial or full):

data class Media( val uri: Uri, val name: String, val size: Long, val mimeType: String, val dateTaken: Long ) // We run our querying logic in a coroutine outside of the main thread to keep the app responsive. // Keep in mind that this code snippet is querying all the images of the shared storage suspend fun getImages(contentResolver: ContentResolver): List<Media> = withContext(Dispatchers.IO) { val projection = arrayOf( Images.Media._ID, Images.Media.DISPLAY_NAME, Images.Media.SIZE, Images.Media.MIME_TYPE, ) val collectionUri = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { // This allows us to query all the device storage volumes instead of the primary only Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL) } else { Images.Media.EXTERNAL_CONTENT_URI } val images = mutableListOf<Media>() contentResolver.query( collectionUri, projection, null, null, "${Images.Media.DATE_ADDED} DESC" )?.use { cursor -> val idColumn = cursor.getColumnIndexOrThrow(Images.Media._ID) val displayNameColumn = cursor.getColumnIndexOrThrow(Images.Media.DISPLAY_NAME) val sizeColumn = cursor.getColumnIndexOrThrow(Images.Media.SIZE) val mimeTypeColumn = cursor.getColumnIndexOrThrow(Images.Media.MIME_TYPE) while (cursor.moveToNext()) { val uri = ContentUris.withAppendedId(collectionUri, cursor.getLong(idColumn)) val name = cursor.getString(displayNameColumn) val size = cursor.getLong(sizeColumn) val mimeType = cursor.getString(mimeTypeColumn) val dateTaken = cursor.getLong(4) val image = Media(uri, name, size, mimeType, dateTaken) images.add(image) } } return@withContext images }

The code snippet above is simplified to illustrate how to interact with MediaStore. In a proper production app, you should consider using pagination with something like the Paging library to ensure good performance.

You may not need permissions

As of Android 10 (API 29), you no longer need storage permissions to add files to shared storage. This means that you can add images to the gallery, record videos and save them to shared storage, or download PDF invoices without having to request storage permissions. If your app only adds files to shared storage and does not query images or videos, you should stop requesting storage permissions and set a maxSdkVersion of API 28 in your AndroidManifest.xml:

<!-- No permission is needed to add files from Android 10 --> <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="28" />

ACTION_GET_CONTENT behavior change

In our last storage blog post, we announced that we’ll be rolling out a behavior change whenever ACTION_GET_CONTENT intent is launched with an image and/or video mime type. If you haven’t tested yet this change, you can enable it manually on your device:

adb shell device_config put storage_native_boot take_over_get_content true

That covers how to offer visual media selection in your app with the privacy-preserving changes we've made across multiple Android releases.If you have any feedback or suggestions, submit tickets to our issue tracker.

Introducing Jetpack Emoji Picker: A New Way to Add Emojis to Your Android App

Posted by Lin Guo, Software Engineer

The use of emojis in communication has become increasingly popular in recent years. These small icons can be used to express a wide range of emotions and can add a personal touch to messages. However, adding emojis to your Android app can be a bit of a challenge. That's where the Emoji picker library comes in. You can simply add a few lines of code to your app, and you'll be able to start using emojis right away. It's the easiest way to get started with emojis, and it will make your app more fun and expressive.

Moving image of using EmojiPicker on Google Pixel 6 Pro
Figure 1. Emoji Picker

Some useful features provided by the library

Up-to-date emojis without tofu (☐)

Every year, new emoji versions are published, and we will regularly update the library to provide these new emojis. Higher-end phones will be able to render these newer emojis without any problem. For lower-end phones, newer emoji may be displayed as a small square box called tofu (☐). The library guarantees to detect and remove them. This ensures the library is compatible across multiple Android versions/devices.

Smooth UI

The library has several optimizations that attempt to reduce startup latency and speed up scrolling experience, such as caching renderable emojis, drawing emojis asynchronously and RecyclerView optimizations.

Personalized inclusive experience

User selections are persistent in the library. Emojis that are newly chosen will be shown at the top row, making it simpler for users to find and share them. The library also offers a variety of emojis that represent different people and cultures in the variant panels. If the user chooses an emoji from one of the variation panels (Figure 2), the choice is retained and set as the default in the main panel.

Image showijng diversity of characters to choose from in EmojiPicker
Figure 2. Emoji variants

Integrate emoji picker into your app in 3 steps

 Step 1: Import the library in build.gradle 
dependencies { implementation "androidx.emoji2:emojipicker:$version" }

Step 2: Inflate the EmojiPickerView

Optionally set emojiGridColumns and emojiGridRows based on the desired size of each emoji cell

An example that uses EmojiPickerView in XML
<androidx.emoji2.emojipicker.EmojiPickerView … app:emojiGridColumns="9" />

A very simple emoji picker should now be presented on your app! For the next step, we assume you would like to do something to the picked emoji.


Step 3: Provide listener to the picked emoji
// a listener example emojiPickerView.setOnEmojiPickedListener { findViewById<EditText>(R.id.edit_text).append(it.emoji) }

Now you have a basic functioning emoji picker. To customize it further (e.g, override some styles or provide a different behavior to the recent emoji row), please refer to our api and sample app.

Feel free to file Bug Report or Feature Request to help us improve the library!

Try the K2 compiler in your Android projects

Posted by Márton Braun, Developer Relations Engineer

The Kotlin compiler is being rewritten for Kotlin 2.0. The new compiler implementation–codenamed K2–brings with it significant build speed improvements, compiling Kotlin code up to twice as fast as the original compiler. It also has a more flexible architecture that will enable the introduction of new language features after 2.0.

Try the new compiler

With Kotlin 1.9, K2 is now available in Beta for JVM targets, including Android projects. To help stabilize the new compiler and make sure you’re ready for Kotlin 2.0, we encourage you to try compiling your projects with the new compiler. If you run into any issues, you can report them on the Kotlin issue tracker.

To try the new compiler, update to Kotlin 1.9 and add the following to your project’s gradle.properties file:
kotlin.experimental.tryK2=true

Note that the new compiler should not be used for production builds yet. A good approach for trying it early is to create a separate branch in your project for compiling with K2. You can find an example of this in the Now in Android repository.

Tooling support

Plugins and tools that depend on the Kotlin compiler frontend will also have to be updated to add support for K2. Some tools already have experimental support for building with K2: the Jetpack Compose compiler plugin supports K2 starting in 1.5.0, which is compatible with Kotlin 1.9.

Android Lint also supports K2 starting in version 8.2.0-alpha12. To run Lint on K2, upgrade to this version and add android.lint.useK2Uast=true to your gradle.properties file. Note that any custom lint rules that rely on APIs from the old frontend will have to be updated to use the analysis API instead.

Adding K2 support in other tools is still in progress: KSP and KAPT tasks currently fall back to using the old compiler when building your project with K2. However, compilation tasks can still run using K2 when these tools are used.

Android Studio also relies on the Kotlin compiler for code analysis. Until Android Studio has support for K2, building with K2 might result in some discrepancies between the code analysis of the IDE and command line builds in certain edge cases.

If you use any additional compiler plugins, check their documentation to see whether they are compatible with K2 yet.

Get started with the K2 compiler today

The Kotlin 2.0 Compiler offers significant improvements to help you ship updates faster, be more productive, and spend more time focusing on what makes your app unique.

It already works with Jetpack Compose and we have a roadmap to improve support in other tools, including Android Studio, KSP, and compiler plugins. Now is a great time to try it in your app's codebase and provide feedback related to Kotlin, Compose, or Lint.