Android manages user identity, cloud synchronisation, and single sign-on credentials through its centralised AccountManagerService. Every Google Workspace account, corporate Exchange identity, enterprise MDM credential, and third-party sync provider registers an authenticator with this service. When diagnosing failed background synchronisation, orphaned account tokens, or privilege escalation vulnerabilities, inspecting the account subsystem provides immediate visibility into registered accounts, authenticator packages, and active visibility rules. Using Android Debug Bridge (ADB), system administrators and security researchers can extract diagnostic telemetry directly from the operating system kernel and framework without root access.
Understanding AccountManagerService Architecture
The Android framework decouples applications from authentication logic through the AbstractAccountAuthenticator pattern. When an application requests an authentication token, AccountManagerService queries the registered authenticator component for the matching account type. In modern Android releases (Android 8.0 Oreo and later), account visibility is governed by explicit package-level access control lists (ACLs) to prevent untrusted applications from enumerating user accounts.
The dumpsys account command interrogates this service, dumping four critical subsystems:
- Accounts per User: Enumerates accounts bound to each user profile (such as primary User 0, work profile User 10, or guest profiles), including their account type identifiers and internal database keys.
- Registered Authenticators: Lists all system and third-party services that advertise the
android.accounts.AccountAuthenticatorintent, mapping each authenticator to its hosting package and process. - Visibility Rules: Displays per-package access permissions (such as
VISIBILITY_VISIBLE,VISIBILITY_USER_MANAGED_ALLOWED, orVISIBILITY_NOT_VISIBLE), indicating which applications can detect specific accounts. - Account Sync and Token Metadata: Exposes user data keys, auth token types, and last-sync status flags stored in the system account database.
Extracting Account Subsystem Telemetry via ADB
To inspect system accounts, connect the Android device via USB or wireless debugging and ensure ADB debugging is authorised. Execute the command within a desktop terminal:
adb shell dumpsys account
The command produces structured terminal output divided by user ID and component type. On devices configured with work profiles (Android Enterprise) or multiple user accounts, the dump segments accounts by user ID:
User UserInfo{0:Owner:13}
Accounts: 3
Account {[email protected], type=com.google}
Account {name=corporate-sso, type=com.microsoft.workaccount}
Account {name=device-sync, type=com.android.local}
Registered Authenticator Types:
AccountAuthenticatorDescription {type=com.google}, ComponentInfo{com.google.android.gms/com.google.android.gms.auth.account.authenticator.GoogleAccountAuthenticatorService}
AccountAuthenticatorDescription {type=com.microsoft.workaccount}, ComponentInfo{com.microsoft.workaccount/com.microsoft.aad.adal.AuthenticatorService}
Filtering Registered Authenticators and Services
When auditing malicious or unrecognised account services, inspect the registered authenticators to determine which installed package hosts the authenticator endpoint. Use grep or PowerShell filters to isolate authenticators:
adb shell dumpsys account | grep -A 2 "Registered Authenticator Types:"
Review the ComponentInfo declaration for each entry. Authenticators running inside untrusted third-party packages or unfamiliar background services warrant immediate inspection with package management commands:
adb shell pm dump com.microsoft.workaccount | grep -E "(versionName|signatures)"
Auditing Account Visibility and Access Control Lists
Beginning with Android 8.0 (API level 26), applications cannot see accounts created by other applications unless granted explicit access. The dumpsys account output includes an extensive visibility matrix detailing which packages hold visibility privileges:
adb shell dumpsys account | grep -A 10 "Visibility:"
The output categorises visibility states:
- VISIBILITY_VISIBLE (1): The package has full programmatic visibility to query account details and request auth tokens.
- VISIBILITY_USER_MANAGED_ALLOWED (4): The user explicitly granted the application access via the account chooser prompt.
- VISIBILITY_NOT_VISIBLE (3): The account is hidden from the package; queries return empty arrays.
- VISIBILITY_UNDEFINED (0): Default state where visibility falls back to authenticator rules.
To verify which applications have requested access to a specific account type, check the visibility entries under the account’s unique identifier block.
Inspecting Account Database Sessions and Auth Tokens
When investigating authentication failures or stuck sync tokens, inspect the active session queue inside the account dump. Under the Active Sessions: section, Android lists ongoing authentication requests:
adb shell dumpsys account | grep -A 5 "Active Sessions:"
If an application repeatedly requests tokens without completing the challenge, an orphaned session will linger in this table, recording the calling package UID, the target account type, and the request timestamp. Terminating the stuck client application with am force-stop clears the hanging session:
adb shell am force-stop com.example.clientapp
Automating Account Audits in Enterprise Scripts
For fleet audits and compliance monitoring, query account summaries using a shell script that verifies whether managed work accounts are correctly provisioned across secondary user profiles:
#!/bin/bash
echo "=== Android Account Audit ==="
USERS=$(adb shell pm list users | grep -o 'UserInfo{[0-9]*' | cut -d '{' -f 2)
for USER_ID in $USERS; do
echo "[+] Inspecting User Profile: $USER_ID"
adb shell dumpsys account --user $USER_ID | grep -E "Account \{name="
done
Executing this diagnostic routine provides an automated inventory of all active user identities across personal and containerised enterprise work partitions.