Category Archives: Android Developers Blog

An Open Handset Alliance Project

Handling Nullability in Android 11 and Beyond

Posted by David Winer, Kotlin Product Manager

Android blog banner

Last May at Google I/O, we announced that Android was going Kotlin first, and now over 60% of the top 1000 Android apps use Kotlin. One feature we love about Kotlin is that nullability is baked into its type system — when declaring a reference, you say upfront whether it can hold null values. In this post, we’ll look at how the Android 11 SDK does more to expose nullability information in its APIs and show how you can prepare your Kotlin code for it.

How does nullability in Kotlin work?

When writing code in Kotlin, you can use the question mark operator to indicate nullability: 

KOTLIN

var x: Int = 1
x = null // compilation error

var y: Int? = 1
y = null // okay

This aspect of Kotlin makes your code safer — if you later call a method or try to access a property on a non-null variable like x, you know you’re not risking a null pointer exception. We hear over and over again that this feature of Kotlin gives developers more peace of mind and leads to higher quality apps for end users.

How does nullability work with the Java programming language?

Not all of your (or Android’s) APIs are written in Kotlin. Fortunately, the Kotlin compiler recognizes annotations on Java programming languages methods that indicate whether they produce nullable or non-nullable values. For example: 

JAVA

public @Nullable String getCurrentName() {
   return currentName;
}

The @Nullable annotation ensures that when using the result of getCurrentName in a Kotlin file, you can’t dereference it without a null check. If you try, Android Studio will notify you of an error, and the Kotlin compiler will throw an error in your build. The opposite is true of @NonNull — it tells the Kotlin compiler to treat the method result as a non-null type, forbidding you from assigning that result to null later in your program.

The Kotlin compiler also recognizes two similar annotations, @RecentlyNullable and @RecentlyNonNull, which are the exact same as @Nullable and @NonNull, only they generate warnings instead of errors1.

Nullability in Android 11

Last month, we released the Android 11 Developer Preview, which allows you to test out the new Android 11 SDK. We upgraded a number of annotations in the SDK from @RecentlyNullable and @RecentlyNonNull to @Nullable and @NonNull (warnings to errors) and continued to annotate the SDK with more @RecentlyNullable and @RecentlyNonNull annotations on methods that didn’t have nullability information before.

What’s next

If you are writing in Kotlin, when upgrading from the Android 10 to the Android 11 SDK, you may notice that there are some new compiler warnings and that previous warnings may have been upgraded to errors. This is intended and a feature of the Kotlin compiler — these warnings tell you that you may be writing code that crashes your app at runtime (a risk you would miss entirely if you weren’t writing in Kotlin). As you encounter these warnings and errors, you can handle them by adding null checks to your code.

As we continue to make headway annotating the Android SDK, we’ll follow this same pattern — @RecentlyNullable and @RecentlyNonNull for one numbered release (e.g., Android 10), and then upgrade to @Nullable and @NonNull in the next release (e.g., Android 11). This practice will give you at least a full release cycle to update your Kotlin code and ensure you’re writing high-quality, robust code.

1. Due to rules regarding handling of annotations in Kotlin, there is currently a small set of cases where the compiler will throw an error for @Nullable references but not for @RecentlyNullable references.

Java is a trademark of Oracle and/or its affiliates.

Join us for the digital Google for Games Developer Summit

Posted by the Google for Games Team GDC banner

Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.

Google for Games Developer Summit

The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.

Here are some types of sessions to expect:

  • Success stories from industry leaders on how they’ve conquered game testing, built backend infrastructure, and launched great games across all platforms.
  • New announcements like Android development and profiling tools that can help deploy large APKs to devices faster, fine tune graphic performance, and analyze device memory more effectively.
  • Updates on products like Game Servers (currently in alpha)—a fully managed offering of Agones, letting developers easily deploy and manage containerized game servers around the globe.

Sign up to stay informed at g.co/gamedevsummit.

Support for the game developer community

We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.

We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.

We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.

This article was cross-posted from the Google Developer Blog. Google Play will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Google Play even more powerful for game developers!

Android Platform Codelab Kickstarts OS Development

Posted by Clay Murphy, Technical Writer

The Android Platform Codelab has been published to take developers from bare metal to a (virtual) device under test in a single page. This document will help new Android operating system engineers quickly learn the tools and processes needed to establish a build environment, sync the repository, build a virtual device image, and load that image onto an Android virtual device (AVD), allowing quick iteration of platform changes.

The codelab walks through:

  1. Environment setup
  2. Downloading of code
  3. Creating a Cuttlefish Android Virtual Device (AVD) image
  4. Building the OS
  5. Using Acloud to set up and render the Cuttlefish AVD
  6. Creating and testing changes
  7. Uploading, reviewing, and reverting those modifications

If you encounter errors during this codelab, please report them using the Site feedback link on the bottom of any page. Send questions to the android-building group.

Unveiling expert insights in our new podcast series: Apps, Games, & Insights

Posted by Lily Sheringham, Global Marketing, Platforms & Ecosystems

This is a cross-post from The Google Keyword blog.

Apps, Games, & Insights illustrated banner with gaming imagery.

Today we’re launching the Apps, Games, & Insights podcast series, bringing together insights, stories, and learnings from industry experts, on some of today's hottest topics surrounding mobile, apps and games businesses, and the wider industry.

