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
Mishaal's Android News Feed
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…
Here are screenshots of the setup process:
Also, the Cross-Device Services update is rolling out now on my ZenFone 9 as well. So today's rollout may not be limited to Pixels after all!
EDIT:
Okay, so how do you know if the feature is *actually* available for you?
- You must update Cross-Device Services to version 1.0.285.1 from Google Play first. The update is only available on Pixels and the select Android devices I mentioned earlier.
- Your device/account must be opted-in to the feature; this part seems to be server-side controlled by Google. I don't know how Google's rolling this out.
- Open your Chromebook settings > Connected devices > tap your Android device to open Phone Hub settings. (If you haven't already set up Phone Hub, first do that.)
- If you see "Apps (Beta)" in the list and a "set up" button, then the feature is available for you. Tap "set up" and you'll see a pop-up on your phone to grant access.
- Once you've done that, you can open Phone Hub on your Chromebook to see your recently opened apps. Click any of them to launch it in a window on your Chromebook.
Also, the Cross-Device Services update is rolling out now on my ZenFone 9 as well. So today's rollout may not be limited to Pixels after all!
EDIT:
Okay, so how do you know if the feature is *actually* available for you?
- You must update Cross-Device Services to version 1.0.285.1 from Google Play first. The update is only available on Pixels and the select Android devices I mentioned earlier.
- Your device/account must be opted-in to the feature; this part seems to be server-side controlled by Google. I don't know how Google's rolling this out.
- Open your Chromebook settings > Connected devices > tap your Android device to open Phone Hub settings. (If you haven't already set up Phone Hub, first do that.)
- If you see "Apps (Beta)" in the list and a "set up" button, then the feature is available for you. Tap "set up" and you'll see a pop-up on your phone to grant access.
- Once you've done that, you can open Phone Hub on your Chromebook to see your recently opened apps. Click any of them to launch it in a window on your Chromebook.
🔥25👍5❤2
I wrote this tweet from a Chromebook that has Twitter for Android streamed to it from a Pixel 6 Pro running Android 13!
Manually enabled the new "app streaming" feature. There was a bug preventing it from working on Android 14 DP2, so I downgraded one of my Pixels to Android 13 and then got it to work 😁
The grid of icons in the "Recent apps" section is actually a shortcut to open an app drawer! That means you aren't only limited to picking from the 5 most recent apps to launch.
Audio is also streamed from your phone to your Chromebook, meaning you can watch videos (or maybe even play some games?) - surprisingly little latency, too!
You can *technically* launch multiple apps onto the virtual display if you have "force desktop mode" and "enable freeform windows" enabled in developer options, but it's not a good idea, obviously.
You can also launch apps directly onto the virtual display, with an app like Taskbar by Braden Farmer that uses the APIs to do so, or through the 'am' shell command (append --display <DISPLAY_ID>).
And thanks to the VirtualAudioDevice API in Android 13, the app streaming feature can inject audio from a remote source (in this case, the mic on my Chromebook) into an app running on the virtual display! This means your phone doesn't have to be next to you to send voice messages.
Manually enabled the new "app streaming" feature. There was a bug preventing it from working on Android 14 DP2, so I downgraded one of my Pixels to Android 13 and then got it to work 😁
The grid of icons in the "Recent apps" section is actually a shortcut to open an app drawer! That means you aren't only limited to picking from the 5 most recent apps to launch.
Audio is also streamed from your phone to your Chromebook, meaning you can watch videos (or maybe even play some games?) - surprisingly little latency, too!
You can *technically* launch multiple apps onto the virtual display if you have "force desktop mode" and "enable freeform windows" enabled in developer options, but it's not a good idea, obviously.
You can also launch apps directly onto the virtual display, with an app like Taskbar by Braden Farmer that uses the APIs to do so, or through the 'am' shell command (append --display <DISPLAY_ID>).
And thanks to the VirtualAudioDevice API in Android 13, the app streaming feature can inject audio from a remote source (in this case, the mic on my Chromebook) into an app running on the virtual display! This means your phone doesn't have to be next to you to send voice messages.
❤29👍9🔥5
Mishaal's Android News Feed
I wrote this tweet from a Chromebook that has Twitter for Android streamed to it from a Pixel 6 Pro running Android 13! Manually enabled the new "app streaming" feature. There was a bug preventing it from working on Android 14 DP2, so I downgraded one of…
Although Google Play currently lets you install Cross-Device Services onto any Android 13 device, the Android-to-Chromebook app streaming feature will NOT work for you unless you the app was already preinstalled in the OS by the OEM.
For example, I could install Cross-Device Services onto my Zenfone 8 running Android 13. It installs fine, but it will never work for one reason: It can't get the permissions it needs!
Problem 1: Priv-app permissions. Cross-Device Services requests several permissions that can only be granted to privileged apps (located in a priv-app directory) through Android's privileged permission allowlisting mechanism. This must be done at build time by the OEM.
Problem 2: COMPANION_DEVICE_APP_STREAMING role. Some of the other important permissions the app needs (like the ability to create a virtual display!) are granted when the app becomes the COMPANION_DEVICE_APP_STREAMING role holder.
This role can only be given to system apps, however. The pop-up that you see when you're setting up app streaming is you making the Cross-Device Services app the role holder.
So how can OEMs bring app streaming to their devices?
1) Include Google's Cross-Device Services stub in their build and implement the priv-app permission allowlist.
2) Declare the "com.google.ambient.streaming" feature.
3) ????
4) Profit!
In all seriousness, Google has only rolled out the app streaming feature to a very small number of people, not including me. I myself had to manually enable it to show it off earlier.
So even if you have one of the devices I mentioned before, you may not have this feature because you need to enable a few flags on the Chrome OS AND Android side. If/when Google announces this, they'll flip those flags for you server-side.
For example, I could install Cross-Device Services onto my Zenfone 8 running Android 13. It installs fine, but it will never work for one reason: It can't get the permissions it needs!
Problem 1: Priv-app permissions. Cross-Device Services requests several permissions that can only be granted to privileged apps (located in a priv-app directory) through Android's privileged permission allowlisting mechanism. This must be done at build time by the OEM.
Problem 2: COMPANION_DEVICE_APP_STREAMING role. Some of the other important permissions the app needs (like the ability to create a virtual display!) are granted when the app becomes the COMPANION_DEVICE_APP_STREAMING role holder.
This role can only be given to system apps, however. The pop-up that you see when you're setting up app streaming is you making the Cross-Device Services app the role holder.
So how can OEMs bring app streaming to their devices?
1) Include Google's Cross-Device Services stub in their build and implement the priv-app permission allowlist.
2) Declare the "com.google.ambient.streaming" feature.
3) ????
4) Profit!
In all seriousness, Google has only rolled out the app streaming feature to a very small number of people, not including me. I myself had to manually enable it to show it off earlier.
So even if you have one of the devices I mentioned before, you may not have this feature because you need to enable a few flags on the Chrome OS AND Android side. If/when Google announces this, they'll flip those flags for you server-side.
👍14❤1