Google Play will require apps that support user sign-in (optional or mandatory) to automatically
restore sign-in state on device-to-device migration, via the Android Restore Credentials API.
Games are exempt. Announced 2026-08 on the Android Developers blog:
https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html
Nine Lives is not a game and ABS server login is mandatory, so on paper we are in scope.
Where we stand today
We deliberately do the opposite. app/src/main/res/xml/data_extraction_rules.xml excludes
nine_lives_secure_prefs.xml from BOTH cloud-backup and device-transfer, and
backup_rules.xml excludes it for API < 31. A user moving to a new phone re-enters the server
URL and their credentials. That was the correct call for a bearer token pointed at a server we
do not control. Play is about to score it as a defect.
The structural problem
Restore Credentials assumes a backend that can mint and validate a restore key. Our "backend" is
whatever Audiobookshelf instance the user runs, and ABS has no such endpoint. The sanctioned
implementation does not exist for a self-hosted client.
Options (no work authorized yet)
- Migrate the non-secret half (server URL + username) through device-transfer, leave the
password/token excluded. New device lands on a pre-filled login instead of a blank one.
Cheap, and probably a defensible good-faith answer.
- Wait for the actual policy text. "Supporting user sign-in" reads like it was written for
first-party-account apps. There may be a carve-out for clients authenticating to user-owned
servers.
- Full Restore Credentials against ABS, which means landing a restore-key endpoint upstream in
Audiobookshelf. Not ours to start unilaterally.
Next action
Re-read the policy when Google publishes the real language (expected before the April 2027
enforcement date), then pick an option. Jeff explicitly declined a prototype for now.
Google Play will require apps that support user sign-in (optional or mandatory) to automatically
restore sign-in state on device-to-device migration, via the Android Restore Credentials API.
Games are exempt. Announced 2026-08 on the Android Developers blog:
https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html
Nine Lives is not a game and ABS server login is mandatory, so on paper we are in scope.
Where we stand today
We deliberately do the opposite.
app/src/main/res/xml/data_extraction_rules.xmlexcludesnine_lives_secure_prefs.xmlfrom BOTH cloud-backup and device-transfer, andbackup_rules.xmlexcludes it for API < 31. A user moving to a new phone re-enters the serverURL and their credentials. That was the correct call for a bearer token pointed at a server we
do not control. Play is about to score it as a defect.
The structural problem
Restore Credentials assumes a backend that can mint and validate a restore key. Our "backend" is
whatever Audiobookshelf instance the user runs, and ABS has no such endpoint. The sanctioned
implementation does not exist for a self-hosted client.
Options (no work authorized yet)
password/token excluded. New device lands on a pre-filled login instead of a blank one.
Cheap, and probably a defensible good-faith answer.
first-party-account apps. There may be a carve-out for clients authenticating to user-owned
servers.
Audiobookshelf. Not ours to start unilaterally.
Next action
Re-read the policy when Google publishes the real language (expected before the April 2027
enforcement date), then pick an option. Jeff explicitly declined a prototype for now.