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.

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?

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.

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.

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."

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 aosp_cf_riscv64_phone-userdebug target in the lunch menu.

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

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!)

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.