Summary
eas metadata manages the Apple App Store only. eas metadata:push has no Google Play path (the CLI exposes no --platform android, and the docs state under EAS Metadata that "The Google Play Store is one of those features currently not implemented"). This forces manual Play Console work for every Android release, including the first-release app-content declarations.
The concrete, already-automatable part
Google exposes a service-account-writable endpoint for the Data safety declaration:
POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/dataSafety
{ "safetyLabels": "<contents of the Data safety CSV>" }
(scope https://www.googleapis.com/auth/androidpublisher). I verified a Play service account can write it — an invalid body returns 400 Invalid safety labels declaration, not 401/403, and a correctly-formatted CSV passes format validation. The Main store listing is similarly writable via edits.listings.
EAS Metadata could wrap these to push the Data safety declaration and the Play store listing from store.config, exactly as it already syncs Apple metadata — covering the majority of Android first-release setup friction.
Out of scope (no Google API exists)
Content rating, target audience, financial-features, and health declarations remain Console-only in Google's API, so those can't be automated by anyone today. This request is specifically about the surfaces Google does expose (Data safety + store listing).
Why it matters
For a new app's first release, the parts EAS could drive (Data safety + listing) are exactly the ones that currently require a manual Console pass. Wrapping the existing androidpublisher write APIs in eas metadata would close most of that gap for paying EAS customers.
Environment
eas-cli 21.7.x- Verified against
androidpublisher v3 (dataSafety endpoint, docs last updated 2025-05-21)
Summary
eas metadatamanages the Apple App Store only.eas metadata:pushhas no Google Play path (the CLI exposes no--platform android, and the docs state under EAS Metadata that "The Google Play Store is one of those features currently not implemented"). This forces manual Play Console work for every Android release, including the first-release app-content declarations.The concrete, already-automatable part
Google exposes a service-account-writable endpoint for the Data safety declaration:
(scope
https://www.googleapis.com/auth/androidpublisher). I verified a Play service account can write it — an invalid body returns400 Invalid safety labels declaration, not401/403, and a correctly-formatted CSV passes format validation. The Main store listing is similarly writable viaedits.listings.EAS Metadata could wrap these to push the Data safety declaration and the Play store listing from
store.config, exactly as it already syncs Apple metadata — covering the majority of Android first-release setup friction.Out of scope (no Google API exists)
Content rating, target audience, financial-features, and health declarations remain Console-only in Google's API, so those can't be automated by anyone today. This request is specifically about the surfaces Google does expose (Data safety + store listing).
Why it matters
For a new app's first release, the parts EAS could drive (Data safety + listing) are exactly the ones that currently require a manual Console pass. Wrapping the existing
androidpublisherwrite APIs ineas metadatawould close most of that gap for paying EAS customers.Environment
eas-cli21.7.xandroidpublisherv3 (dataSafety endpoint, docs last updated 2025-05-21)