Category Archives: Android Developers Blog

An Open Handset Alliance Project

Code Search with Cross References for the Android Open Source Project


Posted by Jeff Bailey, AOSP Engineering Manager; Ally Sillins, AOSP Program Manager; Kris Hildrum, Open Source Code Search Tech Lead; Jay Sachs, Kythe Tech Lead/Manager
Android Screenshot
Searching for "it's all about the code" open source on Google returns more than a million hits. Today we’re introducing a public code search tool for the Android Open Source Project (AOSP).
Link: https://cs.android.com
The Android repository is made up of a collection of git repositories which are managed together using our ‘repo’ tool. Because of this, most tools (such as github, gitweb, etc) can’t see the source code the way that it’s laid out when it’s checked out on the system. In partnership with our colleagues who run Google’s internal Code Search and Kythe, we’re pleased to present a code search tool that presents a view of all of the Android source code as you actually use it.
Here are some features you can take advantage of starting today:
  • View the source code
  • Navigate cross-references across the entire code base that allow you to click through one part of the source code to another
  • Switch between Android’s open source branches (not all branches will have cross-reference information)
  • View tool documentation on https://source.android.com/setup/contribute/code-search
This is the beginning of our journey, and while today not all parts of the Android code base are cross-referenced, you can expect to see this grow over time.
We hope this makes it easier to engage with the Android code base!

Android 10 on Android TV

Posted by Paul Lammertsma, Developer Advocate

Technology has changed the way media and entertainment is accessed and consumed in the home. While the living room experience is evolving with the addition of smart devices, TVs still remain the largest and most frequently used screen for watching content.

When Android TV was first introduced in 2014, we set out to bring the best of Android into the connected home on the TV. We worked closely with the developer community to grow our content and app ecosystem and bring users the content they want. Since then, we’ve seen tremendous momentum with OEM and operator partners as well as consumer adoption worldwide.

Today, we are bringing Android API level 29 with the recent performance and security updates made with Android 10 to Android TV. We’re excited to provide faster updates through Project Treble and more secure storage with encrypted user data. TLS 1.3 by default also brings better performance benefits and is up to date with the TLS standard. In addition, Android 10 includes hardening for several security-critical areas of the platform.

ADT-3

To make sure developers have the ability to build and test Android TV app implementations on Android 10 prior to rollout, we’re introducing a new, developer-focused streaming media device called ADT-3.

With a quad-core A53, 2GB of DDR3 memory and 4Kp60 HDR HDMI 2.1 output, we’ve designed this pre-certified TV dongle with updates and security patches to help developers design for the next generation of Android TV devices. By providing a way to test on physical and up to date hardware, developers can better validate their Android TV app’s compatibility.

Android TV box and remote

ADT-3 will be made available to developers in the coming months for purchase online through an OEM partner.

Android’s commitment to Kotlin

Posted by David Winer, Kotlin Product Manager

Android and Kotlin banner

When we announced Kotlin as a supported language for Android, there was a tremendous amount of excitement among developers. Since then, there has been a steady increase in the number of developers using Kotlin. Today, we’re proud to say nearly 60% of the top 1,000 Android apps contain Kotlin code, with more and more Android developers introducing safer and more concise code using Kotlin.

During this year’s I/O, we announced that Android development will be Kotlin-first, and we’ve stood by that commitment. This is one of the reasons why Android is the gold partner for this year’s KotlinConf.

Seamless Kotlin on Android

In 2019, we focused on making programming in Kotlin on Android a seamless experience, with modern Kotlin-first APIs across the Android platform. Earlier this year, we launched a developer preview of Jetpack Compose, a modern UI toolkit for Android built using a Kotlin domain-specific language (DSL). We also incorporated coroutines into several of the flagship Jetpack libraries, including Room and Lifecycle. Finally, we brought Kotlin extensions (KTX) to even more major Google libraries, including Firebase and Play Core.

On the tooling side, we strengthened our commitment to Kotlin in Android Studio and the Android build pipeline. Significant updates to R8 (the code shrinker for Android) brought the ability to detect and handle Kotlin-specific bytecode patterns. Support was added for .kts Gradle build scripts in Android Studio, along with improved Kotlin support in Dagger. We worked closely with the JetBrains team to optimize support for the Kotlin plugin, and make the Kotlin editing experience in Android Studio fluid and fast.

