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.
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.
ADT-3 will be made available to developers in the coming months for purchase online through an OEM partner.
Posted by David Winer, Kotlin Product Manager
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.
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.
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.
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.
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
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
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
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.
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!
Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security
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.
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 as part of the pre-launch report.
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>
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.
isCleartextTrafficPermitted
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
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:
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 !
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.
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.
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!