Skip to content

Device & systemSecurity & malware

Android Settings: settings_secure, global and system

Android settings stores: settings_secure.xml, settings_global.xml and settings_system.xml, the forensic keys, ABX format and the settings command.

Location
/data/system/users/<user>/settings_secure.xml, settings_global.xml (user 0 only), settings_system.xml
Proves
Device configuration at extraction time: enabled accessibility services and notification listeners, input methods, ADB and developer options, automatic time, airplane mode, Bluetooth and Wi-Fi state, device name, screen timeout
Timestamps
No per-setting timestamps; only the file's modification time, which reflects the latest change of any setting in the file
Access
Logical (no root): adb shell settings list secure|global|system. Bugreport: settings dumps. Full file system: /data/system/users is device-encrypted, so BFU readable by a privileged extraction. Not in ADB backup.
Retention
Current values only; a changed setting overwrites the previous value, and a factory reset restores defaults
Collection
adb shell settings list secure, adb shell settings list global, adb shell settings list system, adb bugreport, Full file system extraction

What it is

Android keeps most user and system configuration in the settings provider, which stores three tables per user:

  • Secure: settings apps can read but not write, controlled by the system or by the user through Settings (accessibility, input methods, location mode, notification listeners).
  • Global: device-wide settings shared by all users (ADB, developer options, airplane mode, automatic time, device name).
  • System: user preferences apps can sometimes write (screen timeout, brightness, ringtones, 12/24-hour format).

Since Android 6 the provider writes them as XML files rather than a SQLite database, and since Android 12 most builds write them in Android Binary XML. For a triage they are a compact checklist: is an accessibility service enabled, is something reading notifications, was ADB on, was automatic time disabled.

Where it lives

ItemPathNotes
Secure/data/system/users/<user>/settings_secure.xmlPer user
Global/data/system/users/0/settings_global.xmlOwner only
System/data/system/users/<user>/settings_system.xmlPer user
Per-app Android ID/data/system/users/<user>/settings_ssaid.xmlSSAID values
Device config/data/system/users/0/settings_config.xmlServer-pushed feature flags
Legacy/data/data/com.android.providers.settings/databases/settings.dbPre-Android 6 or leftovers on upgraded devices

OEMs add their own keys to the same files (Samsung builds carry many One UI specific ones); the file layout stays AOSP. Verify key names on your build before relying on one.

What it proves

Secure keys:

  • enabled_accessibility_services, accessibility_enabled: which accessibility services are on.
  • enabled_notification_listeners: apps reading every notification.
  • default_input_method, enabled_input_methods: the active keyboard, a classic keylogger vector.
  • location_mode or location_providers_allowed, notification_history_enabled, android_id on old releases.

Global keys:

  • adb_enabled, development_settings_enabled, adb_wifi_enabled: debugging state at extraction.
  • auto_time, auto_time_zone: whether the clock was set by the network or manually, important when a user may have changed the time.
  • airplane_mode_on, bluetooth_on, wifi_on, device_name, package_verifier_enable.

System keys:

  • screen_off_timeout, time_12_24, screen_brightness_mode.

Key fields

Each entry is a <setting> element:

AttributeMeaning
idSequence number, increasing as settings are written
nameSetting key
valueCurrent value
packagePackage that last wrote it (android, com.android.settings, an app)
defaultValue, defaultSysSetDefault and whether the system set it
tagOptional tag used by restore logic

The package attribute is valuable: a secure setting written by a third-party package instead of com.android.settings deserves a closer look.

Timestamps

There are none per setting. The file modification time shows when the file was last written, which is the last change to any key in it. The id attribute increases with writes, so a high id on enabled_accessibility_services compared with its neighbours suggests a recent change. Date that change with usagestats (the Settings app in the foreground) and install times.

adb shell settings list secure | sort > settings_secure.txt
adb shell settings list global | sort > settings_global.txt
adb shell settings list system | sort > settings_system.txt
grep -E 'enabled_accessibility_services|enabled_notification_listeners|default_input_method' settings_secure.txt
grep -E '^adb_enabled|development_settings_enabled|auto_time' settings_global.txt

Retention

Only current values are stored. The previous value of a setting is not kept, except as residue in older file copies (.bak or -backup files written during an interrupted save) or in logs. A factory reset restores defaults.

Collection

  • Logical: the settings list commands above, as early as possible and before you enable anything else (enabling ADB itself changes adb_enabled).
  • Bugreport: includes a settings dump.
  • Full file system extraction: the XML files with their timestamps, plus any backup copies next to them.

Parsing

  • abx2xml on a device, or ccl_abx offline, converts Android 12+ binary files; then xmllint or Python ElementTree.
  • ALEAPP reports selected settings.
  • MVT checks settings for risky configurations (for example disabled package verification) during check-adb or bugreport analysis.

Investigator tips

  • Record that you enabled Developer options and ADB yourself, so adb_enabled=1 and a recent file time are not misread.
  • auto_time=0 means the user or an app set the clock manually: re-examine every local timestamp against a network-derived source.
  • Cross-check enabled_notification_listeners and accessibility keys with runtime permissions and appops for the same packages.
  • The malware triage guide lists the settings stalkerware usually needs.

See also