Tag Archives: Android Go

Optimize for Android Go : Lessons from Google apps Part 2

Posted by Niharika Arora, Developer Relations Engineer

Building for Android Go involves paying special attention to performance optimizations and resource usage.

In part-1 of this blog, we discussed why developers should consider building for Android Go, some tips on optimizing the app memory and identified the standard approach to follow while fixing performance issues. In this blog, we will talk about the other vitals to pay attention to while building apps for Android Go.

Optimize your apps for Android Go

Improve startup latency

Improving app startup time requires a deep understanding of things that affect it.

  • Avoid eager initialization: Avoid doing eager work that may not be needed in your app’s startup sequence. The user launching your app is the most well-known reason a process starts, but WorkManager, JobScheduler, BroadcastReceiver, bound Services, and ContentProviders can also start your app process in the background. Avoid initializing things eagerly in your Application class like ContentProviders, or androidx initializers if possible (If they are not needed for any possible reason for your app process to start).
  • Move the tasks from UI thread to background thread

    • Identify operations which occupy large time frames and can be optimized.
    • Identify operations that consume more time than expected.
    • Identify operations which cause the main thread to be blocked.

If there are tasks which are taking longer and blocking the main thread, try to move them to a background thread or prefer using WorkManager
    • Check third party library initialization 
