windowinsets.info

How I measure

This site is only useful if you can trust its numbers, so here is exactly where each one comes from and where it stops being reliable.

Current status: 92 of 143 devices have measured inset values from real hardware, and 23 Pixel devices have Android Emulator values. Everything else is shown as pending.

1. Every value has a source tier

  • official – published by Samsung or Google (for example resolution and pixel density on the Samsung Developer site).
  • measured – captured by InsetsProbe on a real device or on Samsung Remote Test Lab. The raw JSON is committed to the repository and linked from the value.
  • emulator – captured by the same InsetsProbe on the Android Emulator with the SDK's Pixel device profile and system image. These values show what the framework reports for that profile; they were not read from Pixel hardware. The raw JSON and a manifest with the emulator version, device profile and build fingerprint are committed next to each other.
  • community – contributed by someone else and not yet reproduced. Shown with a clear label until a second capture confirms it.

Each source also shows the date it was last checked, and each measurement records the One UI and Android version it was taken on. Emulator captures name the emulator version, device profile and system image build instead of a One UI version.

2. Why insets must be measured

Samsung publishes screen size, resolution and density, but not status bar height, navigation bar height, cutout geometry or corner radii. Those depend on the device and on the software running on it, so I read them from Android itself instead of estimating.

3. What InsetsProbe reads

InsetsProbe is a small, open-source Android app in this repository. It records:

  • WindowInsets: status bars, navigation bars, system bars, display cutout, caption bar, system gestures, mandatory system gestures, tappable element (px and dp, with and without visibility).
  • DisplayCutout: safe insets, bounding rectangles, waterfall insets, and an OS cutout path when returned (probe 1.3.0+).
  • RoundedCorner for all four corners.
  • Foldables: FoldingFeature (state, orientation, occlusion, bounds) and the hinge angle sensor.
  • Device, Android and One UI version, densityDpi next to the device's default density, font scale and navigation mode.

It prints the raw values as JSON. I do not edit these files by hand. You can build the app yourself and reproduce any number.

How captures are collected

The same probe runs in two collection harnesses. Both feed the same pipeline: raw JSON, then validation, then the published device records. The measurement harness overview explains how they fit together.

Camera cutouts: what can be measured

Cover displays support the same Android cutout APIs when the probe is running on that display. The diagram shows the reported exclusion rectangle's width, height and distances to the captured window's four edges. These are app-layout measurements, not the physical diameter of a camera lens.

For example, the verified Flip8 cover capture reports one 520 × 209 px rectangle at (428, 839) in a 948 × 1048 px window. Its edge distances are left 428, top 839, right 0 and bottom 0 px. Android groups that camera area into one rectangle; it does not identify each lens or the gap between lenses.

Android 12+ also exposes a cutout path. Probe 1.3.0+ saves it when returned, with display coordinates and a 0.25 px polyline approximation tolerance, and current raw captures include it. The site does not draw or measure the path yet: the diagram and exports use the bounding rectangle, and detailed contour dimensions remain pending. A returned path still describes the OS cutout and is not guaranteed to separate physical lenses.

A missing path in an older JSON means it was not collected. A null path in a new capture means the API did not return one. Neither is evidence of a zero-size lens. Camera artwork is illustrative; I do not infer measured lens diameters or spacing from skin pixels. Browser safe-area values cannot provide the missing geometry.

4. Conditions a measurement is valid for

  • A recorded display rotation, app in full screen (no split-screen or pop-up window). Each rotation is its own capture: phones and foldables are captured at their natural orientation, rotation 1 and rotation 3, and tablets also in reverse portrait. InsetsProbe turns itself, or the capture script locks each rotation with cmd window user-rotation lock when a large screen ignores app orientation requests.
  • Default Display size, Font size and, on Samsung, default Screen resolution. Changing them changes pixels and density, so dp values change too. The capture records densityDpi and defaultDensityDpi, which makes a non-default setting visible.
  • One navigation mode per capture (gesture or 3-button), because bar heights and gesture insets differ between them.
  • Foldables: cover and main screens are captured separately, with the fold state and, when the sensor reports one, the hinge angle.

dp is computed as px ÷ (densityDpi ÷ 160) and rounded to two decimals.

5. What I never do

  • Estimate or interpolate a value from another device or from resolution alone.
  • Fill a value from a source that cannot be linked.
  • Overwrite a measurement without keeping the earlier capture in the history.

Anything I cannot verify stays visible as pending.

6. Known limitations

  • Values can change with a One UI update. That is why every measurement names its One UI and Android version.
  • Each capture comes from a specific unit and firmware, recorded by model number.
  • Rotations without their own capture show as not measured. Insets are never rotated from another orientation. Multi-window modes are not covered yet.
  • Only tablets offer upside-down portrait. Galaxy phones and foldables leave 180° out of auto-rotation, so apps never see that orientation there.
  • Pixel values come from emulator device profiles. A profile can reuse cutout or corner geometry across models, so it may differ from the shipping phone. 19 of 22 Pixel models were spot-checked on physical devices in Firebase Test Lab (one screen and navigation mode each, on older Android versions). Those results are documented, and published Pixel values stay labelled as emulator evidence.
  • Apps can add their own padding or use different window flags, so a real app may see different insets than the raw platform values shown here.

7. Found a mistake, or want to add a device?

Open an issue or a pull request with your InsetsProbe JSON. A capture that reproduces (or contradicts) an existing one is just as valuable as a new device.