Tag Archives: #11WeeksOfAndroid

Android 11 Beta 2 and Platform Stability

Posted by Dave Burke, VP of Engineering

A few weeks ago we unwrapped the first Beta of Android 11 with a focus on people, controls, and privacy. As we highlighted in the #Android11Beta Launch, we’re making Android more people-centric and expressive, helping users control their smart devices, and giving them even more control over sensitive permissions. Developers can use APIs like Conversations, Bubbles, Device Controls, and Media Controls, to integrate these experiences into their apps.

Today we’re pushing out the second Beta of Android 11 for you to try. This release takes us to the Platform Stability milestone, which means that Android 11’s APIs and behaviors are finalized. For developers, it’s time to get started on your final compatibility updates and publish them in time for the official release later in Q3.

This week’s theme in #11 Weeks of Android is Android 11 Compatibility and we’ll be sharing helpful content and materials all week. You can find them on the #11 Weeks page or follow Android Developers on Twitter and Youtube.

You can get Beta 2 today on your Pixel 2, 3, 3a, and 4 device by enrolling here for over-the-air updates, and downloads are also available. If you previously enrolled for Beta 1, you will automatically get the over-the-air update. Let us know what you think, and thanks for the feedback you’ve provided so far!

Platform Stability

Beta 2 brings Android 11 to Platform Stability, a new release milestone that we added this year just for developers, based on your feedback.

Platform Stability means that all app-facing surfaces and behaviors are now final in Android 11. This includes not only final SDK and NDK APIs, but also final system behaviors and restrictions on non-SDK interfaces that may affect apps. So from Beta 2, you can release compatibility updates with confidence that the platform won’t change. More on the timeline is here.

With the platform now stable, we’re encouraging all app and game developers to start your final compatibility testing and publish your updates ahead of the final release.

For all SDK, library, tools, and game engine developers, it’s even more important to start testing now and release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates. When you’ve released a compatible update, be vocal and let developers know!

Why app compatibility is important

For Android, the term app compatibility means that your app runs properly on a specific version of the platform, typically the latest version. You can check this right now by installing your production app on a device or emulator running Android 11. Just test all of the user flows and features, and if the app looks and runs properly, then you’re done, it’s compatible!

It sounds simple, but sometimes there’s more to it. With each release, we make integral changes that improve privacy and security, as well as implement changes that evolve the overall user experience across the OS. Sometimes these can affect your apps, so it’s important to take a look at the behavior changes and test against them, then publish the compatible update to users. It’s a basic but critical level of quality.

App compatibility comes into play as users update to the latest version of Android, whether they’ve purchased a new device or installed an update on their current device. They’re excited to explore the latest version of Android, and they want to experience it with their favorite apps. If the apps don’t work properly, it’s a major issue - for users and for all of us.

So while there are a ton of new APIs and capabilities to explore, and more changes to consider when you’re ready to change your app’s targeting, start by testing your current app and releasing a compatible update first.

Updates to Pixel and other devices will get started as soon as Android 11 reaches the final release to Android Open Source Project (AOSP), which we expect later in Q3. Multiple partner devices are also in active public previews now to support your compatibility testing.

Making app compatibility easier in Android 11

With each release, we’re working to reduce the work you’ll need to do to get your apps ready. In Android 11, we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates and make it easier for apps to stay compatible.

Minimizing the impact of behavior changes - we’re making a conscious effort to minimize platform changes that could affect apps by making them opt-in, wherever possible, until you set targetSdkVersion to Android 11 in your app. If you are distributing through Google Play, you’ll have more than a year to opt-in to these changes.
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.

Restrictions on non-SDK interfaces - as part of our ongoing effort to gradually move developers away from non-SDK APIs, 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!
Platform stability milestone - As mentioned, this is a new milestone we’ve added to our release process to give developers a clear date for final changes. It includes not only final SDK/NDK APIs, but also final internal APIs and system behaviors that may affect apps.

Get your apps ready for Android 11!

Now that Android 11 is stable, make your apps compatible as soon as possible. Here’s how to do it.

For testing your current app, start with the behavior changes for all apps to see where it could be affected. Here are the top changes (these apply regardless of your app’s targetSdkVersion):

One-time permission - Users can now grant single-use permission to access location, device microphone and camera. Details here.
External storage access - Apps can no longer access other apps’ files in external storage. Details here.
Scudo hardened allocator - Now the heap memory allocator for native code in apps. Details here.
File descriptor sanitizer - Now enabled by default to detect file descriptor handling issues for native code in apps. Details here.

Remember to test the libraries and SDKs in your app for compatibility. If you find an issue, try updating to the latest version of the SDK, or reach out to the developer for help.

Later, after you’ve published the compatible version of your current app, you can start the process of updating your app's targetSdkVersion. Review the behavior changes for Android 11 apps and try the compatibility framework to help find impacts. Here are some of the top changes to test for (these apply only to targetSdkVersion 30+):

