Author Archives: Android Developers

Raising the bar on technical quality on Google Play

Posted by Lauren Mytton, Group Product Manager, Google Play App quality is the foundation of everything we do at Google Play. Android users expect a great experience from the apps and games they download, so we’re making higher-quality titles more visible on the Play Store, as well as steering users away from lower-quality ones. Some apps and games that don’t meet our quality bar will be excluded from prominent discovery surfaces such as recommendations, while others may display a warning on their store listing to set appropriate user expectations.

One of the most important ways to boost your app quality and attract more users is to focus on technical quality. In this post, we’ll explain how Google Play is evolving its definition of technical quality to be more aligned to user experience, and introduce new features in Android vitals to help you monitor and act on technical issues or opportunities.

1. Aligning our definition of technical quality with user experience

Android vitals is your one-stop destination for monitoring technical quality on Google Play, including stability and performance metrics from the field. The most important metrics are called core vitals, and they affect the visibility of your app on Google Play.

[UPDATED] Core vitals metrics
Moving forward, we’re replacing the existing core vitals metrics with new, more user-focused metrics. We believe these metrics are a better reflection of user experience, and we’ve seen a stronger correlation with uninstalls.
New Core Vitals User-perceived crash rate The percentage of daily active users who experienced at least one crash that is likely to have been noticeable (e.g. in the foreground) User-perceived ANR rate The percentage of daily active users who experienced at least one ANR that is likely to have been noticeable (e.g. after user input)

[CONTINUED] Overall bad behavior threshold
To improve quality across the board, we will continue to enforce an overall bad behavior threshold. The overall threshold will use the new metrics, but remain unchanged at 1.09% for user-perceived crash rate, and 0.47% for user-perceived ANR rate. To maximize your title’s visibility on Google Play, it’s important to stay below these thresholds.

[NEW] Quality bar per phone model
Technical quality can vary across devices. For example, an app can be stable and smooth on one phone model, but not another. To account for this, we are introducing a new bad behavior threshold that is evaluated per phone model (e.g. Pixel 6). At launch, this threshold will be set to 8% for both user-perceived crash rate and user-perceived ANR rate.


GOOGLE PLAY’S APP QUALITY BAR
To maximize visibility on Google Play, keep your app below these thresholds.
Core vital

Overall (across all devices)

Per phone model

User-perceived crash rate1.09%8%
User-perceived ANR rate

0.47%8%


If your title exceeds the device bad behavior threshold on any core vital for a given phone model, then Google Play may reduce the visibility of your title for users on that phone model. For example, we may exclude the title from some discovery surfaces, and in some cases, we will show a warning on your store listing to indicate to users that your app may not work properly on their phone. The Play Store will start applying store listing warnings on November 30, 2022.
Screen shot of a phone screen showing a store listing warning that the app shown, Soccer Winner 2021, may not work properly on the device based on recent data from similar devices
Users may see a store listing warning if a title has a user-perceived crash rate or user-perceived ANR rate above 8% on their phone model starting November 30, 2022. Note that the warning text is subject to change.

2. New tools to help you monitor and act on technical issues

To help you meet these new quality guidelines, we’ve launched a number of new features in Android vitals to make it easier to monitor and act on any issues.

Monitor the new user-perceived crash and ANR rate metrics in Play Console, or using the API
The new metrics are available in Play Console in Android vitals, and also in the Play Developer Reporting API. The existing metrics remain available for context.

Stay on top of overall and per-phone model technical quality with Android vitals
You can monitor how your title is doing against overall bad behavior thresholds in Android vitals. In addition, Android vitals will warn you if you are exceeding the per-phone model threshold. It will also tell you which phones, and how many users, are affected.

Prioritize and address overall and per-phone model technical quality issues with new features in Android vitals
To understand the causes of technical quality issues on your user-perceived crash and ANR rates, look at the underlying crash and ANR clusters that contribute to these rates. You can view these in the Crashes and ANRs page in Android vitals - both overall, or on for any specific phone model. Address the issues affecting most users first to reduce your issue rate more quickly.

Sometimes, specific aspects of device hardware or software can contribute to your issue rates. To help you catch and resolve those issues, we’ve launched a new feature in Android vitals that will notify you if we find any potential associations. You can also explore associations yourself on the Reach and devices overview page.

Your user-perceived crash rate is particularly high on Android 10 Your user-perceived crash rate on Android 10 (3.74%) is significantly higher than your overall user-perceived crash rate (2.22%). This Android version represents 44% of your total installs. Reduce user-perceived crashes on this Android version to improve your overall user-perceived crash rate. Show this Android version View in Reach and devices Dismiss
Android vitals will alert you of issues potentially associated with device hardware or software.

When prioritizing per-phone model quality issues to tackle, take into account both existing users, and the opportunity cost or impact on new users. To help you do this, we have launched one-click access to consolidated device information in Play Console, including install base, revenue, ratings and reviews. This information is displayed in a side panel so you don’t have to leave the page that you’re on.

Screen shot of the Play Console showing the new side panel with device infromation such as ratings and reviews
A new side panel in Play Console provides consolidated device information in context.

3. What to do now

Ensure the relevant people have access to Android vitals. The new quality metrics are live in Android vitals, and any overall or per-phone technical quality issues will be shown there. We recommend that you review Android vitals regularly in Play Console, or that you integrate with the Play Developer Reporting API to incorporate data directly into your own workflows. For more information, check out the Android developer site.

Although we’re starting at 8%, we’d like developers to aim for per-phone stability metrics that are no worse than 2%. With that in mind, you should expect the per phone model threshold to become lower in the first half of 2023. In the future, we may also extend our quality bar to include new metrics that reflect other important aspects of the user experience. We will provide you with advance notice of any changes.

Users expect great experiences on their devices, and developers who deliver on their expectations will achieve greater success on Google Play. While these updates were designed to help both users and developers to avoid the worst experiences, our long-term focus is to increase the number of great user experiences. To do this requires investment in other aspects of technical quality beyond crashes and ANRs, as well as investment in non-technical aspects of quality. Keep an eye out for more on this topic in the coming months.

Supporting and rewarding great Apps and Games on Google Play

Posted by Tom Grinsted, Group Product Manager, Google Play

Supporting and rewarding great Apps and Games on Google Play

At Google Play, our mission is to facilitate relationships between Android users and app and game developers, enabling tens of thousands of businesses worldwide to grow and thrive in the mobile ecosystem. Every day, together, we help billions of people discover engaging, helpful, and enriching experiences on their devices, which is why we care so deeply about the quality of the experience we offer on the Play Store.

