ADB

adb shell settings put and get: Reading and Changing System Settings from the Command Line

Published: July 6, 2026 Applies to: Android 4.2 and later, no root required for most settings

A lot of Android's behavior is stored as a plain key-value setting rather than buried in a UI toggle, and the settings shell command reads or writes those values directly. It is faster than navigating three levels of Settings menus for a one-off test, and it is scriptable, which matters when the same tweak needs to be applied consistently across a batch of test devices.

The Three Namespaces

Every setting lives in one of three tables, and the command requires specifying which one:

Using the wrong namespace for a given key is the most common reason a put command runs without error but has no visible effect — it silently wrote a new, unused key into the wrong table rather than updating the setting that actually controls the behavior.

Reading a Value

adb shell settings get system screen_off_timeout

Returns the current screen timeout in milliseconds. If the key does not exist in that namespace, the command prints null rather than an error, which is worth checking for explicitly in a script rather than assuming a printed value is always meaningful.

Changing a Value

adb shell settings put system screen_off_timeout 600000

Sets the screen timeout to 10 minutes. Some values take effect immediately; others (particularly in the global namespace) are only read by the relevant system service at boot or on a specific trigger event, and changing them mid-session has no visible effect until the device reboots.

A Few Genuinely Useful Keys for Testing

adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0

Setting all three animation scale values to 0 disables UI transition animations device-wide, which speeds up automated UI testing noticeably by removing artificial waits for animations that a script would otherwise need to account for with sleep calls or wait conditions.

adb shell settings put system font_scale 1.3

Useful for testing an app's layout under a larger accessibility font size without navigating the Settings UI on every test device in a suite.

Listing Every Setting in a Namespace

adb shell settings list system

Dumps every currently set key in that namespace. This is the fastest way to discover the exact key name for a setting when only the visible UI label is known, by changing the value in the Settings app once and then diffing the list before and after.

Secure Settings That Refuse to Change

Some secure namespace settings are protected even from a non-root shell and return a permission error on write, by design, since they gate security-relevant behavior like which accessibility services are allowed to run. These require either root access or, for the settings Android explicitly supports changing this way, the dedicated appops or accessibility-specific commands rather than a raw settings put call.

Resetting a Setting Back to Default

There is no single "reset to default" flag; a changed setting has to be set back to its original value explicitly, which is why it is worth recording the output of settings get before changing anything meant to be temporary, particularly for the animation scale and screen timeout values commonly adjusted during testing.

Deleting a Setting Entirely

adb shell settings delete system screen_off_timeout

This removes the key from the table rather than setting it to a specific value, which for some settings causes the system to fall back to its compiled-in default the next time it is read, distinct from setting the value to 0 or an empty string, which is still a defined value rather than an absence of one. The distinction matters for keys where an empty string and "no key present" are handled differently by whichever system service reads them.

When Root Access Changes What Is Possible

On a rooted device, the same settings command running as root can write to keys that a non-root shell is blocked from touching, since the permission check is enforced at the settings provider level based on the caller's UID rather than anything specific to the ADB connection itself. This is why some guides assume root for a particular tweak and others do not — the command syntax is identical either way, but whether it actually succeeds depends entirely on which namespace the specific key lives in and what permission level that namespace enforces.