Listen to the podcast here!

The series has eight episodes which aim to challenge, provoke thought, and enlighten listeners - from designers and developers, through to product managers and marketers, and those interested in the apps and games industry.

The podcast is hosted by Googlers Tamzin Taylor, who heads up Apps & Games Business Development for Google Play in Western Europe, and Dirk Primbs, who leads the Ecosystem Developer Relations team in EMEA. Together, they have many years of experience working with partners to assist with Android development, mobile, app, game, and business growth. Every week they will be joined by different guests for each of the episodes.

Sneak peek at what’s coming up

Kicking off the series are Judy Chen and Sarah Fuchs from Crowdstar, the developers of Covet Fashion and Design Home. They join us for episode 1 to discuss how to build a long-term games business by taking a holistic approach to the game, its players, and the people who create the game.

Ever wonder if it's worth selling your app or game business, and if so how to approach it? It's not all about pocketing the cash and walking away. For episode 2, game mergers and acquisitions expert Chris Petrovic from Zynga will talk about how acquisition can free developers to focus on what they love: creating great apps and games.

The popularity of subscriptions continues to grow, with developers who used subscriptions earning 4X more in 2018, than in 2016. Holly Ackerman and David Berlin, from the sports streaming platform DAZN, join us for episode 3 to provide some fascinating insights into how they have grown their subscription business in this industry.

Whether you are a startup in search of funding or an established business looking to accelerate your investment, venture capital can often be a good source of funds. In episode 4, venture capital expert Matteo Vallone from Cherry Ventures offers insights into the investment process and how to maximize your appeal to investors.

For episode 5, we have what is possibly one of the biggest topics in mobile and throughout the tech industry: privacy. Bruce Gustafson, CEO of Developers Alliance brings us up to speed on trust and safety, platform value, respecting the user, and ultimately building privacy friendly apps and games.

Successful game developers put players front and center of everything they do. When over 270 million people have played your games, you must be doing something right. Ben Clarke, Senior Global Marketing Director at Jagex, joins us for episode 6 to discuss some of the innovative approaches to player engagement and retention taken in their RuneScape games.

Figuring out how to make your app or game accessible to all can often be a challenge, sometimes both from an organizational and technical perspective. However, many developers have made accessibility a core part of their app development process and company culture. For episode 7, we’re joined by Ceri Lindsay and Rosalind Whittam from the BBC to discover how they address accessibility.

Today, Android is not just about smartphones, Android apps and games can run on a range of devices with larger screens, such as Chromebooks. At the same time, mature mobile game franchises are looking for opportunities beyond mobile. In our final episode 8, we’ll be joined by Maximiliano Rodriguez of Gameloft to talk about the challenge of taking games to big screens and new platforms.

We hope you’ll join us over the next eight weeks to dive deeper and hear what our thought leader guests have to say on each topic.

How to stay tuned in

To listen to our first podcast and find out more about what’s coming, check out our new Apps, Games, & Insights podcast homepage.

Listen to our first episode here, or on Spotify, Apple Podcasts, Google Play Music, Google Podcasts, Deezer, iHeartRadio, and also on LibSyn. Keep an eye out on @GooglePlayDev and @AndroidDev on Twitter where we will be announcing the launch of the new episodes each week.

How useful did you find this blog post?

★ ★ ★ ★ ★

Update on Google at GDC 2020

Posted by the Google for Games Team

Last Friday, GDC 2020 organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community.

Every year, we look forward to the Game Developers Conference and surrounding events because it gives our teams a chance to connect with game developers, partners, and friends in the industry.

Although we won’t be connecting in-person this year, we’re still excited to share the latest announcements from Google with everyone through our digital experience. We'll be sharing plans for our digital experience in the coming days.

Thank you to all who keep this community thriving and check back soon at g.co/gdc2020 for more details.

Data Encryption on Android with Jetpack Security

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Illustration by Virginia Poltrack

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples.

The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets.

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection.

Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink.

Key Generation

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object.

Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices. 

val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices.

Important options:

  • userAuthenticationRequired() and userAuthenticationValiditySeconds() can be used to create a time-bound key. Time-bound keys require authorization using BiometricPrompt for both encryption and decryption of symmetric keys.
  • unlockedDeviceRequired() sets a flag that helps ensure key access cannot happen if the device is not unlocked. This flag is available on Android Pie and higher.
  • Use setIsStrongBoxBacked(), to run crypto operations on a stronger separate chip. This has a slight performance impact, but is more secure. It’s available on some devices that run Android Pie or higher.

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present. 

// Custom Advanced Master Key
val advancedSpec = KeyGenParameterSpec.Builder(
    "master_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
).apply {
    setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    setKeySize(256)
    setUserAuthenticationRequired(true)
    setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        setUnlockedDeviceRequired(true)
        setIsStrongBoxBacked(true)
    }
}.build()

val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec)

Unlocking time-bound keys

You must use BiometricPrompt to authorize the device if your key was created with the following options:

  • userAuthenticationRequired is true
  • userAuthenticationValiditySeconds > 0

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user.

BiometricPrompt code to unlock time-bound keys 

// Activity.onCreate