To do that, we’re constantly developing new ways to promote and support high-quality titles throughout the entire lifecycle, from acquisition and engagement to retention and reacquisition. Over the coming months, we’re rolling out enhancements to Google Play and Google Play Console that embed your key events, content, and offers across the Google Play experience. These changes are designed to help you reach more people, improve discovery of higher-quality titles, and optimize your presence for the greatest possible impact.

To help you navigate these updates, we’re sharing our key thinking and direction early, and launching new features to help power your growth across your users’ lifecycle with you. So read on!

Powering developer success across the lifecycle

As a partner, we’re focused on helping developers succeed. In today's app ecosystem, where loyalty and re-engagement are more top of mind than ever before, we’re creating even more opportunities for developers to use our surfaces to not only find first-time users but also to engage, and re-acquire them. 

For select titles, LiveOps is a key channel to reach users directly on Google Play with great offers, launches, and events. LiveOps has helped titles like Rise of Kingdoms, Paramount+, and MyFitnessPal add exciting new content that inspire discovery, re-engagement, and monetization. On average, developers using LiveOps drive +3.6% increase in revenue and a +5.1% increase in 28DAU versus similar titles who don’t. Individual events are already garnering compelling uplifts from Play.

ALT TEXT
Play data: additional growth by a real LiveOp
 Analysis: 90th percentile of over 70 recently run liveOps vs. control groups with 0.9 confidence interval

To accelerate this performance, over the coming months we’re expanding how your content is used on Google Play by creating new high-impact placements and formats. It will become deeply integrated into users’ experiences, from their homepages, through search and discovery, in your title’s listings, and directly into your apps via deep links.
ALT TEXT
New content formats will help users discover and rediscover high-quality content to enjoy. Final design may vary.

To help you take full advantage of the opportunity that content on Play presents, we’re making key changes in Play Console. These start with the renaming of LiveOps to “Promotional Content.” This reflects the breadth of content you can submit to Play today, and new content types we’ll be adding over time. We’ve also updated format guidelines, priority quotas, and now enable bulk data downloads. If you're one of the thousands of titles that already use Promotional Content, look for messages in your Play Console Inbox to find out more. We're looking to expand access to even more apps and games next year.

These changes bring even more opportunities to leverage your events to grow your active audience and revenue. Visibility and promotion across Play are also dependent on the quality of your title and individual content. So make sure you check our updated content guidelines and recommendations.

Driving reacquisitions

Another key part of the lifecycle is bringing back users who’ve tried your title before. As mobile ecosystems continue to mature and developers continue to invest for the long-term, this growth channel is only getting more important.

That’s why we’re introducing Churned-user Custom Store Listings. These enable you to tell a different story to users on Play who’ve tried but uninstalled your apps or games before. Because our store listings power experiences like the overlay you see when interacting with an app ad on YouTube, your custom re-acquisition messages can be seen by users across different Google surfaces.

Over the coming months, we will also look at how Google Play can help enable more reacquisition for great, high-quality titles. Churned-user Custom Store Listings will begin rolling out towards the end of this year and you can express your interest in being one of the first to use them by filling out this form.

Caring about quality - driving acquisitions for high-quality apps and games

We focus on crafting exciting and fresh journeys for users on Play. Among other signals, quality evaluation factors in our teams’ judgements and editorial decisions. Users expect great experiences, and we aim to support titles that deliver on their expectation which is why quality is a key aspect of discovery.

First, we consider in-app quality. We look at a range of factors including: Does your title have a polished design, and content that keeps users engaged for the long term? Is your onboarding experience clear, and are any ads well-integrated? Does your title have intuitive navigation, controls, and menu access? Do you meet the guidelines for functional behavior across all the form factors that you support? And is your title accessible to all users?

Technical quality is another important consideration. It can differ greatly depending on user and device, so we're introducing new more user-focused crash and ANR metrics in Android vitals. These will increasingly influence Play Store treatments—steering users away from titles that are likely to provide a poor experience on their specific devices, and towards ones that may be more suitable. In some cases, a warning could be displayed on store listings.

ALT TEXT
Users may see a store listing warning if a title has a user-perceived crash rate or user-perceived ANR rate above 8% on their phone model starting November 30, 2022. Note that final design and text is subject to change.

We’ll warn you in Android vitals if there’s a risk that your app will get this treatment before it’s visible in Play, so you can take remedial action. Please read our App Quality blog post to learn more.

Finally on the topic of quality, we’re setting a minimum ratings bar of 3.0 stars to improve top charts. We will first launch the ratings change to Top Free charts worldwide and across all form factors in February 2023. Later next year, we plan to bring this change to top paid and grossing charts as well.

Play Console has tools for you to triage your rating, deep dive into top issues users are writing about and respond to reviews directly. Find out more here.

Being transparent about our contributions

As we continue to make Play an even more valuable platform for developers, we want to make sure that you can see the positive impact our surfaces have on your growth. So we’re updating Store Performance reports to better reflect how users discover your titles on Play. This includes more data from off-Play experiences, differentiating paid-for and direct traffic from users’ organic behavior on Play, and the inclusion of key discovery journeys - for instance, searching for categories like ‘Puzzle Games’ - in Explore traffic. Coming soon, we’ll send you a message in Play Console when this update goes live.

All of these changes, along with other exciting features we have in the works, work together. So if you’re invested in the quality of your experiences, evolving your offer, and crafting exciting events and compelling content, Play is the platform and partner to super-charge your growth and success.

Keeping Google Play Safe with New Features and Programs

Posted by Ron Aquino, Senior Director, Trust and Safety, Chrome, Android and Play

Google Play has been the launchpad for millions of developer businesses to connect with consumers around the world as we strive to deliver a safe place to find great apps and games. Our safety initiatives and policies are core ways that we create the trusted experience that users have come to expect. By responsibly evolving these features, policies, and programs, we’re able to help you safely launch new experiences to more than 2.5 billion users in 190 countries around the world.

Today, we’re sharing a number of new features and programs to better partner with you and continue making Google Play a safe platform for everyone.


Protecting your business and your users from risky, unknown traffic

We launched Play Integrity API to all developers earlier this year to help you detect risky, unknown interactions such as from tampered versions of your app or unsupported app environments. You call this API when a user performs an action in your app to check whether it’s your genuine app on a genuine Android device. If something’s off, you can decide what defensive actions to take. Early data show that this feature has helped developers reduce unauthorized usage of their apps by over 50%.

