Android Q Beta Introducing

With new technologies ranging from 5 G to edge to edge displays and even foldable screens, mobile innovation is stronger than ever in 2019. Android is at the center of this innovation cycle, and thanks to the wide ecosystem of partners across billions of devices, Android helps push hardware and software boundaries bringing users new experiences and capabilities.

Android is focused on helping users take advantage of the latest innovations as the mobile ecosystem evolves, while ensuring the safety and privacy of users is always a top priority. Building on efforts such as Google Play Protect and runtime permissions, Android Q provides users with a number of additional privacy and security features, as well as foldable enhancements, new connectivity APIs, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 support, and more.

Today we release Android Q's Beta 1 for early adopters and developers with a preview SDK. Today you can start with Beta 1 by registering any Pixel device (including the original Pixel and Pixel XL, for which we have extended popular demand support!) Please let us know what you think! Read on for a taste of what's in Android Q, and we're going to see you at Google I / O in May when we're going to have more to share.

Android has been designed in the center with security and privacy. As Android has matured, we've added a wide range of user-protecting features, including file-based encryption, OS controls requiring apps to request permission before accessing sensitive resources, camera / microbackground access, lockdown mode, encrypted backups, Google Play Protect (which scans over 50 billion apps a day to identify and remove potentially harmful apps), and more. We made even more improvements in Android Q to protect our users. Many of these improvements are part of Project Strobe's work.

With Android Q, the OS helps users gain more control over the location of apps. As in previous versions of the OS, apps can only be located once you've been asked for permission by the app and you've given it.

One thing that is especially sensitive is access to location for apps while the app is not in use (in the background). Android Q allows users to allow apps to never see where they are, only when the app is in use (running), or all the time (when in the background).

For example, it makes sense to have an app requesting a user's food delivery location and the user may want to give it the ability to do that. However, since the application may not need a location outside when it is currently in use, the user may not want to grant that access. Android Q now offers more control over this. For details on how to adapt your app to this new control, read the developer guide. In the upcoming Betas, look for more user-centered improvements. At the same time, our goal is to be very sensitive with these changes in order to always give developers as much notice and support as possible.

We make further updates to ensure transparency, provide user control, and secure personal data beyond location changes.

The OS provides users with even greater control over apps in Android Q, controlling access to shared files. Users will be able to use new runtime permissions to control the access of apps to the Photos and Videos or Audio collections. Apps need to use the system file picker for downloads, which allows the user to decide which files the app can access to download. There are changes in how your apps can use shared areas on external storage for developers. For details, make sure you read the changes to the Scoped Storage.

We also saw users (and developers!) getting upset when an app jumps into the foreground unexpectedly and becomes focused. Android Q will prevent apps from launching an activity in the background to reduce these interruptions. You can use a high-priority notification and provide a full-screen intent if your app is in the background and needs to get the user's attention quickly-such as incoming calls or alarms. For more information, see the documentation.

We restrict access to device identifiers that are not resettable, including device IMEI, serial number, and similar identifiers. To help you select the right identifiers for your use case, read the best practices and see the details here. Also, when connected to various Wi-Fi networks by default, we randomize the device's MAC address-a setting that was optional in Android 9 Pie.

We bring these changes to you early, so you can have as much time as you can to prepare for them. We have also worked hard to provide detailed information to developers in advance, we recommend reviewing the detailed privacy changes docs and starting testing right away.

In Android Q, we are enabling new ways to bring users into your apps as they transition from other apps and streamline the experience.

Some innovative experiences and use cases have been opened up by foldable devices. We've made a number of improvements in Android Q to help your apps take advantage of these and other large-screen devices, including changes to onResume and onPause to support multi-resume and notify your app when it's focused. We've also changed how the resizableActivity manifest attribute works to help you manage how your app appears on both foldable and large screens. We've been working hard to update the Android Emulator to support multi-display type switching to get you started building and testing on these new devices-more details coming soon!