Scoped storage - New storage restrictions, behaviors, and APIs for apps reading and writing files. Details here.
Background location - Changes to how apps request background location and how users grant it. Details here.
Package visibility - Changes to how apps can query and interact with other installed apps. Details here.
Compressed resource files - Apps can’t be installed or updated if they contain a compressed resources.arsc file, or if the file is not aligned on a 4-byte boundary. Details here.
APK Signature Scheme v2 - Apps must now be signed using APK Signature Scheme v2 or higher. Details here.
Heap pointer tagging - For 64-bit processes, native heap allocations have a tag set in the top byte of the pointer that should not be modified by apps. Details here.

During testing, watch for uses of restricted non-SDK interfaces in your app and move those to public SDK equivalents instead. You can read about the restricted APIs here.

Explore the new features and APIs

As soon as you’re ready, dive into Android 11 and learn about the new experiences you can build. Our #Android11 Beta post has a recap of new features for developers, and you can also visit the Beta Launch page to see talks from the Android team on what’s new in their areas.

Android Studio also has new features for Android 11 also, to improve your productivity and workflow, such as ADB incremental for faster installs of large APKs, and additional nullability annotations on platform APIs. You can give these a try by downloading the latest Android Studio Beta or Canary version. Instructions for configuring Android Studio for Android 11 are here.

For complete details on Android 11 features and APIs, visit the Android 11 developer site.

How do I get Beta 2?

It’s easy! You can enroll here to get Android 11 Beta updates over-the-air for Pixel 2, 3, 3a, and 4 devices. Alternatively, give Android Flash Tool a try for easy on-demand updates, and downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator in Android Studio or try a GSI image to run Android 11 on supported Treble-compliant devices.

As always, your feedback is critical, so please let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far -- thank you!

Android 11 compatibility week

This week in #11 Weeks of Android, we’re highlighting Android 11 Compatibility, a theme that’s important for all developers now that the platform has reached stability.

We’re sharing resources to help you with compatibility testing here, and you can follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week!

Also, the Android engineering team will host a Reddit AMA on r/androiddev tomorrow, July 9 at 12:00PM PST, to answer your technical questions about Android 11. See this post for details and to submit your questions.

Source: Android Developers Blog

Excelliance Tech: moving to new Android dynamic resource loading APIs for long-term compatibility

This blogpost is a collaboration between Google and Excelliance Tech. Authored by Zhuo Chen with support from Zhihai Wang, Gao Huang from Excelliance Tech.

Excelliance Tech improved the stability and compatibility of their LeBian SDK by moving away from non-SDK APIs, toward stable, official APIs. Their collaboration with the Android team during the process also led to a new public API for resource loading that all developers can use - the ResourcesLoader API in Android 11.

Helping game developers keep users engaged

Games are becoming increasingly complex, and a loading progress bar is not only a countdown to a new adventure, but also a bridge which connects players and developers.

Players want the game to load right away, so "loading" has its own priorities: resources that will be used in the first few minutes need to be packed into the APK, while the rest of the content can be downloaded in the background after the game starts.

Developers are always creating new content for their games, so "change" is the only constant: different campaigns bring different launch screens and themes, keeping the game experience fresh for players.

Excelliance Tech’s LeBian (乐变) game assets streaming service helps game developers meet players’ needs by loading fresh resources dynamically while the game is loading or being played.

Meteor, Butterfly And a Sword (流星群侠传) by NetEase Games, Duoduo Auto Chess (多多自走棋) by Dragonest Game, Langrisser (梦幻模拟战) by ZlongGames, Junior Three Kingdom 2 (少年三国志 2) by Yoozoo Games - these games are created by different developers and have different look and feel, but one thing they have in common: they all use LeBian game streaming service to load resources.

The resource loading technology is so useful that Excelliance Tech is even using it in the LeBian SDK itself, bringing a better experience for developers. Dynamic resource loading makes the SDK much easier to use. By dynamically updating its internal resources when needed, the library doesn’t require developers to update the SDK for new resources.

Before Android 11 introduced the ResourcesLoader API, Excelliance Tech had to build their dynamic resource loading capability the hard way, using non-SDK interfaces.

Building the initial product

When Excelliance was first building their product, Android did not offer public APIs for the dynamic resource loading use-case. The team did what they could, but ended up using non-SDK interfaces to add the external resources. While this met the technical need initially, the implementation was fragile - it depended on non-SDK interfaces, which don’t have the same compatibility guarantees as official SDK APIs and can change without notice.

As a result, Excelliance found that compatibility issues would surface unexpectedly as new versions of Android were released. These required additional testing and development to assure the stability of the product. Over many iterations, it took the Excelliance team six engineer-months and a lot of code to stabilize their solution, while knowing that it might break again in the next Android release. With Android tightening restrictions on non-SDK interfaces to achieve better stability and app compatibility, relying on those non-SDK interfaces became no longer an option.

Working toward a sustainable solution

As the Android team increased its focus on moving apps to public APIs, Excelliance saw an opportunity to migrate to a stronger foundation. They reached out to the Android team to give their feedback and highlighted their use case and need for public SDK APIs.