In addition to customizing your API responses and setting up tests in Play Console, we’re launching reporting so you can analyze and break down API responses across your install base. And, soon, you’ll be able to debug Integrity API responses from the Play Store app’s developer settings on any device. This will help you spot issues and refine your anti-abuse strategy. Get started today with the Play Integrity API here.

Introducing new protections against review attacks on Play apps

For you to grow successful businesses and for users to have trustworthy information to help them decide if an app is right for them, it’s critical that app reviews are accurate, relevant, and genuine. Earlier this year, we rolled out a more aggressive program to proactively stop inaccurate, coordinated user attacks on app ratings. Our strengthened system now better detects anomalies and unexplained spikes in low star ratings so that our team can quickly investigate suspicious activity and respond to it. Since this program launched at the start of this year, we have had no major review attacks that materially impacted the ratings of top-downloaded apps. We’ve continued to strengthen the program further by introducing a mandatory 24-hour-delay of all incoming app reviews. Play is also exploring ways to evolve our policy to help ensure the content of app reviews is relevant to the app experience and further elevate trustworthy information on our platform. We'll have more to share soon.



Expanding our program to give developers direct Play Policy support

While we help developers understand our policy changes through a variety of communications and trainings, we heard that you want more direct policy support from Google. Early last year, we started our Google Play Developer Helpline pilot to explore giving developers direct policy support over the phone. By the first half of 2021, we scaled the pilot to 12,000 developers in India and since then, we’ve expanded this offering to 44,000 developers in 17 countries. Today, the Helpline program has completed nearly 4,000 policy support sessions with developers and received a satisfaction score of around 90%. So far, this program has helped developers navigate policy compliance issues. We look forward to further scaling the program to many more of you soon.


Launching the Strike Removal pilot program

Beyond expanded policy support, we also introduced a new program this year to provide developers deeper education on important but commonly misunderstood policy areas. We know that most developers work hard to create and distribute their apps with good intentions, and may sometimes unknowingly violate policies. The Play Strike Removal pilot program provides the opportunity for you to remove an enforcement strike by successfully taking a Play Academy training course and assessment related to the policy violation. We’ve started this program with courses on IP Infringement and Spam policy violations, which account for nearly 2 out of 3 developer suspensions. We hope to add more courses in the future to help you better understand the policies that keep Play safe.


Previewing a more privacy-friendly approach to advertising

As a reminder, Privacy Sandbox for Android is a multi-year initiative to create innovative technologies that will both protect user privacy and give you tools to build thriving digital businesses. These solutions aim to make current tracking mechanisms obsolete and limit covert tracking techniques, like fingerprinting. To do this, we're working on core advertising capabilities that don’t need access to cross-app identifiers, like the Ad ID. You'll be able to use these solutions individually or together to target ads and measure them to create efficient campaigns, all while better protecting user privacy. We’re working in close partnership with the industry and developers. Today, you can test Developer Previews, begin designing integrations, and send us feedback.As a platform, we only succeed when our developers succeed. We work with partners, like you, every day to understand the challenges you face, help launch innovative apps to Google Play, and ensure that the apps remain safe and trusted by our shared users. Thank you for your partnership in making Google Play a safe and trustworthy platform for everyone.

Google Play Games beta on PC continues global expansion

Posted by Arjun Dayal, Director, Google Play Games

Earlier this year, we announced that Google Play Games would be coming to PCs as a beta experience in a limited number of markets. Our goal was to gather early feedback so we could continue improving the product to fit the needs of players and developers around the world. In August, we expanded the product to more players in Korea, Hong Kong, Taiwan, Thailand, and Australia. Beginning today, we’re excited to make Google Play Games beta available for download to all players in the United States, Canada, Mexico, Brazil, Indonesia, Philippines, Malaysia, and Singapore.
Photo of a desktop monitor with keyboard and mouse. On the monitor is the Google Play homepage showing the game Cookie Run Kingdom as the main item ready for install
Google Play Games is available to download in the United States, Canada, Mexico, Brazil, Indonesia, Philippines, Malaysia, and Singapore.
 Subject to game availability and PC compatibility.

In the last few months, our Google Play Games catalog growth has been accelerating with many popular mobile titles including 1945 Air Force, Blade Idle, Cookie Run: Kingdom, and Evony: The King’s Return. All of these titles and dozens more can be played on Windows PCs via a standalone application built by Google.

Our broader goal continues to be meeting players where they are and giving them access to their games on as many devices as possible. Players participating in the beta have expressed excitement at being able to seamlessly play their favorite games across their phones, tablets, Chromebooks, and PCs. Additionally, since launching earlier this year we have made significant strides to reach even more players by reducing the minimum spec requirements to PCs running Windows 10+ with an integrated graphics card and 4+ core CPU.

A phone, Desktop monitor and large tablet screens overlapping side by side while simultanously playing a video trailer for Cookie Run Kingdom. A keyboard and mouse are also visible beneath the screens
Seamless sync across signed-in devices
Subject to game availability and PC compatibility.

We’re thrilled to expand our platform to more markets for players to enjoy their favorite games on Google Play. As we move towards a full release, we will continue to add new features and evaluate developer and player feedback. To sign up for future announcements, or to access the beta in the United States, Canada, Mexico, Brazil, Indonesia, Philippines, Malaysia, Singapore, Korea, Hong Kong, Taiwan, Thailand, or Australia, please go to g.co/googleplaygames. If you’re an Android games developer looking to learn more about Google Play Games, please express interest on our developer site. We’ll have more to share on future beta releases and regional availability soon.

Windows is a trademark of the Microsoft group of companies.
Game titles may vary by region.

Pixel 7, the first 64-bit-only Android phone

Posted by Serban Constantinescu, Product Manager,Pixel 7 and Pixel 7 Pro are the first Android phones to support only 64-bit apps. This configuration drops OS support for 32-bit code, reducing memory usage, improving performance, and enhancing security. Over time, we expect this device configuration to become commonplace.

Thanks to the efforts and collaboration of the entire Android community, our ecosystem is ready. Transitioning Android devices to 64-bit-only required many changes across the platform, tooling, Play, and, of course, your apps. We started by introducing 64-bit support in 2014, announcing policy changes in 2017 and requiring support for Google Play apps starting 2019.

Your device is faster, safer and uses less memory

64-bit apps run faster because they have access to extra registers and instructions that aren't available to 32-bit apps. In addition, newer CPUs deliver up to 25% better performance when running 64-bit code or even drop support for 32-bit code altogether.

64-bit can help improve security. The bigger address space makes defenses like ASLR more effective and the spare bits can be used to protect control flow integrity. These countermeasures may reduce the chance an intruder can take control of your device.