val promptInfo = PromptInfo.Builder()
    .setTitle("Unlock?")
    .setDescription("Would you like to unlock this key?")
    .setDeviceCredentialAllowed(true)
    .build()

val biometricPrompt = BiometricPrompt(
    this, // Activity
    ContextCompat.getMainExecutor(this),
    authenticationCallback
)

private val authenticationCallback = object : AuthenticationCallback() {
        override fun onAuthenticationSucceeded(
            result: AuthenticationResult
        ) {
            super.onAuthenticationSucceeded(result)
            // Unlocked -- do work here.
        }
        override fun onAuthenticationError(
            errorCode: Int, errString: CharSequence
        ) {
            super.onAuthenticationError(errorCode, errString)
            // Handle error.
        }
    }

To use:
biometricPrompt.authenticate(promptInfo)

Encrypt Files

Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it's not possible to reorder. 

val secretFile = File(filesDir, "super_secret")
val encryptedFile = EncryptedFile.Builder(
    secretFile,
    applicationContext,
    advancedKeyAlias,
    FileEncryptionScheme.AES256_GCM_HKDF_4KB)
    .setKeysetAlias("file_key") // optional
    .setKeysetPrefName("secret_shared_prefs") // optional
    .build()

encryptedFile.openFileOutput().use { outputStream ->
    // Write data to your encrypted file
}

encryptedFile.openFileInput().use { inputStream ->
    // Read data from your encrypted file
}

Encrypt SharedPreferences

If your application needs to save Key-value pairs - such as API keys - JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to.

Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups. 

EncryptedSharedPreferences.create(
    "my_secret_prefs",
    advancedKeyAlias,
    applicationContext,
    PrefKeyEncryptionScheme.AES256_SIV,
    PrefValueEncryptionScheme.AES256_GCM
).edit {
    // Update secret values
}

More Resources

FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security.

Happy Encrypting!

Android Studio 3.6

Posted by Scott Swarthout, Product Manager

Android Studio logo

We are excited to announce the stable release of Android Studio 3.6 with a targeted set of features addressing quality in primarily code editing and debugging use cases. This is our first release after the end of Project Marble, which was focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. We learned a lot from Project Marble and in Android Studio 3.6 we introduce a small set of features, polished existing features, and spent a notable effort addressing bugs and improving underlying performance to ensure we meet the high quality bar we set in the past year.

Some highlights of Android Studio 3.6 include a new way to quickly design, develop and preview app layouts using XML, with a new Split View in the design editors. Additionally, you no longer have to manually type in GPS coordinates to test location with your app because we now embedded Google Maps right into the Android Emulator extended control panel. Finally, we’ve made it easier to optimize your app and find bugs with automatic memory leak detection for Fragments and Activities. We hope all of these features help you be happier and more productive while developing on Android.

Thank you to those who gave your early feedback in preview releases. Your feedback helped us iterate and improve features in Android Studio 3.6. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.6 is ready to download for you to get started.

Below is a full list of new features in Android Studio 3.6, organized by key developer flows.

Design

Split view in design editors

Design editors, such as the Layout Editor and Navigation Editor, now provide a Split view that enables you to see both the Design and Code views of your UI at the same time. Split view replaces and improves upon the earlier Preview window, and can be configured on a file-by-file basis to preserve context information like zoom factor and design view options, so you can choose the view that works best for each use case. To enable split view, click the Split icon in the top-right corner of the editor window. Learn more.

Split view for design editors

Split view for design editors

Color picker resource tab

In this release we wanted to make it easier to apply colors you have defined as color resources. In Android Studio 3.6, the color picker populates the color resources in your app for you to quickly choose and replace color resources values. The color picker is accessible in the design tools as well as in the XML editor.

Color picker resource tab

Color picker resource tab

Develop

View binding

View binding is a feature that allows you to more easily write code that interacts with views by providing compile-time safety when referencing views in your code. When enabled, view binding generates a binding class for each XML layout file present in that module. In most cases, view binding replaces findViewById. You can reference all views that have an ID with no risk of null pointer or class cast exceptions.These differences mean that incompatibilities between your layout and your code will result in your build failing at compile time rather than at runtime. To enable view binding in your project, include the following in each module’s build.gradle file: 

android {
    viewBinding.enabled = true
}

For more information, check out this blog post by one of our developer experts.

Android NDK updates

The following Android NDK features in Android Studio, previously supported in Java, are now also supported in Kotlin:

  • Navigate from a JNI declaration to the corresponding implementation function in C/C++. View this mapping by hovering over the C or C++ item marker near the line number in the managed source code file.
  • Automatically create a stub implementation function for a JNI declaration. Define the JNI declaration first and then type “jni” or the method name in the C/C++ file to activate.

Learn more

IntelliJ Platform Update

Android Studio 3.6 includes the IntelliJ 2019.2 platform release. This IntelliJ release includes many improvements from a new services tool window to much improved startup times. Learn more

Add classes with Apply Changes

You can now add a class and then deploy that code change to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.

To learn more about the difference between these two actions, see Apply Changes.

Build

Android Gradle Plugin (AGP) updates

Android Gradle plugin 3.6 and higher includes support for the Maven Publish Gradle plugin, which allows you to publish build artifacts to an Apache Maven repository. The Android Gradle plugin creates a component for each build variant artifact in your app or library module that you can use to customize a publication to a Maven repository. This change will make it easier to manage the release lifecycle for your various targets. Learn more

