Skip to content
Android command reference

Android wm size and wm density: what the commands actually change

Read physical and override values, understand the difference, apply one deliberate change, verify it, and reset it safely.

Reviewed July 14, 202612 minute read
Important: These are powerful shell commands. A syntactically valid value can still produce an unusable interface. Keep an authorized recovery route and record the original output first.
1

The short answer

wm size changes the display size Android renders for a chosen display. wm density changes the logical density used to map density-independent layout units to pixels. Neither command changes the physical pixel grid manufactured into the panel or creates additional physical detail.

The current AOSP WindowManager shell exposes query, override, and reset forms for both commands. Phone manufacturers can change permissions or behavior, so AOSP proves the platform surface exists—not that every retail device accepts every override identically.

2

Do not mix up four different measurements

MeasurementMeaningCan wm change it?
Physical panel resolutionThe panel's manufactured pixel matrixNo
Rendered / logical sizeThe pixel grid Android uses for compositionwm size can override it
Physical PPIPanel pixels per physical inchNo
Logical densityAndroid's scaling value for converting dp to pixelswm density can override it
3

The safe order of operations

  1. 1.Authorize ADB from a computer you control, or use a trusted app route that exposes equivalent readback and reset behavior.
  2. 2.Run the read-only size and density queries and save the complete output outside the phone.
  3. 3.Change either size or density first—not both—so the cause of a problem stays obvious.
  4. 4.Read the value back and test critical system screens.
  5. 5.Reset at the first sign of clipped dialogs, missing controls, or an inaccessible lock screen.
4

Read physical and override values

With no argument, each command prints the initial value and, when one exists, the current override. The wording matters: “Physical” or initial is the baseline reported by the system; “Override” is the forced value currently in effect.

Read-only commands

adb shell wm size
adb shell wm density
5

Apply one override and verify it

AOSP accepts width by height for size and an integer for density. Current AOSP help also exposes a display selector. Do not copy a value from another phone: aspect ratio, cutouts, OEM system UI, and the original density all matter.

After applying one value, run the matching query again. A visual change is not enough; readback confirms which layer changed.

Command shapes—not recommended values

adb shell wm size WIDTHxHEIGHT
adb shell wm density DENSITY
adb shell wm size
adb shell wm density
Important: Some current AOSP branches support -d DISPLAY_ID and density may also expose a user selector. Check wm help on the actual device before targeting anything other than the default display.
6

Reset the matching layer

Use the specific reset command for the layer you changed. This is safer than guessing the old number because it asks WindowManager to clear the forced override and return to the system baseline.

  • Reset density first if only interface scale changed.
  • Reset size first if screenshots, shape, sharpness, or the entire rendered grid changed.
  • Reboot after a successful reset and verify that no override is reported.
  • Avoid wm reset unless you intentionally want to clear the broader set of WindowManager overrides listed by your device's help.

Reset commands

adb shell wm density reset
adb shell wm size reset
7

Hands-on check on Android 17

On July 14, 2026, we ran the query, override, readback, and reset sequence on Google's Pixel 10 Pro Android Virtual Device running Android 17 (API 37). The baseline reported Physical size: 1280x2856 and Physical density: 480.

After setting density to 500, readback reported Override density: 500; density reset removed the override and returned to the physical value. After setting size to 1200x2678, readback reported Override size: 1200x2678; size reset removed that override too.

This verifies the documented command flow on current Google system software. It is emulator evidence, not a promise that Samsung, Xiaomi, OnePlus, or another OEM build exposes identical permissions or System UI behavior.

Observed readback after each temporary override

Physical density: 480
Override density: 500
Physical size: 1280x2856
Override size: 1200x2678
8

Why apps relayout after a density change

Android apps normally size layouts in dp and text in sp. Changing logical density changes the conversion to rendered pixels and can change the available dp width. An app may move between compact and expanded layouts, reload density-specific resources, or handle a configuration change while running.

That behavior is why a lower density can expose more content without changing physical resolution—and why an app with brittle fixed dimensions can clip or look wrong.

9

What the commands do not prove

  • A lower density does not prove higher touch accuracy, faster input, or better aim.
  • A lower rendered size can reduce work in some graphics paths, but it does not guarantee battery or frame-rate gains.
  • A successful default-display command does not prove external displays use the same ID or accept the same override.
  • A persistent override after reboot is not a hardware change; it remains a software configuration that should be reset through the matching layer.

Questions, answered

Frequently asked questions

Is wm density the same as changing physical DPI?+

No. It changes Android's logical density used for layout scaling. Physical PPI is fixed by panel dimensions and pixel count.

Why does wm size show both Physical size and Override size?+

Physical size is the system's initial display size. Override size is the forced rendered size currently applied. Reset clears the override rather than changing the panel.

Do wm size and wm density require root?+

They are shell commands. ADB shell can run the supported forms on many devices without root, but permissions and OEM behavior vary. A normal app needs an authorized route such as a prepared permission, Shizuku, local ADB, or root.

Sources and review notes

We favor platform documentation and original project material. Device-maker behavior can still differ, so manufacturer-specific claims are kept narrow.

  1. WindowManagerShellCommand.java

    Android Open Source ProjectCurrent AOSP implementation and help text for wm size, wm density, display targeting, and reset behavior.

  2. Android Debug Bridge (adb)

    Android DevelopersOfficial reference for the ADB client, device daemon, shell, and connection model.

  3. Support different pixel densities

    Android DevelopersDefines dp, sp, density scaling, and the distinction between density-independent layouts and physical pixels.

  4. Android 7.0 behavior changes: Screen Zoom

    Android DevelopersExplains Display size as a density configuration change and its effect on app processes.

  5. Handle configuration changes

    Android DevelopersDocuments display size and font size as runtime configuration changes.

Keep exploring