Removing support for 32-bit code saves up to 150MB of RAM, which was used by the OS even when not running 32-bit apps. These memory savings result in fewer out-of-memory conditions meaning less jank and fewer background app kills.

Developers have access to better tools

Developers targeting 64-bit have access to better tools such as HWASan for detecting memory errors and improving the quality of an app.

Faster OS updates for vendors

64-bit-only device configurations halve the CTS testing time. Combined with GKI, vendors can update devices faster and more easily.

Going forward

With 64-bit-only devices now reaching users, we encourage developers to start paying extra attention to testing their apps and updates for 64-bit-only devices. To support this, Google Play now provides pre-launch reports that are run on 64-bit-only devices to detect and report compatibility problems.

Note: While 64-bit-only devices will grow in popularity with phones joining Android Auto in this group, 32-bit-only devices will continue to be important for Android Go, Android TV, and Android Wear. Please continue supporting 32-bit ABIs; Google Play will continue serving 32-bit apps to 32-bit-only devices.

Optimize for Android (Go edition): Lessons from Google apps Part 3

Posted by Niharika Arora, Developer Relations Engineer

In Part 1 and Part 2 of our “Optimizing for Android Go” blog series, we discussed why we should consider building for Android Go and how to optimize your app to perform well on Go devices. In this blog, we will talk about the tools which helped Google optimize their Google apps performance.

Tools

Monitoring Memory

Analyze Memory Footprint 

 1.    To determine the memory footprint for an application, any of the following metrics may be used:
    • Resident Set Size (RSS): The number of shared and non-shared pages used by the app
    • Proportional Set Size (PSS): The number of non-shared pages used by the app and an even distribution of the shared pages (for example, if three processes are sharing 3MB, each process gets 1MB in PSS)
      • Note: Private Set Size (PSS) = Private memory + (shared memory / the number of processes sharing).
    • Unique Set Size (USS): The number of non-shared pages used by the app (shared pages are not included)

PSS is useful for the operating system when it wants to know how much memory is used by all processes since pages don’t get counted multiple times. PSS takes a long time to calculate because the system needs to determine which pages are shared and by how many processes. RSS doesn't distinguish between shared and non-shared pages (making it faster to calculate) and is better for tracking changes in memory allocation.

So, which method should you choose? The choice depends on the usage of shared memory.

For example, if the shared memory is being used by the application only then we should use the RSS approach. While, if the shared memory is taken by the Google Play Services then we should use the USS approach. For more understanding, please read here. 

2.    Take a heap dump and analyze how much memory is utilized by the running processes. Follow
    • Review the Prerequisites. 
      • Developer options Don't keep activities must be OFF. 
      • Use recent release builds for testing.
    • Execute the user journey you desire to measure.
    • Run the following command:
                    adb shell am dumpheap <You Android App Process ID> <output-file-name>
    • In a second terminal, run the following command and wait for message indicating that the “heap dump has completed”:
adb logcat | grep hprof
    • Run:
adb pull <output-file-name> 
 
This will pull the generated file to your machine for analysis.
 
To get info on native heap, read here :

To know about Java heap, read here :

3.    Understand low-memory killer

In Android, we have a process called low memory killer, and this will pick a process from the device and will kill that process when the device is under low RAM, the thresholds can be tuned by OEMs. By doing so, you will get back all the memory that the process was using.
But what if the low memory killer kills the process that the user cares about?
 
In Android, we have a priority list of applications and based on that priority list we remove the app when the low memory killer comes into play. Read more here.

You can run this command and know :
adb shell dumpsys activity oom

To check stats on low memory killer :
adb shell dumpsys activity lmk

For more information, please check Perfetto documentation for Memory.
 

Tools 

 1.    Debug Memory usage using Perfetto
This is one the best tools to find where all your app memory is consumed. Use Perfetto to get information about memory management events from the kernel. Deep dive and understand how to profile native and Java heap here. 
 
2.    Inspect your memory usage using Memory Profiler
The Memory Profiler is a component in the Android Profiler that helps you identify memory leaks and memory churn that can lead to stutter, freezes, and even app crashes. It shows a real time graph of your app's memory use and lets you capture a heap dump, force garbage collections, and track memory allocations. To learn more about inspecting performance, please check MAD skills videos here. 
 
3.    Utilize meminfo
You may want to observe how your app's memory is divided between different types of RAM allocation with the following adb command: 

adb shell dumpsys meminfo <package_name|pid> [-d]


You can view the following seven memory categories with Meminfo:
    • Java heap – memory allocated by Java code
    • Native heap – memory allocated by native code. These are best understood using debug malloc. Allocations made by the application from C or C++ code using malloc or new.
    • Code – memory used for Java, native code and some resources, including dex bytecode, shared libraries and fonts
    • Stack – memory used for both native and Java stacks. This usually has to do with how many threads your application is running.
    • Graphics – Memory used for graphics buffer queues to display pixels to the screen, GL surfaces and textures and such.
    • Private Other – uncategorized private memory
    • System – memory shared with the system or otherwise under the control of the system.

Key memory terms:

    • Private – Memory used only by the process.
    • Shared – System memory shared with other processes.
    • Clean – Memory-mapped pages that can be reclaimed when under memory pressure.
    • Dirty – Memory-mapped page modified by a process. These pages may be written to file/swap and then reclaimed when under memory pressure.

Note :

    • Debug class is super useful and provides different methods for Android applications, including tracing and allocation counts. You can read about usage here.
    • For deeper understanding and tracking allocations for each page, read about page owner here.
4.    Detailed analysis using showmap
The showmap command provides a much more detailed breakdown of memory than friendly meminfo. It lists the name and sizes of memory maps used by a process. This is a summary of the information available at /proc/<pid>/smaps, which is the primary source of information used in dumpsys meminfo, except for some graphics memory.
$adb root
$ adb shell pgrep <process>
Output - process id
$ adb shell showmap <process id>

Sample Output :

 virtual                     shared   shared  private  private

    size      RSS      PSS    clean    dirty    clean    dirty object

-------- -------- -------- -------- -------- -------- -------- ------------------------------

    3048      948      516      864        0       84        0 /data/app/……

    2484     2088     2088        0        0     2084        4 /data/app/……..

     144       72        2       68        4        0        0 /data/dalvik-cache/arm64/system@framework@<...>.art

     216      180        5      176        4        0        0 /data/dalvik-cache/arm64/system@framework@<...>.art

     168      164        8      136       24        0        4 /data/dalvik-cache/arm64/system@framework@<...>.art

      12        8        0        4        4        0        0 /data/dalvik-cache/arm64/system@framework@<...>.art

    1380     1300       73     1100      164        0       36 /data/dalvik-cache/arm64/system@framework@<...>.art