Over time, their collaboration led to the development of the ResourcesLoader public API that’s available for the first time in Android 11. Excelliance Tech has already moved to the new ResourcesLoader API and they’ve seen better productivity and product quality as a result. Excelliance believes the ResourcesLoader API provides advantages including the following:

Easy to use. The development team migrated the solution to the new API in 2 days, testing included.
No performance loss. In some cases, the loading speed even increased because ResourcesLoader can load uncompressed resources much faster.
Easy to develop. Before using the ResourcesLoader API, the team had to assign a senior engineer to 1) understand how AssetManager works, 2) find private APIs and find out how they work on different Android versions, 3) learn zip file structure, etc. Now it only takes a junior engineer who can read the API documentation.
Much less code. Before the ResourcesLoader API, the solution took more than 1,000 lines of code, now it has less than 50 lines of code, with the essential code down to just a few lines.
Forward compatibility. By using official public APIs that will continue to be supported by the Android team, the developer’s solution will have much better compatibility on the future Android platforms.

String sdkroot = getApplicationInfo().dataDir + "/lebian";
ResourcesLoader rl = new ResourcesLoader();
rl.addProvider(ResourcesProvider.loadFromDirectory(sdkroot, null));
Resources res = getResources();
res.addLoaders(rl);
final AssetManager assetManager = res.getAssets();

After moving to the new ResourcesLoader API, the essential code has just a few lines (down from hundreds of lines of code across a number of source files).

Improving performance

Excelliance Tech did a comparison test, loading 16,028 files (uncompressed 1.47GB, compressed 1.36GB) in 4 ways:

Load resources directly from APK
Load resources using non-SDK interfaces
Load APK using ResourcesLoader
Load resources directly from a directory using ResourcesLoader

Resources are compressed in option 1, 2 and 3, and the average loading times are around 19 seconds. Option 4 loads uncompressed resources directly from a directory using ResourcesLoader, the average loading time is about 3 seconds - a 6x performance improvement!

Summarizing the overall impact of ResourcesLoader, Huang Gao, CEO & Product Lead at Excelliance Tech, said “The new ResourcesLoader API dramatically reduces development and maintenance costs and allows us to focus more on product and business innovation."

Co-creating the future

The Excelliance Tech team.

"On the Android platform, we've created some valuable products and services, which makes us want to invest more to create innovative products", Excelliance Tech stated, "We hope to have more opportunities to participate in the building of the Android ecosystem and contribute our efforts to make a better Android both for consumers and developers."

Excelliance Tech made an investment for the long-term compatibility of the LeBian SDK. Moving to the ResourcesLoader API has already yielded stability and performance benefits, reduced the complexity of their code, and reduced risks of future compatibility issues as Android rolls out new versions of the platform. The ResourcesLoader API is part of Android 11’s public APIs, benefitting the entire Android developer community.

Source: Android Developers Blog

Excelliance Tech: moving to new Android dynamic resource loading APIs for long-term compatibility

This blogpost is a collaboration between Google and Excelliance Tech. Authored by Zhuo Chen with support from Zhihai Wang, Gao Huang from Excelliance Tech.

Helping game developers keep users engaged

Games are becoming increasingly complex, and a loading progress bar is not only a countdown to a new adventure, but also a bridge which connects players and developers.

Excelliance Tech’s LeBian (乐变) game assets streaming service helps game developers meet players’ needs by loading fresh resources dynamically while the game is loading or being played.

Before Android 11 introduced the ResourcesLoader API, Excelliance Tech had to build their dynamic resource loading capability the hard way, using non-SDK interfaces.

Building the initial product

Working toward a sustainable solution

Easy to use. The development team migrated the solution to the new API in 2 days, testing included.
No performance loss. In some cases, the loading speed even increased because ResourcesLoader can load uncompressed resources much faster.
Easy to develop. Before using the ResourcesLoader API, the team had to assign a senior engineer to 1) understand how AssetManager works, 2) find private APIs and find out how they work on different Android versions, 3) learn zip file structure, etc. Now it only takes a junior engineer who can read the API documentation.
Much less code. Before the ResourcesLoader API, the solution took more than 1,000 lines of code, now it has less than 50 lines of code, with the essential code down to just a few lines.
Forward compatibility. By using official public APIs that will continue to be supported by the Android team, the developer’s solution will have much better compatibility on the future Android platforms.

String sdkroot = getApplicationInfo().dataDir + "/lebian";
ResourcesLoader rl = new ResourcesLoader();
rl.addProvider(ResourcesProvider.loadFromDirectory(sdkroot, null));
Resources res = getResources();
res.addLoaders(rl);
final AssetManager assetManager = res.getAssets();

After moving to the new ResourcesLoader API, the essential code has just a few lines (down from hundreds of lines of code across a number of source files).

Improving performance

Excelliance Tech did a comparison test, loading 16,028 files (uncompressed 1.47GB, compressed 1.36GB) in 4 ways:

Load resources directly from APK
Load resources using non-SDK interfaces
Load APK using ResourcesLoader
Load resources directly from a directory using ResourcesLoader

Co-creating the future

The Excelliance Tech team.

Source: Android Developers Blog

