Posted by Madan Ankapura, Product Manager, Android
Google’s vision is to bring a safe and seamless connected experience to every car. Since 2017, we have announced collaborations with vehicle manufacturers like Volvo Car Group, General Motors and others to power infotainment systems with Android Automotive OS, Google’s open-source Android platform, and to enable integration of Google technology and services. Now with the reveal of Volvo’s XC40 Recharge and the previously announced Polestar 2, we are making progress on our vision with these brand new, customized infotainment systems that feature real-time updates to the Google Assistant, Google Maps and automotive apps created by Google, and the global developer community.
Volvo XC40 Recharge & its infotainment unit
With more manufacturers adding Android Automotive OS based infotainment systems to their vehicles, app developers have an opportunity to reach even more users with innovative, and drive optimized experiences.
Concept image from GM on Maps & Media integration
At Google I/O 2019, we published design guidelines for developing media apps for cars, added wizard support to Android Studio, updated emulator to have car specific controls and the Android Automotive OS emulator system image. These latest features helped Android developers start to design, as well as develop and test their existing media apps to run on Android Automotive OS (review developer documentation here).
Today, we’re announcing that developers can download an updated Android Automotive OS emulator system image that includes the Google Play Store. This means developers no longer have to wait to get their hands on a vehicle, but can design, develop, run apps right within the emulator, and can now test distribution via Play Console by requesting access.
In addition to the apps announced at Google I/O, more media app developers, including Amazon Music, Audioburst and YouTube Music, are adapting their apps for Android Automotive OS. The process of porting existing media apps that support Android Auto to this platform is simple and requires minimal development resources.
Audioburst, Amazon Music and YouTube Music running on the Android Automotive OS emulator
And if you want to learn more about creating apps for Android Automotive OS — join us at Android Dev Summit 2019. Come talk to us in our sandbox, tune in via livestream on YouTube, or post on the automotive-developers Google Group or Stack Overflow using android-automotive tags.
We hope to see you there!
Android NDK r21 is now in beta! It’s been a longer than usual development cycle (four months since NDK r20), so there’s quite a lot to discuss for this release.
We have the usual toolchain updates, improved defaults for better security and performance, and are making changes to our release process to better accommodate users that need stability without hindering those that want new features.
This release comes with new minimum system requirements. Following Android Studio and the SDK, 32-bit Windows is no longer supported. While this change will not affect most developers, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. Linux users must have glibc 2.17 or newer.
One release a year will be our Long Term Support (LTS) release for users that want stability more than they need new features. The release will undergo a longer beta cycle before being released, and will receive bug fixes as backports until next year’s LTS release. Generally releasing in Q4, our first LTS release will be NDK r21.
The non-LTS releases each year, which we call the “rolling” release, will be similar to our current process. These will be approximately quarterly releases of our latest set of features, which will only be patched later for critical toolchain fixes. If you want the latest features from Clang and libc++, this is the release for you.
More detail, including the criteria we will use to determine what will be backported, what kinds of bugs will trigger a point release, and the bar we hold each release to can be found documented on our GitHub Wiki.
There are quite a lot of new things in this release, resolving bugs and helping you write better, safer code.
We’ve updated GNU Make to version 4.2, which enables --output-sync to avoid interleaving output with error messages. This is enabled by default with ndk-build. This also includes a number of bug fixes, including fixing the pesky CreateProcess errors on Windows.
--output-sync
CreateProcess errors on Windows
GDB has been updated to version 8.3, which includes fixes for debugging modern Intel CPUs.
As always, we’ve updated LLVM and all of its components (Clang, lld, libc++, etc) which includes many improvements.
The toolchain has been updated to r365631 (the master branch as of 10 July 2019). This includes fixes for quite a few bugs in the previous release, perhaps most importantly LLD no longer hangs when using multithreaded linking on Windows. OpenMP is now available as a dynamic library (and this is the new default behavior, so link with -static-openmp if you want to stick with the static runtime).
-static-openmp
A handful of driver improvements have been made to reduce the amount of compiler configuration required by each build system as well. Build system owners should check the updated Build System Maintainers guide.
libc++ has been updated to r369764.
Fortify is now enabled by default when using ndk-build or the CMake toolchain file (this includes ExternalNativeBuild users). Fortify enables additional checks in the standard library that can help catch bugs sooner and mitigate security issues. For example, without fortify the following code compiles fine:
ExternalNativeBuild
const char src[] = "this string is too long"; char dst[10]; strcpy(dst, src);
With fortify, the buffer overflow is diagnosed at compile-time:
test.cpp:10:18: error: 'strcpy' called with string bigger than buffer strcpy(dst, src); ^
It is not always possible for the compiler to detect this issue at compile-time. In those cases, a run-time check will be used instead that will cause the program to abort rather than continue unsafely.
If you’re using a build system other than ndk-build or CMake via the NDK’s toolchain file, this will not be enabled by default. To enable, simply define _FORTIFY_SOURCE=2. The most reliable way to do this is by adding -D_FORTIFY_SOURCE=2 to your compiler flags.
_FORTIFY_SOURCE=2
-D_FORTIFY_SOURCE=2
Clang can also statically detect some of these issues by using -Wfortify-source (also new in r21). This is on by default, but it’s recommended to enforce fixing issues with -Werror=fortify-source. Use this in addition to the C library features, not instead of, since the warnings do not cover the same cases as the C library extension, nor can it add run-time checks.
-Wfortify-source
-Werror=fortify-source
Note that because run-time support is required for fortify and the feature was gradually added to Android over time, the exact set of APIs protected by fortify depends on your minSdkVersion. Fortify is an improvement, but it is not a replacement for good tests, ASan, and writing safe code.
minSdkVersion
See FORTIFY in Android for an in-depth explanation of fortify.
Since August 2019, all existing and new apps are now required to support 64-bit before they can be released to Google Play; there’s an extension for a limited set of apps. For more information and help on adding support for 64-bit, see our guide.
Arm code is now built with Neon by default. In a previous release we enabled it conditionally based on minSdkVersion, but given the very small number of devices that don’t support Neon we now enable it unconditionally. This offers improved performance on all 32-bit Arm devices (64-bit Arm always had this, and it does not affect Intel ABIs).
As before, this behavior can be disabled for apps that need to continue supporting devices without Neon. Alternatively, those devices can be blacklisted in the Play Console. See https://developer.android.com/ndk/guides/cpu-arm-neon for more information.
Have a look at our roadmap to see what we’re working on next. The next few big things coming up are package management and better CMake integration.
In two weeks, we'll be welcoming Android developers from around the world at Android Dev Summit 2019, broadcasting live from the Google Events Center (MP7) in Sunnyvale, CA on October 23 & 24. Whether you’re joining us in person or via the livestream, we’ve got a great show planned for you; starting today, you can read more details about the keynote, sessions, codelabs, sandbox, the mobile app, and how online viewers can participate.
The summit kicks off on October 23 at 10 a.m. PDT with a keynote, where you'll hear from Dave Burke, VP Engineering for Android, and others on the present and future of Android development. From there, we'll dive into two days of deep technical content from the Android engineering team, on topics such as Android platform, Android Studio, Android Jetpack, Kotlin, Google Play, and more.
The full agenda is now available, so you can start to plan your summit experience. We'll also have demos in the sandbox, hands-on learning with codelabs, plus exclusive content for those watching on the livestream.
The official app for Android Dev Summit 2019 has started rolling out on Google Play. With the app, you can explore the agenda by searching through topics and speakers. Plan your summit experience by saving events to your personalized schedule. You’ll be able to watch the livestream and find recordings after sessions occur, and more. (By the way, the app is also an Instant app, so with one tap you can try it out first before installing!)
We’ll be broadcasting live on YouTube and Twitter starting October 23 at 10 a.m. PDT. In addition to a front row seat to over 25 Android sessions, there will be exclusive online-only content and an opportunity to have your most pressing Android development questions answered live, broadcast right from the event.
Tweet us your best questions using the hashtag #AskAndroid in the lead-up to the Android Dev Summit. We’ve gathered experts from Jetpack to Kotlin to Android 10, so we’ve got you covered. We’ll be answering your questions live between sessions on the livestream. Plus, we will share updates directly from the Google Events Center to our social channels, so be sure to follow along!
Developers often use the Android Emulator during their day-to-day development to quickly test the latest changes before they are being committed. In addition, developers are increasingly using the emulator in their continuous integration (CI) systems to run a larger suite of automated tests. To better support this use-case, we are open sourcing the Android Emulator Container Scripts and improving the developer experiences around two pain points:
Android supports a wide variety of hardware and software configurations, and the Android Emulator is no different. However, this wide variety can create confusion over environment configurations. How should developers obtain emulators and system images? What drivers are required? How do you run with or without CPU or GPU acceleration? (etc. etc.)
To address this we have launched:
To increase reproducibility, the underlying Dockerfile template makes the required command line flags and system dependencies more explicit (and reproducible via building Docker images from them). For hardware acceleration, note the --privileged flag that is passed to run.sh; we assume CPU acceleration is available when running the emulator, and --privileged is needed to run the containers with CPU acceleration (KVM) enabled.
For more details on how to create and deploy the Android Emulator image, go to the README.
When the emulator is running and a test or the emulator fails, it can be difficult to dive into the running environment and diagnose the error. Often, diagnosis requires direct interaction with the virtual device. We provide two mechanisms for direct interaction:
In the case of ADB, we allow all commands, such as logcat and shell, by forwarding a particular port from the Docker guest to the host. Because the current port is 5555, we'll need to collect more feedback and do more research on how best to separate ports across different containers.
Security note: With remote streaming, keep in mind that once the service is started, anyone who can connect to your computer on port 80/443 can interact with the emulator. So be careful with running this on a public server!
With remote streaming, you can run the emulator in a container, which is as interactive as running locally. Running the emulator in a container makes it easier to debug issues that can be hard to discover using ADB commands. You can access the emulator using a browser with WebRTC, which is used to stream the video, and gRPC, which is used to send mouse and keyboard events to the emulator. Remote streaming requires three containers:
You can compose the Docker containers together using docker-compose, as described in the README. The containers bind to port 80 and 443, so make sure you do not have a web server running. A self-signed certificate will be offered if you point the browser to the host. If you point your browser to the host you should see something like the image below:
Again, keep in mind that anyone who can connect to your host can interact with the emulator. So be careful with running this on a public server!
Testing can seem to be a tax on development time. However, as many seasoned developers have seen, proper automated testing can increase development velocity as the code base becomes bigger and more complex. Continuous testing should give you confidence that the change you make won’t break your app.
With over 2.5 billion active Android devices, Google Play helps your apps and games get discovered by billions of users worldwide. And from the latest Google Play Store visual refresh to the Indie Games Showcase, we’re constantly working to help users find apps and games they love while helping you grow successful businesses. Today we’re excited to announce the US launch of Google Play Pass, a new subscription service offering access to hundreds of apps and games, completely free of ads and in-app purchases. Play Pass provides subscribers with a high-quality, curated collection of titles–with new titles added frequently.
Letting diverse, high-quality content shine
Play Pass is designed to enable Google Play users to better experience the variety of content on Play, and all types of apps and games can participate. “For a small studio like ours, being part of Play Pass makes a huge amount of sense,” said Jon Ingold of inkle. “We have the expertise and the creative freedom to create games unlike anything subscribers have ever played before, and we hope they will be thrilled by what they discover as they lose themselves in the worlds we’ve made.”
A new way to make money
Being a part of Google Play Pass’s curated collection of apps and games can help you attract new users who may not have discovered your titles on their own. Subscribers can find your content either through the new “Play Pass” tab or by looking for the Play Pass “ticket” badge that indicates apps and games unlocked with Play Pass. And the more value subscribers find in your title, the more revenue you’ll earn on a recurring basis.
In addition, for a limited time, we’re offering a low introductory price for Play Pass subscribers so that even more users will subscribe and discover Play Pass content. Google is funding this launch offer so that you can benefit from subscriber interest without impacting the revenue you can earn.
Little work, lots of opportunity
The same APK that distributes your app or game in the Google Play Store can be used for Play Pass with minimal development work, so you can keep one version of your app or game updated for all of your users. We'll make sure your content is easily identifiable as part of Play Pass and enjoyed without interruptions, so you can stay focused on creating amazing experiences without compromise.
Express interest
If you’re building a great experience that Play Pass users would love, get more information and fill out this form to express interest in participating. Play Pass is currently invitation-only, though we’ll regularly be inviting more developers to participate, so stay tuned!
How useful did you find this blog post?
★ ★ ★ ★ ★
Want to learn to build Android apps in Kotlin? Get started with the Kotlin Bootcamp for Programmers and Developing Android apps in Kotlin codelabs courses.
Google and Udacity currently offer video-based courses for Kotlin Bootcamp and How to build Android apps in Kotlin. To help people that learn in different ways, we have recently reworked these courses to publish them as tutorial-based codelab courses. More than 2.5 million users have worked through Google codelabs like this just this year.
Google provides first class support for building Android apps in Kotlin, including Kotlin-friendly Android APIs and API extensions. Kotlin fully interoperates with the Java programming language and libraries, and is included with IntelliJ and Android Studio.
In the Kotlin Bootcamp course, you will learn everything you need to program in Kotlin, beginning with the basics such as how to write Kotlin statements, and working up to functional manipulation such as extending builtin functions.
If you already know how to program, the Kotlin Bootcamp provides the foundation you'll need to build Android apps in Kotlin.
Start the Kotlin Bootcamp now!
When you feel comfortable with Kotlin, you can dive right into building Android apps. This course takes you from "Hello World" to connecting with the world. You start building a basic interactive user interface on one screen, and end with a multi-screen Google Developer Group (GDG) Finder app that gets data from a live server on the internet. In between, you learn about Android Jetpack components, such as Room for databases, Work Manager for background processing, the Navigation component, and more. You'll use popular community libraries to simplify common tasks, such as Glide for image loading, Retrofit for networking, and Moshi for JSON parsing. The course teaches key Kotlin features such as coroutines to help you write your app code more quickly and concisely.
In each lesson, you will work with a realistically architected app and implement key features. For example, you start out learning how to deploy a dice roller app. You learn how to implement navigation by building the "Android Trivia" game. You learn how to create a Room database by building a sleep tracker app.
Overall, you will create and work with more than 10 apps, so, by the end of this course, you will have a portfolio of example code that you can use to realize your own amazing app ideas!
Get started now!
Billions of people rely on their Android-powered devices to securely store their sensitive information. A vital component of the Android security stack is the key attestation system. Android devices since Android 7.0 are able to generate an attestation certificate that attests to the security properties of the device’s hardware and software. OEMs producing devices with Android 8.0 or higher must install a batch attestation key provided by Google on each device at the time of manufacturing.
These keys might need to be revoked for a number of reasons including accidental disclosure, mishandling, or suspected extraction by an attacker. When this occurs, the affected keys must be immediately revoked to protect users. The security of any Public-Key Infrastructure system depends on the robustness of the key revocation process.
All of the attestation keys issued so far include an extension that embeds a certificate revocation list (CRL) URL in the certificate. We found that the CRL (and online certificate status protocol) system was not flexible enough for our needs. So we set out to replace the revocation system for Android attestation keys with something that is flexible and simple to maintain and use.
Our solution is a single TLS-secured URL (https://android.googleapis.com/attestation/status) that returns a list containing all revoked Android attestation keys. This list is encoded in JSON and follows a strict format defined by JSON schema. Only keys that have non-valid status appear in the list, so it is not an exhaustive list of all issued keys.
This system allows us to express more nuance about the status of a key and the reason for the status. A key can have a status of REVOKED or SUSPENDED, where revoked is permanent and suspended is temporary. The reason for the status is described as either KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED, or SOFTWARE_FLAW. A complete, up-to-date list of statuses and reasons can be found in the developer documentation.
REVOKED
SUSPENDED
KEY_COMPROMISE
CA_COMPROMISE
SUPERSEDED
SOFTWARE_FLAW.
The CRL URLs embedded in existing batch certificates will continue to operate. Going forward, attestation batch certificates will no longer contain a CRL extension. The status of these legacy certificates will also be included in the attestation status list, so developers can safely switch to using the attestation status list for both current and legacy certificates. An example of how to correctly verify Android attestation keys is included in the Key Attestation sample.
