Is this our first look at the new remote for an upcoming Chromecast with Google TV refresh?

I found a video showcasing the new remote in the latest Android TV 14 beta.

The video shows an outline of a remote that bears resemblance to the current CCwGT remote, except that it has four large round buttons on the left, two large round buttons and a third large oblong button on the right, and a new⭐️button.

Attached to this post is a still image from the video. And for comparison, I also attached a photo of the current remote for a Chromecast with Google TV (HD).

If you're wondering what that new⭐️ button might be for, I previously discovered that Android TV 14 will add "magic button" customization settings that will let you choose whether pressing the button will "open a favorite app" or "view and switch inputs for TV or other devices".

Google hasn't confirmed that a new Chromecast is in the works, but 9to5Google reported back in January, based on evidence seen within the Google Home app, that a new device was in the works.

Qualcomm has published documentation on how to prepare, optimize, and execute the Stable Diffusion model on Snapdragon 8 Gen 2-powered Android devices using Qualcomm's AI Engine Direct SDK.

They previously only had instructions on how to do this for Windows on Snapdragon devices, but now docs are live for Android as well.

You'll need a PC with a NVIDIA GPU running Ubuntu 20.04 (instructions are also available for WSL as well). There's a lot of steps involved, so I haven't tried setting this up myself yet. Let me know if you get it working!

Google has released a new version of the Android Studio IDE called Android Studio for Platform (ASfP).

Android Studio for Platform is the official IDE for Android platform development. It's intended for AOSP platform developers who build with the Soong build system.

ASfP supports C++, Kotlin, and Java and lets you configure your lunch target and platform modules from the project setup wizard.

In order to get started with ASfP, you'll need to have installed and initialized a Repo client on a Linux machine.

H/T @beachfuneral

The Play Integrity API will soon give developers a way to evaluate the "account activity" of a user. This new signal will help app and game developers detect "potentially risky and fraudulent traffic".

(Although the details of this EAP are apparently supposed to be confidential, the page documenting it all is just ... publicly available. [Thanks to @linuxct for the heads up!])

Play Integrity evaluates account activity "based on the presence and volume of store activity and the age of the accounts on the device." The API returns a level for the current user session that is "not linked to user or device identifiers." These levels include:

* UNEVALUATED: Account activity is not evaluated because the device is not trusted or the user does not have a Play app license
* UNUSUAL: Google Play store activity is unusual for at least one of the user accounts on the device. Google Play recommends checking that this is a real user.
* UNKNOWN: Google Play does not have sufficient store activity for the user account on the device. The account may be new, or it may lack activity on Google Play.
* TYPICAL (BASIC): Google Play store activity is typical for the user account or accounts on the device.
* TYPICAL (STRONG): Google Play store activity is typical for the user account or accounts on the device, with harder-to-replicate signals.

Google recommends using account activity as part of an overall anti-abuse strategy rather than as the sole determinant. Further, risky traffic should be challenged before high-value actions are allowed to proceed, rather than outright denying access.

The new account activity signal is currently under an early access program (EAP). As such, the features are in "active development and currently only available to select Play partners", such as developers in the Google Play Partner Program for Games.

Google has deleted all code related to Fast Pair from AOSP.

Fast Pair is Google's proprietary standard for simplifying the first time discovery and pairing of nearby devices over Bluetooth Low Energy. It's available on most Android devices through the Google Play Services app.

However, Google Play Services is not available on devices shipped in China, which means that Android devices in China don't support Fast Pair. Some OEMs implemented their own Fast Pair-like pairing process, but this usually only works with audio products from their own brand.

To make Fast Pair ubiquitous on Android, Google aimed to bring Fast Pair to AOSP as part of the Connectivity Mainline module. The code for Fast Pair and the HalfSheet UX (the pop-up UI that appears when a device is discovered) was uploaded to AOSP with the release of Android 13, but this code was just deleted by Google a few days ago.

I'm not entirely sure why Fast Pair was deleted from AOSP, as I don't have access to the Issue Tracker reports linked in the commit. Perhaps it saw low adoption/interest from OEMs? If you know why it was removed, send me a DM!

Apparently, Google Play Services does seem to actually be available on many Android devices sold in China. However, there are some caveats to this.

OEMs are not required to bundle GMS (Google Mobile Services) with the Android builds they distribute in China. Google Play Services and Google Play Store are part of GMS and are thus not included with AOSP builds by default. No Chinese build ships the Play Store, of course, but many do include apps like Google Services Framework and even undergo GMS certification, making it easy to sideload the Google Play Store on CN models.

And as it turns out, many OEMs seem to include the Google Play Services app in China as well. This is because while many Google services are blocked in China, not every feature/API provided by Play Services requires connecting to a Google server that can be/is blocked in the country.

CN builds of ColorOS, for example, ship GmsCore under the my_bigball partition (yes, it's really called that lol.) This allows features like Google's unknown tracker alerts to be available for users in China!

As I mentioned before, not every feature/API provided by Play Services is available to users in China. Things like Nearby Share and anything that relies on Google's location services won't work. CN builds declare the cn.google.services PackageManager flag to tell Play Services what features should be enabled on the device.

With regards to my previous post on Fast Pair, I don't know if Play Services in China supports Fast Pair. Fast Pair through Play Services connects to a Google server to sync and serve certified Fast Pair device metadata, like the image and device name shown in the HalfSheet UX.

If you live in China and have an Android phone with Play Services, let me know what does/doesn't work for you!

(Thanks to @MlgmXyysd for the heads up and for sharing the unknown tracker alert screenshots!)

Google is working on a Thread network stack for Android that will allow an Android device with a Thread radio to create a Thread network and act as a Thread Border Router. The Thread network stack is being added to the Connectivity Mainline module.

What's interesting, though, is that the Thread network service may be supported on some upcoming Android TV 14 devices, whereas for non-TV devices it'll be supported in Android 15.

However, some Googlers are hesitant to add a TV and SDK level check, as removing these checks would allow "Google and partners to enable Thread on U [Android 14] devices (such as tablets) if they backport the Thread HAL service." Apparently, some Android Partners did indeed reach out to Google asking if they can support Thread on older platforms.

Thread, by the way, is an IPv6-based wireless mesh networking technology designed for smart home/IoT devices. Thread-enabled devices join an existing home network through a Thread Border Router. Google's Nest Hub (2nd gen), Nest Hub Max, and Nest WiFi Pro can all act as Thread Border Routers.

(If you want to learn more about Thread, check out this great article on The Verge by Jennifer Pattison Tuohy.)

But with this change, this means that we may soon see devices running Android act as Thread Border Routers. Some upcoming TVs running Android TV 14 may support this, as well as some non-TV devices running Android 14 if the OEM chooses to backport the feature.