Additionally, Android Gradle plugin has made significant performance improvement for annotation processing/KAPT for large projects. This is caused by AGP now generating R class bytecode directly, instead of .java files.

New packaging tool

The Android build team is continuously working on changes to improve build performance, and in this release we changed the default packaging tool to zipflinger for debug builds. Users should see an improvement in build speed, but you can also revert to using the old packaging tool by setting android.useNewApkCreator=false in your gradle.properties file.

Edit your gradle.properties file to disable the new packaging tool

Edit your gradle.properties file to disable the new packaging tool

Test

Android Emulator - Google Maps UI

Android Emulator 29.2.12 includes a new way for app developers to interface with the emulated device location. We embedded the Google Maps user interface in the extended controls menu to make it easier to specify locations and also to construct routes from pairs of locations. Individual points can be saved and re-sent to the device as the virtual location, while routes can be generated through typing in addresses or clicking two points. These routes can be replayed in real time as locations along the route are sent to the guest OS.

Android Emulator location UI with real-time location streaming

Android Emulator location UI with real-time location streaming

Multi-display support

Emulator 29.1.10 includes preliminary support for multiple virtual displays. As more devices are available that have multiple displays, it is important to test your app on a variety of multi-display configurations. Users can configure multiple displays through the settings menu (Extended Controls > Settings).

Multi-display support in Android Emulator

Multi-display support in Android Emulator

Configure secondary displays in the Android Emulator Extended Controls Panel

Configure secondary displays in the Android Emulator Extended Controls Panel

Resumable SDK downloads

When downloading Android SDK components and tools using the Android Studio SDK Manager, Android Studio now allows you to resume downloads that were interrupted (for example, due to a network issue) instead of restarting the download from the beginning. This enhancement is especially helpful for large downloads, such as the Android Emulator or system images, when internet connectivity is unreliable.

Pause and resume SDK downloads

Pause and resume SDK downloads

In-place updates for imported APKs

Android Studio allows you to import externally-built APKs to debug and profile them. Previously, when changes to those APKs were made, you would have to manually import them again and reattach symbols and sources. Android Studio 3.6 now automatically detects changes made to the imported APK file and gives you an option to re-import it in-place.

Attach Kotlin sources to imported APKs

We added support for attaching Kotlin source files to imported APKs. To learn more, see Attach Kotlin/Java sources.

Attach Kotlin/Java sources to imported APKs

Attach Kotlin/Java sources to imported APKs

Optimize

Leak detection in Memory Profiler

Based on your feedback, we’ve added in the Memory Profiler the ability to detect Activity and Fragment instances which may have leaked. To get started, capture or import a heap dump file in the Memory Profiler, and check the Activity/Fragment Leaks checkbox to generate the results. For more information on how Android Studio detects leaks, please see our documentation.

Detect leaked Activities and Fragments in the Memory Profiler

Detect leaked Activities and Fragments in the Memory Profiler

Deobfuscate class and method bytecode in APK Analyzer

When using the APK Analyzer to inspect DEX files, you can now deobfuscate class and method bytecode. While in the DEX file viewer, load the ProGuard mappings file for the APK you’re analyzing. When loaded, you will be able to right-click on the class or method you want to inspect by selecting Show bytecode. Learn more

Deobfuscate class and method bytecode by selecting Show Bytecode in the APK Analyzer

Deobfuscate class and method bytecode by selecting Show Bytecode in the APK Analyzer

To recap, Android Studio 3.6 includes these new enhancements & features:

Design

  • Split View in Design Editors
  • Color Picker Resource Tab

Develop

  • View binding
  • Android NDK support updates
  • IntelliJ Platform Update
  • Add classes with Apply Changes

Build

  • Android Gradle Plugin (AGP) Updates
  • New packaging tool

Test

  • Android Emulator Google Maps UI
  • Multi-display support
  • Resumable SDK downloads
  • In-place updates for imported APKs

Optimize

  • Leak detection in Memory Profiler
  • Deobfuscate class and method bytecode in APK Analyzer
  • Attach Kotlin sources to imported APKs

Getting Started

Download

Download Android Studio 3.6 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.2.12 downloaded via the Android Studio SDK Manager.

As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

Native Dependencies in Android Studio 4.0

By Dan Albert, Software Engineer

One thing that NDK users struggle with is managing native dependencies:

  • Library authors need to maintain support for both ndk-build and CMake (and hope that their users are using one of those two options and not something else).
  • Libraries don’t always distribute prebuilt binaries for Android, so users must either build the library themselves or rely on (potentially untrustworthy) prebuilt binaries found elsewhere on the web.
  • Android-specific build scripts are often out of date and no longer work.
  • Libraries are sometimes built by a build system that Android doesn’t support.
  • Libraries may not build on the user’s machine. For example, Unix shell scripts won’t run on Windows.
  • Libraries often depend on other libraries, leaving users to chase them down and start the process again.

With version 4.0 of the Android Gradle Plugin, we’ve addressed these issues by adding support for distributing and exposing native libraries through the same mechanism that you do for Java libraries: Android Archives (AARs).

Here’s how you’d use curl and jsoncpp for example (and automatically pull in the implicit OpenSSL dependency that curl has): 