Better Kotlin learning

This year we’ve also invested in quality Kotlin on Android learning content.

We released two free video learning courses in partnership with Udacity: Developing Android Apps in Kotlin and Advanced Android in Kotlin. This content was also released as the Codelab courses Android Kotlin Fundamentals and Advanced Android in Kotlin, for those who prefer text-based learning. The popular Kotlin Bootcamp for Programmers Udacity course was also published as a Codelabs course, helping provide a Kotlin foundation for non-Kotlin developers. Kotlin-based instructional Codelabs were also created for topics including Material Design, Kotlin coroutines, location, refactoring to Kotlin, billing in Kotlin, and Google Pay in Kotlin. It hasn’t been just about new content: we've updated Kotlin Codelab favorites to take advantage of important features such as coroutines.

Looking ahead

In 2020, Android development will continue to be Kotlin-first. We’ve been listening to your feedback, and will continue partnering with JetBrains to improve your experience with Kotlin.

This includes working with JetBrains to improve the Kotlin compiler over the next year. Our teams are making the compiler more extensible with a new backend, and making your builds faster with a significantly faster frontend. We’re also working with many of the largest annotation processors to make compilation faster for Kotlin code. You can also expect more Kotlin-first updates to Android, including more Jetpack libraries that make use of Kotlin features such as coroutines.

Thank you for letting us be part of your app development journey this year. We look forward to continuing the journey with you in 2020.

Android Game SDK

Posted by Dan Galpin, Developer Advocate

With over 2.5 billion monthly active devices, the Android Platform gives incredible reach for game developers. Taking advantage of that opportunity can be a challenge, particularly if your game really tries to push the limits of what mobile can do. We've spent years working with game developers to try to both capture and address the biggest issues, and we're just beginning to see the fruits of that effort with the launch of the Android Game SDK. The Android Game SDK is a set of libraries that you can use to enhance your Android game.

The first library we are launching in the Android Game SDK helps developers with frame pacing, the synchronization of a game's rendering loop with the OS display subsystem and underlying display hardware. Android's display subsystem is designed to avoid tearing that occurs when the display hardware switches to a new frame in the middle of an update. To this end, it buffers past frames, detects late frame submissions, and repeats the display of past frames when late frames are detected. When a game render loop renders at a different rate than the native display hardware, such as a game running at 30 frames-per-second attempting to render on a device that natively supports 60 FPS, the optimal display flow involves synchronization between the game render loop, the system compositor, and the display hardware.

Optimal Display Flow

Optimal Display Flow

Any mismatch in synchronization can create substantial inconsistencies in frame times. If a frame takes substantially less time to render, it can shorten the presentation of the previous frame, causing something like a 33ms, 16ms, and a 50ms sequence.

Synchronization Mismatch: Rendering too Fast

Synchronization Mismatch: Rendering too Fast

If a frame takes too long to render, a similar problem occurs. The frame will be presented for an extra frame, causing something like a 50ms, 16ms, and 33ms sequence.

Synchronization Mismatch: Slow Frame

Synchronization Mismatch: Slow Frame

In either of these two scenarios, the game player will experience inconsistent delays between game input and screen updates. Visually, things will look less smooth and polished. Both visuals and game play can be impacted.

The Frame Pacing library uses Android's Choreographer API for synchronization with the display subsystem, using presentation timestamp extensions on both OpenGL and Vulkan APIs to make sure frames are presented at the proper time, and sync fences to avoid buffer stuffing. Multiple refresh rates are handled if supported by the device, giving a game more flexibility in presenting a frame. For a device that supports a 60 Hz refresh rate as well as 90 Hz, a game that cannot produce 60 frames per second can drop to 45 FPS instead of 30 FPS to remain smooth. The library detects the expected game frame rate and auto-adjusts frame presentation times accordingly. The Frame Pacing library allows games to take advantage of higher refresh rate 90 and 120 Hz displays, while also making it easy to lock the refresh rate to a desired value, regardless of the underlying display refresh rate.