Excelliance Tech: moving to new Android dynamic resource loading APIs for long-term compatibility

This blogpost is a collaboration between Google and Excelliance Tech. Authored by Zhuo Chen with support from Zhihai Wang, Gao Huang from Excelliance Tech.

Helping game developers keep users engaged

Games are becoming increasingly complex, and a loading progress bar is not only a countdown to a new adventure, but also a bridge which connects players and developers.

Excelliance Tech’s LeBian (乐变) game assets streaming service helps game developers meet players’ needs by loading fresh resources dynamically while the game is loading or being played.

Before Android 11 introduced the ResourcesLoader API, Excelliance Tech had to build their dynamic resource loading capability the hard way, using non-SDK interfaces.

Building the initial product

Working toward a sustainable solution

Easy to use. The development team migrated the solution to the new API in 2 days, testing included.
No performance loss. In some cases, the loading speed even increased because ResourcesLoader can load uncompressed resources much faster.
Easy to develop. Before using the ResourcesLoader API, the team had to assign a senior engineer to 1) understand how AssetManager works, 2) find private APIs and find out how they work on different Android versions, 3) learn zip file structure, etc. Now it only takes a junior engineer who can read the API documentation.
Much less code. Before the ResourcesLoader API, the solution took more than 1,000 lines of code, now it has less than 50 lines of code, with the essential code down to just a few lines.
Forward compatibility. By using official public APIs that will continue to be supported by the Android team, the developer’s solution will have much better compatibility on the future Android platforms.

String sdkroot = getApplicationInfo().dataDir + "/lebian";
ResourcesLoader rl = new ResourcesLoader();
rl.addProvider(ResourcesProvider.loadFromDirectory(sdkroot, null));
Resources res = getResources();
res.addLoaders(rl);
final AssetManager assetManager = res.getAssets();

After moving to the new ResourcesLoader API, the essential code has just a few lines (down from hundreds of lines of code across a number of source files).

Improving performance

Excelliance Tech did a comparison test, loading 16,028 files (uncompressed 1.47GB, compressed 1.36GB) in 4 ways:

Load resources directly from APK
Load resources using non-SDK interfaces
Load APK using ResourcesLoader
Load resources directly from a directory using ResourcesLoader

Co-creating the future

The Excelliance Tech team.

Source: Android Developers Blog

Bringing modern storage to Viber’s users

This blogpost is a collaboration between Google and Viber. Authored by Kseniia Shumelchyk from Google and Anton Novikov, Sergey Kozlov from Viber.

As a messaging app, Viber needs to store, process and share a significant amount of data. Viber aims to give its users an easy, fast, reliable and secure communication platform by providing an intuitive interface and operating with files in a privacy-preserving way. We believe the modern scoped storage paradigm provides this foundation for app developers and users.

Scoped storage was introduced in Android 10 with further improvements in Android 11 to provide better protection to app and user data on a platform level. Due to Viber's complexity, the team opted to incrementally implement the changes that were required to comply with scoped storage.

In this article, we’ll share how Viber handled the migration to scoped storage, focusing on what they did to optimize working with media files and other data in the app.

Managing storage across Android versions

Android’s storage model has evolved to adapt to changing privacy considerations, leading to the changes in the storage system APIs. Let’s take a look at key platform changes that affected the legacy Viber implementation.

Media directories

Scoped storage changes the way that apps store and access files on a device's external storage. Viber needed to evaluate the differences between the existing app's storage model and updated platform guidelines, followed by gradual application changes to work with files in scoped storage. Therefore Viber invoked the requestLegacyExternalStorage flag to temporarily opt-out of scoped storage on Android 10 until the app was fully compatible.

In order to adjust their app experience to scoped storage, Viber now contributes public media files to well-defined media collections using the MediaStore API. This way, the files are accessible in a device gallery, and can be read by other apps with the storage permission. Private media files are stored in the app-specific directory on external storage and are accessed via the internal ContentProvider.

Storage permissions

The other notable update is related to changes in the storage permissions model: Apps in scoped storage have unrestricted access to their app-specific directories on external storage and can contribute to well-defined media collections without requesting a runtime permission. This change will help Viber provide more granular control to their users:

“This addition supports our efforts to provide our users with the best security and privacy solutions we can provide supported by the Android OS, users will benefit from this added security later without needing to opt-in. We also added a new ‘Save to gallery’ option allowing users to choose to make their photos readable by other apps or not. Because chats may contain private images or videos, it’s important to give users the ability to hide these files from the gallery. This change gives users additional control over the content included in their Viber messages.“ said Anton Novikov and Sergey Kozlov from Viber.

Accessing files outside of app-specific directory

Previously, Viber created and consumed files in a custom top level directory and depended on file path access. With scoped storage, saving app files to a top level directory became an anti-pattern, so Viber has followed best practices to update their implementation to store media files from the chats only in locations that are accessible in scoped storage.

However, to reduce the complexity of migration, Viber decided to keep their own top level directory for Android 10 and below, storing only the media files that are not exposed to the device’s Gallery app, while for Android 11 and above this directory is used in read-only mode to provide backward compatibility.