…

Common memory mappings are:

    • [anon:libc_malloc] - Allocations made from C/C++ code using malloc or new.
    • *boot*.art - The boot image. A Java heap that is pre-initialized by loading and running static initializers where possible for common frameworks classes.
    • /dev/ashmem/dalvik-main space N - The main Java heap.
    • /dev/ashmem/dalvik-zygote space - The main Java heap of the zygote before forking a child process. Also known as the zygote heap.
    • /dev/ashmem/dalvik-[free list ] large object space - Heap used for Java objects larger than ~12KB. This tends to be filled with bitmap pixel data and other large primitive arrays.
    • *.so - Executable code from shared native libraries loaded into memory.
    • *.{oat,dex,odex,vdex} - Compiled dex bytecode, including optimized dex bytecode and metadata, native machine code, or a mix of both.
5.    Analyze native memory allocations using malloc debug
Malloc debug is a method of debugging native memory problems. It can help detect memory corruption, memory leaks, and use after free issues. You can check this documentation for more understanding and usage.  
 
6.    Use Address Sanitizer to detect memory errors in C/C++ code
Beginning with Android 27, Android NDK supports Address Sanitizer which is a fast compiler-based tool for detecting memory bugs in native code. ASan detects:
      • Stack and heap buffer overflow/underflow
      • Heap use after free
      • Stack use outside scope
      • Double free/wild free

            ASan runs on both 32-bit and 64-bit ARM, plus x86 and x86-64. ASan's CPU overhead is roughly 2x, code size overhead is between 50% and 2x, and the memory overhead is large (dependent on your allocation patterns, but on the order of 2x). To learn more, read here.

            Camera from the Google team used it and automated the process that would run and get back to them in the form of alerts in case of Asan issues, and found it really convenient to fix memory issues missed during code authoring/review.

            Monitoring Startup

            Analyze Startup

            1.    Measure and analyze time spent in major operations
            Once you have a complete app startup trace, look at the trace and measure time taken for major operations like bindApplication, activitystart etc.

            Look at overall time spent to

              • Identify which operations occupy large time frames and can be optimized
              • Identify which operations consume high time where it is not expected.
              • Identify which operations cause the main thread to be blocked
            2.    Analyze and identify different time consuming operations and their possible solutions
              • Identify all time consuming operations.
              • Identify any operations which are not supposed to be executed during startup (Ideally there are a lot of legacy code operations which we are not aware about and not easily visible when looking at our app code for performance)
              • Identify which all operations are absolutely needed OR could be delayed until your first frame is drawn.
            3.    Check Home activity load time
            This is your app’s home page and often performance will depend on the loading of this page. For most apps, there is a lot of data displayed on this page, spanning multiple layouts and processes running in background. Check the home activity layout and specifically look at the Choreographer.onDraw method of the home activity.
              • Measure time taken for overall operations of measure, draw,inflate,animate etc.
              • Look at frame drops.
              • Identify layouts taking high time to render or measure.
              • Identify assets taking a long time to load.
              • Identify layouts not needed but still getting inflated.

            Tools 

             1.    Perfetto
              • To know CPU usage, thread activity, frame rendering time, Perfetto will be the best tool.
              • Record trace either by using command line or UI tools like Perfetto. Add app package name with the -a tag, to filter data for your app. Some ways to capture trace :
              • Produces a report combining data from the Android kernel, such as the CPU scheduler, disk activity, and app threads.
              • Best when enabled with custom tracing to know which method or part of code is taking how long and then develop can dig deep accordingly.
              • Understand Atrace, and ftrace while analyzing traces through Perfetto.
            2.    App Startup library
            The App Startup library provides a straightforward, performant way to initialize components at application startup. Both library developers and app developers can use App Startup to streamline startup sequences and explicitly set the order of initialization. Instead of defining separate content providers for each component you need to initialize, App Startup allows you to define component initializers that share a single content provider. This can significantly improve app startup time. To find how to use it in your app, refer here. 
             
            3.    Baseline Profiles
            Baseline Profiles are a list of classes and methods included in an APK used by Android Runtime (ART) during installation to pre-compile critical paths to machine code. This is a form of profile guided optimization (PGO) that lets apps optimize startup, reduce jank, and improve performance for end users. Profile rules are compiled into a binary form in the APK, in assets/dexopt/baseline.prof.

            During installation, ART performs Ahead-of-time (AOT) compilation of methods in the profile, resulting in those methods executing faster. If the profile contains methods used in app launch or during frame rendering, the user experiences faster launch times and/or reduced jank. For more information on usage and advantages, refer here.  

            4.    Android CPU Profiler
            You can use the CPU Profiler to inspect your app’s CPU usage and thread activity in real time while interacting with your app, or you can inspect the details in recorded method traces, function traces, and system traces. The detailed information that the CPU Profiler records and shows is determined by which recording configuration you choose:
              • System Trace: Captures fine-grained details that allow you to inspect how your app interacts with system resources.
              • Method and function traces: For each thread in your app process, you can find out which methods (Java) or functions (C/C++) are executed over a period, and the CPU resources each method or function consumes during its execution.
            5.    Debug API + CPU Profiler
            To give apps the ability to start and stop recording CPU profiling and then inspect in CPU profiler is what Debug API is all about. It provides information about tracing and allocation counts the same way using startMethodTracing() and stopMethodTracing().
             

            Debug.startMethodTracing("sample") - Starts recording a trace log with the name you provide


             Debug.stopMethodTracing() - he system begins buffering the generated trace data, until the

             application calls this method.

            Usage

              • Debug API is designed for short intervals or scenarios that are hard to start/stop recording manually. (Used it once to find the lock contention happening due to some library)
              • To generate a method trace of an app's execution, we can instrument the app using the Debug class. This way developers get more control over exactly when the device starts and stops recording tracing information.
            6.    MacroBenchmark
              • Measures Scrolling / Animation rendering time.
              • Use a UiAutomator to trigger a scroll or animation. (It captures frame timing / janks for whatever the app is doing. Scroll and animations are just the easiest ways to produce frames where jank is noticeable)
              • Requires Android 10 or higher to run the tests.
              • Can view traces on Systrace/Perfetto Traces.
              • FrameTimingMetric is the API reporting frame time in ms.
            This sample can be used for app instrumentation. 
             

              • Added in API level 30 and supported in the latest Studio Bumblebee preview (2021.1)
              • Uses simpleperf with customized build scripts for profiling.
              • Simpleperf supports profiling java code on Android >M.
              • Profiling a release build requires one of following:
                • Device to be rooted
                • Android >=O, use a script wrap.sh and make android::debuggable=“true” to enable profiling.
                • Android >=Q, add profileable in manifest flag.

            <profileable android:shell=["true" | "false"] android:enable=["true" | "false"] />

              • Helpful in app instrumentation with Macrobenchmark.
            8.    MicroBenchmark
            The Jetpack Microbenchmark library allows you to quickly benchmark your Android native code (Kotlin or Java) from within Android Studio. The library handles warmup, measures your code performance and allocation counts, and outputs benchmarking results to both the Android Studio console and a JSON file with more detail. Read more here.

            Monitoring App size

            No user wants to download a large APK that might consume most of their Network/Wifi Bandwidth, also most importantly, space inside the mobile device.

            The size of your APK has an impact on how fast your app loads, how much memory it uses, and how much power it consumes. Reducing your app's download size enables more users to download your app.


            Tools

            • Use the Android Size Analyzer
            The Android Size Analyzer tool is an easy way to identify and implement many strategies for reducing the size of your app. It is available as both an Android Studio plugin as well as a standalone JAR
            • Remove unused resources using Lint
            The lint tool, a static code analyzer included in Android Studio, detects resources in your res/ folder that your code doesn't reference. When the lint tool discovers a potentially unused resource in your project, it prints a message like the following example.

            Note : Libraries that you add to your code may include unused resources. Gradle can automatically remove resources on your behalf if you enable shrinkResources in your app's build.gradle file.

            • Native animated image decoding
            In Android 12 (API level 31), the NDK ImageDecoder API has been expanded to decode all frames and timing data from images that use the animated GIF and animated WebP file formats. When it was introduced in Android 11, this API decoded only the first image from animations in these formats. 
             
            Use ImageDecoder instead of third-party libraries to further decrease APK size and benefit from future updates related to security and performance. 
             
            For more details on the API, refer to the API reference and the sample on GitHub.
            • Crunch PNG files using aapt
            The aapt tool can optimize the image resources placed in res/drawable/ with lossless compression during the build process. For example, the aapt tool can convert a true-color PNG that does not require more than 256 colors to an 8-bit PNG with a color palette. Doing so results in an image of equal quality but a smaller memory footprint. Read more here.

            Note : Please check Android developer documentation for all the useful tools which can help you identify and help fix such performance issues.

            Recap

            This part of the blog captures the tools used by Google to identify and fix performance issues in their apps. They saw great improvements in their metrics. Most Android Go apps could benefit from applying the strategies described above. Optimize and make your app delightful and fast for your users!

            Better Device Compatibility with CameraX

            Posted by The Android Team CameraX is an Android Jetpack library that makes it easy to incorporate camera functionality directly in your Android app. That’s why we focus heavily on device compatibility out-of-the-box, so you can focus on what makes your app unique.

            In this post, we’ll look at three ways CameraX makes developers’ lives easier when it comes to device compatibility. First, we’ll take a peek into our CameraX Test Lab where we test over 150 physical phones every day. Second, we’ll look at Quirks, the mechanism CameraX uses to automatically handle device inconsistencies. Third, we’ll discuss the ways CameraX makes it easier to develop apps for foldable phones.


            CameraX Test Lab

            A single rack in our CameraX Test Lab on the left, and on the right, a moving image of the inside of a test inclusure with rotating phone mount 
            (Left) A single rack in our CameraX Test Lab. Each test enclosure contains two identical Android phones for testing front and back cameras. (Right) A GIF showing the inside of a test inclosure, with a rotating phone mount (for testing portrait and landscape orientations) and a high-resolution test chart (not pictured).

            We built the CameraX Test Lab to ensure CameraX works on the Android devices most people have in their pockets. The Test Lab opened in 2019 with 52 phone models. Today, the Test Lab has 150 phone models. We prioritize devices with the most daily active users over the past 28 days (28DAUs) and devices that leverage a diverse range of systems on a chip (SoCs). The Test Lab currently covers over 750 million 28DAUs. We also test many different Android versions, going back to Android 5.1 (Lollipop).

            To generate reliable test results, each phone model has its own test enclosure to control for light and other environmental factors. Each enclosure contains two phones of the same model to simplify testing the front and back cameras. On the opposite side of the test enclosure from the phones, there’s a high-resolution test chart. This chart has many industry-standard tests for camera attributes like color correctness, resolution, sharpness, and dynamic range. The chart also has some specific elements for functional tests like face detection.

            When you adopt CameraX in your app, you get the assurance of this continuous testing across many devices and API levels. Additionally, we’re continuously making improvements to the Test Lab, including adding new phones based on market trends to ensure that the majority of your users are well represented. See our current test device list for the latest inventory in our Test Lab.

            Quirks

            Google provides a Camera Image Test Suite so that OEM’s cameras meet a baseline of consistency. Still, when dealing with the wide range of devices that run Android, there can be differences in the end user camera experience. CameraX includes an abstraction layer, called Quirks, to remove these variations in behavior so that CameraX behaves consistently across all devices with no effort from app developers.

            We find these quirks based on our own manual testing, the Test Lab’s automatic testing, and bug reports filed in our public CameraX issue tracker. As of today, CameraX has over 30 Quirks that automatically fix behavior inconsistencies for developers. Here are a few examples:

            • OnePixelShiftQuirk: Some phones shift a column of pixels when converting YUV data to RGB. CameraX automatically corrects for this on those devices.
            • ExtensionDisableQuirk: For phones that don’t support extensions or have broken behavior with extensions, CameraX disables certain extensions.
            • CameraUseInconsistentTimebaseQuirk: Some phones do not properly timestamp video and audio. CameraX fixes the timestamps so that the video and audio align properly.

            These are just a few examples of how CameraX automatically handles quirky device behavior. We will continue to add more corrections as we find them, so app developers won’t have to deal with these one-offs on their own. If you find inconsistent behavior on a device you’re testing, you can file an issue in the CameraX component detailing the behavior and the device it’s happening on.

            Foldable phones

            Foldables continue to be the fastest growing smartphone form factor. Their flexibility in screen size adds complexity to camera development. Here are a few ways that CameraX simplifies the development of camera apps on foldables.

            CameraX’s Preview use case handles differences between the aspect ratio of the camera and the aspect ratio of the screen. With traditional phone and tablet form factors, this difference should be small because Section 7.5.5 of the Android Compatibility Definition Document requires that the “long dimension of the camera aligns with the screen’s long dimension.” However, with foldable devices the screen aspect ratio can change, so this relationship might not always hold. With CameraX you can always preserve aspect ratio by filling the PreviewView (which may crop the preview image) or fitting the image into the PreviewView (which may result in letterboxing or pillarboxing). Set PreviewView.ScaleType to specify which method to use.

            The increase in foldable devices also increases the possibility that your app may be used in a multi-window environment. CameraX is set up for multi-window support out-of-the-box. CameraX handles all aspects of lifecycle management for you, including the multi-window case where other apps can take priority access of singleton resources, such as the microphone or camera. This means no additional effort is required from app developers when using CameraX in a multi-window environment.

            We’re always looking for more ways to improve CameraX to make it even easier to use. With respect to foldables, for example, we’re exploring ways to let developers call setTargetResolution() without having to take into account the different configurations a foldable device can be in. Keep an eye on this blog and our CameraX release notes for updates on new features!

            Getting started with CameraX

            We have a number of resources to help you get started with CameraX. The best starting place is our CameraX codelab. If you want to dig a bit deeper with CameraX, check out our camera code samples, ranging from a basic app to more advanced features like camera extensions. For an overview of everything CameraX has to offer, see our CameraX documentation. If you have any questions, feel free to reach out to us on our CameraX discussion group.

            5 Play Console updates to help you understand your app’s delivery performance

            Posted by Lidia Gaymond, Product Manager, Google PlayPowered by Android App Bundles, Google Play gives all developers the benefits of modern Android distribution. As the Android ecosystem expands, it’s more important than ever to know how your app is being delivered to different devices.

            Delivery insights help you better understand and analyze your app’s delivery performance and what contributes to it, and take action to optimize the experience for your users. Here are five recent Play Console updates you can use to get more insight into your delivery performance.


            1. When you release your app, you’ll now see its expected app size and update size at the point of release creation, so you can determine if the size change from the previous release is acceptable.

            Screenshot of Google Play Console showing expected app size and update size
            Get the expected app size and update size when you create a new release.

            2. If you use advanced Play delivery tools, such as Play Asset Delivery or Play Feature Delivery, detailed information about how these are shipped to users are now available on the Statistics page and in the Delivery tab in App bundle explorer. Understanding your feature modules and asset packs usage can help you make better decisions about further modularization and uncover usage patterns across your users.

            Screenshot of the Devliery tab in the App bundle explorer page in Play Console
            Get detailed information about how your feature modules are shipped to users in the Delivery tab in the App bundle explorer page in Play Console.

            Screenshot of performance metrics on the Statistics page in Play Console
            See per module performance metrics on the Statistics page in Play Console.


            3. When analyzing your existing release, you can now see how many users are on it to help you assess the “freshness” of your install base and how quickly users migrate to new releases. To improve your update rate, consider using the In-app updates API.

            Screenshot of the Release Summary showing percentage of install base on this release in Releases Overview in Play Console
            Know how many users are on your existing release and how quickly users migrate to new releases.

            4. For a deeper dive into your individual app version performance, you can find information about your download size per device model, most common update sizes, and install base in App bundle explorer.

            Screenshot of App bundle explorer page in Play Console
            Evaluate device-specific bundle download size and install base on the App bundle explorer page.

            5. All of these features are also available in your App Dashboard, where you can track these measurements over time alongside other app metrics.

            Screenshot of App bundle explorer page in Play Console
            Monitor these new delivery metrics on your App Dashboard.

            We hope these changes will help you make more informed decisions about your app development and provide you with a detailed view of how your app is being delivered to end user devices.


            How useful did you find this blog post?

            Google Play Logo

            Modern Android Development at Android Developer Summit ‘22

            Posted by Nick Butcher, Developer Relations Engineer

            The Android Developer Summit is back and the first stop on the world tour just finished! We focussed on the latest developments in Modern Android Development: our set of libraries, tools and guidance that make it faster and easier to build amazing Android apps. Here a recap of the top 3 announcements from the conference.

            #1: Jetpack Compose October ‘22

            The October ‘22 stable release of Jetpack Compose brings support for staggered grids, snapping behaviors, pull to refresh, drawing text directly to canvas and many bug fixes and performance improvements. It also includes the first stable release of the Compose Material 3 library, helping you to build fresh, beautiful apps with updated components and styling.

            We’ve also released a new Gradle BOM to simplify how you specify compose dependencies and launched the first alphas of Compose for Android TV—in our continued efforts to bring the joys of writing Compose UIs to all Android form factors.

            #2: Stable Baseline Profile generation

            If you haven’t tried them yet, Baseline Profiles are a powerful way to improve app startup and runtime performance—without changing a single line of app code—and we’ve seen them yield up to 40% faster startup times.

            With Jetpack Benchmark 1.1 and Android Gradle Plugin 7.3 both reaching stable, the toolchain for generating a profile is now completely stable and ready to integrate into your app and start seeing the speed benefits. See the “Making Apps Blazing Fast with Baseline Profiles” talk for all the details.

            #3: Architectural Guidance

            A solid app needs a strong architecture and we’ve been bikeshedding on your behalf to provide detailed guidance on building scalable, testable, high quality apps. Check out the talks and new docs on Modularization, State holders & State Production, UI Events, Flow collection, building Offline first apps and more.

            Those were the top three announcements about Modern Android Development at Android Developer Summit. To learn more, check out the full playlist.

            Material Design 3 for Compose hits stable

            Posted by Gurupreet Singh, Developer Advocate; Android

            Today marks the first stable release of Compose Material 3. The library allows you to build Jetpack Compose UIs with Material Design 3, the next evolution of Material Design. You can start using Material Design 3 in your apps today!

            Note: The terms "Material Design 3", "Material 3", and "M3" are used interchangeably. 

            Material 3 includes updated theming and components, exclusive features like dynamic color, and is designed to be aligned with the latest Android visual style and system UI.
            ALT TEXT
            Multiple apps using Material Design 3 theming

            You can start using Material Design 3 in your apps by adding the Compose Material 3 dependency to your build.gradle files:

            // Add dependency in module build.gradle

            implementation "androidx.compose.material3:material3:$material3_version" 


            Note: See the latest M3 versions on the Compose Material 3 releases page.


            Color schemes

            Material 3 brings extensive, finer grained color customisation, and comes with both light and dark color scheme support out of the box. The Material Theme Builder allows you to generate a custom color scheme using core colors, and optionally export Compose theming code. You can read more about color schemes and color roles.
            ALT TEXT
            Material Theme Builder to export Material 3 color schemes


            Dynamic color

            Dynamic color derives from the user’s wallpaper. The colors can be applied to apps and the system UI.

            Dynamic color is available on Android 12 (API level 31) and above. If dynamic color is available, you can set up a dynamic ColorScheme. If not, you should fall back to using a custom light or dark ColorScheme.
            Reply Dynamic theming from wallpaper(Left) and Default app theming (Right)

             

             


















            The ColorScheme class provides builder functions to create both dynamic and custom light and dark color schemes:

            Theme.kt

            // Dynamic color is available on Android 12+
            val dynamicColor = Build.VERSION.SDK_INT >= Build.VERSION_CODES.S
            val colorScheme = when {
               dynamicColor && darkTheme -> dynamicDarkColorScheme(LocalContext.current)
               dynamicColor && !darkTheme -> dynamicLightColorScheme(LocalContext.current)
               darkTheme -> darkColorScheme(...)
               else -> lightColorScheme(...)
            }

            MaterialTheme(
               colorScheme = colorScheme,
               typography = typography,
               shapes = shapes
            ) {
              // M3 App content
            }


            Material components

            The Compose Material 3 APIs contain a wide range of both new and evolved Material components, with more planned for future versions. Many of the Material components, like Card, RadioButton and CheckBox, are no longer considered experimental; their APIs are stable and they can be used without the ExperimentalMaterial3Api annotation.

            The M3 Switch component has a brand new UI refresh with accessibility-compliant minimum touch target size support, color mappings, and optional icon support in the switch thumb. The touch target is bigger, and the thumb size increases on user interaction, providing feedback to the user that the thumb is being interacted with.
            ALT TEXT
            Material 3 Switch thumb interaction

            Switch(
                  checked = isChecked,
                  onCheckedChange = { /*...*/ },
                  thumbContent = {
                      Icon(
                          imageVector = Icons.Default.Check,
                          contentDescription = stringResource(id = R.string.switch_check)
                      )
                  },
              )


            Navigation drawer components now provide wrapper sheets for content to change colors, shapes, and elevation independently.

            Navigation drawer component

            		Content
            ModalNavigationDrawerModalDrawerSheet
            PermanentNavigationDrawer

            		PermanentDrawerSheet
            DismissableNavigationDrawerDismissableDrawerSheet


            ALT TEXT
            ModalNavigationDrawer with content wrapped in ModalDrawerSheet

            ModalNavigationDrawer {
                ModalDrawerSheet(
                    drawerShape = MaterialTheme.shapes.small,
                    drawerContainerColor = MaterialTheme.colorScheme.primaryContainer,
                    drawerContentColor = MaterialTheme.colorScheme.onPrimaryContainer,
                    drawerTonalElevation = 4.dp,
                ) {
                    DESTINATIONS.forEach { destination ->
                        NavigationDrawerItem(
                            selected = selectedDestination == destination.route,
                            onClick = { ... },
                            icon = { ... },
                            label = { ... }
                        )
                    }
                }
            }


            We have a brand new CenterAlignedTopAppBar  in addition to already existing app bars. This can be used for the main root page in an app: you can display the app name or page headline with home and action icons.


            ALT TEXT
            Material CenterAlignedTopAppBar with home and action items.

            CenterAlignedTopAppBar(
                      title = {
                          Text(stringResources(R.string.top_stories))
                      },
                      scrollBehavior = scrollBehavior,
                      navigationIcon =  { /* Navigation Icon */},
                      actions = { /* App bar actions */}
                  )


            See the latest M3 components and layouts on the Compose Material 3 API reference overview. Keep an eye on the releases page for new and updated APIs.


            Typography

            Material 3 simplified the naming and grouping of typography to:
            • Display
            • Headline
            • Title
            • Body
            • Label
            There are large, medium, and small sizes for each, providing a total of 15 text style variations.

            The             Typography constructor offers defaults for each style, so you can omit any parameters that you don’t want to customize:

            val typography = Typography(
               titleLarge = TextStyle(
                   fontWeight = FontWeight.SemiBold,
                   fontSize = 22.sp,
                   lineHeight = 28.sp,
                   letterSpacing = 0.sp
               ),
               titleMedium = TextStyle(
                   fontWeight = FontWeight.SemiBold,
                   fontSize = 16.sp,
                   lineHeight = 24.sp,
                   letterSpacing = 0.15.sp
               ),
               ...
            }


            You can customize your typography by changing default values of TextStyle and font-related properties like fontFamily and letterSpacing.

            bodyLarge = TextStyle(
               fontWeight = FontWeight.Normal,
               fontFamily = FontFamily.SansSerif,
               fontStyle = FontStyle.Italic,
               fontSize = 16.sp,
               lineHeight = 24.sp,
               letterSpacing = 0.15.sp,
               baselineShift = BaselineShift.Subscript
            )


            Shapes

            The Material 3 shape scale defines the style of container corners, offering a range of roundedness from square to fully circular.

            There are different sizes of shapes:
            • Extra small
            • Small
            • Medium
            • Large
            • Extra large

            ALT TEXT
            Material Design 3 shapes used in various components as default value.

            Each shape has a default value but you can override it:

            val shapes = Shapes(
               extraSmall = RoundedCornerShape(4.dp),
               small = RoundedCornerShape(8.dp),
               medium = RoundedCornerShape(12.dp),
               large = RoundedCornerShape(16.dp),
               extraLarge = RoundedCornerShape(28.dp)
            )


            You can read more about applying shape.


            Window size classes

            Jetpack Compose and Material 3 provide window size artifacts that can help make your apps adaptive. You can start by adding the Compose Material 3 window size class dependency to your build.gradle files:

            // Add dependency in module build.gradle

            implementation "androidx.compose.material3:material3-window-size-class:$material3_version"


            Window size classes group sizes into standard size buckets, which are breakpoints that are designed to optimize your app for most unique cases.


            ALT TEXT
            WindowWidthSize Class for grouping devices in different size buckets

            See the Reply Compose sample to learn more about adaptive apps and the window size classes implementation.


            Window insets support

            M3 components, like top app bars, navigation drawers, bar, and rail, include built-in support for window insets. These components, when used independently or with Scaffold, will automatically handle insets determined by the status bar, navigation bar, and other parts of the system UI.

            Scaffold now supports the contentWindowInsets parameter which can help to specify insets for the scaffold content.

            Scaffold insets are only taken into consideration when a topBar or bottomBar is not present in Scaffold, as these components handle insets at the component level.

            Scaffold(
                contentWindowInsets = WindowInsets(16.dp)
            ) {
                // Scaffold content
            }



            Resources

            With Compose Material 3 reaching stable, it’s a great time to start learning all about it and get ready to adopt it in your apps. Check out the resources below to get started.