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

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 (/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.)

FYI: Android 14 removes the 3-minute maximum recording time on the 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!

Rant: Google Play's warning that users can't download certain apps because they're "made for an older version of Android" has issues.

While this is done to ensure that users only install apps that abide by the latest privacy & security features of Android, it has some unintended consequences.

First of all, a bit of context. Back in April 2022, Google announced that it would expand Play's target API level requirements to "strengthen user security". Google said that "existing apps that don’t target an API level within two years of the latest major Android release version will not be available for discovery or installation for new users with devices running Android OS versions higher than apps’ target API level."

(Target API level determines what app-facing system behaviors the app is affected by. An app that targets API level 33 is affected by system behaviors of Android 13.)

* Since November 1, 2022 (or May 1, 2023 if the developer requested an extension), an app that targets API level 29 (Android 10) or lower can't be discovered or installed by new users with devices running an Android OS version higher than the app's target API level.
* Starting August 31, 2023 (or November 1, 2023 if the developer requests an extension), this will extend to apps targeting API level 30 (Android 11).

While in many ways this makes things more secure overall for users, as apps targeting older API levels aren't subject to a lot of the privacy & security restrictions introduced by newer Android versions, simply telling many users on Google Play they can't install an app isn't going to stop them from trying.

In fact, as pointed out by @phhusson, it may even lead to an increase of users downloading potentially dangerous versions of apps from sketchy websites. If you Google the error message, for example, you'll find threads on Reddit and elsewhere suggesting you to sideload the app. Google's generative AI response even recommends you sideload the app!

(1/2)

So this makes me think: Why not just add an "install anyway" button on Google Play (after the user acknowledges the warning)? If the app is malicious or harmful, it should just be removed. Otherwise, just inform the user about potential issues and let them make their choice.

This is not a wild suggestion. Android itself already warns users when they try to run an app that targets older API levels. (The threshold for this warning to appear was bumped from API level 23 in Android 13 to API level 28 in Android 14.)

Android 14 also has an additional protection layer in the form of the minimum installable target API level. The OS won't let you install apps that target an API level older than 23, which is when runtime permissions were introduced.

Obviously, most users won't be running Android 14+ for a while, so Google Play's target API level changes protects older users in the interim. But still, if the app is on Google Play, it should be downloadable. If it's malicious, then remove it. If it's simply outdated and thus not using the latest security features, just warn users. Maybe make it so discoverability limitations apply to apps targeting API levels < 30, pre-install warning dialogs appear for apps targeting API levels < 28, and hard installation limitations only apply to apps targeting API levels < 23, matching Android 14's behavior.

"Well, these developers should just update their apps!" A lot of indie app and game developers barely make money from their projects or just do it out of passion. They may not make a lot of money for Google Play, but they should simply not be rewarded (through favored discoverability/search rankings) for not updating their apps rather than punished. Lots of games and useful apps (like the "My Sensors" one, which a LineageOS developer tried to install for testing something) don't need yearly updates.

(2/2)

How to make your Android widget display on the cover screen of the Samsung Galaxy Z Flip 5

A recent blog post by developer Akexorcist shows how to make your app's widget appear on the outer display of the Galaxy Z Flip 5.

The Galaxy Z Flip 5 has a 728x720 resolution outer display measuring 3.4" diagonally, which is much larger than on last year's model. However, by default, only select app widgets can appear on the cover screen.

Samsung, for whatever reason, hasn't published official documentation yet on how to do this, so Akexorcist said they had to decompile the Good Lock app to find out how this works.

You can read their blog post here.

(If you're a user, you can either use the MultiStar module [part of the Good Lock suite] or the third-party CoverScreen OS app to force unsupported app widgets to appear on the cover screen.)

What will the upcoming "Watch Unlock" feature do and how is it different from Smart Lock > Trusted devices?

I still see a lot of confusion about Watch Unlock, which is set to come to the Pixel Watch, Galaxy Watch 6 series, and other devices, so here's what you need to know.

For a bit of context, Android supports a few authentication methods.

Primary authentication methods include PIN, pattern, or password. Primary authentication can be used to unlock the device or authenticate within apps.

Biometric authentication methods include fingerprint, face, and iris. Biometric authentication methods are classified into three tiers: Class 3 (formerly Strong), Class 2 (formerly Weak), or Class 1 (formerly Convenience). While all 3 can be used to unlock the device, only Class 3 and Class 2 biometrics can integrate with BiometricPrompt (ie. authenticate within apps). No matter what, though, you'll eventually have to fall back to primary authentication to unlock the device (72 hours if you've been using a Class 3 biometric, 24 hours for Class 2 or Class 1).

Finally, there are Trust Agents. Trust Agents cannot unlock the device. They can only extend the unlock duration for a device that is already unlocked. In other words, they just keep your device unlocked for longer.

You may already be familiar with "Smart Lock". It's been around for years as part of Google Play Services, and it's what's considered a Trust Agent. Smart Lock offered multiple ways to keep the device unlocked for longer: on-body detection, trusted places, trusted faces (before Android 10), and trusted devices.

Trusted devices is what many people are confusing with Watch Unlock. They are not the same. Trusted devices lets you pick a connected Bluetooth device (like your smartwatch) to extend the duration your phone is unlocked for. In other words, after you manually unlock your phone using either a primary or biometric authentication method, your connected smartwatch will keep your phone unlocked.

(1/2)