Another use case that Viber has been refining is sharing files in the chats. The updated storage runtime permission gives read access only to the images, videos and audio files that are available through MediaProvider. Starting from Android 11, the only way for Viber to access non-media files created by other apps is by using the Storage Access Framework document picker, which they had already utilized in a different part of their app.

App-specific files within external storage

In the scoped storage environment, app-specific directories on external storage are becoming private from other apps. This change has helped Viber leverage its use of external storage for storing private user files:

”We find change to app-specific directories to be useful, because it will help to ensure that personal chats are protected and backed with platform security.” said Anton Novikov from Viber. Learn more about how to access app-specific files.

Single interface to access storage

Because Viber targets a large audience running on Android 4.2 and above, they introduced an abstraction layer that aids them in managing storage access efficiently across all supported Android versions and with their use cases in mind.

Previously, Viber heavily used File API to access files, including files in legacy storage locations. Further, they stored absolute file paths for entries in the local database to keep the user's conversation history.

To standardize access to this conversation history and thus ensure that users don’t lose access to their files, Viber replaced absolute file paths with content URIs. In the new implementation, the app is accessing files only via content providers:

Internal FileProvider for Viber app-specific directories.
External file providers available in the Android framework, such as MediaStore or Storage Access Framework, or those belong to another app that shares files with Viber through Intent.ACTION_SEND.

By using a consistent ContentProvider layer, the ContentResolver gives the app a unified interface to access the file content.

This approach has also helped Viber optimize the network layer and define a universal Loader abstraction to upload/fetch and to read/store different types of media files like voice messages, chat images and stickers.

Summary

Android 11 further enhances scoped storage, which provides better protection of app and user data and makes the transition easier for developers. It’s amazing to see many apps like Viber are migrating to take advantage of scoped storage since Android 10.

We hope Viber’s story is useful and will inspire you to modernize your Android apps as well. Learn more about Android storage use cases and best practices.

Source: Android Developers Blog

System hardening in Android 11

Posted by Platform Hardening Team

In Android 11 we continue to increase the security of the Android platform. We have moved to safer default settings, migrated to a hardened memory allocator, and expanded the use of compiler mitigations that defend against classes of vulnerabilities and frustrate exploitation techniques.

Initializing memory

We’ve enabled forms of automatic memory initialization in both Android 11’s userspace and the Linux kernel. Uninitialized memory bugs occur in C/C++ when memory is used without having first been initialized to a known safe value. These types of bugs can be confusing, and even the term “uninitialized” is misleading. Uninitialized may seem to imply that a variable has a random value. In reality it isn’t random. It has whatever value was previously placed there. This value may be predictable or even attacker controlled. Unfortunately this behavior can result in a serious vulnerability such as information disclosure bugs like ASLR bypasses, or control flow hijacking via a stack or heap spray. Another possible side effect of using uninitialized values is advanced compiler optimizations may transform the code unpredictably, as this is considered undefined behavior by the relevant C standards.

In practice, uses of uninitialized memory are difficult to detect. Such errors may sit in the codebase unnoticed for years if the memory happens to be initialized with some "safe" value most of the time. When uninitialized memory results in a bug, it is often challenging to identify the source of the error, particularly if it is rarely triggered.

Eliminating an entire class of such bugs is a lot more effective than hunting them down individually. Automatic stack variable initialization relies on a feature in the Clang compiler which allows choosing initializing local variables with either zeros or a pattern.

Initializing to zero provides safer defaults for strings, pointers, indexes, and sizes. The downsides of zero init are less-safe defaults for return values, and exposing fewer bugs where the underlying code relies on zero initialization. Pattern initialization tends to expose more bugs and is generally safer for return values and less safe for strings, pointers, indexes, and sizes.

Initializing Userspace:

Automatic stack variable initialization is enabled throughout the entire Android userspace. During the development of Android 11, we initially selected pattern in order to uncover bugs relying on zero init and then moved to zero-init after a few months for increased safety. Platform OS developers can build with `AUTO_PATTERN_INITIALIZE=true m` if they want help uncovering bugs relying on zero init.

Initializing the Kernel:

Automatic stack and heap initialization were recently merged in the upstream Linux kernel. We have made these features available on earlier versions of Android’s kernel including 4.14, 4.19, and 5.4. These features enforce initialization of local variables and heap allocations with known values that cannot be controlled by attackers and are useless when leaked. Both features result in a performance overhead, but also prevent undefined behavior improving both stability and security.

For kernel stack initialization we adopted the CONFIG_INIT_STACK_ALL from upstream Linux. It currently relies on Clang pattern initialization for stack variables, although this is subject to change in the future.

Heap initialization is controlled by two boot-time flags, init_on_alloc and init_on_free, with the former wiping freshly allocated heap objects with zeroes (think s/kmalloc/kzalloc in the whole kernel) and the latter doing the same before the objects are freed (this helps to reduce the lifetime of security-sensitive data). init_on_alloc is a lot more cache-friendly and has smaller performance impact (within 2%), therefore it has been chosen to protect Android kernels.

Scudo is now Android's default native allocator

