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
The April 2023 Android Security Bulletin is now live! The bulletin lists what vulnerabilities have been patched in the 2023-04-01 and 2023-04-05 security patch levels.
There are two RCE issues affecting AOSP "System" components marked as "critical" severity vulnerabilities. No details are available yet for either (CVE-2023-21085 & CVE-2023-21096).
There are also two issues impacting Project Mainline components (MediaProvider and WiFi), but it is unclear when updates to these components will roll out (if they haven't already).
There are two RCE issues affecting AOSP "System" components marked as "critical" severity vulnerabilities. No details are available yet for either (CVE-2023-21085 & CVE-2023-21096).
There are also two issues impacting Project Mainline components (MediaProvider and WiFi), but it is unclear when updates to these components will roll out (if they haven't already).
π19π₯4
In Android 14, Android's dynamic color engine ("monet") seems to be adding better support for users who enable "high contrast" to improve visibility! Apps should look good for everyone, including those who rely on Android's accessibility features!
In Android 14, the system generates a new FRRO (Fabricated Runtime Resource Overlay) called "dynamic" that overlays several new R.color fields. You can see the mapping in the below screenshot. The full list of new R.color fields can be seen here.
I wasn't sure what these new tokens were really for until I spotted this recent commit to the Material Components library: "[Tokens/Color] Added U color resources for contrast mode support."
What's happening is Android is generating a FRRO with new Material You tonal palettes that take into account if the user has high contrast mode enabled. Monet already accounts for contrast issues when generating palettes, but high contrast presents additional challenges.
The Material Components library will probably handle juggling the various R.color resources to use based on whether high contrast is enabled, so most app developers probably won't have to worry about anything (unless you were directly using R.color values instead of tokens).
(Sidenote: It's not clear if "contrast" is specifically related to "high contrast text" in Settings. There could be some new contrast settings added to the ThemePicker [Wallpaper & styles on Pixels]. We'll have to wait and see.)
As usual, since Google hasn't made a formal announcement on this change yet, there's no guarantee it'll ship in the stable Android 14 release. Also, there's a chance I misinterpreted things, but this also made sense to a few developers I talked to, so I hope not!
In Android 14, the system generates a new FRRO (Fabricated Runtime Resource Overlay) called "dynamic" that overlays several new R.color fields. You can see the mapping in the below screenshot. The full list of new R.color fields can be seen here.
I wasn't sure what these new tokens were really for until I spotted this recent commit to the Material Components library: "[Tokens/Color] Added U color resources for contrast mode support."
What's happening is Android is generating a FRRO with new Material You tonal palettes that take into account if the user has high contrast mode enabled. Monet already accounts for contrast issues when generating palettes, but high contrast presents additional challenges.
The Material Components library will probably handle juggling the various R.color resources to use based on whether high contrast is enabled, so most app developers probably won't have to worry about anything (unless you were directly using R.color values instead of tokens).
(Sidenote: It's not clear if "contrast" is specifically related to "high contrast text" in Settings. There could be some new contrast settings added to the ThemePicker [Wallpaper & styles on Pixels]. We'll have to wait and see.)
As usual, since Google hasn't made a formal announcement on this change yet, there's no guarantee it'll ship in the stable Android 14 release. Also, there's a chance I misinterpreted things, but this also made sense to a few developers I talked to, so I hope not!
π27
The Chrome team continues evaluating how they'll implement support for the Android Photo Picker. Recently they added a flag that controls what Picker is launched:
1) ACTION_GET_CONTENT intent
2) ACTION_PICK_IMAGES intent
3) ACTION_PICK_IMAGES "Plus" intent
4) Chrome Picker
(H/T @LanceAdams for pointing out the flag!)
β-
1) GET_CONTENT is currently handled by DocumentsUI (the system file picker). Google is experimenting with having the new Android Photo Picker "take over" handling of the GET_CONTENT intent. This briefly rolled out in December but was reverted.
2) ACTION_PICK_IMAGES intent is the standard way to invoke the framework Photo Picker on Android 11+ (though Chrome stills seems to require Android 13?). Through GMS, Photo Picker is also backported to Android 4.4+
3) ACTION_PICK_IMAGES "Plus" is interesting. The MIME type is set to
I personally think this would be useful; give users the option to open the more feature-rich DocumentsUI, no matter how the Photo Picker is invoked, while still defaulting to the prettier Photo Picker for image/video selection.
4) Chrome Picker, this just launches the old in-app media picker, which means you have to grant Chrome gallery access permissions.
1) ACTION_GET_CONTENT intent
2) ACTION_PICK_IMAGES intent
3) ACTION_PICK_IMAGES "Plus" intent
4) Chrome Picker
(H/T @LanceAdams for pointing out the flag!)
β-
1) GET_CONTENT is currently handled by DocumentsUI (the system file picker). Google is experimenting with having the new Android Photo Picker "take over" handling of the GET_CONTENT intent. This briefly rolled out in December but was reverted.
2) ACTION_PICK_IMAGES intent is the standard way to invoke the framework Photo Picker on Android 11+ (though Chrome stills seems to require Android 13?). Through GMS, Photo Picker is also backported to Android 4.4+
3) ACTION_PICK_IMAGES "Plus" is interesting. The MIME type is set to
*/* (ie. all) which Photo Picker does not handle and instead forwards to DocumentsUI. It seems the Chrome team wants the Photo Picker team to add a way to force the Photo Picker to show the "browse" button in the overflow menu; currently this "browse" button only appears when the Photo Picker is invoked through the GET_CONTENT takeover, and tapping it opens the system file picker/DocumentsUI.I personally think this would be useful; give users the option to open the more feature-rich DocumentsUI, no matter how the Photo Picker is invoked, while still defaulting to the prettier Photo Picker for image/video selection.
4) Chrome Picker, this just launches the old in-app media picker, which means you have to grant Chrome gallery access permissions.
β€18π1
A couple of more Android 14 (DP2) findings in this thread π:
1) A new EXECUTE_APP_ACTION permission that "allows an assistive application to perform actions on behalf of users inside of applications." This permission is granted to the default Assistant. Currently, I don't see any APIs that require this permission.
2) A new LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE permission that "allows an application to capture screen content to perform a screenshot using the intent action." This is intended for the app that holds the ROLE_NOTES role.
ROLE_NOTES is a new role in Android 14. It can only be granted to apps that target SDK 34 and that handle the android.intent.action.CREATE_NOTE intent. The role itself is disabled unless config_enableDefaultNotes = true, and the default holder is defined by config_defaultNotes.
(In case you're wondering, Google Keep doesn't currently qualify to be the holder of ROLE_NOTES.)
Attached is the settings page for setting the "default notes app".
Apps with the permission can use the ACTION_LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE intent action to trigger SystemUI to get a screenshot of the current window on behalf of the app. The user then has a chance to edit the screenshot, which can then be returned to the notes app.
3) Companion Device sync: In Android 13, Google laid the groundwork for syncing certain data when setting up a companion device (like a smartwatch or earbuds) through an app that uses the CompanionDeviceManager API. They added preliminary support for syncing permissions.
I've never seen it in action yet, but what they added was the ability to automatically grant certain permissions to apps you approve the transfer of from your phone to your watch, provided you already granted those permissions on your phone.
Now in Android 14, there's a more generic "system data sync" feature. Right now, it "only supports call metadata sync", which isn't that useful since this is something you already see done (usually through NotificationListeners).
1) A new EXECUTE_APP_ACTION permission that "allows an assistive application to perform actions on behalf of users inside of applications." This permission is granted to the default Assistant. Currently, I don't see any APIs that require this permission.
2) A new LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE permission that "allows an application to capture screen content to perform a screenshot using the intent action." This is intended for the app that holds the ROLE_NOTES role.
ROLE_NOTES is a new role in Android 14. It can only be granted to apps that target SDK 34 and that handle the android.intent.action.CREATE_NOTE intent. The role itself is disabled unless config_enableDefaultNotes = true, and the default holder is defined by config_defaultNotes.
(In case you're wondering, Google Keep doesn't currently qualify to be the holder of ROLE_NOTES.)
Attached is the settings page for setting the "default notes app".
Apps with the permission can use the ACTION_LAUNCH_CAPTURE_CONTENT_ACTIVITY_FOR_NOTE intent action to trigger SystemUI to get a screenshot of the current window on behalf of the app. The user then has a chance to edit the screenshot, which can then be returned to the notes app.
3) Companion Device sync: In Android 13, Google laid the groundwork for syncing certain data when setting up a companion device (like a smartwatch or earbuds) through an app that uses the CompanionDeviceManager API. They added preliminary support for syncing permissions.
I've never seen it in action yet, but what they added was the ability to automatically grant certain permissions to apps you approve the transfer of from your phone to your watch, provided you already granted those permissions on your phone.
Now in Android 14, there's a more generic "system data sync" feature. Right now, it "only supports call metadata sync", which isn't that useful since this is something you already see done (usually through NotificationListeners).
π18
Google is finally rolling out the "app streaming" feature they first announced at CES 2022!
This won't be a Pixel-exclusive feature, either, though the update today is only available for Pixels. If you have a Pixel, check for an update to the "Cross-Device Services" app on Google Play. The "Cross-Device Services" app has been a stub APK for a while now, but an update brings it to version 1.0.285.1.
(This can't be installed over the app by the same name on OEM devices, though, because it's signed with a different certificate. At least, that's the case with my Zenfone 9.)
After downloading the update on my Pixel 6a and setting up Phone Hub on my Chromebook, I personally don't have the ability to stream apps. However, one user reports that it's working on their Pixel 7 and Chromebook, and that it works with any apps! (This is also reflected in the Play Store listing screenshots).
Full list of devices that are currently expected to support app streaming:
* Pixels
* ASUS Zenfone 9
* Nothing Phone 1
* OPPO A78 5G
* OPPO Find N2 Flip
* Redmi A2
* Redmi Note 12
* Xiaomi 12T
* Xiaomi 12T Pro
Want to know how this feature works and why it requires Android 13? This thread from January goes into detail?
This won't be a Pixel-exclusive feature, either, though the update today is only available for Pixels. If you have a Pixel, check for an update to the "Cross-Device Services" app on Google Play. The "Cross-Device Services" app has been a stub APK for a while now, but an update brings it to version 1.0.285.1.
(This can't be installed over the app by the same name on OEM devices, though, because it's signed with a different certificate. At least, that's the case with my Zenfone 9.)
After downloading the update on my Pixel 6a and setting up Phone Hub on my Chromebook, I personally don't have the ability to stream apps. However, one user reports that it's working on their Pixel 7 and Chromebook, and that it works with any apps! (This is also reflected in the Play Store listing screenshots).
Full list of devices that are currently expected to support app streaming:
* Pixels
* ASUS Zenfone 9
* Nothing Phone 1
* OPPO A78 5G
* OPPO Find N2 Flip
* Redmi A2
* Redmi Note 12
* Xiaomi 12T
* Xiaomi 12T Pro
Want to know how this feature works and why it requires Android 13? This thread from January goes into detail?
β€27π6π₯4