The Frame Pacing library is built into Unity versions 2019.2 and beyond. Just select the optimized Frame Pacing checkbox under Android Settings to enable smoother frame rates for your game. If you have source to your game engine, it's straightforward to integrate the library into your OpenGL or Vulkan renderer. We've just added library binaries for download at developer.android.com/games/sdk/, or you can download the source code from the Android Open Source Project.

To learn more about Frame Pacing, check out the documentation at developer.android.com, along with the Frame Pacing section of the Optimizing Android Games Performance talk from Google I/O 2019. Be sure to subscribe to our Twitter channel and stay tuned for our announcements at GDC 2020 for more on how we're working to make Android game development better, so you can bring the best game experience to billions of devices.

#AndroidDevChallenge: today is the last day to apply!

Dev Challenge banner with Android logo

Today is the last day to apply for the Android Developer Challenge! And to spark your imagination, we wanted to take a look at one of the original Android Developer Challenge winners, from over 10 years ago. Meet Maurizio Leo:

Maurizio and team have been working on Android for a while now. In fact, he was one of the winners of the original Android Developer Challenge, which launched with the start of Android over ten years ago. Their app, which won 3rd place worldwide at the time, has gone on to be downloaded over 30 million times!

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the deadline today! Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

An Update on Android TLS Adoption

Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security

banner illustration with several devices and gaming controller

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS).

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Percentage of apps that block cleartext by default.

Percentage of apps that block cleartext by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

The latest releases of Android Studio and Google Play’s pre-launch report warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers as part of the pre-launch report.

Example of a warning shown to developers as part of the pre-launch report.

What can I do to secure my app?

For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.

If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
</network-security-config>

If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your element inside a element. This ensures the connections in the production version of your app are secure.

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

What can I do to secure my library?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

Android’s built-in networking libraries and other popular HTTP libraries such as OkHttp or Volley have built-in Network Security Config support.

Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams

3 things to know about Jetpack from Android Dev Summit 2019

Posted by Jisha Abubaker, Product Manager

Last month’s #AndroidDevSummit was jam-packed with announcements and technical news...so much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. We previously spotlighted Jetpack Compose, Kotlin and Android Studio, and today, we’re highlighting the rest of Android Jetpack, with the top three things you should know:

#1: A number of new & updated Jetpack libraries ready to use:

WorkManager 2.2 (Stable) has landed significant updates in the last releases with features like on-demand initialization improving app startup time when using WorkManager and improved testing support. Hear more of the new features and best practices.

Room 2.2 (Stable) is packed with features you asked for too : pre-packaged databases, improved relationship support and now better support for Kotlin Flow as well. Check out the What’s new in Room session to catch up.

Benchmarking (Stable) helps you measure the performance of tasks in your app with confidence. Here’s a deep dive on how you can exercise the library in fighting performance regressions in CI, like we do ourselves for Jetpack libraries and Compose.

LiveData w/ support for Kotlin coroutines & Flow (RC) : Kotlin coroutines and Flows has been the Android developer community’s interest in simplify async patterns in your apps. Learn how best to take advantage of the liveData builder in your app:

View binding (Beta) is type-safe solution bundled with Android Studio 3.6 Beta with minimal build-time impact, no more findViewById(), no more annotation processors. Check out What’s new in Studio for a demo !

#2: We’re busy baking more libraries

CameraX (Alpha) simplifies the development experience and lets you focus on your app instead by addressing the differences between the many devices in the Android ecosystem, like Samsung, Xiaomi, Oppo, Motorola, LG who are already unifying behind CameraX. Expected in Beta soon, learn what the Camera team has been up to since I/O 2019.

Security (Alpha) helps you simplify data at rest encryption for your app needs. Hear of best practices with encryption on Android from the Security library team.

#3:It’s time to migrate to androidx!

With all the new and updated Jetpack libraries and upcoming release of Jetpack Compose, it is time to get your app updated and ready. Nick and Tiem share a great step by step plan and best practices from the community in migrating to androidx namespace.

...and we also heard from you!

But Android Dev Summit isn’t just about what we’ve got to say; it’s also about you telling us what you’d like to see worked on to make your life easier. And this year, one thing that we heard strongly from our community was the need to provide a simplified Dependency injection developer experience for Jetpack libraries and expand improved Kotlin support to other Jetpack libraries! We’re on it!