In Android 11, Scudo replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap, such as:

Scudo does not fully prevent exploitation but it does add a number of sanity checks which are effective at strengthening the heap against some memory corruption bugs.

It also proactively organizes the heap in a way that makes exploitation of memory corruption more difficult, by reducing the predictability of the allocation patterns, and separating allocations by sizes.

In our internal testing, Scudo has already proven its worth by surfacing security and stability bugs that were previously undetected.

Finding Heap Memory Safety Bugs in the Wild (GWP-ASan)

Android 11 introduces GWP-ASan, an in-production heap memory safety bug detection tool that's integrated directly into the native allocator Scudo. GWP-ASan probabilistically detects and provides actionable reports for heap memory safety bugs when they occur, works on 32-bit and 64-bit processes, and is enabled by default for system processes and system apps.

GWP-ASan is also available for developer applications via a one line opt-in in an app's AndroidManifest.xml, with no complicated build support or recompilation of prebuilt libraries necessary.

Software Tag-Based KASAN

Continuing work on adopting the Arm Memory Tagging Extension (MTE) in Android, Android 11 includes support for kernel HWASAN, also known as Software Tag-Based KASAN. Userspace HWASAN is supported since Android 10.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs in the Linux kernel. Its Software Tag-Based mode is a software implementation of the memory tagging concept for the kernel. Software Tag-Based KASAN is available in 4.14, 4.19 and 5.4 Android kernels, and can be enabled with the CONFIG_KASAN_SW_TAGS kernel configuration option. Currently Tag-Based KASAN only supports tagging of slab memory; support for other types of memory (such as stack and globals) will be added in the future.

Compared to Generic KASAN, Tag-Based KASAN has significantly lower memory requirements (see this kernel commit for details), which makes it usable on dog food testing devices. Another use case for Software Tag-Based KASAN is checking the existing kernel code for compatibility with memory tagging. As Tag-Based KASAN is based on similar concepts as the future in-kernel MTE support, making sure that kernel code works with Tag-Based KASAN will ease in-kernel MTE integration in the future.

Expanding existing compiler mitigations

We’ve continued to expand the compiler mitigations that have been rolled out in prior releases as well. This includes adding both integer and bounds sanitizers to some core libraries that were lacking them. For example, the libminikin fonts library and the libui rendering library are now bounds sanitized. We’ve hardened the NFC stack by implementing both integer overflow sanitizer and bounds sanitizer in those components.

In addition to the hard mitigations like sanitizers, we also continue to expand our use of CFI as an exploit mitigation. CFI has been enabled in Android’s networking daemon, DNS resolver, and more of our core javascript libraries like libv8 and the PacProcessor.

The effectiveness of our software codec sandbox

Prior to the Release of Android 10 we announced a new constrained sandbox for software codecs. We’re really pleased with the results. Thus far, Android 10 is the first Android release since the infamous stagefright vulnerabilities in Android 5.0 with zero critical-severity vulnerabilities in the media frameworks.

Thank you to Jeff Vander Stoep, Alexander Potapenko, Stephen Hines, Andrey Konovalov, Mitch Phillips, Ivan Lozano, Kostya Kortchinsky, Christopher Ferris, Cindy Zhou, Evgenii Stepanov, Kevin Deus, Peter Collingbourne, Elliott Hughes, Kees Cook and Ken Chen for their contributions to this post.

Source: Android Developers Blog

11 Weeks of Android: Privacy and Security

Posted by:
Charmaine D’Silva, Product Lead, Android Privacy and Framework
Narayan Kamath, Engineering Lead, Android Privacy and Framework
Stephan Somogyi, Product Lead, Android Security
Sudhi Herle, Engineering Lead, Android Security

This blog post is part of a weekly series for #11WeeksOfAndroid. For each #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we spotlighted Privacy and Security; here’s a look at what you should know.

Privacy and security is core to how we design Android, and with every new release we increase our investment in this space. Android 11 continues to make important strides in these areas, and this week we’ll be sharing a series of updates and resources about Android privacy and security. But first, let’s take a quick look at some of the most important changes we’ve made in Android 11 to protect user privacy and make the platform more secure.

As shared in the “All things privacy in Android 11” video, we’re giving users even more control over sensitive permissions. Throughout the development of this release, we have engaged deeply and frequently with our developer community to design these features in a balanced way - amplifying user privacy while minimizing developer impact. Let’s go over some of these features:

One-time permission: In Android 10, we introduced a granular location permission that allows users to limit access to location only when an app is in use (aka foreground only). When presented with the new runtime permissions options, users choose foreground only location more than 50% of the time. This demonstrated to us that users really wanted finer controls for permissions. So in Android 11, we’ve introduced one time permissions that let users give an app access to the device microphone, camera, or location, just that one time. As an app developer, there are no changes that you need to make to your app for it to work with one time permissions, and the app can request permissions again the next time the app is used. Learn more about building privacy-friendly apps with these new changes in this video.

