Home Assistant, an open source home automation app, has been updated to show a Home Assistant dashboard instead of Android's limited set of device controls, when accessing the Device Controls interface on Android 14.
This is a bit confusing to explain, but bear with me.
Android 11 introduced a feature called Quick Access Device Controls (Device Controls for short) that provides an interface for smart home apps like Google Home to display controls for devices like smart lights, thermostats, cameras, and more. This Device Controls interface is accessed by tapping a shortcut in Quick Settings or on the lock screen.
These controls are displayed as templated widgets, ie. they all look the same no matter what app you use (Google Home, LG ThinQ, Mi Home, etc.) since Android handles the UI.
Android 14, though, added a new API (ControlsProviderService#META_DATA_PANEL_ACTIVITY) that lets apps embed a custom activity in the Device Controls interface. This means that instead of showing controls whose UI is determined by Android, apps can show basically whatever they want.
The Google Home app was the first to support this new API (which they call the "home panel"), and now Home Assistant supports it as well, as shown in the above video (recorded by tipster Hamzah Malik).
Here's Home Assistant's documentation on the app's support for Android's Device Controls feature. And also attached are some screenshots from a developer showing the settings interface for enabling this on Android 14.
This is a bit confusing to explain, but bear with me.
Android 11 introduced a feature called Quick Access Device Controls (Device Controls for short) that provides an interface for smart home apps like Google Home to display controls for devices like smart lights, thermostats, cameras, and more. This Device Controls interface is accessed by tapping a shortcut in Quick Settings or on the lock screen.
These controls are displayed as templated widgets, ie. they all look the same no matter what app you use (Google Home, LG ThinQ, Mi Home, etc.) since Android handles the UI.
Android 14, though, added a new API (ControlsProviderService#META_DATA_PANEL_ACTIVITY) that lets apps embed a custom activity in the Device Controls interface. This means that instead of showing controls whose UI is determined by Android, apps can show basically whatever they want.
The Google Home app was the first to support this new API (which they call the "home panel"), and now Home Assistant supports it as well, as shown in the above video (recorded by tipster Hamzah Malik).
Here's Home Assistant's documentation on the app's support for Android's Device Controls feature. And also attached are some screenshots from a developer showing the settings interface for enabling this on Android 14.
❤48👍28🤩6❤🔥3🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
FLAPPY BIRD FLAPS ON!
Qualcomm's Snapdragon 8 Gen 3 does not have any CPU cores that support AArch32 (32-bit Arm apps).
Despite this, the Xiaomi 14 series is able to run 32-bit Arm apps like Flappy Bird, as shown above by @MlgmXyysd.
How is this possible?
MlgmXyysd did some digging, and discovered that Xiaomi integrated a 32-bit to 64-bit Arm binary translator called "Tango" from a company called Amanieu Systems.
Tango is a commercial tool that can be integrated into builds as a kernel module compatible with the GKI. For reference purposes, an OS image (based on Android 13 GrapheneOS) is provided for the Pixel 6.
Given Google's latest crackdown on 32-bit app support in Android 14, shipping a 32-bit to 64-bit Arm binary translator will be the only way for devices with new chipsets to support 32-bit apps. More details on this crackdown here (for subscribers).
MlgmXyysd's original post (in Chinese) talks a bit more about how this tool is integrated into the build (it's found under /system_ext/bin) and, more interestingly, how it performs.
Qualcomm's Snapdragon 8 Gen 3 does not have any CPU cores that support AArch32 (32-bit Arm apps).
Despite this, the Xiaomi 14 series is able to run 32-bit Arm apps like Flappy Bird, as shown above by @MlgmXyysd.
How is this possible?
MlgmXyysd did some digging, and discovered that Xiaomi integrated a 32-bit to 64-bit Arm binary translator called "Tango" from a company called Amanieu Systems.
Tango is a commercial tool that can be integrated into builds as a kernel module compatible with the GKI. For reference purposes, an OS image (based on Android 13 GrapheneOS) is provided for the Pixel 6.
Given Google's latest crackdown on 32-bit app support in Android 14, shipping a 32-bit to 64-bit Arm binary translator will be the only way for devices with new chipsets to support 32-bit apps. More details on this crackdown here (for subscribers).
MlgmXyysd's original post (in Chinese) talks a bit more about how this tool is integrated into the build (it's found under /system_ext/bin) and, more interestingly, how it performs.
👍86💩22🤯8🤔5❤1👎1👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Nearby Share seems to automatically redact phone numbers/IMEIs, but only if you share them from Android to Windows.
It's a bit odd, though, since Nearby Share on Windows thinks you're receiving an "audio file". Does this happen for anyone else?
It's a bit odd, though, since Nearby Share on Windows thinks you're receiving an "audio file". Does this happen for anyone else?
🤔39🤨14👍9❤1
After updating to Android 14, some users with a Pixel 6 and later who have multiple users or profiles set up have been unable to access any of their media storage on the primary user.
Google now says they "have already pushed out a Google Play system update" that will "help prevent this issue from being triggered on additional devices." Google anticipates that "a system update will repair the issue and restore access to media files without requiring a factory reset."
Unfortunately, if your device is "stuck in a 'Pixel is starting' boot loop", which happens when the device repeatedly reboots and the user declines factory resetting their device when prompted on the Android recovery screen, then there currently isn't a fix. However, Google says they are "investigating methods that may be able to recover some data" and that they'll "provide more information as soon as it is available."
If you have a Pixel phone on Android 14 and are not currently having this issue, or you already factory reset your phone after encountering this issue, then it's recommended that you don't create or log into a secondary user on the device until Google pushes the OTA update fixing the issue.
Google now says they "have already pushed out a Google Play system update" that will "help prevent this issue from being triggered on additional devices." Google anticipates that "a system update will repair the issue and restore access to media files without requiring a factory reset."
Unfortunately, if your device is "stuck in a 'Pixel is starting' boot loop", which happens when the device repeatedly reboots and the user declines factory resetting their device when prompted on the Android recovery screen, then there currently isn't a fix. However, Google says they are "investigating methods that may be able to recover some data" and that they'll "provide more information as soon as it is available."
If you have a Pixel phone on Android 14 and are not currently having this issue, or you already factory reset your phone after encountering this issue, then it's recommended that you don't create or log into a secondary user on the device until Google pushes the OTA update fixing the issue.
👍63🤡13🤔6😁5
Samsung is starting to roll out the stable release of One UI 6.0 (based on Android 14) to the Galaxy S23 series, as reported by Sam Mobile.
With Android 14 now reaching Samsung's flagships, we should start seeing a noticeable uptick in the number of users on the latest Android OS release.
With Android 14 now reaching Samsung's flagships, we should start seeing a noticeable uptick in the number of users on the latest Android OS release.
SamMobile
BREAKING: Stable Galaxy S23 Android 14 (One UI 6.0) update is here!
Samsung is rolling out the stable Android 14-based One UI 6.0 update for the Galaxy S23, Galaxy S23+, and Galaxy S23 Ultra for beta testers.
🔥55🥱13❤6😱6👍3🥰1
Porsche has announced that it's integrating Android Automotive with Google Automotive Services into its future infotainment systems. Production of this updated infotainment system will start "in the middle of the decade".
"This integration of the Google ecosystem will include Google Maps, Google Assistant, and a wide variety of apps available through the Google Play Store."
Porsche says that the UI of its Porsche Communication Management (PCM) system will remain familiar to existing customers, and that in the future, "ecosystems from different providers that are relevant for customers will be integrated directly into the vehicle via standardized interfaces and platforms."
"This integration of the Google ecosystem will include Google Maps, Google Assistant, and a wide variety of apps available through the Google Play Store."
Porsche says that the UI of its Porsche Communication Management (PCM) system will remain familiar to existing customers, and that in the future, "ecosystems from different providers that are relevant for customers will be integrated directly into the vehicle via standardized interfaces and platforms."
👍60❤9🤡4👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Google has provided an update on the status of RISC-V support in Android.
- Work on a fully optimized backend for the Android Runtime (ART) is still a work in progress
- AOSP, external projects, and compilers haven't generated fully optimized, reduced code that also takes advantage of the latest ratified extensions, such as the one for vectors.
- Later this year, Google expects to have the NDK ABI finalized and canary builds made available on Android's public CI soon, as well as RISC-V on x86-64 & ARM64 available for easier testing of riscv64 Android apps on a host machine.
- By 2024, the plan is to have emulators available publicly with a full feature set to test apps for various device form factors. Wearables are expected to be the first form factor available (see: Google and Qualcomm's recent announcement).
- Google is working with the community and the RISC-V Software Ecosystem (RISE) Project to provide a way to accelerate the availability of software for high-performance and power-efficient RISC-V processor cores running high-level operating systems. Google is also continuing to invest in RISC-V International.
If you're interested in contributing, you can go to the android-riscv64 GitHub project to discuss, submit issues, and stay up-to-date on the current progress. You can also subscribe to the RISC-V Android SIG mailing list. Finally, you can also build, test, and run an Android RISC-V image as a CVD. Just select the
- Work on a fully optimized backend for the Android Runtime (ART) is still a work in progress
- AOSP, external projects, and compilers haven't generated fully optimized, reduced code that also takes advantage of the latest ratified extensions, such as the one for vectors.
- Later this year, Google expects to have the NDK ABI finalized and canary builds made available on Android's public CI soon, as well as RISC-V on x86-64 & ARM64 available for easier testing of riscv64 Android apps on a host machine.
- By 2024, the plan is to have emulators available publicly with a full feature set to test apps for various device form factors. Wearables are expected to be the first form factor available (see: Google and Qualcomm's recent announcement).
- Google is working with the community and the RISC-V Software Ecosystem (RISE) Project to provide a way to accelerate the availability of software for high-performance and power-efficient RISC-V processor cores running high-level operating systems. Google is also continuing to invest in RISC-V International.
If you're interested in contributing, you can go to the android-riscv64 GitHub project to discuss, submit issues, and stay up-to-date on the current progress. You can also subscribe to the RISC-V Android SIG mailing list. Finally, you can also build, test, and run an Android RISC-V image as a CVD. Just select the
aosp_cf_riscv64_phone-userdebug target in the lunch menu.👍45🤔9❤4🔥3
Google has once again updated the Android version distribution statistics shown to developers in Android Studio to reflect data up to October 1, 2023.
Here's how the % of (GMS Android) devices has changed since May 30, 2023 when the stats were last publicly updated.
- Android 13: 15% -> 22.4%
- Android 12: 16.3% -> 15.8%
- Android 11: 23.1% -> 21.6%
- Android 10: 17.8% -> 16.1%
- Android 9: 11.9% -> 10.5%
- Android 8.1: 6.1% -> 5.4%
- Android 8: 2.2% -> 1.9%
- Android 7.1: 1.5% -> 1.3%
- Android 7: 1.5% -> 1.3%
- Android 6: 2.3% -> 1.9%
- Android 5.1: 1.5% -> 1.2%
- Android 5: 0.3% -> 0.2%
- Android 4.4: 0.5% -> 0.4%
Android 13 leaps from 15% to 22.4% of all devices. The Android OS version with the second highest install base is now Android 11 at 21.6% followed by Android 10 at 16.1%. Android 12 is installed on 15.8% of all devices.
The % of devices running an Android OS version that Google actively supports through security patch backports (ie. Android 11+) is 59.8%, up from 54.4%.
H/T GizChina
Here's how the % of (GMS Android) devices has changed since May 30, 2023 when the stats were last publicly updated.
- Android 13: 15% -> 22.4%
- Android 12: 16.3% -> 15.8%
- Android 11: 23.1% -> 21.6%
- Android 10: 17.8% -> 16.1%
- Android 9: 11.9% -> 10.5%
- Android 8.1: 6.1% -> 5.4%
- Android 8: 2.2% -> 1.9%
- Android 7.1: 1.5% -> 1.3%
- Android 7: 1.5% -> 1.3%
- Android 6: 2.3% -> 1.9%
- Android 5.1: 1.5% -> 1.2%
- Android 5: 0.3% -> 0.2%
- Android 4.4: 0.5% -> 0.4%
Android 13 leaps from 15% to 22.4% of all devices. The Android OS version with the second highest install base is now Android 11 at 21.6% followed by Android 10 at 16.1%. Android 12 is installed on 15.8% of all devices.
The % of devices running an Android OS version that Google actively supports through security patch backports (ie. Android 11+) is 59.8%, up from 54.4%.
H/T GizChina
👍89❤14👎3
The Pixel's car crash detection feature is now available in 5 new countries, including Austria, Belgium, India, Portugal, and Switzerland.
Google updated its support page to include these countries sometime this month, and several users from India told me they're now able to turn this feature on.
Thanks to Yuval for the tip!
Google updated its support page to include these countries sometime this month, and several users from India told me they're now able to turn this feature on.
Thanks to Yuval for the tip!
👍79❤15🙏5🔥4🤔2
Android is preparing to add better support for Apple pkpass files. PKPass is a file type that holds pass data that can be imported into Apple Wallet.
Android currently maps the .pkpass and .pkpasses file extensions to the
Soon, though, Android may map these file extensions to
What does this actually mean for Android, though? Well, it doesn't mean that apps like Google Wallet will all of a sudden be able to import .pkpass files, nor does it mean that apps couldn't already recognize or parse .pkpass files already. For example, the Pass2Pay app already lets you import .pkpass files.
What this does mean is that it'll be easier for apps to set up a handler for .pkpass files. Pass2Pay, for example, uses some messy regex in its Manifest to handle .pkpass files. Hopefully Google Wallet adds .pkpass import support soon, especially now that it just added generic pass photo import.
Android currently maps the .pkpass and .pkpasses file extensions to the
application/octet-stream MIME type. A MIME type is a string that consists of a "type/subtype" representing the kind of data contained within the file. Mapping .pkpass and .pkpasses to application/octet-stream means they're treated as generic binary data.Soon, though, Android may map these file extensions to
application/vnd.apple.pkpass and application/vnd.apple.pkpasses respectively, which would allow Apple Wallet PKPass files to be resolved correctly.What does this actually mean for Android, though? Well, it doesn't mean that apps like Google Wallet will all of a sudden be able to import .pkpass files, nor does it mean that apps couldn't already recognize or parse .pkpass files already. For example, the Pass2Pay app already lets you import .pkpass files.
What this does mean is that it'll be easier for apps to set up a handler for .pkpass files. Pass2Pay, for example, uses some messy regex in its Manifest to handle .pkpass files. Hopefully Google Wallet adds .pkpass import support soon, especially now that it just added generic pass photo import.
👍62🗿4
Mishaal's Android News Feed
Android is preparing to add better support for Apple pkpass files. PKPass is a file type that holds pass data that can be imported into Apple Wallet. Android currently maps the .pkpass and .pkpasses file extensions to the application/octet-stream MIME type.…
Last year, a Googler said that "we are actively working on this feature." The feature being support for importing .pkpass files into Google Wallet.
(Thanks to Xander for the heads up!)
(Thanks to Xander for the heads up!)
👍41🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
The latest loophole that third-party file manager apps were using to get access to files and folders under /Android/data and /Android/obb has been patched.
As part of Android 11's Scoped Storage restrictions, apps that use the Storage Access Framework (SAF) to launch the documents picker are not supposed to be able to get access to files and folders under the /Android/data or /Android/obb directories.
However, third-party file managers figured out that if they set the initial directory when launching the documents picker to either /Android/data or /Android/obb, the documents picker lets the user grant the app full access to directories. This loophole was patched in Android 13, but then another loophole was discovered that got around this.
Since Android 13 only blocked apps from setting /Android/data or /Android/obb as the initial directory when launching the documents picker, it was quickly discovered that you could set the initial directory to one of the subdirectories under /Android/data or /Android/obb, thus the user could grant access to individual subdirectories one-by-one.
However, this latest loophole was patched with a recent Google Play System Update. The latest version of the DocumentsUI app, the Project Mainline module that comprises the documents picker, now restricts the initial location for the ACTION_OPEN_DOCUMENT/_TREE intent so that apps cannot request the initial location to be one of /Android/data, /Android/sandbox, /Android/obb, or one of their subdirectories.
If the DocumentsUI app (AKA 'Files' app) on your device is on version 14-10492947 (version code 340916000), then this loophole is patched.
—-
If you still want to read/write files under /Android/data or /Android/obb, there are no restrictions if you connect your phone to a PC or use ADB shell commands.
The AOSP Files app also lets you browse files in those directories, though you're limited in how much you can modify.
As part of Android 11's Scoped Storage restrictions, apps that use the Storage Access Framework (SAF) to launch the documents picker are not supposed to be able to get access to files and folders under the /Android/data or /Android/obb directories.
However, third-party file managers figured out that if they set the initial directory when launching the documents picker to either /Android/data or /Android/obb, the documents picker lets the user grant the app full access to directories. This loophole was patched in Android 13, but then another loophole was discovered that got around this.
Since Android 13 only blocked apps from setting /Android/data or /Android/obb as the initial directory when launching the documents picker, it was quickly discovered that you could set the initial directory to one of the subdirectories under /Android/data or /Android/obb, thus the user could grant access to individual subdirectories one-by-one.
However, this latest loophole was patched with a recent Google Play System Update. The latest version of the DocumentsUI app, the Project Mainline module that comprises the documents picker, now restricts the initial location for the ACTION_OPEN_DOCUMENT/_TREE intent so that apps cannot request the initial location to be one of /Android/data, /Android/sandbox, /Android/obb, or one of their subdirectories.
If the DocumentsUI app (AKA 'Files' app) on your device is on version 14-10492947 (version code 340916000), then this loophole is patched.
—-
If you still want to read/write files under /Android/data or /Android/obb, there are no restrictions if you connect your phone to a PC or use ADB shell commands.
The AOSP Files app also lets you browse files in those directories, though you're limited in how much you can modify.
👎97👍38💔8😁2🤡2
scrcpy just keeps getting better and better. Version 2.2 was just released with support for camera mirroring. This lets you mirror the device camera instead of the device screen.
I tried it out, and it worked pretty well at 1080p even when connected wirelessly.
I tried it out, and it worked pretty well at 1080p even when connected wirelessly.
❤92👍14👏7❤🔥6🔥6
Google has announced that the new Telecom Jetpack library is now in alpha. This library is aimed at voice and/or video calling apps and provides a variety of features, including:
* Platform synchronization: Makes the platform "aware" of your VoIP call so that other surfaces (like watches) can show information like who the caller is as well as actions to answer, decline, hang up, or mute your call. Also, if other calls such as a PTSN/SIM-based call comes through, you can give the user a chance to hold the call they're currently on.
* Dedicated foreground support. Android 14 requires apps to specify foreground service types. The Jetpack Telecom library takes care of that requirement for you.
* Audio routing: The Telecom library can list all available endpoints to your app for streaming audio to/from, so you don't have to use the audio manager API to track state, focus, and obtain a list of audio devices yourself.
* Backwards compatibility: This library works on devices that support Android's Telecom stack (PackageManager.FEATURE_TELECOM) running Android 8.0 Oreo or later.
Coming soon:
* Expanded support for VoIP Call actions: Being able to locally mute the VoIP app for the specific call and display the name of the speaker on another surface like Android Auto.
* Transfer VoIP calls: Users will be able to transfer ongoing VoIP calls between their phones and tablets.
Version 1.0.0-alpha01 was released on May 10 at Google I/O 2023, but alpha02 was released on October 4.
* Platform synchronization: Makes the platform "aware" of your VoIP call so that other surfaces (like watches) can show information like who the caller is as well as actions to answer, decline, hang up, or mute your call. Also, if other calls such as a PTSN/SIM-based call comes through, you can give the user a chance to hold the call they're currently on.
* Dedicated foreground support. Android 14 requires apps to specify foreground service types. The Jetpack Telecom library takes care of that requirement for you.
* Audio routing: The Telecom library can list all available endpoints to your app for streaming audio to/from, so you don't have to use the audio manager API to track state, focus, and obtain a list of audio devices yourself.
* Backwards compatibility: This library works on devices that support Android's Telecom stack (PackageManager.FEATURE_TELECOM) running Android 8.0 Oreo or later.
Coming soon:
* Expanded support for VoIP Call actions: Being able to locally mute the VoIP app for the specific call and display the name of the speaker on another surface like Android Auto.
* Transfer VoIP calls: Users will be able to transfer ongoing VoIP calls between their phones and tablets.
Version 1.0.0-alpha01 was released on May 10 at Google I/O 2023, but alpha02 was released on October 4.
👍58❤11👏2🤔1👀1
Here are the most important Google System updates that rolled out in October 2023.
* "[Phone] Support to connect your watch to multiple phones seamlessly" (available with Google Play Services v23.39+). It's not exactly clear what this means.
* "[Phone] Content received over Nearby Share is stored in a new location" (available with Google Play Services v23.40+). Files you receive via Nearby Share are now saved in the "Nearby Share" folder under "Download" rather than the "Download" folder itself.
* "[Phone] Nearby Share is disabled in work profiles" (available with Google Play Services 23.41+). Some have speculated that this was done to mitigate theft (intentional or not) of corporate data, but I heard this was disabled simply because it just didn't work properly and there isn't enough bandwidth to fix the issues.
* "[Phone] You can now decide if Google Play can update an app that was installed by a different app store" (available with Google Play Store v38.2+). This may be Google Play implementing support for Android 14's update ownership API, or it might not be. Either way, this is a welcome change for users who sideload and/or install apps from alternative sources.
* "[Wear] Users can now install and set watch faces directly from the Play store listing and opt in to always automatically set watchfaces upon install" (available with Google Play Store v38.2+). This hasn't rolled out on my Pixel Watch 2 yet, so I don't have a screenshot to share.
* "[Phone] Support adding Wallet passes from images containing barcodes or QR codes" (available with Google Play Services v23.42+). Google Wallet now lets you create a pass using a photo or screenshot of a barcode or QR code. This was announced as part of the September 2023 Android Feature Drop.
(1/2)
* "[Phone] Support to connect your watch to multiple phones seamlessly" (available with Google Play Services v23.39+). It's not exactly clear what this means.
* "[Phone] Content received over Nearby Share is stored in a new location" (available with Google Play Services v23.40+). Files you receive via Nearby Share are now saved in the "Nearby Share" folder under "Download" rather than the "Download" folder itself.
* "[Phone] Nearby Share is disabled in work profiles" (available with Google Play Services 23.41+). Some have speculated that this was done to mitigate theft (intentional or not) of corporate data, but I heard this was disabled simply because it just didn't work properly and there isn't enough bandwidth to fix the issues.
* "[Phone] You can now decide if Google Play can update an app that was installed by a different app store" (available with Google Play Store v38.2+). This may be Google Play implementing support for Android 14's update ownership API, or it might not be. Either way, this is a welcome change for users who sideload and/or install apps from alternative sources.
* "[Wear] Users can now install and set watch faces directly from the Play store listing and opt in to always automatically set watchfaces upon install" (available with Google Play Store v38.2+). This hasn't rolled out on my Pixel Watch 2 yet, so I don't have a screenshot to share.
* "[Phone] Support adding Wallet passes from images containing barcodes or QR codes" (available with Google Play Services v23.42+). Google Wallet now lets you create a pass using a photo or screenshot of a barcode or QR code. This was announced as part of the September 2023 Android Feature Drop.
(1/2)
❤31👍17