-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
Describe the bug
Account addition always fails when "Authenticate with device registration" is enabled
To Reproduce
Steps to reproduce the behavior:
- Go to 'Google Accounts'
- Keep "Authenticate with device registration" enabled (by default)
- Click Add Google Account and follow instructions to add it
- See error "Sorry.. There was a problem communicaing with Google servers. Try later"
Expected behavior
If the "Authenticate with device registration" setting is enabled, microG should either:
- Successfully register the device and add the account, or
- Clearly indicate that this option is incompatible with the current environment (e.g., due to missing DroidGuard) and prevent its use or warn the user. Also turn off it by default
Screenshots
If applicable, add screenshots to help explain your problem.
System
Android Version: 12
Custom ROM: custom aosp fork
MicroG version: v0.3.9.250932
Additional context
Log analysis reveals the key difference:
✅ When the setting is OFF:
The authentication request includes androidId=null.
→ Server responds with valid tokens (Auth, SID, LSID, Email, accountId).
→ AccountManagerService broadcasts LOGIN_ACCOUNTS_CHANGED — account is added.
❌ When the setting is ON:
The request includes a real androidId (e.g., androidId=36100077e0388ed2).
→ Server responds with Error=ServerError.
→ Account is not added.
In both cases I see in logs that, DroidGuard is unavailable (as expected in microG) and fallback is not implemented:
W GmsGuardHandleImpl: java.lang.IllegalAccessException: DroidGuard should not be available locally
W DGFallback: kotlin.NotImplementedError: An operation is not implemented: Not yet implemented
This indicates that Google’s auth backend rejects requests with a non-null androidId when DroidGuard is not present
Question:
Is this behavior intentional? Should the "Authenticate with device registration" setting be considered incompatible with account addition in current microG builds? If so, consider disabling it by default or adding a warning.