You can find the entire playlist of Jetpack sessions at the Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

Our panel of experts for the #AndroidDevChallenge (apply by Dec. 2)

Just a little over a week left to finish your submission for the Android Developer Challenge, due December 2! Technology is enabling us to create a whole new era of helpful innovation by helping people get things done more quickly and surfacing patterns that would be difficult to detect using traditional methods. Ultimately, this helpful innovation is enabling us to live better, more productive, and safer lives.

Earlier this week, we highlighted the type of helpful innovation ideas powered by machine learning which are the sort of examples we’re looking for, to help inspire you. Today, we wanted to share the names of the panel of experts we’ve assembled to help bring your projects to life as part of the Android Developer Challenge. These experts will be making the final decision on the 10 finalists of the Android Developer Challenge, and if you’re selected as one of those finalists, we plan to have you meet them when we bring you to Google HQ for a bootcamp next year:

  • Dave Burke is Vice President of Engineering at Google where he leads engineering for the Android platform. Android is the largest mobile platform and ecosystem in the world, with over 2 billion active devices spanning smartphones, tablets, wearables, auto, TV, and IOT. Dave joined Google UK in 2007, becoming an engineering site lead and later moving to California in 2011. Prior to Google, Dave co-founded and was CTO of an internet/telecoms voice startup and helped define related Web and Internet standards.
  • Stephanie Cuthbertson is Senior Director of Developer PM, DevRel and UX for Android. She previously worked on Google’s Search & Ads businesses, as well as a range of developer tools used by Google employees internally. Prior to Google, she was at AWS where she led the product management team for Storage, including Amazon S3. Before AWS, she spent 10 years working on Visual Studio and developer tools.
  • Brahim Elbouchikhi is a Director of Product Management on the Android team. On Android, Brahim is responsible for developer and consumer facing ML and Camera products including CameraX and ML Kit. Prior to Android, Brahim led Daydream’s software team. Brahim was also a founding PM of the Google Play store where he led monetization, search, and discovery.
  • Yossi Matias is Vice President, Engineering, at Google. He is leading efforts in Search (Google Autocomplete, Search Live Results, Google Trends), Conversational AI (Google Duplex, Call Screen, Live Caption, Live Relay, Recorder, Pronunciation), and other Research initiatives. Yossi is the founding Head of Google's R&D Center in Israel, and the founding executive lead of Google for Startup Campus Tel Aviv and of Launchpad. He is the lead of Crisis Response and co-lead of Google’s AI for Social Good. In addition to his experience as an executive and entrepreneur, Yossi has a rich record of scientific research, published extensively, and has dozens of patents on his name. Yossi is a recipient of the Godel Prize and is an ACM Fellow.
  • Sarah Sirajuddin is an engineering director working on TensorFlow at Google. She leads the teams working on on-device machine learning, TensorFlow Extended, and efforts around training models for the best accuracy and performance with Google’s cutting-edge infrastructure, including TensorFlow and tensor processing units (TPUs).

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

Android Developer Challenge: here’s what we’re looking for! (Apply by Dec. 2)

Last month, we kicked off the next Android Developer Challenge, and asked you to submit your ideas focused on helpful innovation, powered by on-device machine learning. But what exactly do we mean when we say helpful innovation? We’re glad you asked! We rounded up a few of Google’s on-device machine learning offerings, together with some great recent examples of this technology in action, to help inspire your submission. Don’t forget, submit your idea by December 2!

Using machine learning to tackle Fall Armyworm

Take Nazirini Siraji. When she and a team of developers noticed a crop-pest threatening the livelihood of Ugandan farmers, they taught themselves TensorFlow to combat this pest. They collected training data from nearby fields in the form of images. With TensorFlow, they re-trained a MobileNet, a technique known as transfer learning and then used the TensorFlow Converter to generate a TensorFlow Lite FlatBuffer file which they deployed in an Android app. With the app, a farmer can snap a picture of their crop and the image frame is analysed to look for Fall armyworm damage. Depending on the results from this phase, a suggestion of a possible solution is given. It’s pretty cool!