If a user wants to share content in another app like a photo, the process should be quick. We make this faster and easier with Sharing Shortcuts in Android Q, which allows users to jump into another app to share content directly. Developers can publish targets for sharing that launch a specific activity with content attached in their apps, and these are shown in the share UI to users. Because they are published in advance, when launched, the share UI can load immediately.

The mechanism for sharing shortcuts is similar to how App Shortcuts works, so we have expanded the ShortcutInfo API to make it easier to integrate both features. The new ShareTarget AndroidX library also supports this new API. This allows the new functionality to be used by apps while allowing pre-Q devices to work with Direct Share. An early sample app with source code can be found here.

Using a new Settings Panel API, which takes advantage of the Slices feature we introduced in Android 9 Pie, you can now also show key system settings directly in the context of your app.

A settings panel is a floating user interface that you invoke from your app to show system settings that users may need, such as internet connectivity, NFC, and volume audio. A browser might display a panel with connectivity settings such as Airplane Mode, Wi-Fi (including nearby networks) and Mobile Data, for example. No need to leave the app; users can manage settings from the panel as needed. Simply fire an intent with one of the new Settings. Panel actions to display a settings panel.

In Android Q, we've added new connectivity APIs to what your apps can do with Android's connectivity stack.

Most of our network scanning APIs already require COARSE location permission, but we are increasing the protection around these APIs in Android Q for Bluetooth, Cellular and Wi-Fi by requiring instead FINE location permission. If your app only needs to make peer-to-peer connections or suggest networks, check the upgraded Wi-Fi APIs below-they simplify connections and do not require permission to locate them.

We are adding new standard Wi-Fi support, WPA3 and Enhanced Open, in addition to the randomized MAC addresses that Android Q provides when connected to different Wi-Fi networks, to improve security for home and work networks as well as open / public networks.

We refactured the Wi-Fi stack in Android Q to improve privacy and performance, but also to improve common usage cases such as managing IoT devices and suggesting internet connections-without requiring permission to locate them.

The network connection APIs make it easier for peer-to-peer functions such as configuring, downloading, or printing to manage IoT devices over local Wi-Fi. Apps initiate requests for connections indirectly by specifying preferred SSIDs & BSSIDs as specifiers for WiFiNetwork. The platform handles the Wi-Fi scanning itself and displays in a Wi-Fi picker matching networks. The platform sets the connection automatically when the user chooses to do so.

The network suggestion APIs allow the user to surface Internet connectivity with preferred Wi-Fi networks. Using a ranked list of networks and credentials as WifiNetworkSuggestions, apps initiate connections indirectly. The platform will connect seamlessly in the range of those networks based on past performance.

By enabling high performance and low latency modes, you can now request adaptive Wi-Fi in Android Q. These will be of great benefit where low latency is important for the user experience, such as real-time gaming, active voice calls, and similar use cases.