Lazy load third party libraries. A lot of libraries do have on demand initialization or disabling auto init options.
      • Check rendering time of webp / png images
        • Prefer webp images over jpg/png
        • Prefer svg for small icons.
        • Check if any layouts are invisible, but still spend time for the images to be loaded.
        • Explore using a low resolution image according to the memory capabilities of the device.
        • Remove unnecessary backgrounds/alpha from views.
    • Avoid synchronous IPCs on UI thread: Check for binder transactions keeping the main thread busy: Often there are multiple Inter process communication happening within the app. These could be anything like image / asset loading, third party libs loading, heavy work on application’s main thread like disk or network access etc. StrictMode is a useful developer tool to detect such accident usage.
    Identify and measure these transactions to understand :
        • How much time does this take and if it is expected & necessary ?
        • Is the main thread sleeping / idle / blocked during this time ? If yes, this could be a performance bottleneck.
        • Can this be delayed ?
    • Wisely use XML and Json parsing: The Gboard app optimized file list parsing by using Java code instead of XML parsing as they were parsing them out into memory as Java objects at runtime. So, GBoard did a work to convert all the XML into Java code at compile time, the latency then become time of class loading, which is much more faster, almost of previous. Benchmarking both XML and Json parsing for your app to identify the appropriate library to be used.
    • Analyze and fix severe disk read contention: To capture this, use StrictMode in your development environment.
      • Detects accidental disk or network access on the application's main thread, where UI operations are received and animations take place.
      • Can automatically terminate the app (or log it to logcat), when a violation has occurred by adding different penalties.

    Optimize app size

    Users often avoid downloading apps that seem too large, particularly in emerging markets where devices connect to spotty 2G and 3G networks with low bandwidth speed or work on pay-by-the-byte plans.

    • Remove unnecessary layouts: Gboard and Camera from Google teams validated the layouts which were unused or could be merged with small UI changes and removed the unnecessary layouts reducing overall app code size.
    • Migrate to dynamic layouts/views when appropriate: The apps deep dive and find out the layouts and views which can be dynamically rendered. They used merge and viewstub to further optimize their views and layouts.
    • Revaluate features with low DAU. Try to disable features which take more memory and make the app less performant: The team further analyzed their apps to specifically optimize for Android Go and disabled features on go devices which were not of much usage but were taking a lot of memory. They removed complex animations, large GIFs etc. to make space for parts of the app.
    • Try combine native binaries with common dependencies into one: If the app has different JNI implementations with a lot of common underlying dependencies - all the different binaries add up to the apk size with redundant components. Camera from Google app benefited from combining several JNI binaries into a single JNI binary while keeping the Java and JNI files separate. This helped the app reduce the apk size by several Mbs.
    • Try to reduce dalvik code size: Check for code that is never used at runtime, eg) large classes and auto-generated code.
      • Code optimizers like ProGuard () could help optimize and shrink code size, but they can't deal with codes guarded by runtime-constants. Replacing the check/flags with compile-time constants to make most usage of the optimization tools.
      • Reduce translatable strings size :
      a.    Don’t translate internal-only UI strings. Mark them as translatable = “false”. 
      b.    Remove unused alternative resources: You can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need. if you are using a library that includes language resources (such as AppCompat or Google Play Services), then your app includes all translated language strings for the messages in those libraries whether the rest of your app is translated to the same languages or not. If you'd like to keep only the languages that your app officially supports, you can specify those languages using the resConfig property. Any resources for languages not specified are removed. 
      The following snippet shows how to limit your language resources to just English and French

        android {
            defaultConfig {
                resConfigs "en", "fr"

        You can read more here.

        c.    Don’t translate what doesn’t need translation: If the string does not participate in a UI, it should not be translated. Strings for the purpose of debugging, exception messages, URLs and so on should be string literals in code, not resources. 
        i.    Don’t translate what’s not shown to the user anyway
        It’s possible to have a String resource that’s practically never shown to the user, but is still strongly referenced. One example is in your <activity>, if you have an android:label set and referencing a String resource but the Activity’s label is never actually shown (e.g. it’s not a launcher Activity and it doesn’t have an app bar that shows its own label).
         d.    Don’t translate URLs:  Consider this example:

        <string name="car_frx_device_incompatible_sol_message">

        This device doesn\'t support Android Auto.\n

        <a href="https://support.google.com/androidauto/answer/6395843">Learn more</a>


        You may recognize < and > - these are escape characters for “<” and “>”. They’re needed here because if you were to put an <a> tag inside a <string> tag, then the Android resource compiler would just drop them (as it does with all tags it doesn’t recognize).

        However, this means that you’re translating the HTML tags and the URL to 78 languages. Totally unnecessary.

        Instead, remove the part with HTML:

        <string name="car_frx_device_incompatible_sol_message">

        This device doesn\'t support Android Auto.


        Note we don’t define a separate string for “Learn more”, because it’s a common string. To produce the HTML snippet for the link, we define "<a href="https://support.google.com/androidauto/answer/6395843>%s</a>" as a string literals in code, and then drop the value of “Learn more” from resources into the format specifier.
        e.    Inline untranslated stringsBy specifying strings in strings.xml you can leverage the Android framework to automatically change the actual value used at runtime based on the current configuration (e.g. based on the current locale, show a localized value for the string).    
        f.    Remove duplicate stringsIf you have the same string multiple times as a literal in code (“Hello World”), it will be shared across all instances. But resources don’t work this way - if you have an identical string under a different name then unless both are translated identically across 78 languages (unlikely) you’ll end up with duplicates.

        Don’t have duplicate strings!  

        g.    Don’t have separate strings for ALL CAPS or Title Case: Android has built-in support for case mutations. 

        Use android:capitalize (since API level 1). If set, specifies that this TextView has a textual input method and should automatically capitalize what the user types. The default is "none".

          • Reducing asset size: Be mindful of different target device form factors that your app supports and adjust your assets accordingly.
          • Upload your app with Android app bundles: The easiest way to gain immediate app size savings when publishing to Google Play is by uploading your app as an Android App Bundle, which is a new upload format that includes all your app’s compiled code and resources, but defers APK generation and signing to Google Play. Read more here.
          • Utilize dynamic delivery feature if applicable: Play Feature Delivery uses advanced capabilities of app bundles, allowing certain features of your app to be delivered conditionally or downloaded on demand. You can use feature modules for custom delivery. A unique benefit of feature modules is the ability to customize how and when different features of your app are downloaded onto devices running Android 5.0 (API level 21) or higher. Learn more here.


          This part of the blog captures some best practices, recommendations and learnings from Google apps to optimize your app size, startup latency and improve go app experience that helps drive user engagement and adoption for your Android app. In part-3, you will get to know the tools that helped the Google apps identify and fix such performance issues in their app!

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

          Posted by Niharika Arora, Developer Relations Engineer

          The Android operating system brings the power of computing to everyone. This vision applies to all users, including those on entry-level phones that face real constraints across data, storage, memory, and more.
          This was especially important for us to get right because, when we first announced Android (Go edition) back in 2017, people using low-end phones accounted for 57% of all device shipments globally (IDC Mobile Phone Tracker).

          What is Android (Go edition)?

          Android (Go edition) is a mobile operating system built for entry-level smartphones with less RAM. Android (Go edition) runs lighter and saves data, enabling Original Equipment Manufacturers (OEMs) to build affordable, entry-level devices that empower people with possibility. RAM requirements are listed below, and for full Android (Go edition) device capability specifications, see this page on our site.









          Android 8

          Android 9

          Android 10

          Android 11

          Android 12

          Android 13

          Min RAM







          Android (Go edition) provides an optimized experience for low-RAM devices. By tailoring the configuration and making key trade-offs, we’re able to improve speed and performance for low-end devices and offer a quality phone experience for more than 250M people around the world.

          Recent Updates

          We are constantly making phones powered by Android (Go edition) more accessible with additional performance optimizations and features designed specifically for new & novice internet users, like translation, app switching, and data saving.

          Below are the recent improvements we made for Android 12:

          Faster App Launches

          Longer Battery Life 

          Easier App Sharing 

          More Privacy Control

          Why build for Android (Go edition)?

          With the fast growing & easily accessible internet, and all the features available at low cost, OEMs and developers are aiming & building their apps specifically for Android (Go edition) devices.

          Fast forward to today — over 250 million+ people worldwide actively use an Android (Go edition) phone. And also considering the big OEMs like Jio, Samsung, Oppo, Realme etc. building Android (Go edition) devices, there is a need for developers to build apps that perform well especially on Go devices.

          But the markets with the fast growing internet and smartphone penetration can have some challenging issues, such as:
          • Your app is not starting within the required time limit.
          • A lot of features/required capabilities increases your app size 
          • How to handle memory pressure while working on Go apps?

          Optimize your apps for Android (Go edition)

          To help your app succeed and deliver the best possible experience in developing markets, we have put together some best practices based on experience building our own Google apps Gboard & Camera from Google.


          Define Metrics & breakdowns → Benchmark Metrics → Identify bottlenecks → Optimize bottlenecks → Add regression tests.        ↑_________________________________↓



          DefineBefore starting any optimization effort, it’s important to define the goals. Key Performance Indicators (KPIs) have to be defined for the app.
          • KPIs can be common across different apps and some can be very specific. Some examples of KPIs can be  
          App Startup Latency
          Common to all apps
          App Crash Rate
          Common to all apps
          End to end latency for CUJ - Camera Shot
          Specific to Camera app
          App Not Responding RateCommon to all apps
          • Once KPIs are defined the team should agree on the target thresholds. This can be derived from the minimum user experience/benchmarks in mind.
          • KPIs should ideally be defined from the perspective of balancing User Experience and technical complexity.
          BreakdownOnce KPIs are defined, the next steps could be to break down a given KPI into individual signal metrics.
          • For example → End to end latency for CUJ (shots in Camera) can be divided into → Frame capture latency, image processing latency, time spent on saving a processed image to disk etc.
          • Similarly, App Crash Rate can be bucketed into → Crash due to unhandled errors, Crash due to high memory usage, Crash due to ANR etc.
          BenchmarkBenchmark or measure the KPI values and individual metrics to identify current performance.
          If KPI targets are met, things are good. If not → identify the bottlenecks by looking at the individual breakdowns.
          Repeat the process

          After optimizing a certain bottleneck go back and benchmark the metrics again to see if the KPI targets are met. If not, repeat the process. If yes, great job!
          Add Regular regression testThat either runs for every change or in some frequency to identify regressions in KPIs. It is more difficult to debug and find sources of regressions or bugs than to not allow them to get into the codebase. Don’t allow the changes that fail the KPI goals unless the decision is to update the KPI targets.
          • Try to invest in building a regression infrastructure to deal with such issues in early stages.
          • Decide on how often tests should run? What should be the optimal frequency for your app?

          Optimize App Memory

          GBoard used the onTrimMemory() signal to trim unneeded memory while it goes in the background and there is not enough memory to keep as many background processes running as desired, for example, trimming unneeded memory usage from expressions, search, view cache or openable extensions in background. It helped them reduce the number of times being low memory killed and the average background RSS. Resident Set Size(RSS) is basically the portion of memory occupied by your app process that is held in main memory (RAM). To know more about RSS, please refer here. 
          • Check if malloc can be replaced with mmap when accessing read-only & large files: mmap is only recommended for reading a large file onto memory ('read-only memory mapped file'). The kernel has some special optimizations for read-only memory mapped files, such as unloading unused pages.
          Typically this is useful for loading large assets or ML models.
          • Scheduling tasks which require similar resources(CPU, IO, Memory) appropriately: Concurrent scheduling could lead to multiple memory intensive operations to run in parallel and leading to them competing for resources and exceeding the peak memory usage of the app. The Camera from Google app found multiple problems, ensured a cap to peak memory and further optimized their app by appropriately allocating resources, separating tasks into CPU intensive, low latency tasks(tasks that need to be finished fast for Good UX) & IO tasks. Schedule tasks in right thread pools / executors so they can run on resource constrained devices in a balanced fashion.
          • Find & fix memory leaks: Fighting leaks is difficult but there are tools like Android Studio Memory Profiler/Perfetto specifically available to reduce the effort to find and fix memory leaks.
          Google apps used the tools to identify and fix memory issues which helped reduce the memory usage/footprint of the app. This reduction allowed other components of the app to run without adding additional memory pressure on the system.

          An example from Gboard app is about View leaks
          A specific case is caching subviews, like this: 

          void onKeyboardViewCreated(View keyboardView) {
            this.keyButtonA = keyboardView.findViewById(...);

          The |keyboardView| might be released at some time, and the |keyButtonA| should be assigned as null appropriately at some time to avoid the view leak.

          Lessons learned:
            • Always add framework/library updates after analyzing the changes and verifying its impact early on.
            • Make sure to release memory before assigning new value to a pointer pointing to other object allocation in heap in Java. (native backend java objects) 
          For example :
          In Java it should be ok to do

          ClassA obj = new ClassA("x");
          // ... something
          obj = new ClassB("y");

          GC should clean this up eventually.
          if ClassA allocates native resources underneath and doesn't cleanup automatically on finalize(..) and requires caller to call some release(..)  method, it needs to be like this 

          ClassA obj = new ClassA("x");
          // ... something

          // Explicit cleanup.

          obj = new ClassB("y");

          else it will leak native heap memory. 
          • Optimize your bitmaps: Large images/drawables usually consume more memory in the app. Google apps identified and optimized large bitmaps that are used in their apps. 
          Lessons learned :
            • Prefer Lazy/on-demand initializations of big drawables.
            • Release view when necessary.
            • Avoid using full colored bitmaps when possible. 
          For example: Gboard’s glide typing feature needs to show an overlay view with a bitmap of trails, which can only has the alpha channel and apply a color filter for rendering.

          // Creating the bitmap for trails.

          trailBitmap = Bitmap.createBitmap(w, h, Bitmap.Config.ALPHA_8);


          // Setup paint for trails.

          trailPaint.setColorFilter(new ColorMatrixColorFilter(new ColorMatrix(new float[] {

            0, 0, 0, 0, (color >> 16) & 0xFF,

            0, 0, 0, 0, (color >> 8) & 0xFF,

            0, 0, 0, 0, color & 0xFF,

            0, 0, 0, 1, 0



          // onDraw


          protected void onDraw(Canvas canvas) {


            if (trailBitmap != null) {

              canvas.drawBitmap(trailBitmap, 0, 0, trailPaint);



          A screenshot of glide typing on Gboard
          • Check and only set the alpha channel for the bitmap for complex custom views used in the app. This saved them a couple of MBs (per screen size/density).
          • While using Glide, 
            • The ARGB_8888 format has 4 bytes/pixel consumption while RGB_565 has 2 bytes/pixel. Memory footprint gets reduced to half when RGB_565 format is used but using lower bitmap quality comes with a price too. Whether you need alpha values or not, try to fit your case accordingly.
            • Configure and use cache wisely when using a 3P lib like Glide for image rendering.
          • Try to choose other options for GIFs in your app when building for Android (Go edition) as GIFs take a lot of memory.
          • 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.
          • You can reduce PNG file sizes without losing image quality using tools like pngcrush, pngquant, or zopflipng. All of these tools can reduce PNG file size while preserving the perceptive image quality.
          • You could use resizable bitmaps. The Draw 9-patch tool is a WYSIWYG editor included in Android Studio that allows you to create bitmap images that automatically resize to accommodate the contents of the view and the size of the screen. Learn more about the tool here


          This part of the blog outlines why developers should consider building for Android (Go edition), a standard approach to follow while optimizing their apps and some recommendations & learnings from Google apps to improve their app memory and appropriately allocate resources.

          In the next part of this blog, we will talk about the best practices on Startup latency, app size and the tools used by Google apps to identify and fix performance issues.

          Google I/O 2017: Empowering developers to build the best experiences across platforms

          By Jason Titus, Vice President, Developer Product Group
          It's great to be in our backyard again for Google I/O to connect with developers around the world. The 7,200 attendees at Shoreline Amphitheatre, millions of viewers on the livestream, and thousand of developers at local I/O Extended events across 80+ countries heard about our efforts to make the lives of developers easier -- allowing them to focus on the problems they're trying to solve by minimizing the pain points of building a product.
          Earlier this morning, our CEO Sundar Pichai talked about our various billion-user platforms. Whether it's Android or Chrome or the mobile Web, our success would not have been possible without the developer community. And during our Developer Keynote, we covered our heavy investments in tools and services for developers who build on our platforms every day.
          We have a lot to cover over the next three days. Let's take a closer look at the major developer news at I/O so far:

          Platforms that connect developers to billions of users around the world

          • Android O Developer Preview 2 — Get a look at the next release of Android O focused on fluid experiences that make Android even more useful, and our efforts to optimize battery life, startup time, graphic rendering time, and stability. Early adopters can opt in to the Android O Beta Program at android.com/beta and run Android O now.
          • Project Treble — Last week, we also introduced a new Android framework designed to help reduce the time and effort it takes device makers to upgrade a phone to a new version of Android, starting with Android O.
          • Android Go — We're optimizing Android to run smoothly on entry-level devices, starting with the O release. We're also designing Google apps to use less memory, storage space, and mobile data, including apps such as YouTube Go, Chrome, and Gboard.
          • Kotlin — Android is officially supporting the Kotlin programming language, in addition to the Java language and C++. Kotlin is a brilliantly designed, mature, production-ready language that we believe will make Android development faster and more fun.
          • Android Studio 3.0 Canary — Our new preview includes three major features to accelerate development flow: a new suite of app performance profiling tools to quickly diagnose performance issues, support for the Kotlin programming language, and increased Gradle build speeds for large sized app projects.
          • Mobile Web — AMP and Progressive Web Apps (PWAs) are re-defining modern mobile web development. AMP gets content in front of users fast and PWAs deliver app-focused experiences that are reliable, fast and engaging. We're seeing success stories from all around the world - travel company Wego has rolled out a successful AMP based PWA and Forbes has seen user engagement double since launching a PWA. If you're wondering how good your current web experience is, you can use Lighthouse - an automated tool for measuring web-page quality. Be sure to tune in this afternoon for the Mobile Web: State of the Union talk to hear more about building rich mobile web experiences.

          Infrastructure and services to take mobile apps and the Web to the next level

          • Firebase — At last year's I/O, we expanded Firebase to a full mobile development platform with products to help you build your app and grow your business. Over a million developers now use Firebase, and we're doubling down on our efforts to simplify more every-day developer challenges. We're giving more insights to understand app performance through Firebase Performance Monitoring, introducing integration between Hosting and Cloud Functions, adding support for Phone Number Authentication, and continuing to improve Analytics in a number of ways. We've also started open sourcing our SDKs.
          • Mobile web developer certifications — At I/O'16 we launched the Associate Android Developer Certification. This year, we're adding two new certifications for web developers: the Mobile Sites Certification and the Mobile Web Specialist Certification.

          Powerful tools to acquire and engage new users; grow successful businesses

          • Google Play Console — We announced several powerful, new features and reports in the Play Console to help developers improve their app's performance, manage releases with confidence, reach a global audience, and grow their business. The Play Console also has a new name, to reflect its broadened business uses, and a fresh look to make it easier to get things done.
          • Android Instant Apps — We opened Android Instant Apps, a new way to run Android apps without requiring installation, to all developers. Now anyone can build and publish an instant app. There are also more than 50 new experiences available for users to try out from a variety of brands, such as Jet, New York Times, Vimeo and Zillow.
          • Payments, Monetization & Ads — We introduced a Google Payment API that enables developers to give their customers the ability to pay in apps and online with credit or debit cards saved to their Google Account. New AdMob integration with Google Analytics for Firebase helps them monetize efficiently and updates to Universal Apps Campaigns will help them grow their user base.

          New interfaces to push the limits of what's possible

          • Actions on Google for the Google Assistant — We brought Actions on Google to phones, introduced new features and functionality, improved our SDK and more. We also launched the Actions Console, a new developer console that helps developers work as a team, and collect data on app usage, performance and user discovery patterns. This new console is integrated with the Firebase and Google Cloud consoles.
          • VR and AR at Google — We'll have more to share on the latest Daydream platform features and developer tools during our "VR and AR at Google" session tomorrow (May 18) at 9:30 AM PT in the Amphitheatre and on the livestream.
          It's important to us that developers are successful. In addition to building products that help solve developer challenges, we're on the ground in over 130 countries, growing and expanding the developer community through programs such as Women Techmakers & Google Developer Groups (GDGs). We're also investing in training programs like Google Developers Certification and courses through Udacity and other partners to help developers deepen their technical capability. We're also excited to announce two large multi-product developer events, Google Developer Days, which are planned for Europe (September 2017 in Krakow, Poland) and India (December 2017 in Bangalore, India). If you are interested to find out more, sign up for updates on g.co/gdd2017.
          During Google I/O, attendees and viewers have an opportunity to dive deep into a number of these areas with 14 content tracks and 140+ breakout sessions -- covering Android to Assistant to VR -- and all livestreamed. We've also launched over 70 codelabs to get developers up and running with our latest APIs today.
          Whether it's Android, Chrome, Play, VR/AR, the Cloud, and the Mobile Web — we're constantly investing in the platforms that connect developers to billions of users around the world. Thank you to the continued support and feedback from the developer community.

          What’s New in Android: O Developer Preview 2 & More

          Posted by: Dave Burke, VP of Engineering

          With billions of Android devices around the world, Android has surpassed our wildest expectations. Today at Google I/O, we showcased a number of ways we’re pushing Android forward, with the O Release, new tools for developers to help create more performant apps, and an early preview of a project we call Android Go -- a new experience that we’re building for entry-level devices.
          Fluid experiences in Android O
          It's pretty incredible what you can do on mobile devices today, and how easy it is to rely on them as computers in our pockets. In the O release we've focused on creating fluid experiences that make Android even more powerful and easy to use, and today we highlighted some of those:
          • Picture-in-picture: lets users manage two tasks simultaneously, whether it’s video calling your friend while checking your calendar, or reading a new recipe while watching a video on a specific cooking technique. We’ve designed PIP to provide seamless multitasking on any size screen, and it’s easy for apps to support it.
          • Notification dots extend the reach of notifications, a new way for developers to surface activity in their app, driving engagement. Built on our unique and highly regarded notification system, dots work with zero effort for most apps - we even extract the color of the dot from your icon. 
          • Autofill with Google simplifies setting up a new device and synchronizing passwords by bringing Chrome's Autofill feature to Android. Once a user opts-in, Autofill will work out-of-the-box for most apps. Developers can optimize their apps for Autofill by providing hints about the type of data expected or add support in custom views. 
          • A new homescreen for Android TV makes it easy for users to find, preview, and watch content provided by apps. Apps can publish one or more channels, and users can control the channels that appear on the homescreen. You’ll be able to get started with creating channels using the new TvProvider support library APIs
          • Smart Text Selection: In Android O, we’re applying on-device machine learning to copy/paste, to let Android recognize entities like addresses, URLs, telephone numbers, and email addresses. This makes the copy/paste experience better by selecting the entire entity and surfacing the right apps to carry out an action based on the type of entity.
          • TensorFlow Lite: As Android continues to take advantage of machine learning to improve the user experience, we want our developer partners to be able to do the same. Today we shared an early look at TensorFlow Lite, an upcoming project based on TensorFlow, Google’s open source machine learning library. TensorFlow Lite is specifically designed to be fast and lightweight for embedded use cases. Since many on-device scenarios require real-time performance, we’re also working on a new Neural Network API that TensorFlow can take advantage of to accelerate computation. We plan to make both of these available to developers in a maintenance update to O later this year, so stay tuned!  
          (L) Android O: Picture-in-picture, (R) Android O: Notification dots

          Working on the Vitals in Android
          We think Android’s foundations are critical, so we’re investing in Android Vitals, a project focused on optimizing battery life, startup time, graphic rendering time, and stability. Today we showcased some of the work we’ve done so far, and introduced new tools to help developers understand power, performance, and reliability issues in their apps:
          • System optimizations: in Android O, we’ve done a lot of work across the system to make apps run faster and smoother. For example we made extensive changes in our runtime - including new optimizations like concurrent compacting garbage collection, code locality, and more. 
          • Background limits: up to now it’s been fairly easy for apps to unintentionally overuse resources while they’re in the background, and this can adversely affect the performance of the system. So in O, we've introduced new limits on background location and wi-fi scans, and changes in the way apps run in the background. These boundaries prevent overuse -- they’re about increasing battery life and freeing up memory.
          • New Android Vitals Dashboards in the Play Console: today we launched six Play Console dashboards to help you pinpoint common issues in your apps - excessive crash rate, ANR rate, frozen frames, slow rendering, excessive wakeups, and stuck wake locks, including how many users are affected, with guidance on the best way to address the issues. You can visit the Play Console today to see your app's data, then learn how to address any issues.
          Android Go
          Part of Android’s mission is to bring computing to everyone. We’re excited about seeing more users come online for the first time as the price of entry level smart phones drop, and we want to help manufacturers continue to offer lower-cost devices that provide a great experience for these users. Today we gave a sneak peek of a new experience that we’re building specifically for Android devices that have 1GB or less of memory -- Internally we call it “Android Go,” and it’s designed around three things
          • OS: We’re optimizing Android O to run smoothly and efficiently on entry-level devices
          • Apps: We’re also designing Google apps to use less memory, storage space, and mobile data, including apps such as YouTube Go, Chrome, and Gboard. 
          • Play: On entry-level devices, Play store will promote a better user experience by highlighting apps that are specifically designed for these devices -- such as apps that use less memory, storage space, and mobile data -- while still giving users access to the entire app catalog.
          The Android Go experience will ship in 2018 for all Android devices that have 1GB or less of memory. We recommend getting your apps ready for these devices soon -- take a look at the Building for Billions to learn about the importance of offering a useful offline state, reducing APK size, and minimizing battery and memory use.

          O Developer Preview 2, Now in Public Beta
          Today’s release of O Developer Preview 2 is our first beta-quality candidate, available to test on your primary phone or tablet. We’re inviting those who want to try the beta release of Android O to enroll now at android.com/beta -- it’s an incredibly convenient way to preview Android O on your Nexus 5X, 6P, and Player, as well as Pixel, Pixel XL, or Pixel C device.

          With more users starting to get Android O on their devices through the Android Beta program, now is the time to test your apps for compatibility, resolve any issues, and publish an update as soon as possible. See the migration guide for steps and a recommended timeline.

          Later today you’ll be able to download the updated tools for developing on Android O, including the latest canaries of Android Studio, SDK, and tools, Android O system images, and emulators. Along with those, you’ll be able to download support library 26.0.0 beta and other libraries from our new Maven repo. The change to Maven from SDK Manager means a slight change to your build configuration, but gives you much more flexibility in how you integrate library updates with your CI systems.

          When you’re ready to get started developing with Android O, visit the O Developer Preview site for details on all of the features you can use in your apps, including notification channels and dots, picture-in-picture, autofill, and others. APIs have changed since the first developer preview, so take a look at the diff report to see where your code might be affected.

          Thanks for the feedback you’ve given us so far. Please keep it coming, about Android O features, APIs, issues, or requests -- see the Feedback and Bugs page for details on where to report feedback.