// build.gradle
dependencies {
    implementation 'com.android.ndk.thirdparty:curl:7.68.0-alpha-1'
    implementation 'com.android.ndk.thirdparty:jsoncpp:1.8.4-alpha-1'
}

Note: With AGP 4.0 this is still experimental, so to enable this functionality you must set the following properties in your project's gradle.properties file: 

# Enables Prefab
android.enablePrefab=true
# Work around https://issuetracker.google.com/149575364
android.enableParallelJsonGen=false
# 4.0.0 canary 9 defaults to Prefab 1.0.0-alpha3, which is not the latest.
android.prefabVersion=1.0.0-alpha5

Importing packages into your build

Declaring the dependencies in your build.gradle will cause Gradle to download those dependencies from Maven, but you must still instruct CMake or ndk-build how those dependencies should be used. Fortunately, the necessary CMake package config or ndk-build module will be automatically generated on your behalf. All you need to do is import and use them.

Here’s an example with CMake: 

    cmake_minimum_required(VERSION 3.6)
    project(app VERSION 1.0.0 LANGUAGES CXX)

    find_package(curl REQUIRED CONFIG)
    find_package(jsoncpp REQUIRED CONFIG)

    add_library(app SHARED app.cpp)
    target_link_libraries(app curl::curl jsoncpp::jsoncpp)

And here’s the same example with ndk-build: 

    LOCAL_PATH := $(call my-dir)

    include $(CLEAR_VARS)
    LOCAL_MODULE := libapp
    LOCAL_SRC_FILES := app.cpp
    LOCAL_SHARED_LIBRARIES := jsoncpp curl
    include $(BUILD_SHARED_LIBRARY)

    $(call import-module,prefab/curl)
    $(call import-module,prefab/jsoncpp)

And that’s it. In app.cpp you can now do the following: 

#include "curl/curl.h"
#include "json/json.h"

A very common issue that people have is building OpenSSL to use with curl. While not explicitly mentioned in the build scripts above, the curl package itself depends on OpenSSL so this support is available automatically.

For the complete example, see the curl-ssl sample.

Prefab

The tool that facilitates all of this is called Prefab. Each AAR that exposes C++ libraries to its consumers packages their libraries, headers, and a small amount of metadata into the prefab directory in the AAR. If the prefab directory is found in an AAR dependency, the Android Gradle Plugin automatically runs Prefab to generate build system scripts from the contained information.

Each AAR might contain a large number of prebuilts for different configurations, so Prefab will perform a number of compatibility checks to find a suitable library for your build configuration. The selected library will match your build’s ABI, minSdkVersion, STL choice, and be the best fit for the version of the NDK that you’re using.

What libraries are available?

We’ve already published the following libraries:

  • com.android.ndk.thirdparty:curl:7.68.0-alpha-1
  • com.android.ndk.thirdparty:jsoncpp:1.8.4-alpha-1
  • com.android.ndk.thirdparty:openssl:1.1.1d-alpha-1
  • com.google.oboe:oboe:1.3.0

For an up to date list, search https://maven.google.com/web/index.html for “com.android.ndk.thirdparty”.

How can I distribute my own libraries?

For the libraries we currently distribute, we wrote ndkports. This is a good fit if the library you’re building is a typical Linux or cross-platform project that doesn’t fit naturally into a typical Android build. If that’s a fit for the library you want, feel free to use ndkports for it, and consider sending us the patch!

If you’d like to request that Google maintain and publish an open source library in Prefab, use the “Package request” bug template on https://github.com/google/prefab/issues. Please keep in mind that each package does come with an ongoing cost, and we will be adding support on a limited basis so we will not be able to support everything.

Coming next is support for exposing your libraries in AARs using the existing Android Library publishing workflow.

Links

For more information about using native dependencies with the Android Gradle Plugin, see the documentation. For more examples, see the NDK samples.

If you’d like to learn more about Prefab itself, see its documentation on GitHub.

If you encounter any issues, file bugs in our Issue Tracker.

Turning it up to 11: the first Developer Preview of Android 11

Posted by Dave Burke, VP of Engineering



Android 11 Dial logo

Android has led the way towards the future of mobile, with new technologies like 5G to foldable displays to machine learning built into the core. A hallmark of our approach is a strong developer community that provides early and thoughtful feedback, helping us deliver a robust platform for apps and games that delight billions of users around the world. So today, we’re releasing the first Developer Preview of Android 11, and building on a strong feedback cycle last year, we’re making this year’s preview available to you earlier than ever.

With Android 11 we’re keeping our focus on helping users take advantage of the latest innovations, while continuing to keep privacy and security a top priority. We’ve added multiple new features to help users manage access to sensitive data and files, and we’ve hardened critical areas of the platform to keep the OS resilient and secure. For developers, Android 11 has a ton of new capabilities for your apps, like enhancements for foldables and 5G, call-screening APIs, new media and camera capabilities, machine learning, and more.

This is just a first look; like prior years, we’ll continue to share new features and updates over the coming months and into Google I/O as we work through your feedback. The most important thing for you to do right now is this: visit the Android 11 developer site, download a system image for your Pixel 2, 3, 3a, or 4 device, and let us know what you think!