Call WifiManager. WifiLock.createWifiLock) (with WIFI_MODE_FULL_LATENCY or WIFI_ MODE_FULL_HIGH_PERF to use the new performance modes. The platform works with the device firmware in these modes to satisfy the requirement with the lowest power consumption.

Dynamic photo depth format

Many cameras on mobile devices, by blurring the foreground or background relative to the subject, can simulate narrow field depth. They capture metadata depth for different image points and apply a static blur to the image, after which they discard the metadata depth.

Starting with Android Q, apps can request a Dynamic Depth image consisting of a JPEG, depth-related XMP metadata, and a depth and trust map embedded on devices advertising support in the same file.

Requesting a JPEG + Dynamic Depth image allows you to provide your app with specialized blurs and bokeh options. You can even use the data in future to create 3D images or to support use-cases for AR photography. We make Dynamic Depth an open format for the ecosystem and work with our device maker partners to make it available across devices running Android Q and beyond.

Android Q introduces AV1 open source video codec support. This enables media providers to use less bandwidth to stream high-quality video content to Android devices. Android Q also supports audio encoding with Opus-a codec optimized for speech and music streaming, and HDR10+ for high-dynamic video on devices that support it.

The MediaCodecInfo API presents an easier way to determine an Android device's video rendering capabilities. Use VideoCodecCapabilities.getSupportedPerformancePoints) (to obtain a list of supported sizes and frame rates for any given codec. This allows you to choose the video content of the best quality to render on any device.

Android Q introduces a native MIDI API to communicate with MIDI devices via the NDK for applications that perform their audio processing in C++. Using a non-blocking read, this API enables low latency processing of MIDI messages to be retrieved inside an audio callback. Here you can try the sample app and source code.

We are working towards a standard, updatable OpenGL driver for all devices built on Vulkan to enable more consistency for game and graphics developers. We are adding experimental support for ANGLE in Android Q on Android devices in addition to Vulkan. ANGLE is an abstraction layer of graphics designed for high-performance OpenGL compatibility across implementations. ANGLE allows the many apps and games that use OpenGL ES to take advantage of Vulkan's performance and stability and benefit from a consistent, vendor-independent implementation of ES on Android devices. We plan to support OpenGL ES 2.0 in Android Q, with ES 3.0 on our roadmap next.

With more OpenGL features, bug fixes, and performance optimizations, we will expand the implementation. See the docs for details on Android's current ANGLE support, how to use it, and how to move forward with our plans. With our initial support, you can start testing by opting-in through Settings developer options. Give it an attempt today!

We continue to expand Vulkan's impact on Android, our implementation of high-performance 3D graphics low-overhead, cross-platform API. Our objective is to make Vulkan a widely supported and consistent graphics developer API on Android. We work with our device manufacturer partners to make Vulkan 1.1 a requirement for all Android Q and higher 64-bit devices, and a recommendation for all 32-bit devices. This will help to provide a consistent high-performance graphics API for applications and games to be used in the future.

We have continued to expand the number of operations supported and improve existing functionality since the introduction of the Neural Networks API (NNAPI) in 2017. In Android Q, in addition to a range of performance optimizations, we have added 60 new ops including ARGMAX, ARGMIN, quantized LSTM. This lays the foundation for speeding up a much wider range of models-such as those for object detection and segmentation of images. To optimize and roll out NNAPI 1.2 support, we work with hardware vendors and popular machine learning frameworks such as TensorFlow.

Android Q introduces several new enhancements to the ART runtime that helps apps start faster and consume less memory without requiring developers to do anything.

ART has been offering Profile Guided Optimization (PGO) since Android Nougat, which speeds up the startup of the app over time by identifying and precompiling frequently executed parts of your code. Google Play now provides cloud-based profiles along with APKs to help with the initial start-up of the app. These are anonymous, aggregate ART profiles that allow ARTto pre-compile parts of your app even before it runs, giving the overall optimization process a significant jump-start. Cloud-based profiles benefit all apps, and devices running Android P and higher already have access to them.

In ART itself, we also continue to make improvements. For example, in Android Q, by starting the process of your app earlier and moving it to a security container, we have optimized the Zygote process, so it's ready to start immediately. In the heap image of the app, such as classes, we store more information and use threading to load the image faster. We also add Generational Garbage Collection to ART's Garbage Collector for Concurrent Copying (CC). Generational CC is more efficient as it collects objects of the young generation separately, incurring significantly lower costs compared to full-heap GC, while still retrieving a good amount of space. In general, this makes garbage collection more time-and CPU-efficient, reducing janks and helping apps run better on lower-end devices.

BiometricPrompt is our unified system-level authentication framework to support biometrics. We extend support for passive authentication methods such as face in Android Q, and add flows of implicit and explicit authentication. During the authentication, the user must explicitly confirm the transaction in the TEE. The implicit flow is designed to provide a lighter-weight alternative for passive authentication transactions. We have also improved the device credentials fallback when necessary.

Android Q adds support to TLS 1.3, a major TLS standard revision that includes performance benefits and increased security. Our benchmarks indicate that TLS 1.3 can establish secure connections as much as 40% faster than TLS 1.2. For all TLS connections, TLS 1.3 is enabled by default. See the details of the docs.

Another thing we're all concerned about is ensuring apps run smoothly as the operating system changes and evolves. Apps that use non-SDK APIs for users risk crashes and developer emergency rollouts. In Android Q, we're continuing our long-term Android P effort to move apps to use public APIs only. We know it's going to take time to move your app away from non-SDK APIs, so we give you advance notice.

We restrict access to more non-SDK interfaces in Android Q and ask you instead to use the public equivalents. To help you make the transition and avoid breaking your apps, we only allow the restrictions when your app targets Android Q. We will continue to add alternative public APIs based on your requests; please let us know in cases where there is no public API that meets your use case.

Testing your apps for non-SDK interface uses is important. We recommend using the detectNonSdkApiUsage) (method of StrictMode to warn you when your application accesses non-SDK APIs through reflection or JNI. Even if the APIs are currently exempt (grey-listed), the best way to plan for the future is to eliminate their use to reduce compatibility issues. See the developer guide for more details on the restrictions in Android Q.

We are expanding our efforts to ensure that all apps take full advantage of the latest version of Android's security and performance features. Google Play will require you to set the targetSdkVersion of your app to 28 (Android 9 Pie) in new apps and updates later this year. Android Q will warn users with a dialog when they first run an app targeting a platform earlier than API level 23 (Android Marshmallow) in line with these changes. Here is a resource checklist to help you migrate your application

For 64-bit devices, we are also moving the ecosystem towards readiness. Google Play will need 64-bit support in all apps later this year. When using native SDKs or libraries, remember to provide 64-bit versions of those SDKs or libraries. For details on how to get ready, see the developer guide.

With important privacy features that may affect your apps, we recommend that you start testing immediately. Specifically, with Android Q storage changes, new location permission states, background app launch restrictions, and device identifier restrictions, you'll want to enable and test. See the details of the privacy documentation.

Install your current Google Play app on a device or Android Virtual Device running Android Q Beta and work through user flows to get started. The app should look great and run, and handle changes in the behavior of Android Q properly for all apps. If you encounter problems, we recommend that you fix them in the current app without changing your target level. For steps and a recommended timeline, take a look at the migration guide.

Next, update as soon as possible the targetSdkVersion of your app to' Q.' This allows you to test your app with all of Android Q's privacy and security features, as well as any other changes in behavior for Q-targeted apps.

Dive into Android Q and learn about the new features and APIs that you can use in your apps when you're ready. Take a look at the report on the API diff, the Android Q Beta API reference, and the starting point for developer guides. You will also find release notes and support resources for reporting issues on the Android Q Beta developer site.

Download the Android Q Beta SDK and tools to Android Studio 3.3 or higher to build with Android Q, and follow these instructions to set up your environment. We recommend using Android Studio 3.5 or higher if you want the latest fixes for changes related to Android Q.

It's easy-you can sign up for Android Q Beta over - the-air updates on any Pixel device (and this year we're supporting all three Pixel generations-Pixel 3, Pixel 2, and even the original Pixel!). Downloadable system images are also available for these devices. You can use the Android Emulator if you don't have a Pixel device and download the latest emulator system images via the Android Studio SDK Manager.

We plan to update system preview images and SDK throughout the preview on a regular basis. As the Beta program moves forward, we will have more features to share.

Your feedback is critical as always, so please let us know what you think — the sooner we hear from you, the more we can integrate your feedback. Please report them here when you find issues. We have separate hotlists for filing issues with the platform, compatibility issues with apps, and SDK issues with third parties.

Credit : Source