Here's a look at a potential new feature in Android 14: a toggle to change back to the old "persistent" taskbar style from Android 12L. The Pixel Tablet and Pixel Fold use Android's new "transient" taskbar which doesn't stay on screen for long.
Read more here.
Read more here.
Android Police
Android 14 may let you bring back the old taskbar on the Pixel Tablet and Pixel Fold
With Android 14 nearing the end of development, we could still be getting one big upgrade to how the taskbar operates
🔥22👍5
Twitter on the Pixel Tablet before and after letterboxing tweaks.
- Made the app window slightly bigger (but unable to make it fully stretch)
- Changed the background to the wallpaper with a slight blur
I don't have a Pixel Tablet so thanks to Kartheek Alladi for testing😁
Before you ask, "how?" You should know that Android really doesn't seem to like you messing with an app's aspect ratio. If you do, you may get this cursed recents overview transition.
...but if you want to try anyway (to see if you can get better results), you'll need these ADB shell commands:
To output the default letterbox config:
To change the letterbox config:
Type
- Made the app window slightly bigger (but unable to make it fully stretch)
- Changed the background to the wallpaper with a slight blur
I don't have a Pixel Tablet so thanks to Kartheek Alladi for testing😁
Before you ask, "how?" You should know that Android really doesn't seem to like you messing with an app's aspect ratio. If you do, you may get this cursed recents overview transition.
...but if you want to try anyway (to see if you can get better results), you'll need these ADB shell commands:
To output the default letterbox config:
wm get-letterbox-styleTo change the letterbox config:
wm set-letterbox-style <ARG> <VALUE>Type
wm for the help text.👍23😨3🥰2
The DirtyPipe vulnerability (CVE-2022-0847) is apparently under active exploitation according to Google (H/T @flawedworlddev).
This vulnerability was addressed in the May 2022 bulletin, though, so if your device reports a security patch level of 2022-05-05 or newer it should already be protected against it.
This vulnerability was addressed in the May 2022 bulletin, though, so if your device reports a security patch level of 2022-05-05 or newer it should already be protected against it.
👍17🔥2
Mishaal's Android News Feed
You can now use Nearby Share to send text/files to your devices even when they're sleeping! You no longer have to turn on your device's screen and unlock it just to share something. More details (and a demo) here.
Bumping this because I just learned that this change, in fact, was announced by Google last September (H/T aniruddhdodiya on Twitter).
I somehow missed/forgot this was announced, as did many others. Still, I messed up, so I've updated the article to reflect that.
I somehow missed/forgot this was announced, as did many others. Still, I messed up, so I've updated the article to reflect that.
👍26
I was asked why the Pixel Fold doesn't have Android's one-handed mode feature, which also lets you swipe down on any screen to pull down the notifications.
The reason is that Google intends for this feature to only be available on small screen devices.
You can see here that the system property
Given that the Fold has a relatively normal sized outer display where OHM might still be useful, I think it should just be left up to the user whether they want to use it.
But what do you think? Would you use OHM/swipe down for notifications on your Pixel Fold?
(Yes, I know you can still swipe down while on the Pixel Launcher home screen to pull down the notifications, but the OHM version of the feature lets you do that on almost any screen.)
The reason is that Google intends for this feature to only be available on small screen devices.
You can see here that the system property
ro.support_one_handed_mode is set to false in device-felix.mk. This controls whether the OHM settings page is available.Given that the Fold has a relatively normal sized outer display where OHM might still be useful, I think it should just be left up to the user whether they want to use it.
But what do you think? Would you use OHM/swipe down for notifications on your Pixel Fold?
(Yes, I know you can still swipe down while on the Pixel Launcher home screen to pull down the notifications, but the OHM version of the feature lets you do that on almost any screen.)
😢9👍5🤔3
After deprecating Android Beam in Android 10, Google has now fully removed the NFC P2P communication code it relies on.
(As I reported back in 2019, Google ceased development of Android Beam but left it available for device makers who wanted to use it. Now it'll just be gone from the platform entirely. Of course, this isn't a big deal since we have Nearby Share now, though that's only available on GMS Android devices and not AOSP like Android Beam was.)
Back in September, developer Luca Stefani pointed me to a series of patches cleaning up what remains of Android Beam in the platform. Nearly 10 months later, these code changes have been merged. The code for NFC P2P communication has been removed from AOSP.
Though given that Apple has announced NameDrop, which is a (very beautifully designed) version of Android Beam for iOS, I wonder if Google will change their minds and bring back Android Beam.
In Android 15, Google may make the NFC stack into a new Project Mainline module, so I think if that module's enforced, they could do it.
(As I reported back in 2019, Google ceased development of Android Beam but left it available for device makers who wanted to use it. Now it'll just be gone from the platform entirely. Of course, this isn't a big deal since we have Nearby Share now, though that's only available on GMS Android devices and not AOSP like Android Beam was.)
Back in September, developer Luca Stefani pointed me to a series of patches cleaning up what remains of Android Beam in the platform. Nearly 10 months later, these code changes have been merged. The code for NFC P2P communication has been removed from AOSP.
Though given that Apple has announced NameDrop, which is a (very beautifully designed) version of Android Beam for iOS, I wonder if Google will change their minds and bring back Android Beam.
In Android 15, Google may make the NFC stack into a new Project Mainline module, so I think if that module's enforced, they could do it.
👍31❤1🙏1
Mishaal's Android News Feed
The /r/Android subreddit is back up, but submissions are currently restricted. The mods are seeking feedback from community members about how to proceed from here, so if you want to share your thoughts, you can do so in this thread.
The /r/Android subreddit is no longer restricted, but the moderators have not announced yet what their plans are for the future of the sub following a call for feedback last week.
🤡34👍14💩3
Many people have criticized Google for not stretching apps to full screen on the Pixel Tablet and Pixel Fold.
Why don't they? It's because Pixel is restrained in ways that other OEMs aren't, but that's a good thing.
My latest article for Android Central dives into why.
Why don't they? It's because Pixel is restrained in ways that other OEMs aren't, but that's a good thing.
My latest article for Android Central dives into why.
Android Central
Pixel's ties to Google is its biggest strength—but also a weakness
Google can’t get away with what some of its OEM partners do, but that’s better for developers
👍29🥰1
FYI: Googlers are off today in the U.S. for Independence Day, so the July 2023 Android Security Bulletin won't be published until they're back on the clock. It's expected to go live tomorrow, however, that doesn't guarantee that the Pixel updates will go live at the same time.
👍39🥱11😁4🤡1
Google is developing Android TV 14 on a set-top box called the ADT-4. However, unlike with previous ADTs, Google doesn't plan to sell it. So if you want to develop an Android TV app for TV 14, you'll have to stick to the emulator. More details here.
Personally, this is disappointing. TV apps that utilize advanced display or sound formats can't test everything on the emulator. Not everyone will have an Amlogic contract, so even if you obtain the S905X4 reference device through a 3P, how will you get updated builds?
The Chromecast with Google TV (HD) and (4K) are consumer devices w/o access to Android TV beta builds. They currently run TV 12 while Google's working on TV 14. So while they're good for testing retail device behavior, they won't be useful for testing new platform versions.
Personally, this is disappointing. TV apps that utilize advanced display or sound formats can't test everything on the emulator. Not everyone will have an Amlogic contract, so even if you obtain the S905X4 reference device through a 3P, how will you get updated builds?
The Chromecast with Google TV (HD) and (4K) are consumer devices w/o access to Android TV beta builds. They currently run TV 12 while Google's working on TV 14. So while they're good for testing retail device behavior, they won't be useful for testing new platform versions.
Android Authority
No one will be able to buy Google's ADT-4 Android TV box
Google is developing Android TV 14 on its ADT-4 reference device, but it doesn't have any plans to offer this developer kit to anyone, sadly.
🤔9❤6👍4😢2
The July 2023 Android Security Bulletin is live, listing the vulnerabilities patched in the 2023-07-0X security patch level.
The bulletin also publicizes that CVE-2023-26083 (Mali GPU kernel driver bug), CVE-2021-29256 (also Mali bug), and CVE-2023-2136 (Skia bug) are under "limited, targeted exploitation."
The bulletin also publicizes that CVE-2023-26083 (Mali GPU kernel driver bug), CVE-2021-29256 (also Mali bug), and CVE-2023-2136 (Skia bug) are under "limited, targeted exploitation."
👍20❤6
The Pixel's "recents URL sharing" feature which lets you share links from the recents menu is no longer a Pixel-exclusive feature, because ASUS quietly implemented it in their Android 13-based ZenUI OS!
The Pixel's recents menu enhancements (especially the ability to share text/images) is one of its most underrated exclusive features. I wish other OEMs would replicate it. Enabling the recents URL sharing feature seems simple enough, so hopefully more OEMs add it!
I checked/asked a bunch of users with OEM devices from Samsung, OnePlus/OPPO, Xiaomi, Sony, Nothing, etc. and I couldn't find any other OEM launcher that implemented this feature. No custom ROM that I've seen has it either, but if you know of one, let me know!
The docs for "recents URL sharing" still says that it's Pixel only, but I guess that's now incorrect in light of this news. ASUS doesn't sell many smartphones (they do make great phones), though, so it's not like this one OEM will move the needle in terms of developer interest.
More details here.
The Pixel's recents menu enhancements (especially the ability to share text/images) is one of its most underrated exclusive features. I wish other OEMs would replicate it. Enabling the recents URL sharing feature seems simple enough, so hopefully more OEMs add it!
I checked/asked a bunch of users with OEM devices from Samsung, OnePlus/OPPO, Xiaomi, Sony, Nothing, etc. and I couldn't find any other OEM launcher that implemented this feature. No custom ROM that I've seen has it either, but if you know of one, let me know!
The docs for "recents URL sharing" still says that it's Pixel only, but I guess that's now incorrect in light of this news. ASUS doesn't sell many smartphones (they do make great phones), though, so it's not like this one OEM will move the needle in terms of developer interest.
More details here.
Android Police
Sharing links from Android's Recents menu is no longer a Pixel-exclusive feature
With Android 12, Pixels gained the ability to share links from the Recents menu — now it's time for Asus devices to join the fun
👍34❤3🤔3
This isn't Android news, but if you want to follow me on Threads, you can find me here.
I'm still on Twitter @MishaalRahman, where I'll be posting most of my stuff. I'll still of course post to this channel as well as to Mastodon (@MishaalRahman@AndroidDev.social) in case you want to follow me somewhere that isn't owned by Twitter or Meta.
I'm still on Twitter @MishaalRahman, where I'll be posting most of my stuff. I'll still of course post to this channel as well as to Mastodon (@MishaalRahman@AndroidDev.social) in case you want to follow me somewhere that isn't owned by Twitter or Meta.
🍾17👎16👍10❤3🥰1🗿1
If Google does enable display output/launch desktop mode on the Pixel 8 series, then I hope they include a way to navigate on the external display that doesn't involve a physical mouse, in case you just want to hook your phone up to watch a video.
Many OEMs include a feature that lets you use your phone as a touchpad, and I recently learned of a third-party app on Google Play called "Real Mouse" that enables this on devices where that's not built-in.
The app needs shell-level privileges, which can be granted by running an ADB command or using Shizuku, in order to talk to the Linux kernel driver to act as a "real mouse" (hence the name).
Shown above: Real Mouse running on an ASUS ROG Phone 5, which supports display output but doesn't have a customized desktop mode UI.
(Other apps that use Shizuku in clever ways.)
Many OEMs include a feature that lets you use your phone as a touchpad, and I recently learned of a third-party app on Google Play called "Real Mouse" that enables this on devices where that's not built-in.
The app needs shell-level privileges, which can be granted by running an ADB command or using Shizuku, in order to talk to the Linux kernel driver to act as a "real mouse" (hence the name).
Shown above: Real Mouse running on an ASUS ROG Phone 5, which supports display output but doesn't have a customized desktop mode UI.
(Other apps that use Shizuku in clever ways.)
👍25🥰3❤2
Android 15 "Vanilla Ice Cream" will require Linux kernel 4.19, dropping support for Linux 4.14.
This is expected as with each release, the oldest supported Linux kernel version is bumped. eg. Android 14 required Linux 4.14+ while Android 13 required Linux 4.9+.
Google maintains a table that shows the kernel versions supported and tested with each Android platform release. The table hasn't been updated to note Android 15's kernel requirements, let alone Android 14's, of course.
The projected EOL for Linux 4.14 is Jan. 2024 anyways, so it makes sense to drop support in V. Still, RIP the Pixel 4a, which runs Linux 4.14 but won't be getting Android 14 (at least not officially).
This is expected as with each release, the oldest supported Linux kernel version is bumped. eg. Android 14 required Linux 4.14+ while Android 13 required Linux 4.9+.
Google maintains a table that shows the kernel versions supported and tested with each Android platform release. The table hasn't been updated to note Android 15's kernel requirements, let alone Android 14's, of course.
The projected EOL for Linux 4.14 is Jan. 2024 anyways, so it makes sense to drop support in V. Still, RIP the Pixel 4a, which runs Linux 4.14 but won't be getting Android 14 (at least not officially).
👍42😭20🔥2
Google debuted Project Mainline alongside Android 10, modularizing various system components so they can be updated through the Play Store instead of through regular OTA updates. However, it seems Mainline support for Android 10 devices is winding down.
The min SDK versions of the DNS Resolver, CaptivePortalLogin, Connectivity, and NetworkStack modules have all recently been bumped to '30' (Android 11) from '29' (Android 10), with the reason being that "Mainline push to Q was stopped in February 2023."
This is not surprising, as Feb. 2023 is also when Google ended security patch backports for Android 10. Theoretically, Google could support Android 10 devices for longer since these modules are decoupled from the OS. But that would just mean they'd only be partially protected.
Curiously, I checked with several users, some of whom report that they have Android 10 devices on the May 2023 Google Play System Update version. Not all modules have had their min SDKs bumped yet, so they may have still gotten some updated modules.
When Google first launched Project Mainline with Android 10, only a handful of modules were required for newly launched devices:
- DocumentsUI
- ExtServices
- Media Codecs
- Media Framework components
- Module Metadata
- Permission Controller
- Time Zone data
There were other modules, like Captive Portal Login, Conscrypt, DNS Resolver, and Network Stack, but these were only "strongly recommended".
If you want to learn more about Project Mainline, this blog post I co-wrote with Jonathan Levin is the best resource on it😁
The min SDK versions of the DNS Resolver, CaptivePortalLogin, Connectivity, and NetworkStack modules have all recently been bumped to '30' (Android 11) from '29' (Android 10), with the reason being that "Mainline push to Q was stopped in February 2023."
This is not surprising, as Feb. 2023 is also when Google ended security patch backports for Android 10. Theoretically, Google could support Android 10 devices for longer since these modules are decoupled from the OS. But that would just mean they'd only be partially protected.
Curiously, I checked with several users, some of whom report that they have Android 10 devices on the May 2023 Google Play System Update version. Not all modules have had their min SDKs bumped yet, so they may have still gotten some updated modules.
When Google first launched Project Mainline with Android 10, only a handful of modules were required for newly launched devices:
- DocumentsUI
- ExtServices
- Media Codecs
- Media Framework components
- Module Metadata
- Permission Controller
- Time Zone data
There were other modules, like Captive Portal Login, Conscrypt, DNS Resolver, and Network Stack, but these were only "strongly recommended".
If you want to learn more about Project Mainline, this blog post I co-wrote with Jonathan Levin is the best resource on it😁
👍26
This media is not supported in your browser
VIEW IN TELEGRAM
The July 2023 Google Play System Update quietly enabled the Photo Picker for more apps on Android 13+. In certain apps like Google Chat & Keep, the new Photo Picker will now be invoked instead of the old system file picker. (Attached to this post is a video demonstration.)
This change is a bit tough to explain fully in a thread, but back in December, I discovered that Google rolled out a Play System Update that enabled this change once a server-side flag was flipped. However, the flag was reverted one month later.
(The technical explanation for how the Photo Picker is able to intercept apps' calls to the system file picker [AKA DocumentsUI] can be found in this article.)
So what's actually changed in the July 2023 GPSU? Did Google just flip the server-side DeviceConfig flag again? Nope! Instead, MediaProvider's
Some devices with the June 2023 GPSU are also seeing this change, though I believe that's only the case for devices that ship with the UPB3.230519.008 version of MediaProvider (AKA the one preinstalled with Android 14 Beta 3).
If your app invokes the GET_CONTENT intent with an image or video mime type in order to let the user select files through the system file picker, then be aware that they'll now instead see the new Photo Picker on Android 13+ 😁
Note that although Google backported the Photo Picker to Android 4.4+ through GMS, I don't think they've implemented this "GET_CONTENT" takeover behavior yet in GMS. Hence users on older versions will continue seeing the old DocumentsUI when that intent is invoked.
As for other devices that support the framework Photo Picker - ie. Android 11-12L - I'm not sure if the GET_CONTENT takeover has also been enabled by default for them with the July 2023 GPSU.
Will follow up when I find out!
This change is a bit tough to explain fully in a thread, but back in December, I discovered that Google rolled out a Play System Update that enabled this change once a server-side flag was flipped. However, the flag was reverted one month later.
(The technical explanation for how the Photo Picker is able to intercept apps' calls to the system file picker [AKA DocumentsUI] can be found in this article.)
So what's actually changed in the July 2023 GPSU? Did Google just flip the server-side DeviceConfig flag again? Nope! Instead, MediaProvider's
PhotoPickerGetContentActivity is now enabled by default. Previously it was disabled until the take_over_get_content flag was set to true.Some devices with the June 2023 GPSU are also seeing this change, though I believe that's only the case for devices that ship with the UPB3.230519.008 version of MediaProvider (AKA the one preinstalled with Android 14 Beta 3).
If your app invokes the GET_CONTENT intent with an image or video mime type in order to let the user select files through the system file picker, then be aware that they'll now instead see the new Photo Picker on Android 13+ 😁
Note that although Google backported the Photo Picker to Android 4.4+ through GMS, I don't think they've implemented this "GET_CONTENT" takeover behavior yet in GMS. Hence users on older versions will continue seeing the old DocumentsUI when that intent is invoked.
As for other devices that support the framework Photo Picker - ie. Android 11-12L - I'm not sure if the GET_CONTENT takeover has also been enabled by default for them with the July 2023 GPSU.
Will follow up when I find out!
👍33❤4
Google has renamed AOSP's "master" branch to "main" today, in accordance with the company's commitment to using inclusive language in their products and services.
The legacy "master" branch will be a read-only replica of "main" but will be deleted in the future.
"Hi,
We are renaming the master branch to main in AOSP today. This is in line with our commitment to using inclusive language in our products and services. We believe this name will be more welcoming to everyone who uses our products.
In addition to the change in the branch name, you’ll notice that the targets on http://ci.android.com have new build variants named next, trunk_food, and trunk_staging. These variants represent builds with different feature flags, and you can use any of these for your local development (more information about these variants will be made available on http://source.android.com at a later time).
The legacy master branch will continue to exist in AOSP as a read-only replica of main and will be deleted at some time in the future. We encourage everyone to switch to using main starting today.
For those of you who use codesearch, please note that the source tree for master branch will no longer be updated. Please switch to using main in all your workflows and queries that use codesearch.
Regards,
The AOSP team"
The legacy "master" branch will be a read-only replica of "main" but will be deleted in the future.
"Hi,
We are renaming the master branch to main in AOSP today. This is in line with our commitment to using inclusive language in our products and services. We believe this name will be more welcoming to everyone who uses our products.
In addition to the change in the branch name, you’ll notice that the targets on http://ci.android.com have new build variants named next, trunk_food, and trunk_staging. These variants represent builds with different feature flags, and you can use any of these for your local development (more information about these variants will be made available on http://source.android.com at a later time).
The legacy master branch will continue to exist in AOSP as a read-only replica of main and will be deleted at some time in the future. We encourage everyone to switch to using main starting today.
For those of you who use codesearch, please note that the source tree for master branch will no longer be updated. Please switch to using main in all your workflows and queries that use codesearch.
Regards,
The AOSP team"
👍28🤔22🤡16👎11❤8😁5🌚5🤮2👾1