Today’s release is an early baseline build for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Remember, getting early input from you is crucial in helping us evolve the platform to meet your needs. Read on for a taste of what’s new in Android 11, and visit the developer site for details on timeline, how to test, and how to give feedback.

Helpful innovation

5G experiences

5G brings consistently faster speeds and lower latency to more users around the world. With 5G you can extend your Wi-Fi app experiences -- such as streaming 4K video or loading higher-res game assets -- to mobile users, or you can build new experiences designed specifically for 5G. In Android 11 we’re enhancing and updating the existing connectivity APIs so you can take advantage of 5G’s improved speeds.

  • Dynamic meteredness API - with this API you can check whether the connection is unmetered, and if so, offer higher resolution or quality that may use more data. We’ve extended the API to include cellular networks, so that you can identify users whose carriers are offering truly unmetered data while connected to the carrier’s 5G network.
  • Bandwidth estimator API - we’ve updated this API for 5G to make it easier to check the downstream/upstream bandwidth, without needing to poll the network or compute your own estimate. If the modem doesn’t provide support, we make a default estimation based on the current connection.


Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses.

Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses.



New screen types

Device makers are continuing to innovate by bringing exciting new form-factors and device screens to market. We’ve extended support for these in the platform, with APIs to let you optimize your apps.

  • Pinhole and waterfall screens - Apps can manage pinhole screens and waterfall screens using the existing display cutout APIs. If you want, a new API lets your app use the entire waterfall screen including the edges, with insets to help you manage interaction near the edges.


People and conversations

Communicating with your friends and colleagues is the most important thing many people do on their phones. In Android 11, we are introducing changes that help developers create deeper conversational experiences, a few of which you’ll see early versions of in DP1:

  • Dedicated conversations section in the notification shade - users can instantly find their ongoing conversations with people in their favorite apps.
  • Bubbles - Bubbles are a way to keep conversations in view and accessible while multi-tasking on their phones. Messaging and chat apps should use the Bubbles API on notifications to enable this in Android 11.
  • Insert images into notification replies - if your app supports image copy/paste, you can now let users insert assets directly into notification inline replies to enable richer communication as well as in the app itself. As part of DP1 - you’ll see image copy support in Chrome and image paste support via Gboard clipboard.
Real-time, bilateral communication apps should use the sharing/conversation shortcuts API to provide People targets that Android will surface throughout the phone as well as Bubble APIs to allow users to carry on conversations while using the device in other capacities.

Neural Networks API 1.3

Neural Networks API (NNAPI) is designed for running computationally intensive operations for machine learning on Android devices. In Android 11, we’re expanding the operations and controls available to developers. In this release, we’ve added new operations and execution controls to help optimize common use cases:

  • Quality of Service APIs support priority and timeout for model execution.
  • Memory Domain APIs reduce memory copying and transformation for consecutive model execution.
  • Expanded quantization support, we’ve added signed integer asymmetric quantization where signed integers are used in place of float numbers to enable smaller models and faster inference.

See the NDK sample code for examples using these new APIs.

Watch for more coming in later preview updates. We’re working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.3.

Privacy and security

Privacy

Privacy has always been at the core of Android, and each year we’ve added more ways to keep users secure and increase transparency and control. These changes have been popular with users - for example in Android 10 we added the “While app is in use” permission option to give users more granular control over their location and limit background location access. So far, when given the “While app is in use” option, about half of users select it.

In Android 11 we’re continuing our focus on user privacy with new permission options, updates to scoped storage, and more. Please give these features a try with your apps right away and let us know what you think.

  • One-time permission - For the most sensitive types of data - not just location but also for the device microphone and camera - users can now grant temporary access through a one-time permission. This permission means that apps can access the data until the user moves away from the app, and they must then request permission again for the next access. More information here.


One-time permission dialog in Android 11.

One-time permission dialog in Android 11.



  • Scoped storage - We’ve continued our work to better protect app and user data on external storage, and made further improvements to help developers migrate more easily. We want to take a moment to acknowledge everyone in the Android community who gave us such helpful feedback - thank you so much for helping us make the platform better! This preview release includes several enhancements, such as opt-in raw file path access for media, updated DocumentsUI, and batch edit operations in MediaStore. Along with these technical changes, based on your input, we are also giving you more time to make the migration and the changes will apply to your apps when they target Android 11. Read more here and watch for more enhancements in subsequent updates.

In addition to these platform changes, users tell us that they want more protection on earlier versions of Android and more transparency around how apps will use this data, so we are updating Google Play Policy to ensure that apps only request location permissions when truly necessary. Read more

Security

We focus on raising the bar for security with each version of Android -- from reaching more devices with monthly security updates to building more protections into the latest platform. In Android 11, we’ve extended Android’s defense-in-depth strategies to more areas of the platform and added new features and APIs for apps.

  • Biometrics - We’ve expanded our biometrics support to meet the needs of a wider range of devices. BiometricPrompt now supports three authenticator types with different levels of granularity -- strong, weak, and device credential. We’ve also decoupled the BiometricPrompt flow from the app’s Activity lifecycle to make it easier to integrate with various app architectures, and to improve the transaction UI. All apps using biometric auth should move to the BiometricPrompt APIs, which are also available in AndroidX for compatibility with earlier versions of Android.
  • Platform hardening - We’ve expanded use of compiler-based sanitizers in security-critical components, including BoundSan, IntSan, CFI, and Shadow-Call Stack. We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps. We've used HWAsan to find and fix many memory errors in the system, and we now offer HWAsan-enabled system images to help you find such issues in your apps.
  • Secure storage and sharing of data - Apps can now share data blobs easily and more safely with other apps through a BlobstoreManager. The Blob store is ideal for use-cases like sharing ML models among multiple apps for the same user.
  • Identity credentials - Android 11 adds platform support for secure storage and retrieval of verifiable identification documents, such as ISO 18013-5 compliant Mobile Driving Licenses. We’ll have more details to share on this soon!


