Yesterday, Google released Android 11 Beta 2, bringing the finalized SDK, NDK, app-facing surfaces, platform behaviors, and restrictions on non-SDK interfaces for developers. Today, Google is answering questions related to Android 11 over on Reddit’s /r/AndroidDev community after fielding questions last week. Here’s a summary of everything we learned from Google’s AMA (Ask Me Anything).
No Scrolling Screenshots
One of Android 11’s most anticipated features won’t be available when the OS exits beta on September 8th: Scrolling screenshots. Initially planned for launch in Android 11, Google has now confirmed that the feature “didn’t make the cut for R.” Android 11 Developer Preview 1 and all subsequent DP and Beta releases have a placeholder button for taking a scrolling screenshot that can be manually surfaced with a hidden developer command, but tapping the button simply shows a toast message stating that the feature is “not implemented.”
Android 11’s unimplemented scrolling screenshot button.
We were hoping the feature would make its way into a beta or even just the stable release, but it looks like that just won’t happen.
This news will understandably be upsetting to some users. After all, many OEMs have had this feature in their own software for years, so what’s taking Google so long to add it to Pixel phones? As explained by Dan Sandler from Google’s System UI team, the problem is that Google wants to do it right. Some scrolling screenshot implementations out there simply emulate a scroll and then stitch together multiple screenshots as the screen moves. If you’ve ever dealt with UI automation on Android, you’ll know that this doesn’t always work since, as Mr. Sandler mentions, apps can use “a bog-standard RecyclerView or have implemented their own OpenGL-accelerated scrolling engine.” Since Google plans to implement this feature for not just Pixel smartphones but for the entire Android ecosystem as part of AOSP, they need to make sure it’ll work on all apps and not just “one or two hand-picked apps on a particular device.”
Because the team had to “focus [their] limited resources,” especially due to the challenges brought about by COVID-19, the team decided to put scrolling screenshots on the backburner for a future Android release.
New CDD requirement to inform users of background restrictions
It’s no secret that many Android OEMs, especially Chinese ones, have aggressive restrictions on apps running in the background. Some developers were so frustrated with their apps being killed in the background that they banded together to make a website called “Don’t Kill My App” to rank OEMs based on how poorly they handle background app processes. Those same developers even recently made a benchmark so users can test how aggressively their device kills apps in the background. The reason why many OEMs love to kill background app processes is complicated, but I think it’s best explained in this comment by Redditor /u/possiblyquestionable. The comment outlines the complicated status of Android app development in China, how Chinese tech companies are involved in further complicating things, and how a lack of Google services contributes to the ongoing mess.
Regardless, many app developers are understandably frustrated by these tweaks to Android platform behavior, which has resulted in developers pushing a comment asking Google what they’re doing about it to the top of the Reddit AMA. Here’s Google’s response:
There are a few things to take away from this response. First, Google wants OEMs to be more transparent with users about the background app restrictions they’re applying. I checked the (unreleased) Android 11 Compatibility Definition Document (CDD) and found the following proposed addition to Section 3.5 – API Behavioral Compatibility:
If device implementations implement proprietary mechanism to restrict apps and that mechanism is more restrictive than “Rare” standby bucket on AOSP, they:
[C-1-5] MUST inform users if app restrictions are applied to an app automatically. (NEW) Such information MUST not be provided earlier than 24 hours before such restrictions are applied.
(Note)Force Stop is considered to be more restrictive than “Rare” and MUST comply all requirements under 3.5.1, including new 3.5.1/C-1-5
Basically, Google isn’t much to stop OEMs from implementing their own restrictive app-killing features. They’re only requiring that OEMs inform users if their app restrictions are being automatically applied. An OEM could show a dialog that they’re going to stop battery-sucking background apps from running in the background, and the user could consent without realizing the apps they really want to run in the background are also affected! Google is placing the onus on developers to deal with cases when their app is killed unexpectedly in the background. Indeed, the Reddit comment goes on to highlight the new “app process exit reasons” API that can tell developers whether their app was killed by the user, the OS, or if it simply crashed.
On the other hand, Google is finally addressing the unfair practice of OEMs allowing certain privileged applications to bypass their background app restrictions. This Medium post by developer Timothy Asiimwe goes into detail about apps like WhatsApp, Facebook, and other apps are automatically exempt from the harsh background restrictions of some OEM software. Google says they “require that device manufacturers don’t create allow lists for top apps.” We don’t know how this will be enforced, but it’s good to know that OEMs will finally be forced to treat third-party developers on equal footing—no matter how big or small their apps are.
Finally, Google also mentions how Android 11 has “added extra measures to prevent abusive behavior by misbehaving apps,” making it less enticing for OEMs to aggressively kill background processes. The company did not elaborate on what these “extra measures” entail, however.
Improved Device-to-Device Backups
Last month, we spotted a change to Android 11’s documentation that hinted at support for better local data backups. In Android 11, the system will disregard the allowBackup Manifest attribute for any app that targets API level 30 when the user initiates a “device-to-device” migration of app files. Googler Eliot Stock says that this feature is intended to make it “much easier for phone manufacturers to build device to device migration tools” such as “Samsung’s excellent Smart Switch product” to help “ensure apps more reliably transfer between devices from a user perspective.” Sadly, this doesn’t apply to cloud-based backups, as Google wants to “give software developers control around what happens with their app data.” As such, Android 11 will still respect the allowBackup attribute for any cloud-based backup and restore, such as through Google Play Service’s built-in Google Drive backup. Lastly, Google acknowledges that the 25MB-per-app backup ceiling may not be enough for some developers, so they’re looking into ways to solve that. Local backups to a PC aren’t under consideration, though, and Google reiterates their plan to phase out adb backup in a future Android release.
Developers are encouraged to implement frictionless data migration methods. The new Block Store library, which is part of the Google Identity Services Library, is designed to make it easier to sign into apps restored from the cloud on new devices, but it’s up to developers to choose whether or not they want to implement this library.
Faster App Startup Speeds with I/O Read Ahead Process (IORap)
Google is always experimenting with ways to improve performance in Android. One of the little known features they added in Android 10 is called the Unspecialized App Process Pool (USAP). This feature eliminates forking Zygote during the app startup process, saving approximately ~5ms in average app startup speeds on a Pixel 2 device. The feature is currently disabled by default in AOSP, and Google explains that its added memory use still needs testing. What’s more interesting, though, is a new feature coming to Android 11 called I/O Read Ahead Process (IORap). According to Google, this feature will lead to “more than 5% faster cold startups with hero cases reaching 20% faster.” This feature “will prefetch applications artifacts (like code and resources) during the startup process” to boost app launch speeds.
Google has also “made improvements to the profiles used to optimize the boot class path and system image” which will improve app performance and reduce the memory and storage cost associated with system artifacts. These changes will mostly benefit devices with higher amounts of RAM, though Google has not said what the cutoff is for where we’ll see the most benefits.
Android 11’s Scoped Storage changes – Why is access to /Downloads restricted?
Apps that target Android 11 and use the ACTION_OPEN_DOCUMENT_TREE intent to request access to specific directories on the external storage will no longer be able to ask users for access to the root directory of the external storage (/data/media/{user}), the Download directory (/data/media{user}/Download), or any of the app-specific data directories on the external storage (/Android/data or /Android/obb). Why is access to the Download directory restricted? According to Google Roxanna Aliabadi, it’s because the download folder “is the most at risk of having private information.” As an example, users who download their tax returns or banking statements shouldn’t have to worry about the possibility of apps abusing their continuous read access to the directory. Google says that the document picker will have “updated text…to indicate that Android has restricted certain folders to be selected.” This will hopefully reduce confusion about why they can’t grant apps access to certain directories anymore.
For more information on the upcoming Scoped Storage and Play policy changes, refer to this article.
Miscellaneous Topics
- Google’s stance on rooting/modding
- Jeff Bailey from Google’s AOSP team reiterates the company’s stance on supporting choice. Google will “continue to ensure that modding/rooting of the Pixel line of devices is possible,” but will also “support the choice of OEMs to not permit their devices to be rooted.” Furthermore, Google is giving software developers the choice “to not allow their software to run on rooted devices,” in reference to recent changes in software tampering detection of the SafetyNet Attestation API.
- What happened to “open and set to default”?
- Using the Vulkan Graphics API to render the UI?
- Missing CallScreeningService on many devices
- Android apps can implement the CallScreeningService API to intercept new incoming and outgoing calls, allowing them to identify the caller and either accept or reject the call. Although this is an officially documented API, there are apparently many OEMs that don’t properly implement it, according to developer /u/_zeromod_. Google confirms that this API is validated by the Compatibility Test Suite (CTS), an automated test suite that all devices must pass to be considered Android compatible. For whatever reason, this API returns null when called on devices from OEMs like Huawei, Vivo, Xiaomi, or Samsung, so it’s likely these OEMs have a bug in their software.
- No plans for an audio plugin framework
- A developer asked Google if they plan to implement an audio plugin framework like Apple’s Audio Units, but the answer is that it’s unlikely to happen in the near future.
You can read all of the answers from the Android engineering team here. The team talks a bit about Java, Kotlin, the Android build system, the CameraX API, and other topics in a few comments. There are also several comments about Wear OS, Android TV, and Android Auto, but Google mostly reiterates their existing work on these platforms and tells developers to stay tuned for more information during the “Android Beyond Phones” week starting August 10th.
The post Android 11 AMA Summary: No scrolling screenshots, New OEM restrictions, Faster app launches, and more appeared first on xda-developers.
from xda-developers https://ift.tt/3faN8T4
via
IFTTT
