Hi, I’d like to share my thoughts on how Apache Cordova should approach this new requirement. # Opinion I believe this feature should be provided as a plugin rather than being integrated directly into the core framework. However, considering the native lifecycle constraints, a completely standalone third-party plugin might face heavy limitations. My intuition suggests that a hybrid approach—where we add minimal extension points/hooks to cordova-android (core) and pair it with a new official or community plugin—would be the most realistic way forward. # Reasons I would like to divide my arguments into two distinct points: why it should not be in the core, and why we should provide a plugin solution rather than leaving it entirely to the community. [Why it should NOT be in the core] 1. Sign-In-Free Apps: Google's "Zero-Tap Sign-In" mandate applies only to apps that support a user sign-in flow. We should not force unnecessary core-level dependencies or background processes onto simple apps that do not require any login functionality. 2. Difference from Web Standards: While the Web has the Credential Management API (navigator.credentials), the Android Restore Credentials API is an OS-specific mechanism tied tightly to device migration. Its behavior and secure system storage are different from standard web-based passkey/authentication flows, making it inappropriate to integrate as a standard feature in the Cordova core. [Why Apache Cordova should provide a plugin solution (rather than leaving it entirely to the community)] 1. Infeasibility of standard community plugins: As detailed below, I am concerned that trying to implement this feature entirely through a regular community plugin—without making any modifications to the core framework—will result in an impossible or broken architecture due to native OS constraints. 2. Developer Needs: This is a platform compliance task rather than core business logic. Developers do not want to spend extensive development resources figuring this out; they want an environment where they can satisfy the requirement simply by installing an official or well-supported plugin. # Implementation Concerns & Technical Questions I have only had a quick look at the documentation, so I haven't been able to deeply consider the implementation at a code level yet. These are just my intuitive concerns, so please let me know if I am missing something or misunderstanding the official specifications. 1. The Challenge of Background Timing (Tier 1): According to Google's official documentation on the Two-Tier Restoration Architecture, this API is designed around a two-tier flow. Crucially, "Tier 1" must be executed in the background—specifically within the BackupAgent.onRestoreFinished() callback—BEFORE the user ever opens the app on the new device. (Ref: https://developer.android.com/agents/skills/identity/restore-credentials/skill#two-tier_restoration_architecture ) 2. Mismatch with Cordova's Lifecycle (onload="true" concern): At this "before the app opens" stage, neither the Cordova WebView nor the JavaScript environment is running. My concern is that even if a plugin sets in its plugin.xml, that only instantiates the Java class AFTER the WebView initializes. Therefore, standard plugin initialization will likely be completely too late for the Tier 1 timing. 3. Question for Everyone: If this intuition is correct, it will be extremely difficult to make this work properly with a completely isolated, standalone community plugin. It seems we might need cordova-android (core) to provide a base mechanism or hooks to catch native events like BackupAgent and delegate them to a plugin. Please let me know if my assumptions are wrong, or if you have any thoughts on how we can address this native lifecycle issue. Best regards, TAICHI ________________________________
2026/10/10 17:28、Dave Alden <[email protected]>のメール: Hi, I had a quick look into this and some of the Android Restore Credentials API documentation implies that a backend is involved: e.g. https://developer.android.com/agents/skills/identity/restore-credentials/skill I'm not clear from the documentation whether this is a requirement or advisory, but this should be a consideration. On Fri, Oct 9, 2026 at 10:09 PM Norman Breau via dev <[email protected]> wrote: Hi all, This is to start a discussion thread and hopefully to develop a formal consensus on how Apache Cordova should handle the upcoming requirement regarding zero-tap sign in. If you're not already familiar, Google has announced that starting April 2027, apps supporting a user sign-in flow (whether mandatory or optional) must automatically restore the sign-in state when the user migrates the app from one device to another, using the Android Restore Credentials API. The announcement can be found at https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html near the bottom, under the "Providing a secure & seamless device migration experience" header. Generally when things are add-ons, we leave that to the community to support so that Apache can focus on bridging the gaps in web features and supporting the core platform, and that could probably extend to restore credentials integration as well, because Apache doesn't provide any tools for supporting user sign-in flows either, no apache-maintained API for accessing the encrypted storage mechanism to store access tokens, but users **could** get by with using web storage. User sign-in flows is something that is very common requirement in many apps so that begs the question and I believe will start requiring app integration. So that begs the question on: 1) Whether Apache Cordova should provide a Restore Credentials Solution 2), and if so, should the solution be part of the core android framework or be a separate plugin to be installed. Or should the community take responsibility of providing the Restore Credentials integration. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