Helping doctors detect respiratory diseases using machine learning

Tambua Health is helping doctors determine the likelihood of respiratory diseases by turning any smartphone into a powerful non-invasive screening tool. They developed an app using TensorFlow Lite that can help doctors analyze lung sounds for the presence of abnormal sounds like wheezes, crackles, stridor, and other adventitious sounds.

adidas uses machine learning to make the shopping experience easier

Even brands are tapping the power of machine learning. Take adidas, who recently launched a new “Bring It to Me” experience for their London store. Shoppers can use Visual Lookup to scan products on their phones while they are in the store, and the app lets them check stock and request their size without the need for queues. Under the hood, ML Kit is helping power the experience. It’s another way machine learning is helping users get things done more quickly.

The benefits of on-device machine learning

Running machine learning on a user’s device comes with a number of benefits. First, you reduce the amount of data you send to your server, enhancing user privacy. And because it runs on device, it can also work offline - perfect for inaccessible areas such as the middle of a rainforest, a desert or the London Underground. Last but not least, the most exciting aspect of running your model on device is low latency and this can enable all kinds of new user experiences. Machine learning is not just for automating tasks, it can work alongside your users and give them super powers too!

At Google, we offer a number of different technologies to help you take advantage of this:

  • ML Kit offers a turnkey SDK to help you tackle tasks with powerful Google Machine Learning models
  • The TensorFlow Lite Framework lets you take a custom model and optimise it to run it on Android
  • There’s also the infrastructure of Firebase / Google Cloud, which can help you train on-device models using AutoML Vision Edge for specific model types or give you the raw processing power to train your own model

If you’ve got a great idea that can help users get things done, we want to hear from you! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. We can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by on-device machine learning to more and more users!

Unifying Background Task Scheduling on Android

Posted by Caren Chang, Developer Programs Engineer

Android users care a lot about the battery life on their phones. In particular, how your app schedules deferrable background tasks play an important role in battery life. To help you build more battery-friendly apps, we introduced WorkManager as the unified solution for all deferrable background processing needs.

Starting November 1, 2020, we are unifying deferrable background tasks on Android around WorkManager, and GCMNetworkManager will be deprecated and no longer supported.

Why WorkManager

The WorkManager API incorporates the features of Firebase Job Dispatcher (FJD) and GcmNetworkManager solutions, providing a consistent job scheduling service back to API level 14 while being conscious of battery life. For example, if your app needs to send log files up to the server, it would be more efficient to wait until the device is both charging and connected to WiFi. In this case, WorkManager will ensure that the sync will execute when the given constraints (charging and connected to WiFi) are met. Additionally, it does not require Google Play Services, unlike FJD and GcmNetworkManager.

Some of the other key features of WorkManager include:

  • Persist scheduled work across app updates and device restarts
  • Schedule one-off or periodic tasks
  • Monitor and manage tasks
  • Chain tasks together

What it means for developers

Now that the WorkManager library has reached maturity, we have decided to deprecate alternative solutions to simplify the developer story and focus on WorkManager stability and features.

  • We announced the deprecation of the FirebaseJobDispatcher library in April 2019. In April 2020 the library will be archived and we will no longer provide support for issues filed on the library.
  • In addition, we are now announcing the deprecation of GCMNetworkManager. The library is no longer receiving any new features and starting in November 2020, we will no longer provide support for issues relating to the library.
  • Furthermore, once your app updates the target API level (targetSdkVersion) to above Android 10 (API level 29), FirebaseJobDispatcher and GcmNetworkManager API calls will no longer work on devices running Android Marshmallow (6.0) and above.

Migrating to WorkManager

Now is the time to migrate your apps to WorkManager if you haven't already done so! You can start by reading the official documentation for WorkManager.

If your app is still using FirebaseJobDispatcher, you can migrate your app to WorkManager by following the migration guide. A similar migration guide from GCMNetworkManager to WorkManager is also available.

YouTube recently moved over to WorkManager for their background scheduling needs and has reported improvements in app startup time as well as an 8% drop in crash rates.

Going forward

The team is dedicated to improving and continuing feature development on WorkManager. If you encounter issues using the library, have proposals for features you would like to see, or have any feedback about the library, please file an issue.