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.
Posted by Sameer Samat, Vice President, Platforms & Ecosystems
From day one, we designed Android to be a flexible, adaptive platform.
Most people picture a smartphone when they think of Android, but Android also powers an amazing number of large-screen devices. In fact, there are more than 175 million Android tablets with the Google Play store,1 making Android tablets a vital form factor for Google and our OEM partners today. Android apps also run on Chrome OS laptops, and the number of monthly active users who enabled Android apps grew 250% in just the last year.2
Here at Google, we’re excited to see how you can take advantage of large-screen formats - including Samsung’s new Galaxy Tab S6, the upcoming Lenovo™ Smart Tab M8 with Google Assistant, the upcoming Samsung Galaxy Fold, and other devices launching this week at IFA. Our OEM partners are building experiences that help users every day:
From the start, Android was designed as a platform that could handle multiple screen sizes. Over the years, we’ve continued to add functionality for developers to accommodate new devices and form factors.
Android’s layout system helps applications smoothly resize and adjust their layout interactively.
By optimizing your app to take advantage of different form factors, developers have an opportunity to deliver richer, more engaging experiences to millions of users on larger screens. And if you don’t have access to physical devices, the Android Emulator supports all of the form factors mentioned above, from Chrome OS to phones and tablets.
Developers of apps like Mint, Evernote, and Asphalt are just a few who have seen success from taking their existing APK to larger screens.
To learn more about optimizing your Android apps for richer experiences on tablets, Chrome OS laptops, foldables, and more, join us at the Android Developer Summit on October 23-24 — either in person or via the livestream — or check out our recap videos on YouTube.
Sources:
[1] The number of tablets only accounts for devices that have the Google Play Store installed (for example, this excludes tablets in China); the actual number of tablets capable of running Android applications is much larger.
[2] Google Internal Data, March 2018 to March 2019.
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
