Google Play appears to be cracking down on "cleaner" type apps that scan your phone to remove files.
Multiple developers on Reddit's /r/AndroidDev community are reporting that their apps/accounts were suspended for violating Google's "stalkerware" policy.
While I'm not sure if the "stalkerware" claims are valid in each instance, Google did warn earlier this year that they would crack down on apps that misleadingly claim they could boost your phone's performance. And last month, Google Play announced new guidelines to their Deceptive Behavior policy that went into effect this month.
It's possible this recent slate of suspensions is related to that, though I'm not sure why "stalkerware" is being cited instead of "deceptive behavior."
(Sidenote: I hear all the time about developers getting suspended from Google Play for X and Y. While the number of stories paints a bleak picture, it's hard to really take a side in any particular case without knowing the exact details of a particular app. Google Play can definitely make a mistake, but you shouldn't always assume that to be the case! I think the SD Maid developer is probably innocent, though.)
Multiple developers on Reddit's /r/AndroidDev community are reporting that their apps/accounts were suspended for violating Google's "stalkerware" policy.
While I'm not sure if the "stalkerware" claims are valid in each instance, Google did warn earlier this year that they would crack down on apps that misleadingly claim they could boost your phone's performance. And last month, Google Play announced new guidelines to their Deceptive Behavior policy that went into effect this month.
It's possible this recent slate of suspensions is related to that, though I'm not sure why "stalkerware" is being cited instead of "deceptive behavior."
(Sidenote: I hear all the time about developers getting suspended from Google Play for X and Y. While the number of stories paints a bleak picture, it's hard to really take a side in any particular case without knowing the exact details of a particular app. Google Play can definitely make a mistake, but you shouldn't always assume that to be the case! I think the SD Maid developer is probably innocent, though.)
👍42💩10😱3🔥2👏2
Absolutely blown away by the response to my post about WarpShare!
It goes to show that:
a) Apple-related posts are popular
b) People REALLY want better cross-device file sharing services.
With that in mind, here's a round-up of other Android --> PC file-sharing apps (links in the reply):
1) Android --> macOS:
* WarpShare. This app uses Apple's AirDrop protocol, so you don't have to install anything on your Mac (you do need to set AirDrop discoverability to "everyone" though). You do have to install the WarpShare app on your phone, though, and then select it from the share sheet when sharing file(s). Does not support receiving files on Android. (If you want my compiled APK, subscribe to me on Patreon/X.)
* NearDrop. This app uses Google's Nearby protocol, so you don't have to install anything on most Android phones since Nearby is built into Google Play Services. You do, however, have to install an app on your Mac in order to make it appear in the Nearby Share menu on your phone. Also does not support receiving files on Android.
2) Android --> Windows:
* Nearby Share from Google: An official app made by Google that uses Google's Nearby protocol, so you don't have to install anything on your Android phone. You do, however, have to install the program on your Windows PC. Sending/receiving files works extremely quickly.
* Nearby Sharing Windows 10/11: This app supports Microsoft's Nearby Sharing protocol so you don't have to install a program on your Windows PC. You do, however, need to install the app on your Android phone. Receiving files works, albeit very slowly as it's over Bluetooth.
3) Android --> Linux
There are no apps (yet) that support Microsoft, Google, or Apple's wireless file sharing protocols, though one developer is attempting to port NearDrop to Linux. That project, CrossDrop, is still a WIP, though.
Otherwise, KDE Connect is a good option. Requires installing an app on your phone and PC, though.
It goes to show that:
a) Apple-related posts are popular
b) People REALLY want better cross-device file sharing services.
With that in mind, here's a round-up of other Android --> PC file-sharing apps (links in the reply):
1) Android --> macOS:
* WarpShare. This app uses Apple's AirDrop protocol, so you don't have to install anything on your Mac (you do need to set AirDrop discoverability to "everyone" though). You do have to install the WarpShare app on your phone, though, and then select it from the share sheet when sharing file(s). Does not support receiving files on Android. (If you want my compiled APK, subscribe to me on Patreon/X.)
* NearDrop. This app uses Google's Nearby protocol, so you don't have to install anything on most Android phones since Nearby is built into Google Play Services. You do, however, have to install an app on your Mac in order to make it appear in the Nearby Share menu on your phone. Also does not support receiving files on Android.
2) Android --> Windows:
* Nearby Share from Google: An official app made by Google that uses Google's Nearby protocol, so you don't have to install anything on your Android phone. You do, however, have to install the program on your Windows PC. Sending/receiving files works extremely quickly.
* Nearby Sharing Windows 10/11: This app supports Microsoft's Nearby Sharing protocol so you don't have to install a program on your Windows PC. You do, however, need to install the app on your Android phone. Receiving files works, albeit very slowly as it's over Bluetooth.
3) Android --> Linux
There are no apps (yet) that support Microsoft, Google, or Apple's wireless file sharing protocols, though one developer is attempting to port NearDrop to Linux. That project, CrossDrop, is still a WIP, though.
Otherwise, KDE Connect is a good option. Requires installing an app on your phone and PC, though.
❤26👍10
Mishaal's Android News Feed
Absolutely blown away by the response to my post about WarpShare! It goes to show that: a) Apple-related posts are popular b) People REALLY want better cross-device file sharing services. With that in mind, here's a round-up of other Android --> PC file…
I am well aware that there are a LOT of other file sharing apps/services out there, some of which don't even require an app as they're PWAs. However, I made this thread mainly to highlight the few options that are compatible with one of Microsoft, Google, or Apple's wireless file sharing protocols.
It's really a shame that all 3 companies have their own file transfer protocols that are all incompatible with one another, even though they're all based on Bluetooth/WiFi LAN/WiFi Direct communications under-the-hood. Microsoft has Nearby Sharing, Google has Nearby, and Apple has AirDrop.
I'm not really sure who even uses Microsoft's, but Apple's is very widely used and Google is slowly catching up. Apple, however, has no incentive to support other platforms. Google, to their credit, open sourced its Nearby library and is even pushing its inclusion into AOSP so Android phone makers can build Nearby compatibility into their own file transfer services (eg. Samsung's Quick Share).
It's really a shame that all 3 companies have their own file transfer protocols that are all incompatible with one another, even though they're all based on Bluetooth/WiFi LAN/WiFi Direct communications under-the-hood. Microsoft has Nearby Sharing, Google has Nearby, and Apple has AirDrop.
I'm not really sure who even uses Microsoft's, but Apple's is very widely used and Google is slowly catching up. Apple, however, has no incentive to support other platforms. Google, to their credit, open sourced its Nearby library and is even pushing its inclusion into AOSP so Android phone makers can build Nearby compatibility into their own file transfer services (eg. Samsung's Quick Share).
👍19😢4
Stylus handwriting support is nearly ready to go live on the Pixel Tablet!
The Pixel Tablet, if you aren't aware, supports USI 2.0 styli. When you connect one to the tablet, you'll get the option to select a "default notes app" and "write in text fields".
Tapping "write in text fields" opens up Gboard's new stylus handwriting settings, where you can change the handwriting speed or handwriting stroke width.
You can also tap "try it" to open a text entry field where you can demo Gboard's new stylus handwriting gestures, including writing, deleting, selecting, inserting, joining words, and new line.
(The first screenshot in this post is from a tipster who actually has a Pixel Tablet and a USI 2.0 stylus. The remaining screenshots are from me, who doesn't have a Pixel Tablet so instead had to fake the config.)
Unfortunately, my tipster reports that, despite the fact that Gboard's stylus handwriting settings appears for him WITHOUT any modifications, it doesn't actually work. We may be missing some stylus handwriting library in the build or APK that's required, or possibly some feature flag needs to be toggled first.
Still, this shows that the feature is closer to launch than previously thought, when users were manually launching the
By the way, if you're wondering what the heck the "default notes app" is, check out my previous thread where I show a first look at the feature and explain how it works.
—-
This is just my guess, but Google could launch a first-party stylus & keyboard accessory for the Pixel Tablet later this year.
Many features (improved keyboard shortcuts, notetaking role + AppClips API, stylus integration in Settings) just weren't ready for Android 13.
The Pixel Tablet, if you aren't aware, supports USI 2.0 styli. When you connect one to the tablet, you'll get the option to select a "default notes app" and "write in text fields".
Tapping "write in text fields" opens up Gboard's new stylus handwriting settings, where you can change the handwriting speed or handwriting stroke width.
You can also tap "try it" to open a text entry field where you can demo Gboard's new stylus handwriting gestures, including writing, deleting, selecting, inserting, joining words, and new line.
(The first screenshot in this post is from a tipster who actually has a Pixel Tablet and a USI 2.0 stylus. The remaining screenshots are from me, who doesn't have a Pixel Tablet so instead had to fake the config.)
Unfortunately, my tipster reports that, despite the fact that Gboard's stylus handwriting settings appears for him WITHOUT any modifications, it doesn't actually work. We may be missing some stylus handwriting library in the build or APK that's required, or possibly some feature flag needs to be toggled first.
Still, this shows that the feature is closer to launch than previously thought, when users were manually launching the
StylusSettingsActivity of Gboard.By the way, if you're wondering what the heck the "default notes app" is, check out my previous thread where I show a first look at the feature and explain how it works.
—-
This is just my guess, but Google could launch a first-party stylus & keyboard accessory for the Pixel Tablet later this year.
Many features (improved keyboard shortcuts, notetaking role + AppClips API, stylus integration in Settings) just weren't ready for Android 13.
🔥26👍11❤2
Mishaal's Android News Feed
Google is working on letting you cast media to your Pixel Tablet just by holding your phone in front of it! Attached to this post is the introduction screen for this feature. (Note that the animation shown above isn't new, but the mention of this feature…
Follow-up: Here's a look at the settings page for this feature, which is apparently called "hold close to cast."
"Hold close to cast" will let you "reach your phone toward a Pixel Tablet to cast media."
"Your devices must be on the same private Wi-Fi network to cast. Not all media apps work with this feature."
This page will be found under Settings > Google > Devices & sharing > Cast options. The video I posted previously showed the promo for this feature.
"Hold close to cast" will let you "reach your phone toward a Pixel Tablet to cast media."
"Your devices must be on the same private Wi-Fi network to cast. Not all media apps work with this feature."
This page will be found under Settings > Google > Devices & sharing > Cast options. The video I posted previously showed the promo for this feature.
🔥32👍11
New chipsets launching with Android 15 support won't be allowed to define HAL interfaces in HIDL anymore, instead they must use AIDL.
This will affect 2024 flagship launches like the Pixel 9 series and devices on the Snapdragon 8 Gen 4, etc.
Interface description languages (IDLs) specify the interface between a HAL and its users (like OS processes). HAL interface definition language or HIDL has been used throughout Android's long history but was deprecated in Android 10 as Google wanted to migrate to using Android interface definition language or AIDL for HALs in Android 11+. Google's motivations for migrating from HIDL to AIDL includes (see above):
However, migrating a HAL interface from HIDL to AIDL is not trivial as it involves rewriting it, which is why the requirements have been incrementally progressing thus far.
Chipsets launching with Android 14 support (ro.vendor.api_level = 34) must not register > 20 HIDL interfaces, which is tested for by a VTS test. That number has been lowered to 10 right now in a new VTS test, with the understanding that it'll be dropped to 0 "when the Android V AOSP release happens". It's 10 right now because of Cuttlefish.
Still, Google says that "many HIDL interfaces are still supported in Android 14, and Android 14 still has HIDL support. It will take many years to phase out support for HIDL, because we still support existing HAL interfaces, many of which are in HIDL, on upgrading devices."
Indeed, if you look at a Pixel 7 build (
(I know this is something most of you won't care about, but if you work on AOSP builds/devices, this should be relevant.)
This will affect 2024 flagship launches like the Pixel 9 series and devices on the Snapdragon 8 Gen 4, etc.
Interface description languages (IDLs) specify the interface between a HAL and its users (like OS processes). HAL interface definition language or HIDL has been used throughout Android's long history but was deprecated in Android 10 as Google wanted to migrate to using Android interface definition language or AIDL for HALs in Android 11+. Google's motivations for migrating from HIDL to AIDL includes (see above):
However, migrating a HAL interface from HIDL to AIDL is not trivial as it involves rewriting it, which is why the requirements have been incrementally progressing thus far.
Chipsets launching with Android 14 support (ro.vendor.api_level = 34) must not register > 20 HIDL interfaces, which is tested for by a VTS test. That number has been lowered to 10 right now in a new VTS test, with the understanding that it'll be dropped to 0 "when the Android V AOSP release happens". It's 10 right now because of Cuttlefish.
Still, Google says that "many HIDL interfaces are still supported in Android 14, and Android 14 still has HIDL support. It will take many years to phase out support for HIDL, because we still support existing HAL interfaces, many of which are in HIDL, on upgrading devices."
Indeed, if you look at a Pixel 7 build (
/system/etc/vintf/manifest.xml & /vendor/etc/vintf/manifest.xml), many HAL interfaces are still defined with HIDL. In addition to the one inherited from AOSP, Pixel 7 has HAL interfaces defined in HIDL for audio, neural networks, telephony, fingerprint, radio, Bluetooth, WiFi, and wireless charging.(I know this is something most of you won't care about, but if you work on AOSP builds/devices, this should be relevant.)
👍36🤔3🤡2👌1
Android 14 won't officially support NTFS, but Google is giving "implementors the [choice] whether to use it or not, even if it will open the door to potentially less secure implementations."
Previously, Google added SELinux policies to Android 14 that would allow OEMs to use Tuxera's NTFS-3G FUSE driver. These policies defined the file contexts for the "ntfsfix", "ntfs-3g", and "ntfs-3g-compart" binaries which would be placed at /system/bin.
Google seems to view the NTFS-3G FUSE driver and the in-kernel NTFS3 driver with skepticism from a security perspective, which is why they're not officially supporting either.
For context, refer to this previous post.
Previously, Google added SELinux policies to Android 14 that would allow OEMs to use Tuxera's NTFS-3G FUSE driver. These policies defined the file contexts for the "ntfsfix", "ntfs-3g", and "ntfs-3g-compart" binaries which would be placed at /system/bin.
Google seems to view the NTFS-3G FUSE driver and the in-kernel NTFS3 driver with skepticism from a security perspective, which is why they're not officially supporting either.
For context, refer to this previous post.
🤯24👍10😢2
"Quick phrases" let you skip saying "Hey Google" on your Pixel for things like snoozing an alarm or answering a call. Soon, a new quick phrase may be added: notification voice replies.
Full details on this upcoming feature are available for Patrons/X subscribers.
Full details on this upcoming feature are available for Patrons/X subscribers.
👍50👎2
A recent update to Play Services (v23.33) apparently brings "improvements to Android Emergency Location Service to help call takers and first responders reduce emergency response times."
This seems like a pretty big deal, but Google's changelog doesn't really elaborate further.
Other noteworthy things in the August 2023 Google System Updates changelog:
* Guest mode setting in Settings > Google > Devices & sharing > Cast options is now deprecated.
* Password checkup and tracker alerts are being integrated into the unified security & privacy settings
* Relevant snippets from help articles will now be shown directly in the Feedback flow.
* New "Recommended" tab with "static feature recommendations in Google Settings." (I talked about this one the other day.)
This seems like a pretty big deal, but Google's changelog doesn't really elaborate further.
Other noteworthy things in the August 2023 Google System Updates changelog:
* Guest mode setting in Settings > Google > Devices & sharing > Cast options is now deprecated.
* Password checkup and tracker alerts are being integrated into the unified security & privacy settings
* Relevant snippets from help articles will now be shown directly in the Feedback flow.
* New "Recommended" tab with "static feature recommendations in Google Settings." (I talked about this one the other day.)
👍17🤨5🔥1
Google recently said that "the runtime and compiler optimizations in the ART 13 update delivered real-world app start-up improvements of up to 30% on some devices."
If you're wondering what contributed to this improvement, here's what Google said about ART optimizations in Android 13:
"
The app start-up improvements are a result of these interpreter/runtime + byte-code verification changes which rolled out last year with the ART 13 update.
Will keep an eye out on the ART repo to see what's behind the "new compiler and runtime optimizations that improve performance while reducing code size" that Google mentions the ART 14 update will bring.
If you're wondering what contributed to this improvement, here's what Google said about ART optimizations in Android 13:
"
In Android 13 (API level 33) and higher, ART makes switching to and from native code much faster, with JNI calls now up to 2.5x faster. Runtime reference processing was also reworked to make it mostly non-blocking, which further reduces jank. In addition, you can use the Reference.refersTo() public API to reclaim unreachable objects sooner, and you'll notice the interpreter is now faster thanks to optimized class and method lookups. ART also performs more byte-code verification at install time, avoiding the expense of verification at runtime and keeping app startup times fast."The app start-up improvements are a result of these interpreter/runtime + byte-code verification changes which rolled out last year with the ART 13 update.
Will keep an eye out on the ART repo to see what's behind the "new compiler and runtime optimizations that improve performance while reducing code size" that Google mentions the ART 14 update will bring.
❤27👍6
FYI: Android 14 removes the 3-minute maximum recording time on the
You can now set
Android 14's source code isn't available yet, but I reported this would be happening nearly a year ago.
(This also impacts screen recordings initiated through Android Studio.)
It's a minor change, but some of y'all might appreciate it!
screenrecord shell command.You can now set
--time-limit to 0 to remove the time limit.Android 14's source code isn't available yet, but I reported this would be happening nearly a year ago.
(This also impacts screen recordings initiated through Android Studio.)
It's a minor change, but some of y'all might appreciate it!
👍45🔥12🥰6❤1