Background location: In Android 10 we added a background location usage reminder so users can see how apps are using this sensitive data on a regular basis. Users who interacted with the reminder either downgraded or denied the location permission over 75% of the time. In addition, we have done extensive research and believe that there are very few legitimate use cases for apps to require access to location in the background.

In Android 11, background location will no longer be a permission that a user can grant via a run time prompt and it will require a more deliberate action. If your app needs background location, the system will ensure that the app first asks for foreground location. The app can then broaden its access to background location through a separate permission request, which will cause the system to take the user to Settings in order to complete the permission grant.

In February, we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021. Check out this helpful video to find possible background location usage in your code.

Permissions auto-reset: Most users tend to download and install over 60 apps on their device but interact with only a third of these apps on a regular basis. If users haven’t used an app that targets Android 11 for an extended period of time, the system will “auto-reset” all of the granted runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. If you have an app that has a legitimate need to retain permissions, you can prompt users to turn this feature OFF for your app in Settings.

Data access auditing APIs: Android encourages developers to limit their access to sensitive data, even if they have been granted permission to do so. In Android 11, developers will have access to new APIs that will give them more transparency into their app’s usage of private and protected data. The APIs will enable apps to track when the system records the app’s access to private user data.

Scoped Storage: In Android 10, we introduced scoped storage which provides a filtered view into external storage, giving access to app-specific files and media collections. This change protects user privacy by limiting broad access to shared storage in many ways including changing the storage permission to only give read access to photos, videos and music and improving app storage attribution. Since Android 10, we’ve incorporated developer feedback and made many improvements to help developers adopt scoped storage, including: updated permission UI to enhance user experience, direct file path access to media to improve compatibility with existing libraries, updated APIs for modifying media, Manage External Storage permission to enable select use cases that need broad files access, and protected external app directories. In Android 11, scoped storage will be mandatory for all apps that target API level 30. Learn more in this video and check out the developer documentation for further details.

Google Play system updates: Google Play system updates were introduced with Android 10 as part of Project Mainline. Their main benefit is to increase the modularity and granularity of platform subsystems within Android so we can update core OS components without needing a full OTA update from your phone manufacturer. Earlier this year, thanks to Project Mainline, we were able to quickly fix a critical vulnerability in the media decoding subsystem. Android 11 adds new modules, and maintains the security properties of existing ones. For example, Conscrypt, which provides cryptographic primitives, maintained its FIPS validation in Android 11 as well.

BiometricPrompt API: Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. We are planning to add this to the Jetpack Biometric library to allow for backward compatibility and will share further updates on this work as it progresses.

Identity Credential API: This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. It’s being built by our security team to ensure this information is stored safely, using security hardware to secure and control access to the data, in a way that enhances user privacy as compared to traditional physical documents. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for such digital-first identity experiences.

Thank you for your flexibility and feedback as we continue to build an increasingly more private and secure platform. You can learn about more features in the Android 11 Beta developer site. You can also learn about general best practices related to privacy and security.

Please follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week.

Resources

You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

Source: Android Developers Blog

11 Weeks of Android: Privacy and Security

Please follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week.

Resources

Source: Android Developers Blog

On-device machine learning solutions with ML Kit, now even easier to use

Posted by Christiaan Prins, Product Manager, ML Kit and Shiyu Hu, Tech Lead Manager, ML Kit

Two years ago at I/O 2018 we introduced ML Kit, making it easier for mobile developers to integrate machine learning into your apps. Today, more than 25,000 applications on Android and iOS make use of ML Kit’s features. Now, we are introducing some changes that will make it even easier to use ML Kit. In addition, we have a new feature and a set of improvements we’d like to discuss.

A new ML Kit SDK, fully focused on on-device ML

ML Kit's APIs are built to help you tackle common challenges in the Vision and Natural Language domains. We make it easy to recognize text, scan barcodes, track and classify objects in real-time, do translation of text, and more.

The original version of ML Kit was tightly integrated with Firebase, and we heard from many of you that you wanted more flexibility when implementing it in your apps. As a result, we are now making all the on-device APIs available in a new standalone ML Kit SDK that no longer requires a Firebase project. You can still use both ML Kit and Firebase to get the best of both products if you choose to.

With this change, ML Kit is now fully focused on on-device machine learning, giving you access to the unique benefits that on-device versus cloud ML offers:

It’s fast, unlocking real-time use cases- since processing happens on the device, there is no network latency. This means, we can do inference on a stream of images / video or multiple times a second on text strings.
Works offline - you can rely on our APIs even when the network is spotty or your app’s end-user is in an area without connectivity.
Privacy is retained: since all processing is performed locally, there is no need to send sensitive user data over the network to a server.

Naturally, you still get access to Google’s on-device models and processing pipelines, all accessible through easy-to-use APIs, and offered at no cost.

All ML Kit resources can now be found on our new website where we made it a lot easier to access sample apps, API reference docs and our community channels that are there to help you if you have questions.

Text recognition + Language ID + Translate gif

What does this mean if I already use ML Kit today?

If you are using ML Kit for Firebase’s on-device APIs in your app today, we recommend you to migrate to the new standalone ML Kit SDK to benefit from new features and updates. For more information and step-by-step instructions to update your app, please follow our Migration guide. The cloud-based APIs, model deployment and AutoML Vision Edge remain available through Firebase Machine Learning.

