Google Play has just announced a couple of new policies. Here's a summary of what they announced:

1) A new blockchain-based content policy that states that devs must complete a declaration for apps that enable users to transact blockchain-based digital content. Additional requirements apply for NFT gamification. Google's blog post on this particular change.

2) Apps that run "On-device Android Containers" will be required to respect the new REQUIRE_SECURE_ENV flag, indicating that they don't want to be run in an On-device Android Container.

I believe this refers to apps like Virtual Android and VMOS on Google Play, which run Android in a container. Google believes apps should be able to opt out of running in containers, hence this new flag.

3) New guidelines to their Deceptive Behavior policy to provide guidance on "non-transparent behavior." Basically, Google's making it clearer what they mean when they say developers can't engage in non-transparent behavior. Devs must make their app's functionality clear to users.

4) Expanded verification: when you create a Play Console account for an organization, you'll need to provide a D-U-N-S number. Further, Google will share more developer details on your app's store listing page.

This will roll out starting August 31 for anyone creating a new Play Console developer account. More details will be shared in October for existing developers. Google's blog post.

5) All apps that offer financial features must complete the declaration form. These apps may need to submit supporting documentation as well. This takes effect August 31.

6) The Request Install Package Permission policy has been expanded to allow companion apps used to sync Android phones to wearables or IoT devices.

ICYMI: the Amazon Appstore on Windows 11 is now generally available for all developers. This means anyone can submit their app to the Amazon Appstore for users with the Windows Subsystem for Android (WSA) to download.

WSA is how I currently post to Threads* from my PC. The Threads app isn't available on the Amazon Appstore, though, so I had to sideload the APK. A program called WSA Tools makes that easy, but you can also just do adb sideload.

The latest version of WSA also makes it easy to share files between your PC's local storage and Android. Any files in C:\Users\{profile} will be indexed by Android.

WSA is pretty niche right now, but it's yet another (albeit one that's not Google endorsed) large screen Android platform to optimize for, alongside tablets, book-style foldables, Chromebooks, and Play Games for PC.

*Just to warn you, there are some strange bugs when using the Threads app on WSA, including the fact that videos you upload get flipped upside down. This has also been happening with the Instagram app, apparently. That WSA now indexes your entire home directory can also be problematic, especially if you've got tons of files and you're dealing with an app that doesn't use the system file picker/photo picker (like Threads). You'll have to either move a lot of files or add .nomedia everywhere.

I was curious about the status of "satellite" support in Android 14 since Hiroshi said this last year, so here's a quick update on what I think is happening.

* The satellite HAL APIs won't be present in the initial release of Android 14, but they could end up in Android 14 QPR1 or a later QPR.

(I don't know if the Pixel 8 will support satellite connectivity, so please don't ask.)

* The framework telephony APIs might have also been punted to a QPR. They won't appear as public APIs in Android 14 simply because it's too late. But it seems Google plans to add an "official API" (maybe public?) in Android 15, at least for some things like these Settings table values.

* Some things were left in the current/initial Android 14 release, like the SATELLITE_COMMUNICATION and BIND_SATELLITE_SERVICE permissions. But there's nothing for even a system dialer/messaging app to hook into

Google has shared how they'll migrate users from the old Play Store version of Health Connect to the new system version in Android 14.

Health Connect is being integrated into the OS as a new Mainline module that's updatable through Play System Updates.

The migration plan is as follows:

1) Once users update to Android 14, the Play Store version of Health Connect will become inactive.

2) The Jetpack Health Connect library will route the user to the system (module) APIs and block them while data migration is in progress.

3) The migration process starts when the system and Play Store versions are feature compatible. Both permissions & data will be migrated. The Play Store version may need an update to become "migration aware", whilst the system version may need one to become "feature compatible".

4) The migration process will commence. Once it's happening, the system (module) APIs will be suspended with a "migration in process" status. If this process is suspended, it can be resumed by the user.

Data migration "is not expected to exceed 2 hours." For example, migrating 10 years of running records collected 1 hour every day would take ~4s. Migrating 5 years of heart rate data collected every minute would take ~15 mins.

During migration, the system version will ignore any duplicate permissions or data originating from the Play Store version, in case it started to acquire data and permissions before any migration or cloud-based restore (not announced!) has taken place.

5) After data migration has completed, the user can uninstall the Play Store version. (On Pixels and the Nothing Phone 2, though, the Play Store version of Health Connect is preinstalled as a system app, so it can't be uninstalled outside of an OTA update.)

OEMs can create a RRO to style the data management and permissions screens for Health Connect. This should be done to bring the app's UI in line with the rest of the OEM's skin.