According to the latest Android version distribution statistics shared by Google (via 9to5Google), the % of (GMS Android) devices running Android 13 has more than doubled since January 2023 - from 5% to 12.1%.
Other changes:
- Android 12: 18.9% -> 16.5%
- Android 11: 24.4% -> 23.5%
- Android 10: 19.5% -> 18.5%
- Android 9: 13.2% -> 12.3%
- Android 8: 9.5% -> 6.7%
- Android 7: 3.7% -> 3.3%
- Android 6: 2.8% -> 2.5%
- Android 5: 2.1% -> 1.9%
- Android 4.4: 0.7% -> 0.6%
If you want to better visualize these stats in pie chart format, 9to5Google's article has 'em.
The updated statistics are not yet available through Android Studio, presumably they're only shown on the backend for now.
Other changes:
- Android 12: 18.9% -> 16.5%
- Android 11: 24.4% -> 23.5%
- Android 10: 19.5% -> 18.5%
- Android 9: 13.2% -> 12.3%
- Android 8: 9.5% -> 6.7%
- Android 7: 3.7% -> 3.3%
- Android 6: 2.8% -> 2.5%
- Android 5: 2.1% -> 1.9%
- Android 4.4: 0.7% -> 0.6%
If you want to better visualize these stats in pie chart format, 9to5Google's article has 'em.
The updated statistics are not yet available through Android Studio, presumably they're only shown on the backend for now.
9to5Google
Android 13 has doubled in market share since January, more stats
Google’s latest Android distribution stats reveal that Android 13 has more than doubled in market share since January, among other tidbits.
👍39👀15🔥3🕊1
Android 14 is bringing a couple of enhancements to Dynamic System Updates (DSU), the feature that lets you boot a generic Android build without overwriting the original installation.
These include:
1) Ability to install a new data partition without supplying a new system image, in case you want to simulate a factory reset.
2) Ability to reboot immediately into the dynamic system when installation is completed.
3) Ability to set "sticky mode" - ie. persist the dynamic system across reboots - during installation rather than post-install.
4) Ability to hide the notification about the status of the dynamic system (in use or ready) so OEMs can customize the UI.
5) Ability to use the default strings provided by keyguard manager when showing the dialog that prompts the user for device credentials.
H/T @onenormalusername
These DSU changes probably came in response to feedback from OEMs. There are surprisingly a couple of OEMs who actually use DSU to let users test Android betas, like Sharp did with their Android 13 beta.
These include:
1) Ability to install a new data partition without supplying a new system image, in case you want to simulate a factory reset.
2) Ability to reboot immediately into the dynamic system when installation is completed.
3) Ability to set "sticky mode" - ie. persist the dynamic system across reboots - during installation rather than post-install.
4) Ability to hide the notification about the status of the dynamic system (in use or ready) so OEMs can customize the UI.
5) Ability to use the default strings provided by keyguard manager when showing the dialog that prompts the user for device credentials.
H/T @onenormalusername
These DSU changes probably came in response to feedback from OEMs. There are surprisingly a couple of OEMs who actually use DSU to let users test Android betas, like Sharp did with their Android 13 beta.
👍25🤔5❤4🔥2
Mishaal's Android News Feed
Android 14 is bringing a couple of enhancements to Dynamic System Updates (DSU), the feature that lets you boot a generic Android build without overwriting the original installation. These include: 1) Ability to install a new data partition without supplying…
Alongside the release of Android 14 Beta 1 for Pixel, Google also released Generic System Images (GSIs) for Android 14 B1! Same build (UPB1.230309.014) and SPL (April 2023) but they're installable on (theoretically) any Project Treble-compatible device - excluding devices with an Android 9 vendor.
In general, it isn't recommended for you to install a GSI through DSU - there's a chance you could brick your phone if the bootloader isn't unlocked because of Android Verified Boot (AVB).
Theoretically you should be able to boot these Android 14 GSIs on Pixels running Android 13 QPR2 WITHOUT unlocking the bootloader since Google installed the GSI keys in the ramdisk, which would let you boot a developer GSI with AVB enabled. This applies to Tensor-based Pixels, coral (Pixel 4 XL), sunfish (Pixel 4a), redbull (Pixel 4a with 5G and Pixel 5).
I don't know if they reverted this change in the QPR3 Beta, so YMMV. Also, the developer_gsi_keys makefile only lists the Q, R, and S GSI AVB pubkeys, not T or U. It's possible they're using the same key now to sign the T and U GSIs, but I haven't tested.
If you want to test booting the Android 14 GSI on your Pixel running Android 13 QPR2+ (again, I HAVEN'T TESTED IF THIS WILL BRICK YOUR PHONE OR WORK), you have to do so manually (or use DSU Sideloader), because Google hasn't updated gsi-src.json to point to the U GSIs yet.
EDIT:
It seems Google literally just updated the gsi-src json to point to the Android 14 GSIs, so they should now appear as an option for you to install in the DSU Loader menu!
(I swear the json didn't have this when I drafted this post, lol!)
According to one user, they were able to boot up the Android 14 Beta 1 GSI on their Pixel 7 which had a locked bootloader and was running the April 2023 Android 13 QPR2 stable release.
In general, it isn't recommended for you to install a GSI through DSU - there's a chance you could brick your phone if the bootloader isn't unlocked because of Android Verified Boot (AVB).
Theoretically you should be able to boot these Android 14 GSIs on Pixels running Android 13 QPR2 WITHOUT unlocking the bootloader since Google installed the GSI keys in the ramdisk, which would let you boot a developer GSI with AVB enabled. This applies to Tensor-based Pixels, coral (Pixel 4 XL), sunfish (Pixel 4a), redbull (Pixel 4a with 5G and Pixel 5).
I don't know if they reverted this change in the QPR3 Beta, so YMMV. Also, the developer_gsi_keys makefile only lists the Q, R, and S GSI AVB pubkeys, not T or U. It's possible they're using the same key now to sign the T and U GSIs, but I haven't tested.
If you want to test booting the Android 14 GSI on your Pixel running Android 13 QPR2+ (again, I HAVEN'T TESTED IF THIS WILL BRICK YOUR PHONE OR WORK), you have to do so manually (or use DSU Sideloader), because Google hasn't updated gsi-src.json to point to the U GSIs yet.
EDIT:
It seems Google literally just updated the gsi-src json to point to the Android 14 GSIs, so they should now appear as an option for you to install in the DSU Loader menu!
(I swear the json didn't have this when I drafted this post, lol!)
According to one user, they were able to boot up the Android 14 Beta 1 GSI on their Pixel 7 which had a locked bootloader and was running the April 2023 Android 13 QPR2 stable release.
👍19❤3
Google is preparing to add "Super Wideband" (SWB) Speech support to Android's Bluetooth stack which (I assume) enables even higher-quality voice transmission over the Bluetooth Hands-Free Profile (HFP)!
This will use the LC3 codec over HFP. In comparison, the codec behind the current "Wideband Speech" (WBS) is mSBC. I don't know exactly how improved voice audio coded in LC3 will sound compared to mSBC - will have to wait for audio samples to find out.
One of the code changes also mentions the Bluetooth stack adding support for HFP 1.9. The currently adopted HFP spec is 1.8.
H/T luca020400 on Twitter
EDIT:
The Bluetooth SIG apparently already has a page covering Super Wide Band Speech and HFP 1.9.
HFP 1.9 hasn't been adopted yet, so the document that describes it is a WIP. Here's Appendix E: Technical Specification of LC3-SWB.
This will use the LC3 codec over HFP. In comparison, the codec behind the current "Wideband Speech" (WBS) is mSBC. I don't know exactly how improved voice audio coded in LC3 will sound compared to mSBC - will have to wait for audio samples to find out.
One of the code changes also mentions the Bluetooth stack adding support for HFP 1.9. The currently adopted HFP spec is 1.8.
H/T luca020400 on Twitter
EDIT:
The Bluetooth SIG apparently already has a page covering Super Wide Band Speech and HFP 1.9.
HFP 1.9 hasn't been adopted yet, so the document that describes it is a WIP. Here's Appendix E: Technical Specification of LC3-SWB.
👍20🔥8
"Smart Lock" is in the process of being rebranded to "Extend Unlock". This rebranding has started to roll out for a few users, but the rollout is incomplete since the Extend Unlock settings page is empty (likely the right server-side flag isn't toggled for these users). Issue Tracker report.
Screenshots of the blank "Extend Unlock" settings page (courtesy Diablo0090, HydroPetro).
If you want to know why Smart Lock is being rebranded to Extend Unlock, I talked about it in this thread before.
Screenshots of the blank "Extend Unlock" settings page (courtesy Diablo0090, HydroPetro).
If you want to know why Smart Lock is being rebranded to Extend Unlock, I talked about it in this thread before.
👍23🤔2❤1
Google Messages appears to be rolling out end-to-end encryption support for group RCS chats for users on the latest stable release (version messages.android_20230329_00_RC01.phone_dynamic).
H/T SeeAreEff on Twitter
H/T SeeAreEff on Twitter
👍30❤6
This media is not supported in your browser
VIEW IN TELEGRAM
Android is preparing to add support for "Valet Key", which I assume refers to a way to securely & temporarily share a digital car key for valet parking. A new system property and SELinux policy for "valet key" have been added, but that's it - no details on the implementation.
With the December 2022 Pixel Feature Drop, Google rolled out the ability to share a digital car key with your (trusted) friends and family. AFAIK, there's currently no way to temporarily grant someone access to your DCK unless you manually grant then remember to revoke access.
Now here's where things get weird. How exactly will you share your DCK temporarily with the valet? Would a temporarily valid credential be transferred to a receiving device via Nearby Share or something? Would you have to text/send them a link? Hand them (!) your phone?
Handing the valet your phone doesn't sound ideal...but that might be how this works? Hear me out.
The SELinux policy that Google set up gives the Settings app r/w access to /metadata/valetkey. This lets it write /metadata/valetkey/enabled to indicate a valet key is enabled.
The status of the valet key is only readable to apps if /metadata/valetkey/enabled exists, ro.valetkey.enabled is true, and a GSI (?) is running.
Why would this be conditioned on whether a GSI is running? Maybe your phone will boot into a GSI temporarily so when you hand your phone over to the valet, your data will be inaccessible to them?
It's a wild theory for sure, but there's so little information to go on!
Oh, and I looked at the CCC v3 specification. There isn't really a section on how valet keys work, but there is a mention of a "valet parking key" as one of the standard profiles in section 11.6 Key Configuration.
With the December 2022 Pixel Feature Drop, Google rolled out the ability to share a digital car key with your (trusted) friends and family. AFAIK, there's currently no way to temporarily grant someone access to your DCK unless you manually grant then remember to revoke access.
Now here's where things get weird. How exactly will you share your DCK temporarily with the valet? Would a temporarily valid credential be transferred to a receiving device via Nearby Share or something? Would you have to text/send them a link? Hand them (!) your phone?
Handing the valet your phone doesn't sound ideal...but that might be how this works? Hear me out.
The SELinux policy that Google set up gives the Settings app r/w access to /metadata/valetkey. This lets it write /metadata/valetkey/enabled to indicate a valet key is enabled.
The status of the valet key is only readable to apps if /metadata/valetkey/enabled exists, ro.valetkey.enabled is true, and a GSI (?) is running.
Why would this be conditioned on whether a GSI is running? Maybe your phone will boot into a GSI temporarily so when you hand your phone over to the valet, your data will be inaccessible to them?
It's a wild theory for sure, but there's so little information to go on!
Oh, and I looked at the CCC v3 specification. There isn't really a section on how valet keys work, but there is a mention of a "valet parking key" as one of the standard profiles in section 11.6 Key Configuration.
🔥24👍6👀5❤1
Mishaal's Android News Feed
Photo
This feature has now been announced.
The prompt will appear on devices running Android 7.0+ when an app in the foreground crashes and there's a more stable version of the app available on Google Play.
The prompt will appear on devices running Android 7.0+ when an app in the foreground crashes and there's a more stable version of the app available on Google Play.
👍28❤7👏2
Android 13 QPR3 Beta 3 is now rolling out for supported Pixel devices in the Android QPR Beta Program!
Build ID: T3B3.230413.003
Release notes & top resolved issues
(I'm on a break this week, so I won't be digging into this release. Not that I expect there to be much new in it anyway.)
Build ID: T3B3.230413.003
Release notes & top resolved issues
(I'm on a break this week, so I won't be digging into this release. Not that I expect there to be much new in it anyway.)
Android Developers
Android 13 | Android Developers
Android 13 is now available in the Android Open Source Project (AOSP).
👍33🎉6👏5
BMW has announced that Digital Key Plus - which uses your UWB-equipped smartphone to wirelessly lock/unlock/start your car - is now compatible with select Android devices. It was previously only compatible with UWB-equipped iPhones and the Apple Watch.
The list of compatible Android devices is as follows:
* Samsung devices (running Android 13.1 or later):
* Galaxy S23+, S23 Ultra, S22+, S22 Ultra, S21+, S21 Ultra, Z Fold4, Z Fold3, Note20 Ultra (in markets with Samsung Wallet)
* Google devices (running Android 13.1 or later):
* Pixel 7 Pro, Pixel 6 Pro
This works with Digital Key Plus-compatible BMWs produced from Nov. 2022. A future software update will expand support to Digital Key Plus-compatible BMWs produced before Nov. 2022.
In the March 2023 Pixel Feature Drop, Google said that compatible Pixels would gain support for ultra-wideband digital car key with select 2022 BMW models.
In the March 2023 Google System Updates changelog, Google noted that Play Services v23.10.23 adds support for wireless use of digital car keys, the implementation of which is based on the Car Connectivity Consortium (CCC) Digital Key specification Release 3.
I'm not sure why the BMW press note mentions "Android 13.1 or later" - Android 13.1 doesn't formally exist, but they're likely referring to Android 13 QPR1. In any case, I think this just relies on a recent version of the AOSP UWB stack to be implemented on the device.
The list of compatible Android devices is as follows:
* Samsung devices (running Android 13.1 or later):
* Galaxy S23+, S23 Ultra, S22+, S22 Ultra, S21+, S21 Ultra, Z Fold4, Z Fold3, Note20 Ultra (in markets with Samsung Wallet)
* Google devices (running Android 13.1 or later):
* Pixel 7 Pro, Pixel 6 Pro
This works with Digital Key Plus-compatible BMWs produced from Nov. 2022. A future software update will expand support to Digital Key Plus-compatible BMWs produced before Nov. 2022.
In the March 2023 Pixel Feature Drop, Google said that compatible Pixels would gain support for ultra-wideband digital car key with select 2022 BMW models.
In the March 2023 Google System Updates changelog, Google noted that Play Services v23.10.23 adds support for wireless use of digital car keys, the implementation of which is based on the Car Connectivity Consortium (CCC) Digital Key specification Release 3.
I'm not sure why the BMW press note mentions "Android 13.1 or later" - Android 13.1 doesn't formally exist, but they're likely referring to Android 13 QPR1. In any case, I think this just relies on a recent version of the AOSP UWB stack to be implemented on the device.
👍19🥰4
Google Chrome may soon integrate with Android's AppSearch feature, which could let you search through your open Chrome tabs and bookmarks right from the Pixel Launcher search bar!
A new Chrome flag was recently added (H/T @LanceAdams) that's titled "Integrate with Android App Search." Its description reads: "If enabled, allows Chrome to integrate with the Android App Search."
In an earlier patchset, the description for the Chrome flag read as:
"Donate the tabs and bookmarks to Android App Search."
The feature doesn't work yet, as it seems only the flag has been added and not the implementation as of now.
While it's not confirmed, I think "Android App Search" refers to the AppSearch feature introduced in 2021 w/ Android 12 and described in this blog. AppSearch IIRC is what powers the Pixel Launcher's universal search.
AppSearch was shipped as an APEX module in Android 12 on Pixel but became a Project Mainline module in Android 13. I think other OEM launchers could integrate with AppSearch and thus show Chrome tabs and bookmarks when/if this launches, but I'm not sure.
A new Chrome flag was recently added (H/T @LanceAdams) that's titled "Integrate with Android App Search." Its description reads: "If enabled, allows Chrome to integrate with the Android App Search."
In an earlier patchset, the description for the Chrome flag read as:
"Donate the tabs and bookmarks to Android App Search."
The feature doesn't work yet, as it seems only the flag has been added and not the implementation as of now.
While it's not confirmed, I think "Android App Search" refers to the AppSearch feature introduced in 2021 w/ Android 12 and described in this blog. AppSearch IIRC is what powers the Pixel Launcher's universal search.
AppSearch was shipped as an APEX module in Android 12 on Pixel but became a Project Mainline module in Android 13. I think other OEM launchers could integrate with AppSearch and thus show Chrome tabs and bookmarks when/if this launches, but I'm not sure.
👍30🔥7👏3
So the Ontario Police has seen a spike in accidental 911 calls from Android phones, which they blame "Emergency SOS" for. Reminds me of how the iPhone 14 triggered false 911 calls when people went on roller coasters.
For those who don't know, Emergency SOS provides a fast way to call emergency services by quickly tapping the power button 5 times.
Many users aren't aware the feature exists, though, so when they repeatedly tap the power button because their phone is unresponsive, they call emergency services by accident. That's a problem since it wastes their time and could result in a delayed response to someone who needs help.
Since Android 12, Google made it a requirement for (phone) builds to include the emergency SOS experience. It's up to OEMs whether it's on by default, though. (It's enabled by default in AOSP.)
Since Android 13, OEMs can ship either Google's Personal Safety app or their own emergency info app (they have to pick one). Some OEMs like Nothing and Sony use Google's app, others like ASUS do not. Emergency SOS is required either way.
The benefit of preloading Google's Personal Safety app is that it provides additional actions it can share info with select contacts and even record a video.
Otherwise, OEMs have to implement these themselves. They're able to configure whether a call is placed to emergency services immediately after power is pressed 5 times and the 5-30s countdown is done, or they can prompt the user for confirmation before initiating the call.
I'm sure Google & OEMs don't want users to accidentally call emergency services, but by not informing users this feature is there/turned on by default, that may be why this is happening.
And to clarify, the Ontario police don't know for sure that the Emergency SOS feature is to blame for this spike in accidental calls. They're assuming it may be, and it makes some sense why they would blame the feature.
I'm just providing some additional context on the feature 😁
For those who don't know, Emergency SOS provides a fast way to call emergency services by quickly tapping the power button 5 times.
Many users aren't aware the feature exists, though, so when they repeatedly tap the power button because their phone is unresponsive, they call emergency services by accident. That's a problem since it wastes their time and could result in a delayed response to someone who needs help.
Since Android 12, Google made it a requirement for (phone) builds to include the emergency SOS experience. It's up to OEMs whether it's on by default, though. (It's enabled by default in AOSP.)
Since Android 13, OEMs can ship either Google's Personal Safety app or their own emergency info app (they have to pick one). Some OEMs like Nothing and Sony use Google's app, others like ASUS do not. Emergency SOS is required either way.
The benefit of preloading Google's Personal Safety app is that it provides additional actions it can share info with select contacts and even record a video.
Otherwise, OEMs have to implement these themselves. They're able to configure whether a call is placed to emergency services immediately after power is pressed 5 times and the 5-30s countdown is done, or they can prompt the user for confirmation before initiating the call.
I'm sure Google & OEMs don't want users to accidentally call emergency services, but by not informing users this feature is there/turned on by default, that may be why this is happening.
And to clarify, the Ontario police don't know for sure that the Emergency SOS feature is to blame for this spike in accidental calls. They're assuming it may be, and it makes some sense why they would blame the feature.
I'm just providing some additional context on the feature 😁
👍23🥰2😁1🤔1
Google has formally announced the backported version of the Photo Picker (provided through Play Services)! It's available on all Android 4.4+ devices with GMS, meaning the new photo picker experience is available on nearly all Android devices!
Developers using the ActivityX library won't have to worry about handling calls to the GMS (Android 4.4+) versus framework (Android 11+) Photo Picker.
Google also says that the GET_CONTENT takeover rollout will resume in the coming months. This change makes the Photo Picker appear in apps that invoke the system file picker using the GET_CONTENT intent. This change briefly rolled out a few months back but was halted.
Also, the blog post reiterates that the Photo Picker will "seamlessly support cloud storage providers like Google Photos". Google Photos support was announced at I/O 2022, and with v6.30, the feature seems nearly ready to launch.
Developers using the ActivityX library won't have to worry about handling calls to the GMS (Android 4.4+) versus framework (Android 11+) Photo Picker.
Google also says that the GET_CONTENT takeover rollout will resume in the coming months. This change makes the Photo Picker appear in apps that invoke the system file picker using the GET_CONTENT intent. This change briefly rolled out a few months back but was halted.
Also, the blog post reiterates that the Photo Picker will "seamlessly support cloud storage providers like Google Photos". Google Photos support was announced at I/O 2022, and with v6.30, the feature seems nearly ready to launch.
❤25👍5🔥1
It's been over 3 years since the last Snapseed update, but version 2.20 is finally starting to roll out to users today.
PhotoScan, meanwhile, was last updated in April 2019, but has also been updated recently to version 1.7.5.
(H/T beanowe on Telegram and stanzillaz on Twitter)
These updates bump the target SDK version to 33, ie. Android 13. This is important because, starting August 31, existing apps must target SDK 31 or higher to be discoverable by all users on Google Play.
Before this update, you wouldn't be able to search and download Snapseed/PhotoScan from Google Play after August 31 if you didn't previously install it on any of your devices or if your device isn't running an older OS. (Snapseed 2.19 targeted SDK 28, while PhotoScan targeted SDK 26.)
As a bonus, ao9news on Twitter pointed out to me that PhotoScan v1.7.X also increases the resolution of pictures!
I tested it before/after the update, and a scan of the same photo went from 1125x2000 to 1969x3500 (1.11MB to 4.26MB). Very useful if you want to go back and scan a bunch of old photos.
PhotoScan, meanwhile, was last updated in April 2019, but has also been updated recently to version 1.7.5.
(H/T beanowe on Telegram and stanzillaz on Twitter)
These updates bump the target SDK version to 33, ie. Android 13. This is important because, starting August 31, existing apps must target SDK 31 or higher to be discoverable by all users on Google Play.
Before this update, you wouldn't be able to search and download Snapseed/PhotoScan from Google Play after August 31 if you didn't previously install it on any of your devices or if your device isn't running an older OS. (Snapseed 2.19 targeted SDK 28, while PhotoScan targeted SDK 26.)
As a bonus, ao9news on Twitter pointed out to me that PhotoScan v1.7.X also increases the resolution of pictures!
I tested it before/after the update, and a scan of the same photo went from 1125x2000 to 1969x3500 (1.11MB to 4.26MB). Very useful if you want to go back and scan a bunch of old photos.
🔥38👍16❤1
Mishaal's Android News Feed
In Android 13 QPR2, you can no longer take a screenshot of the "Share Wi-Fi" page where a QR code is shown that others can scan to join your Wi-Fi network. All you get is a black screen if you do. This is a rather minor change that I didn't notice until someone…
Google seems to have reverted this change in Android 13 QPR3 Beta 3, meaning you can once again take a screenshot of the "Share Wi-Fi" page to share with others!
This change will likely be reflected in the upcoming Android 14 Beta 2 release as well.
This change will likely be reflected in the upcoming Android 14 Beta 2 release as well.
👍24❤10
If you're reviewing an Android device (or developing a game) and want to benchmark gaming performance, there's a new app I suggest you check out: TakoStats.
It shows you an overlay with real-time performance statistics and can output all sorts of useful graphs!
The app is in public beta but seems to be nearing a launch soon. You have to unlock the app ($1.99/year or one-time $4.99) in order to collect data for sessions lasting longer than than 5-minutes.
I'm a big fan of how many items you can display in the overlay (the ability to display the layer name might be useful for developers who want to know what particular part of their app is janky), and also how many graphs it produces.
There are a few apps that are similar to TakoStats, like GameBench, PerfDog, and KFMark. I've used all of them, and there are two big advantages that TakoStats has over its competition.
1) Price. GameBench & PerfDog are the most widely used in the industry (PerfDog is particular popular among Chinese OEMs, its owner WeTest is run by Tencent). Both are considerably more expensive. A free APK for KFMark can be found on the project's GitHub, but it seems abandoned.
2) Usage. All these apps essentially use shell privileges to access framestats/other info. GameBench, PerfDog, & KFMark require you to connect your phone to your PC to run a script (the former two do this automatically, the last one manually).
In contrast, TakoStats uses the Shizuku library (in fact, the devs of TakoStats are also the devs of Shizuku). The Shizuku service can be enabled on-device using wireless debugging.
TakoStats also has a very modern interface, complete with Material You colors, a themed app icon, support for new APIs like the Quick Settings Placement API.
My one complaint with TakoStats is there's currently (AFAIK) no way to export the data so you can graph it yourself.
You can export data from PerfDog into a spreadsheet or just take screenshots from the desktop app/web interface on a much larger/wider screen. Same with GameBench.
It shows you an overlay with real-time performance statistics and can output all sorts of useful graphs!
The app is in public beta but seems to be nearing a launch soon. You have to unlock the app ($1.99/year or one-time $4.99) in order to collect data for sessions lasting longer than than 5-minutes.
I'm a big fan of how many items you can display in the overlay (the ability to display the layer name might be useful for developers who want to know what particular part of their app is janky), and also how many graphs it produces.
There are a few apps that are similar to TakoStats, like GameBench, PerfDog, and KFMark. I've used all of them, and there are two big advantages that TakoStats has over its competition.
1) Price. GameBench & PerfDog are the most widely used in the industry (PerfDog is particular popular among Chinese OEMs, its owner WeTest is run by Tencent). Both are considerably more expensive. A free APK for KFMark can be found on the project's GitHub, but it seems abandoned.
2) Usage. All these apps essentially use shell privileges to access framestats/other info. GameBench, PerfDog, & KFMark require you to connect your phone to your PC to run a script (the former two do this automatically, the last one manually).
In contrast, TakoStats uses the Shizuku library (in fact, the devs of TakoStats are also the devs of Shizuku). The Shizuku service can be enabled on-device using wireless debugging.
TakoStats also has a very modern interface, complete with Material You colors, a themed app icon, support for new APIs like the Quick Settings Placement API.
My one complaint with TakoStats is there's currently (AFAIK) no way to export the data so you can graph it yourself.
You can export data from PerfDog into a spreadsheet or just take screenshots from the desktop app/web interface on a much larger/wider screen. Same with GameBench.
👍50❤7🤮4👎2🌭1