Shrink your app footprint with Google Play Services

Apart from making ML Kit easier to use, developers also asked if we can ship ML Kit through Google Play Services resulting in a smaller app footprint and the model can be reused between apps. Apart from Barcode scanning and Text recognition, we have now added Face detection / contour (model size: 20MB) to the list of APIs that support this functionality.

// Face detection / Face contour model
// Delivered via Google Play Services outside your app's APK…
implementation 'com.google.android.gms:play-services-mlkit-face-detection:16.0.0'

// …or bundled with your app's APK
implementation 'com.google.mlkit:face-detection:16.0.0'

Jetpack Lifecycle / CameraX support

Android Jetpack Lifecycle support has been added to all APIs. Developers can use addObserver to automatically manage teardown of ML Kit APIs as the app goes through screen rotation or closure by the user / system. This makes CameraX integration easier. With this release, we are also recommending that developers adopt CameraX in their apps due to the ease of integration and image quality improvements (compared to Camera1) on a wide range of devices.

// ML Kit now supports Lifecycle
val recognizer = TextRecognizer.newInstance()
lifecycle.addObserver(recognizer)

// ...

// Just like CameraX
val camera = cameraProvider.bindToLifecycle( /* lifecycleOwner= */this,
    cameraSelector, previewUseCase, analysisUseCase)

For an overview of all recent changes, check out the release notes for the new SDK.

Codelab of the day - ML Kit x CameraX

To help you get started with the new ML Kit and its support for CameraX, we have created this code lab to Recognize, Identify Language and Translate text. If you have any questions regarding this code lab, please raise them at StackOverflow and tag it with [google-mlkit]. Our team will monitor this.

Early access program

Through our early access program, developers have an opportunity to partner with the ML Kit team and get access to upcoming features. Two new APIs are now available as part of this program:

Entity Extraction - Detect entities in text & make them actionable. We have support for phone numbers, addresses, payment numbers, tracking numbers, date/time and more.
Pose Detection - Low-latency pose detection supporting 33 skeletal points, including hands and feet tracking.

If you are interested, head over to our early access page for details.

Tomorrow - Support for custom models

ML Kit's turn-key solutions are built to help you take common challenges. However, if you needed to have a more tailored solution, one that required custom models, you typically needed to build an implementation from scratch. To help, we are now providing the option to swap out the default Google models with a custom TensorFlow Lite model. We’re starting with the Image Labeling and Object Detection and Tracking APIs, that now support custom image classification models.

Tomorrow, we will dive a bit deeper into how to find or train a TensorFlow Lite model and use it either with ML Kit, or with Android Studio’s new ML binding functionality.

Source: Android Developers Blog

On-device machine learning solutions with ML Kit, now even easier to use

Posted by Christiaan Prins, Product Manager, ML Kit and Shiyu Hu, Tech Lead Manager, ML Kit

A new ML Kit SDK, fully focused on on-device ML

With this change, ML Kit is now fully focused on on-device machine learning, giving you access to the unique benefits that on-device versus cloud ML offers:

It’s fast, unlocking real-time use cases- since processing happens on the device, there is no network latency. This means, we can do inference on a stream of images / video or multiple times a second on text strings.
Works offline - you can rely on our APIs even when the network is spotty or your app’s end-user is in an area without connectivity.
Privacy is retained: since all processing is performed locally, there is no need to send sensitive user data over the network to a server.

Naturally, you still get access to Google’s on-device models and processing pipelines, all accessible through easy-to-use APIs, and offered at no cost.

What does this mean if I already use ML Kit today?

Shrink your app footprint with Google Play Services

// Face detection / Face contour model
// Delivered via Google Play Services outside your app's APK…
implementation 'com.google.android.gms:play-services-mlkit-face-detection:16.0.0'

// …or bundled with your app's APK
implementation 'com.google.mlkit:face-detection:16.0.0'

Jetpack Lifecycle / CameraX support

// ML Kit now supports Lifecycle
val recognizer = TextRecognizer.newInstance()
lifecycle.addObserver(recognizer)

// ...

// Just like CameraX
val camera = cameraProvider.bindToLifecycle( /* lifecycleOwner= */this,
    cameraSelector, previewUseCase, analysisUseCase)

For an overview of all recent changes, check out the release notes for the new SDK.

Codelab of the day - ML Kit x CameraX

Early access program

Through our early access program, developers have an opportunity to partner with the ML Kit team and get access to upcoming features. Two new APIs are now available as part of this program:

Entity Extraction - Detect entities in text & make them actionable. We have support for phone numbers, addresses, payment numbers, tracking numbers, date/time and more.
Pose Detection - Low-latency pose detection supporting 33 skeletal points, including hands and feet tracking.

If you are interested, head over to our early access page for details.

Tomorrow - Support for custom models

Tomorrow, we will dive a bit deeper into how to find or train a TensorFlow Lite model and use it either with ML Kit, or with Android Studio’s new ML binding functionality.