Google Play is unifying the dates for its target API level requirements.
Starting August 31, 2023:
- New apps and app updates must target API level 33 (Android 13) to be submitted to Google Play. (Wear OS apps must target API level 30 [Android 11])
- Existing apps must target API level 31 or above to be discoverable by all users on Google Play. Apps that target API level 30 or below will only be discoverable on devices running Android versions the same or lower than your apps' target API level. (Wear OS apps must target API level 29 or below to remain discoverable.)
If you need more time to get ready for this change, you can request an extension to November 1, 2023. You'll be able to access the form to request an extension through the Play Console later this year.
Previously, new apps had to target current_release-1 by Aug. 1 of the current year, while app updates had to target current_release-1 by Nov. 1. Now those two dates are unified as well as Google's new app discoverability requirement.
The app discoverability requirement was supposed to go into effect on Nov. 1st of last year but got delayed to Jan. 31 of this year. Now it's starting Aug. 31 of this year, but some users already report they're unable to see apps targeting older versions.
In case you missed it, Google announced this change in an email sent to developers on Google Play yesterday. More details and a FAQ can be found in this support post.
Starting August 31, 2023:
- New apps and app updates must target API level 33 (Android 13) to be submitted to Google Play. (Wear OS apps must target API level 30 [Android 11])
- Existing apps must target API level 31 or above to be discoverable by all users on Google Play. Apps that target API level 30 or below will only be discoverable on devices running Android versions the same or lower than your apps' target API level. (Wear OS apps must target API level 29 or below to remain discoverable.)
If you need more time to get ready for this change, you can request an extension to November 1, 2023. You'll be able to access the form to request an extension through the Play Console later this year.
Previously, new apps had to target current_release-1 by Aug. 1 of the current year, while app updates had to target current_release-1 by Nov. 1. Now those two dates are unified as well as Google's new app discoverability requirement.
The app discoverability requirement was supposed to go into effect on Nov. 1st of last year but got delayed to Jan. 31 of this year. Now it's starting Aug. 31 of this year, but some users already report they're unable to see apps targeting older versions.
In case you missed it, Google announced this change in an email sent to developers on Google Play yesterday. More details and a FAQ can be found in this support post.
👍31❤2
Xiaomi, OPPO, and Vivo are collaborating to make setting up a new Android phone easier when you switch brands. Phones from these brands will support migrating "system data" like "photos and contacts" and - more importantly - third-party app data between one another.
This collab was announced by Xiaomi on Weibo (H/T @AndroidPolice), so it's unclear if this will apply to each company's respective global software versions. Still, setting up a new Android phone can be a pain, especially when you're switching brands, so this is a welcome change.
When you buy a new phone from the same brand that made your old one, chances are that brand's proprietary data transfer tool will move almost everything over. That's not the case when switching brands, as only a limited set of data (usually excluding 3P app data) is transferred.
Full data backups and restores is something Android has lacked for a LONG time, but it's not that Android can't do it (GMS certainly could, and Titanium Backup has existed since forever)...it's ironing out the complications that arise when it is done.
Lots of apps make certain assumptions/have certain configs that apply to certain kinds of devices/devices from specific brands. Or there's a specific per-device token that needs to be reissued (just look up threads on broken push notifications after restoring data using Titanium Backup.)
This collab was announced by Xiaomi on Weibo (H/T @AndroidPolice), so it's unclear if this will apply to each company's respective global software versions. Still, setting up a new Android phone can be a pain, especially when you're switching brands, so this is a welcome change.
When you buy a new phone from the same brand that made your old one, chances are that brand's proprietary data transfer tool will move almost everything over. That's not the case when switching brands, as only a limited set of data (usually excluding 3P app data) is transferred.
Full data backups and restores is something Android has lacked for a LONG time, but it's not that Android can't do it (GMS certainly could, and Titanium Backup has existed since forever)...it's ironing out the complications that arise when it is done.
Lots of apps make certain assumptions/have certain configs that apply to certain kinds of devices/devices from specific brands. Or there's a specific per-device token that needs to be reissued (just look up threads on broken push notifications after restoring data using Titanium Backup.)
👍22👏4🤔4😁1
Since the source code for Android 13 QPR2 was released, let's take a look at some of the under-the-hood and lesser known changes in this thread👇
Twitter
Since the source code for Android 13 QPR2 was released, let's take a look at some of the under-the-hood and lesser known changes in this thread👇
👍19🔥3
Android has supported live wallpapers since Android 2.0 Eclair was released in 2009, but finally with Android 14 in 2023, you may be able to set a different live wallpaper for the home and lock screen.
Details here.
Details here.
XDA Developers
Android 14 may let you finally set different live wallpapers for the home and lock screens
Android has supported live wallpapers since 2009, but in 2023, the OS may finally let you set a separate live wallpaper for the lock screen.
👍37🤔6❤1
Work profile users, heads up: In Android 14, screenshots you take of work apps will now be saved to the work profile instead of your personal profile!
You may see this "Saved in [Files] in the work profile" notice after taking your first screenshot of a work app after updating.
This change is already live in Android 13 QPR3 Beta 1 and Android 14 DP2, but since very few OEMs merge QPRs, most work profile users won't see this change until Android 14.
This change was first implemented in Android 13 QPR2, but it's gated by the SCREENSHOT_WORK_PROFILE_POLICY flag, which is disabled by default in Android 13 QPR2/Android 14 DP1. You can see the code changes for the new work profile screenshot feature here.
As for why screenshots of work profile apps used to be saved in your personal profile's storage, it's because of the way SystemUI (prior to QPR3/DP2) handled screenshots.
Since your personal & work profiles share the same SystemUI instance (profiles are tied to a parent user), SystemUI needed to know which profile the app belonged to when deciding where to save the screen capture. That logic has been implemented in QPR2+.
You may see this "Saved in [Files] in the work profile" notice after taking your first screenshot of a work app after updating.
This change is already live in Android 13 QPR3 Beta 1 and Android 14 DP2, but since very few OEMs merge QPRs, most work profile users won't see this change until Android 14.
This change was first implemented in Android 13 QPR2, but it's gated by the SCREENSHOT_WORK_PROFILE_POLICY flag, which is disabled by default in Android 13 QPR2/Android 14 DP1. You can see the code changes for the new work profile screenshot feature here.
As for why screenshots of work profile apps used to be saved in your personal profile's storage, it's because of the way SystemUI (prior to QPR3/DP2) handled screenshots.
Since your personal & work profiles share the same SystemUI instance (profiles are tied to a parent user), SystemUI needed to know which profile the app belonged to when deciding where to save the screen capture. That logic has been implemented in QPR2+.
👍35❤2👎1
Android's share sheet is getting a handful of improvements in Android 14. The biggest one is a dedicated row for app-defined actions, which should hopefully convince some apps to ditch their custom share sheets and use the OS's!
More details here.
More details here.
www.esper.io
5 ways Google is making the share sheet better in Android 14
Google is making the share sheet better in Android 14. Here are the top 5 improvements to the sharing experience we spotted.
👍35❤4
As I mentioned earlier, Android 14 adds a new feature that lets Device Controls providers specify an activity to embed in the Device Controls interface. The latest beta version of the Google Home app (H/T 9to5Google) adds support for this new feature. Attached to this post are some screenshots.
Google Home's custom embedded Device Controls activity is shown whether you access Device Controls through the lock screen shortcut or the Quick Settings tile.
So what does this mean for end users? It means that smart home apps (or really, any app that uses Device Controls, like
João Dias's Tasker) can embed a nicer, more custom UI with more useful actions, instead of being limited to a couple of buttons with a preset UI.
Although the API in question (ControlsProviderService#META_DATA_PANEL_ACTIVITY) is public starting with the Android 14 SDK, it also works on Android 13 QPR3 Beta 1, because the SysUI flag guarding it (USE_APP_PANELS) became a "ReleasedFlag" (ie. defaults to true). Part of the code for it is also in AOSP already since Android 13 QPR2's source drop.
Google Home's custom embedded Device Controls activity is shown whether you access Device Controls through the lock screen shortcut or the Quick Settings tile.
So what does this mean for end users? It means that smart home apps (or really, any app that uses Device Controls, like
João Dias's Tasker) can embed a nicer, more custom UI with more useful actions, instead of being limited to a couple of buttons with a preset UI.
Although the API in question (ControlsProviderService#META_DATA_PANEL_ACTIVITY) is public starting with the Android 14 SDK, it also works on Android 13 QPR3 Beta 1, because the SysUI flag guarding it (USE_APP_PANELS) became a "ReleasedFlag" (ie. defaults to true). Part of the code for it is also in AOSP already since Android 13 QPR2's source drop.
👍19
Mishaal's Android News Feed
As I mentioned earlier, Android 14 adds a new feature that lets Device Controls providers specify an activity to embed in the Device Controls interface. The latest beta version of the Google Home app (H/T 9to5Google) adds support for this new feature. Attached…
In Android 13 QPR3 Beta 1, currently ONLY the Google Home app is allowed to embed a custom activity in SystemUI's Device Controls interface.
This is because only packages declared in the config_controlsPreferredPackages array can declare activities for use as a panel, and this array currently only holds the package name for the Google Home app (com.google.android.apps.chromecast.app) on Pixels' Android 13 QPR3 Beta 1 builds.
A separate SysUI flag (APP_PANELS_ALL_APPS_ALLOWED) overrides this to allow panels from all apps, but this is disabled by default in Android 13 QPR3 Beta 1 but enabled by default in Android 14 DP2 (which makes sense since this is now a public API in Android 14).
This is because only packages declared in the config_controlsPreferredPackages array can declare activities for use as a panel, and this array currently only holds the package name for the Google Home app (com.google.android.apps.chromecast.app) on Pixels' Android 13 QPR3 Beta 1 builds.
A separate SysUI flag (APP_PANELS_ALL_APPS_ALLOWED) overrides this to allow panels from all apps, but this is disabled by default in Android 13 QPR3 Beta 1 but enabled by default in Android 14 DP2 (which makes sense since this is now a public API in Android 14).
👍15
CameraX will soon support concurrent camera streams, allowing you to record from two cameras simultaneously at 720p or 1440p resolution.
The Camera2 API for concurrent camera streaming was introduced in Android 11, so it's nice to see support finally extend to CameraX as well!
Google tested CameraX's Concurrent Camera API on the Pixel 6 Pro, Samsung Galaxy S21, and OnePlus 7 Pro. But there are many more models that support concurrent camera streams.
According to the Google Play Console's Device Catalog, 179 device models declare android.hardware.camera.concurrent, the feature indicating that the vendor correctly configured the front and back cameras to support concurrent camera streaming.
(A great read on the concurrent camera streaming API.)
The Camera2 API for concurrent camera streaming was introduced in Android 11, so it's nice to see support finally extend to CameraX as well!
Google tested CameraX's Concurrent Camera API on the Pixel 6 Pro, Samsung Galaxy S21, and OnePlus 7 Pro. But there are many more models that support concurrent camera streams.
According to the Google Play Console's Device Catalog, 179 device models declare android.hardware.camera.concurrent, the feature indicating that the vendor correctly configured the front and back cameras to support concurrent camera streaming.
(A great read on the concurrent camera streaming API.)
droidcon
Can We Use the Front & Back Cameras at the Same Time on Android?
TL;DR: Yes, if the device’s software and hardware support it, which can’t be taken for granted. Currently, the only way how to query it is to use the concurrent camera streaming API or look for the FEATURE_CAMERA_CONCURRENT feature on the system.
👍22❤3🔥1
Although Android has supported the EXT4 file system for a very long time now (Pixels and many others have their read-only system/product/etc partitions formatted in it), you still can't mount external USB/SDcard drives formatted in EXT4.
Well, MediaTek is trying once again to get Google to allow this by introducing a patch to vold (Android's volume daemon) that will add support for mounting EXT4 drives.
A similar patch was rejected in 2020 for security reasons, however: "unfortunately complex filesystems (such as ext4) cannot be mounted directly from untrusted media, due to the potential security vulnerabilities in these complex filesystems. The only safe way to mount these complex filesystems is when they've been wrapped in an encryption layer (such as offered by Adoptable Storage) to ensure that a malicious actor cannot tamper with the contents." - Jeff Sharkey
Well, MediaTek is trying once again to get Google to allow this by introducing a patch to vold (Android's volume daemon) that will add support for mounting EXT4 drives.
A similar patch was rejected in 2020 for security reasons, however: "unfortunately complex filesystems (such as ext4) cannot be mounted directly from untrusted media, due to the potential security vulnerabilities in these complex filesystems. The only safe way to mount these complex filesystems is when they've been wrapped in an encryption layer (such as offered by Adoptable Storage) to ensure that a malicious actor cannot tamper with the contents." - Jeff Sharkey
👍14
Android 13 QPR3 Beta 2 is rolling out now!
Build number: T3B2.230316.003
Build number: T3B2.230316.003
👍28😐2🍾1
Android is adding a new "enhanced PIN privacy" feature that will disable animations when entering your PIN on the lock screen!
This will hopefully make it harder for shoulder surfers to steal your PIN while you're out in public.
Full details here.
This will hopefully make it harder for shoulder surfers to steal your PIN while you're out in public.
Full details here.
XDA
Android 14 will make it easier to hide your phone’s PIN from shoulder surfers
Android is adding a new "enhanced PIN privacy" setting that will make it safer for you to enter your phone's PIN in public.
👍39
What's new in the March 2023 Google Play System Update? As usual, a lot of bug fixes and under-the-hood changes that don't impact users.
Here are the modules (and their version codes) that were updated:
AdServices: 331418100
Cell Broadcast: 331510000
Media: 331511000
Media Codecs: 331511000
Media Provider: 331512020
Statsd: 331511000
Permission Controller: 331512020
DNS Resolver: 331512000
Tethering: 331511000
WiFi: 331511020
AOSP tags corresponding to all but AdServices are available.
* Cell Broadcast has been updated to "support Ukraine requirement" (play National Alerts and Emergency Alerts regardless of whether DND is on). It also supports emergency alerts in Norway, and if your ringer is set to mute, alerts won't sound.
* DNSResolver adds support for using Google's DNS64 as the DoH provider.
* Photo Picker adds support for syncing width, height, and orientation fields from the external db; and handling local + cloud items in cloud albums.
There are more changes you can browse in the changelog I made here.
I know these changelogs don't reveal much, but literally nobody else is doing them, and I was curious to see what was actually changing in each Google Play System Update, so here we are!
Here are the modules (and their version codes) that were updated:
AdServices: 331418100
Cell Broadcast: 331510000
Media: 331511000
Media Codecs: 331511000
Media Provider: 331512020
Statsd: 331511000
Permission Controller: 331512020
DNS Resolver: 331512000
Tethering: 331511000
WiFi: 331511020
AOSP tags corresponding to all but AdServices are available.
* Cell Broadcast has been updated to "support Ukraine requirement" (play National Alerts and Emergency Alerts regardless of whether DND is on). It also supports emergency alerts in Norway, and if your ringer is set to mute, alerts won't sound.
* DNSResolver adds support for using Google's DNS64 as the DoH provider.
* Photo Picker adds support for syncing width, height, and orientation fields from the external db; and handling local + cloud items in cloud albums.
There are more changes you can browse in the changelog I made here.
I know these changelogs don't reveal much, but literally nobody else is doing them, and I was curious to see what was actually changing in each Google Play System Update, so here we are!
👍37❤11
This media is not supported in your browser
VIEW IN TELEGRAM
Woohoo, finally! Nearby Share for Windows is finally here (in beta)! It was announced all the way back in CES 2022 and is finally available today for Windows PCs running Windows 10 and up (no ARM support yet).
Download is available from this page.
Download is available from this page.
🎉60❤5👍3🔥3👨💻2👏1😁1🆒1
If you're planning to manually install Android 14 Beta 1 using the factory image for your Pixel when it's released, do not upgrade platform-tools right now. Version 34.0.0 and newer currently have a bug that prevents them from rebooting to userspace fastboot, causing the attached issue:
The fix is to downgrade to an older platform-tools, like r33.0.3. I ran into this problem when reflashing Android 14 DP2 on my Pixel 6 Pro.
r33.0.3 download.
Issue Tracker for this bug.
A Googler says they've "identified the root cause of this issue and are working on a fix."
As of today, latest platform-tools version does not contain this fix.
Some say Android Flash Tool is unaffected; it may be using an older platform-tools under-the-hood.
The fix is to downgrade to an older platform-tools, like r33.0.3. I ran into this problem when reflashing Android 14 DP2 on my Pixel 6 Pro.
r33.0.3 download.
Issue Tracker for this bug.
A Googler says they've "identified the root cause of this issue and are working on a fix."
As of today, latest platform-tools version does not contain this fix.
Some say Android Flash Tool is unaffected; it may be using an older platform-tools under-the-hood.
🔥14👍8😱2❤1
Private Compute Services (PCS), the open source part of Android's "Private Compute Core" that handles downloading models from the Internet, is adding support for performing model downloads in a VM on Android 14. This would make model downloads even more secure in Android 14!
The caveat with this is that this requires devices to support the Android Virtualization Framework (AVF). Currently on Android 13, only the Tensor Pixels support this.
On Android 14, we may see this supported by Linux 6.1-based Snapdragon 8 Gen 3 (?) products.
Add VM permission to PCS for future usecases in Android 14.<!-- This permission is for PCS to use pKVM for protected model downloads. --><uses-permission android:name="android.permission.MANAGE_VIRTUAL_MACHINE" />The caveat with this is that this requires devices to support the Android Virtualization Framework (AVF). Currently on Android 13, only the Tensor Pixels support this.
On Android 14, we may see this supported by Linux 6.1-based Snapdragon 8 Gen 3 (?) products.
👍15❤2