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
Mishaal's Android News Feed
Google Authenticator now supports Google Account synchronization
Google responds to criticism about its rollout of sync in Google Authenticator. The company plans to add E2EE support to Google Authenticator down the line.
X (formerly Twitter)
Mysk ๐จ๐ฆ๐ฉ๐ช (@mysk_co) on X
Google has just updated its 2FA Authenticator app and added a much-needed feature: the ability to sync secrets across devices.
TL;DR: Don't turn it on.
The new update allows users to sign in with their Google Account and sync 2FA secrets across their iOSโฆ
TL;DR: Don't turn it on.
The new update allows users to sign in with their Google Account and sync 2FA secrets across their iOSโฆ
๐33
The Google I/O 2023 schedule is now live! Besides the keynotes, there are a ton of sessions to check out.
I will be there in-person to watch the keynotes, so I probably won't get to see the sessions until the next day. I'll definitely let you know if there's anything interesting revealed during the sessions, though!
I will be there in-person to watch the keynotes, so I probably won't get to see the sessions until the next day. I'll definitely let you know if there's anything interesting revealed during the sessions, though!
io.google
Google I/O 2025
Don't miss Google I/O, featuring product launches, innovations, and insights. Tune in for the live keynotes and sessions.
โค36๐13๐ฅ3๐2๐คฏ1
The May 2023 Android Security Bulletin is now live, detailing the vulnerabilities addressed by the 2023-05-01 and 2023-05-05 security patch levels! The public ASB doesn't go into much detail, but once the AOSP tags go live, we can see what's been patched.
Android Security Bulletin (May 2023): https://source.android.com/docs/security/bulletin/2023-05-01
Pixel Update Bulletin (May 2023): https://source.android.com/docs/security/bulletin/pixel/2023-05-01
Pixel update release notes: https://support.google.com/pixelphone/thread/213627684/google-pixel-update-may-2023
Patches are available for AOSP 11-13. Next month's update will also see the release of the third (and final) quarterly platform release of Android 13, AKA Android 13 QPR3, so look forward to that if you're a Pixel user.
Android Security Bulletin (May 2023): https://source.android.com/docs/security/bulletin/2023-05-01
Pixel Update Bulletin (May 2023): https://source.android.com/docs/security/bulletin/pixel/2023-05-01
Pixel update release notes: https://support.google.com/pixelphone/thread/213627684/google-pixel-update-may-2023
Patches are available for AOSP 11-13. Next month's update will also see the release of the third (and final) quarterly platform release of Android 13, AKA Android 13 QPR3, so look forward to that if you're a Pixel user.
๐30
Android has fixed an issue that made it possible to downgrade system apps beyond the factory installed version, which has been abused to exploit vulnerabilities in older versions of system apps.
Notably, this closes the loophole that power users have been using to achieve system shell privileges on Samsung devices.
Full details here.
Notably, this closes the loophole that power users have been using to achieve system shell privileges on Samsung devices.
Full details here.
www.esper.io
Android update fixes vulnerability that let system apps be downgraded beyond factory version
Google has fixed a security vulnerability in Android that made it possible to downgrade system apps below the factory installed version.
๐29๐ค6๐5๐2
Google and Apple lead initiative for an industry specification to address unwanted tracking - Google Security Blog
Google Online Security Blog
Google and Apple lead initiative for an industry specification to address unwanted tracking
Companies welcome input from industry participants and advocacy groups on a draft specification to alert users in the event of suspected un...
๐11๐คก9๐3๐ณ3
With Chrome 117 for desktop & Android, the browser will replace the "lock" icon in the address bar with a "tune" icon. This is to make it clearer what the icon actually represents: A button to show important security info and controls, not an indicator of site trustworthiness.
Chrome 117 will release in early September 2023 and will also bring a "general design refresh" on desktop.
More info here.
Chrome 117 will release in early September 2023 and will also bring a "general design refresh" on desktop.
More info here.
๐41๐ฅฑ10๐3๐2โค1
Today I learned that a lot of Chromebooks only support the SBC codec for Bluetooth audio. Fortunately, Google may be bringing AAC, aptX, aptX HD, and LDAC support to select Chromebooks in a future update.
The Bluetooth stack in Chrome OS is the standard Linux BlueZ, but since 2021, Google has been experimenting with building Android's Fluoride stack for Linux (Floss). This is disabled by default but can be enabled on compatible Chromebooks through a flag.
When building Floss, "nonstandard" A2DP codecs (aptX, aptX HD, LDAC, and AAC) aren't included by default but can be built with the bt_nonstandard_codecs flag. Floss stopped building these "nonstandard" A2DP codecs by default pending a "license and patent review." But now it looks like AAC, aptX, aptX HD, LDAC, AAC, and a bonus Opus, may be enabled by default in the Floss stack.
2532643: Floss: enable AAC and remove it from nonstandard codecs
2574491: TEST: enable Aptx, AptxHD, LDAC
I don't know if/when this will ever land - Floss itself is still not enabled by default on most Chromebooks IIRC - but it's good to see Google potentially address Bluetooth audio shortcomings in Chrome OS.
Qualcomm recently submitted aptX and aptX HD encoders to AOSP's BT stack, so I was wondering if/when that would make its way to Chrome OS/Floss.
The Bluetooth stack in Chrome OS is the standard Linux BlueZ, but since 2021, Google has been experimenting with building Android's Fluoride stack for Linux (Floss). This is disabled by default but can be enabled on compatible Chromebooks through a flag.
When building Floss, "nonstandard" A2DP codecs (aptX, aptX HD, LDAC, and AAC) aren't included by default but can be built with the bt_nonstandard_codecs flag. Floss stopped building these "nonstandard" A2DP codecs by default pending a "license and patent review." But now it looks like AAC, aptX, aptX HD, LDAC, AAC, and a bonus Opus, may be enabled by default in the Floss stack.
2532643: Floss: enable AAC and remove it from nonstandard codecs
2574491: TEST: enable Aptx, AptxHD, LDAC
I don't know if/when this will ever land - Floss itself is still not enabled by default on most Chromebooks IIRC - but it's good to see Google potentially address Bluetooth audio shortcomings in Chrome OS.
Qualcomm recently submitted aptX and aptX HD encoders to AOSP's BT stack, so I was wondering if/when that would make its way to Chrome OS/Floss.
โค18๐9