Updates and compatibility

Google Play System Updates

Since Android 10, we’ve been scaling up our investment in Google Play System Updates (Project Mainline) to improve security, privacy, and consistency across the ecosystem. Thanks to strong collaboration with device makers, we’ve made significant progress towards this goal and have expanded our infrastructure to reach a wider range of devices more safely and quickly.

In Android 11, we’ve added 12 new updatable modules, for a total of 22 modules. Highlights include a permissions module that standardizes user and developer access to critical privacy controls on Android devices, a media provider module that’s integral to our privacy efforts around Scoped Storage, and an NNAPI (Neural Networks API) module that optimizes performance and guarantees consistent APIs across devices. To learn more about Google Play System Updates, check out the Project Mainline blog post.

App compatibility

We’re also working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates.

  • Minimizing the impact of behavior changes - While changes we make to Android can make the OS more helpful, secure, and better performing, some of these changes can affect developers’ apps. As we built Android 11, we made a conscious effort to minimize behavioral changes that could affect apps by closely reviewing their impact and by making them opt-in, wherever possible, until you set targetSdkVersion to 'R' in your app. We hope this gives developers more control, and leads to more apps working out-of-the-box on Android 11.
  • Easier testing and debugging - To help you test for compatibility, we’ve made many of the breaking changes toggleable - meaning that you can force-enable or disable the changes individually from Developer options or adb. With this change, there’s no longer a need to change targetSdkVersion or recompile your app for basic testing. Check out the details here.


App compatibility toggles in Developer Options.

App compatibility toggles in Developer Options.



  • Updated greylists - We’ve updated the lists of restricted non-SDK interfaces, and as always your feedback and requests for public API equivalents are welcome.
  • Dynamic resource loader - As part of their migration away from non-SDK interfaces, developers asked us for a public API to load resources and assets dynamically at runtime. We’ve now added a Resource Loader framework in Android 11, and thank you to the developers who gave us this input!
  • New platform stability milestone - Developers also told us that preparing for early app compatibility was a challenge without a clear date for final changes. So in Android 11 we’re adding a new release milestone called “Platform Stability”, which we expect to reach in early June. This milestone includes not only final SDK/NDK APIs, but also final internal APIs and system behaviors that may affect apps. We hope you can use this new milestone to plan your final development and testing. More on the release timeline is here.


Polish and quality

Connectivity

  • Call screening service improvements - call-screening apps can now do more to help users. Apps can get the incoming call’s STIR/SHAKEN verification status as part of the call details, and they can customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts.
  • Wi-Fi suggestion API enhancements - We’ve extended the Wi-Fi suggestion API to give connectivity management apps greater ability to manage their own networks. For example, they can force a disconnection by removing a network suggestion, manage Passpoint networks, receive more information about the quality of connected networks, and other management changes.
  • Passpoint enhancements - Android now enforces and notifies about expiration date of a Passpoint profile, supports Common Name specification in the profile, and allows self-signed private CAs for Passpoint R1 profiles. Connectivity apps can now use the Wi-Fi suggestion API to manage Passpoint networks.

Image and camera improvements

  • HEIF animated drawables - The ImageDecoder API now lets you decode and render image sequence animations stored in HEIF files, so you can make use of high-quality assets while minimizing impact on network data and apk size. HEIF image sequences can offer drastic file-size reductions for image sequences when compared to animated GIFs. Developers can display HEIF image sequences in their apps by calling decodeDrawable with an HEIF source. If the source contains a sequence of images an AnimatedImageDrawable is returned.
  • Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples.
  • Muting during camera capture - apps can use new APIs to mute vibration from ringtones, alarms or notifications while the session is active.
  • Bokeh modes - Apps can use metadata tags to enable bokeh modes on camera capture requests in devices that support it. A still image mode offers highest quality capture, while a continuous mode ensures that capture keeps up with sensor output, such as for video capture.

Low latency

  • Low-latency video decoding in MediaCodec -- Low latency video is critical for real-time video streaming apps and services like Stadia. Video codecs that support low latency playback return the first frame of the stream as quickly as possible after decoding starts. Apps can use new APIs to check and configure low-latency playback for a specific codec.
  • HDMI low-latency mode - Apps can use new APIs to check for and request auto low latency mode (also known as game mode) on external displays and TVs. In this mode, the display or TV disables graphics post-processing in order to minimize latency.


Get started with Android 11

The Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. To get started, download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device. Additionally, you can set up the Android Emulator through Android Studio. The Android Emulator running Android 11 system images includes experimental support to run ARM 32-bit & 64-bit binary app code directly on 64-bit x86 Android Emulator system images. Lastly, for broader testing, GSI images are also available.

