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
Magisk v26.0 has been announced🎉
(According to topjohnwu, there are some last minute fixes being implemented, so the build is not live yet!)
It's live!
Big thanks to topjohnwu, vvb2060, yujincheng08, and others for continuing to maintain this excellent tool!
Here's the full changelog:
v26.0
* [General] Bump minimum supported Android version to Android 6.0
* [General] New magic mount backend. It supports loading modules into system with overlayfs files injected
* [Zygisk] Release new API version 4
* [Zygisk] Prevent crashing daemon in error
* [Zygisk] Rewrite zygote code injection with new loader library approach
* [Zygisk] Rewrite code unloading implementation
* [MagiskBoot] Support amonet microloader devices
* [MagiskBoot] Always use lz4_legacy compression on v4 boot images. This fixes boot image patching issues on Android U preview.
* [MagiskInit] Support replacing existing *.rc files in overlay.d
* [MagiskInit] Rewrite sepolicy.rules mounting and loading implementation
* [App] Make stub patching 100% offline
* [App] Support patching init_boot.img for Samsung ODIN firmware
* [MagiskPolicy] Fix minor bug in command line argument parsing
* [MagiskPolicy] Update rules to support Android U
Big thanks to topjohnwu, vvb2060, yujincheng08, and others for continuing to maintain this excellent tool!
Here's the full changelog:
v26.0
* [General] Bump minimum supported Android version to Android 6.0
* [General] New magic mount backend. It supports loading modules into system with overlayfs files injected
* [Zygisk] Release new API version 4
* [Zygisk] Prevent crashing daemon in error
* [Zygisk] Rewrite zygote code injection with new loader library approach
* [Zygisk] Rewrite code unloading implementation
* [MagiskBoot] Support amonet microloader devices
* [MagiskBoot] Always use lz4_legacy compression on v4 boot images. This fixes boot image patching issues on Android U preview.
* [MagiskInit] Support replacing existing *.rc files in overlay.d
* [MagiskInit] Rewrite sepolicy.rules mounting and loading implementation
* [App] Make stub patching 100% offline
* [App] Support patching init_boot.img for Samsung ODIN firmware
* [MagiskPolicy] Fix minor bug in command line argument parsing
* [MagiskPolicy] Update rules to support Android U
🥰21👍9❤2🎉2😁1
This media is not supported in your browser
VIEW IN TELEGRAM
Google Play has just announced a new data deletion policy that I welcome 🎉
If your Android app allows users to create an account, then Google Play will eventually require you to offer a way for users to initiate account AND data deletion from within the app and from the web.
Google Play will require that the web link for account/data deletion be provided to users through your app's Data Safety section, as shown in the GIF above. This is so users can request deletion WITHOUT reinstalling your app.
When completing the Data Safety form, there'll be new questions related to this data deletion policy. Google's asking developers to submit answers by December 7, 2023. Sometime in early 2024, users will see the new data deletion badge and area in apps' store listings.
Developers that need more time to comply with this requirement (such as needing to build out account/data deletion tools) can file an extension in the Play Console until May 31, 2024. After that date non-compliant apps may be removed from Google Play.
For more info on this new policy, read Google's blog post and support page.
If your Android app allows users to create an account, then Google Play will eventually require you to offer a way for users to initiate account AND data deletion from within the app and from the web.
Google Play will require that the web link for account/data deletion be provided to users through your app's Data Safety section, as shown in the GIF above. This is so users can request deletion WITHOUT reinstalling your app.
When completing the Data Safety form, there'll be new questions related to this data deletion policy. Google's asking developers to submit answers by December 7, 2023. Sometime in early 2024, users will see the new data deletion badge and area in apps' store listings.
Developers that need more time to comply with this requirement (such as needing to build out account/data deletion tools) can file an extension in the Play Console until May 31, 2024. After that date non-compliant apps may be removed from Google Play.
For more info on this new policy, read Google's blog post and support page.
👍25🔥8❤2👏2
Mishaal's Android News Feed
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…
Let's continue this thread, shall we?
4) Bluetooth Audio Routing
"Choose whether different types of audio are played on your hearing device or phone speaker"
If you have a hearing aid connected to an Android 14 device, you'll be able to choose where certain sounds (ringtone, call, media, system sounds) will play from by default ("decide automatically", "play on hearing device", or "play on phone speaker").
5) Dual screen:
When an app is using both displays to show content, you'll get a notification that "dual screen is on." When the device gets too warm, you'll be warned that "Dual Screen is unavailable because your phone is getting too warm."
6) SYSTEM_CALL_STREAMING:
Android 14 adds a new SYSTEM_CALL_STREAMING role that only system apps targeting SDK 34 and which have a CALL_STREAMING_SERVICE implemented can hold. This role grants the permissions CALL_AUDIO_INTERCEPTION and RECORD_AUDIO, which can be used to grant access to APIs to stream phone call audio between Android devices.
Following Android 14 DP1's release, Google published documentation for the CallControl and StreamingCall APIs. The latter was removed as presumably it's only intended to be internal.
What I suspect this'll be used for is to stream voice call audio from an Android phone to an Android tablet. Imagine you get a call on your Pixel, but you're near your Pixel Tablet. Tap the output switcher and select the tablet to begin streaming the phone call to your tablet!
There is some evidence behind this, by the way. Back in the Android 12L DP, there was an app that suggested a "Nearby calling" feature was in the works that would let you transfer calls between your phone and Nest Hub.
And in Android 13, Google added some new cross-device calling APIs (the CALL_AUDIO_INTERCEPTION permission was also added in Android 13).
4) Bluetooth Audio Routing
"Choose whether different types of audio are played on your hearing device or phone speaker"
If you have a hearing aid connected to an Android 14 device, you'll be able to choose where certain sounds (ringtone, call, media, system sounds) will play from by default ("decide automatically", "play on hearing device", or "play on phone speaker").
5) Dual screen:
When an app is using both displays to show content, you'll get a notification that "dual screen is on." When the device gets too warm, you'll be warned that "Dual Screen is unavailable because your phone is getting too warm."
6) SYSTEM_CALL_STREAMING:
Android 14 adds a new SYSTEM_CALL_STREAMING role that only system apps targeting SDK 34 and which have a CALL_STREAMING_SERVICE implemented can hold. This role grants the permissions CALL_AUDIO_INTERCEPTION and RECORD_AUDIO, which can be used to grant access to APIs to stream phone call audio between Android devices.
Following Android 14 DP1's release, Google published documentation for the CallControl and StreamingCall APIs. The latter was removed as presumably it's only intended to be internal.
What I suspect this'll be used for is to stream voice call audio from an Android phone to an Android tablet. Imagine you get a call on your Pixel, but you're near your Pixel Tablet. Tap the output switcher and select the tablet to begin streaming the phone call to your tablet!
There is some evidence behind this, by the way. Back in the Android 12L DP, there was an app that suggested a "Nearby calling" feature was in the works that would let you transfer calls between your phone and Nest Hub.
And in Android 13, Google added some new cross-device calling APIs (the CALL_AUDIO_INTERCEPTION permission was also added in Android 13).
👍32❤1👏1
Google Chrome is experimenting with Android 14's new ChooserActions API to display custom actions at the top of Android's share sheet.
This is an important step for Chrome to ditch its custom share sheet on Android, and hopefully other apps follow suit!
Chrome currently uses its own custom share sheet to display these actions (copy link, send to your devices, QR code, print), but Google is trying to move developers away from using custom share sheets.
A new Chrome flag (chrome://flags#share-sheet-migration-android) toggles whether to use the app's custom share sheet or the OS one. When the flag is enabled on Dev or Canary builds on Android 14 devices, the ChooserAction API will be used to display these app actions in the OS share sheet.
Alongside the new row for app-defined actions (powered by the ChooserActions API), Android 14 brings a couple of other improvements to the share sheet experience. You can track the progress of Chrome's share sheet changes here.
This is an important step for Chrome to ditch its custom share sheet on Android, and hopefully other apps follow suit!
Chrome currently uses its own custom share sheet to display these actions (copy link, send to your devices, QR code, print), but Google is trying to move developers away from using custom share sheets.
A new Chrome flag (chrome://flags#share-sheet-migration-android) toggles whether to use the app's custom share sheet or the OS one. When the flag is enabled on Dev or Canary builds on Android 14 devices, the ChooserAction API will be used to display these app actions in the OS share sheet.
Alongside the new row for app-defined actions (powered by the ChooserActions API), Android 14 brings a couple of other improvements to the share sheet experience. You can track the progress of Chrome's share sheet changes here.
👍36👏4❤1🔥1
Mishaal's Android News Feed
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…
Turns out we don't have to wait and see, because contrast level controls are already in Android 14 DP2!
A new "contrast level" slider is buried under Settings > Accessibility > Color and motion. It currently only supports "Standard", medium, and "High" values. This slider controls the value of Settings.Secure.contrast_level (0 for "Standard", 0.5 for the mid setting, and 1.0 for "High") which in turn can be read by apps calling AccessibilityManager's new getUiContrast() method.
SystemUI's ThemeOverlayController class calls that method to read the color contrast value and generate the "dynamic" color scheme accordingly, which is then mapped to the R.color values I mentioned before through the "dynamic" FRRO.
I dumped the values of the "dynamic" FRRO generated based on the AOSP wallpaper and contrast_level values of 0, 0.5, and 1.0. It's evident that as the contrast increases, the tone (lightness) of foreground colors becomes further from the tone of background colors.
Google's official explanation of the dynamic scheme (H/T @kdrag0n):
How this ends up looking in apps depends on how devs choose which tokens to color which UI elements, but in general, devs adhering to Material You guidelines and using the Material components library won't need to worry about the implementation/handling of contrast level changes.
A new "contrast level" slider is buried under Settings > Accessibility > Color and motion. It currently only supports "Standard", medium, and "High" values. This slider controls the value of Settings.Secure.contrast_level (0 for "Standard", 0.5 for the mid setting, and 1.0 for "High") which in turn can be read by apps calling AccessibilityManager's new getUiContrast() method.
SystemUI's ThemeOverlayController class calls that method to read the color contrast value and generate the "dynamic" color scheme accordingly, which is then mapped to the R.color values I mentioned before through the "dynamic" FRRO.
I dumped the values of the "dynamic" FRRO generated based on the AOSP wallpaper and contrast_level values of 0, 0.5, and 1.0. It's evident that as the contrast increases, the tone (lightness) of foreground colors becomes further from the tone of background colors.
Google's official explanation of the dynamic scheme (H/T @kdrag0n):
"Colors without backgrounds do not change tone when contrast changes. Colors with backgrounds become closer to their background as contrast lowers, and further when contrast increases."How this ends up looking in apps depends on how devs choose which tokens to color which UI elements, but in general, devs adhering to Material You guidelines and using the Material components library won't need to worry about the implementation/handling of contrast level changes.
👍25🔥1
Google Play has announced an opt-in "auto-archive" feature that automatically frees up to 60% of the storage space taken up by an app WITHOUT completely uninstalling the app and removing all its data. The archived app can be easily reinstalled at a later time.
When a user opts-in to the "auto-archive" feature, infrequently used apps will be partly removed from the device to save space. The app icon and app data will be preserved. When the user taps the app icon, Google Play redownloads the app and the user is back where they left off.
Users can opt-in to "auto-archive" by trying to install an app when the device is out of storage. They'll see a pop-up window (as seen in the screenshots of the first tweet) asking them to opt-in.
As I explained last year, app archiving uses the new "archived APK" format which is generated by bundletool. Bundletool is used to generate APKs from Android App Bundles, hence app archiving is only available to developers who upload AABs to Google Play.
App archiving started slowly rolling out to some users with Google Play Store version 33.4, while the auto-archive feature was first mentioned in the December 2022 Google System Updates changelog as being part of Google Play Store version 33.5. App archiving will soon become available on Android TV and Google TV as well.
When a user opts-in to the "auto-archive" feature, infrequently used apps will be partly removed from the device to save space. The app icon and app data will be preserved. When the user taps the app icon, Google Play redownloads the app and the user is back where they left off.
Users can opt-in to "auto-archive" by trying to install an app when the device is out of storage. They'll see a pop-up window (as seen in the screenshots of the first tweet) asking them to opt-in.
As I explained last year, app archiving uses the new "archived APK" format which is generated by bundletool. Bundletool is used to generate APKs from Android App Bundles, hence app archiving is only available to developers who upload AABs to Google Play.
App archiving started slowly rolling out to some users with Google Play Store version 33.4, while the auto-archive feature was first mentioned in the December 2022 Google System Updates changelog as being part of Google Play Store version 33.5. App archiving will soon become available on Android TV and Google TV as well.
🔥39👍11❤4😁3
Mishaal's Android News Feed
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…
Pixel updates are out, and now the AOSP tags are up as well!
Here they are:
AOSP tag | Build ID
android-13.0.0_r38 | TQ2A.230405.003
android-13.0.0_r39 | TQ2A.230405.003.A2
android-13.0.0_r40 | TQ2A.230405.003.B2
android-13.0.0_r41 | TQ2A.230405.003.E1
In the attached screenshot, you can see which build ID corresponds to which Pixel OTA.
Here they are:
AOSP tag | Build ID
android-13.0.0_r38 | TQ2A.230405.003
android-13.0.0_r39 | TQ2A.230405.003.A2
android-13.0.0_r40 | TQ2A.230405.003.B2
android-13.0.0_r41 | TQ2A.230405.003.E1
In the attached screenshot, you can see which build ID corresponds to which Pixel OTA.
👍28❤6
Android 14 Beta 1 is here! This is the first Android 14 release that’s available for users enrolled in the Android Beta program! Follow me on Twitter to see my full breakdown of what’s new, but first, read my summary here of what Google announced.
🔥35❤4👍2👏1
Android 14 is introducing an important security feature that authenticator apps can use to block malware from stealing your 2FA codes, like how the “Cerberus” banking trojan and “Nexus” malware were caught snooping on Google Authenticator. Here’s what you should know 👇
The Accessibility API lets apps read the contents of the screen and perform inputs on behalf of the user. It’s intended for screen readers and alternative input systems, but it’s open to any app. Malware authors love abusing this API.
Well-known malware like Cerberus and Nexus have been reported to use Accessibility to read 2FA codes from Google Authenticator. Currently, if an app’s malicious Accessibility Service is enabled, there’s nothing stopping them from doing that.
In Android 14, though, apps can set an attribute to prevent non-accessibility tools from interacting with important Views. Google Authenticator eg. can ensure that only accessibility tools can read 2FA codes.
For more information on this new #Android14 security feature, including a video that shows how it can block malware from reading your 2FA codes, check out my latest article for Esper.
The Accessibility API lets apps read the contents of the screen and perform inputs on behalf of the user. It’s intended for screen readers and alternative input systems, but it’s open to any app. Malware authors love abusing this API.
Well-known malware like Cerberus and Nexus have been reported to use Accessibility to read 2FA codes from Google Authenticator. Currently, if an app’s malicious Accessibility Service is enabled, there’s nothing stopping them from doing that.
In Android 14, though, apps can set an attribute to prevent non-accessibility tools from interacting with important Views. Google Authenticator eg. can ensure that only accessibility tools can read 2FA codes.
For more information on this new #Android14 security feature, including a video that shows how it can block malware from reading your 2FA codes, check out my latest article for Esper.
❤26👍9👏1
If you’re a content creator looking to cover Android 14 Beta 1, I made a document that summarizes ALL the changes I’ve found in Android 14 so far. I’ve made it as simple as possible without sacrificing technical accuracy. Send me a DM if you want to take a look!
I plan to turn this doc into an article after cleaning it up a bit. I’ve documented almost every change I’ve spotted so far and will continue to keep it updated. All I have left to summarize are some developer-oriented changes, which is why I’m opening this up to creators now.
I plan to turn this doc into an article after cleaning it up a bit. I’ve documented almost every change I’ve spotted so far and will continue to keep it updated. All I have left to summarize are some developer-oriented changes, which is why I’m opening this up to creators now.
❤49👍10
Follow this thread if you want to see EVERYTHING that’s new in Android 14 Beta 1!
❤20👍4
Android 14 Beta 1 adds a “transparent navigation bar” toggle to Developer Options that “make[s] [the] navigation bar background color transparent by default.” More details on how this feature works in this article on XDA-Developers.
XDA
Android 14 may let you force apps to have a transparent nav bar
Android 14 Beta 1 adds a "transparent navigation bar" setting, which changes the background color of the nav bar from black to transparent.
❤39🔥10👍7👏1🤯1🤡1
Google Wallet may be bringing back location-based suggestions for loyalty cards in Android 14 👀
It used to have this feature, but it's been missing since the app relaunched last year!
Full details in my latest article for XDA-Developers!
It used to have this feature, but it's been missing since the app relaunched last year!
Full details in my latest article for XDA-Developers!
XDA
Android 14 preps location-based suggestions for loyalty cards, likely for Google Wallet
The documentation for Android 14 Beta 1 hints at Google bringing back location-based suggestions for loyalty cards, possibly for Google Wallet.
👍17👀7🎉1