Next, update your Android Studio environment with the Android 11 Preview SDK and tools - you can do this from inside Android Studio. See the setup guide for complete details. To take advantage of the latest Android Studio features, we recommend installing the latest version of Android Studio from the canary channel.

When you’re set up, here are some of the things you can do:

  • Try the new features and APIs - your feedback is critical during the early part of the developer preview. We’re actively looking for your input on our new APIs, while there’s still time for use to make changes. For more on what’s new, check out the API overview, API reference, and diff report. Please let us know your feedback and requests as soon as possible!
  • Test your current app for compatibility - the goal here is to learn whether your app is affected by default behavior changes in Android 11. Just install your current published app onto a device or emulator and test all of the app flows. If you find issues, we recommend updating your app soon.
  • Test your app with opt-in changes - Like in previous releases, Android 11 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s extremely important to understand and assess these changes early. To make it easier to assess the impact, you can now toggle the changes on and off individually. As you test, please make sure to let us know how these changes are working for your app.

For more information, visit the Android 11 developer site. You’ll find an overview of what’s new in this release, details on behavior changes, setup and migration guides, release notes, feedback channels, and more.

Preview updates

We plan to update the preview system images and SDK regularly throughout the Android 11 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Downloads are here and instructions are here.

As we get closer to a final product, we'll be inviting consumers to try it out as well, and we'll open up enrollments through Android Beta at that time. Stay tuned for details, but for now please note that Android Beta is not currently available for Android 11.

Give us your feedback!

As always, your feedback is crucial, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate, and because of timelines, we’re giving priority to input we receive in the next several weeks. When you find issues, please report them here.

Safer and More Transparent Access to User Location

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

Last year, we made several changes to our platform and policies to increase user trust and safety. We’re proud of the work we’ve done to improve family safety, limit use of sensitive permissions, and catch bad actors before they ever reach the Play Store.

We realize that changes can lead to work for developers. Last year, you told us that you wanted more detailed communications about impactful updates, why we’re making them, and how to take action. You also asked for as much time as possible to make any changes required.

With that feedback in mind, today, we’re previewing Android and Google Play policy changes that will impact how developers access location in the background.

Giving users more control over their location data

Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Since the beginning of Android, users have needed to grant explicit permission to any app that wants access to their location data.

In Android 10, people were given additional control to only grant access when the app is in use, which makes location access more intentional. Users clearly appreciated this option as over half of users select “While app is in use.”

Now in Android 11, we’re giving users even more control with the ability to grant a temporary “one-time” permission to sensitive data like location. When users select this option, apps can only access the data until the user moves away from the app, and they must then request permission again for the next access. Please visit the Android 11 developer preview to learn more.

Preventing unnecessary access to background location

Users tell us they also want more protection on earlier versions of Android - as well as more transparency around how apps use this data.

As we took a closer look at background location usage, we found that many of the apps that requested background location didn’t actually need it. In fact, many of these apps could provide the same user experience by only accessing location when the app is visible to the user. We want to make it easier for users to choose when to share their location and they shouldn't be asked for a permission that the app doesn't need.

Later this year, we will be updating Google Play policy to require that developers get approval if they want to access location data in the background. Factors that will be looked at include:

  • Does the feature deliver clear value to the user?
  • Would users expect the app to access their location in the background?
  • Is the feature important to the primary purpose of the app?
  • Can you deliver the same experience without accessing location in the background?

All apps will be evaluated against the same factors, including apps made by Google, and all submissions will be reviewed by people on our team. Let’s take a look at three examples:

An app that sends emergency or safety alerts as part of its core functionality - and clearly communicates why access is needed to the user - would have a strong case to request background location.

A social networking app that allows users to elect to continuously share their location with friends would also have a strong case to access location in the background.

An app with a store locator feature would work just fine by only accessing location when the app is visible to the user. In this scenario, the app would not have a strong case to request background location under the new policy.

When we spoke to developers for feedback, the vast majority understood user concerns over their information falling into the wrong hands and were willing to change their location usage to be safer and more transparent.

Getting approval for background access

We know that when we update our policies, you want to get actionable feedback and have ample time to make changes. Before we implement this policy change, you will be able to submit your use case via the Play Console and receive feedback on whether it will be allowed under the new policy.

We anticipate the following timeline for this policy rollout; however, it is subject to change.

  • April: official Google Play policy update with background location
  • May: developers can request feedback on their use case via the Play Console with an estimated reply time of 2 weeks, depending on volume
  • August 3rd: all new apps submitted to Google Play that access background location will need to be approved
  • November 2nd: all existing apps that request background location will need to be approved or will be removed from Google Play

Review and evaluate your location access

We encourage all developers to review the following best practices for accessing location data in their apps:

  • Review the background location access checklist to identify any potential access in your code. Remember you are also responsible for ensuring all third party SDKs or libraries that you use comply with our policies, including access to background location.
  • Minimize your use of location by using the minimum scope necessary to provide a feature (i.e., coarse instead of fine, foreground instead of background).
  • Review privacy best practices and ensure you have the proper disclosure and privacy policies in place.

We hope you found this policy preview useful in planning your roadmap for the year and we appreciate your efforts to build privacy-friendly apps. Together, we can keep the Android ecosystem safe and secure for everyone.