Docs

Why this exists

Apps targeting Android 15 (SDK 35) draw edge to edge by default, and apps targeting Android 16 (SDK 36) can no longer opt out. Every app now has to handle insets itself, but few teams own enough devices to see what those insets actually are.

Check how your layout meets the system UI on devices you don't own, before you ship.

Problem	What this site gives you
A bug report says a button is hidden on a device you don't have, such as a Flip cover screen.	Pick the device, screen, rotation and navigation mode, and see the recorded insets and cutout. No device purchase or Remote Test Lab session needed.
Landscape was tested in one direction only.	Rotation 1 and rotation 3 are separate captures, so you can see which side the camera cutout lands on.
QA covers gesture navigation but not three-button navigation.	Each screen is captured in both navigation modes.
A Samsung skin in the emulator looks right, but it only changes the frame, not One UI's bars, cutout or corners.	Samsung values come from real devices or Samsung RTL. Pixel values are clearly labelled as emulator evidence.
Designers need safe margins for foldable cover and inner displays.	Cover and inner displays each have their own insets, corner radii and cutout bounds, in dp and px.

Common objections

"Can't I just read insets at runtime?" Yes, and your code should. The API tells your app what it receives on the device it is running on. It cannot tell you, before release, what it will receive on devices you never tested. Use this site for design, test planning and reproducing reports, not as a replacement for the API.

"If insets are handled correctly, why do the numbers matter?" Your code may not need them. The people you build with often do: designers and frontend developers find safe areas and insets hard to picture from a description. A diagram of a real device, with its status bar, navigation bar, cutout and corners in place, gives everyone the same picture to point at.

"Can't an AI answer this?" An AI can explain WindowInsets and write the handling code. It cannot reliably tell you the navigation bar inset on a specific Galaxy cover screen in rotation 3 with three-button navigation. Nobody publishes that number; it has to be measured, and a model asked for it will give a plausible guess. Every value here links to a raw capture you can check, and missing values stay pending instead of being guessed. AI tools can use the JSON export as ground truth too.

"Why not use Remote Test Lab or buy the devices?" Each RTL session costs credits and minutes per device, screen, rotation and navigation mode. This project has done that work once and published the results for everyone.

Use the data

Look up any device from the terminal, or pull measured values into your tests, with the windowinsets-info CLI (Node.js 18.3+):

npx windowinsets-info get s26-ultra --nav gesture
npx windowinsets-info fixtures --series fold > insets.json

Each device also has a Markdown reference at /<slug>.md (the Markdown button in the Metrics panel). The same data is plain JSON: /data/<slug>.json per device, /data/index.json for the list and /data/all.json for everything at once (see JSON export format). AI tools can start from /llms.txt.

New to insets? The developer guide covers the basics, Compose and View code, foldables, common patterns and using this data in your code. Data and site updates are listed in the changelog (RSS).

Fold it. Measure it.

Explore Galaxy Fold, Flip and TriFold hinge states in real-time 3D, built with Three.js and WebGL. Rigid housings and articulated hinges show the folded depth. Official Samsung display artwork and exterior SVG rulers follow the fold.

0° → 180° → 0° · These recordings use a fixed perspective camera and zoom throughout each fold. The Flip cover sits on the upper half's rear; the Fold cover sits on the left half's rear.

TriFold opens the right hinge first, then the left. Closing reverses that order: the inner display faces forward until the right wing nearly closes, then the middle panel's rear cover faces forward.

Try the hinge slider, drag to pan, or pinch to zoom on windowinsets.info.

The animation illustrates device geometry. Insets remain the recorded Android measurements for the selected cover or inner display; moving the hinge does not create new measurements.

Documentation

Start with this README for the product, data limits, device priorities and local development. The other documents have narrower purposes:

Need	Document
Match the reference UI and understand intentional Android differences	Reference parity
Capture insets, check data quality and find the remaining measurement queue	Measurement workflow
Check which models and official skins belong in the catalogue	Device coverage
Check RTL credit policy and reservation budget	RTL credits
Compare physical Pixel Test Lab captures with emulator data	Pixel hardware validation
Set up the probe's capture inbox	Capture upload
Launch the probe on a Flip cover display	Probe FlexWindow guide
Consume the downloadable device data	JSON export format
Configure and interpret site analytics and the daily Discord report	Analytics
Set up search indexing, analytics consoles and funding for a site launch	Web operations
Keep the client bundle small and re-measure it	Frontend performance
Check asset attribution	Third-party notices

The InsetsProbe guide covers the Android app itself. Asset and test instructions stay next to their files in public/skins/, public/fonts/, design/brand/, docs/media/ and tests/.

Device thickness and artwork limits

Samsung's Galaxy Emulator Skin guide describes skins as the appearance and controls of an Android virtual device. The bundled skins have flat device.png and foreground.png artwork. Their layout gives the screen rectangle and button positions, but no depth, side profile or 3D mesh.

Depth comes from Samsung's published dimensions for Fold8, Fold7, Flip8 and the original Galaxy Fold. Open-body dimensions set each panel's thickness. Folded thicknesses of 9.7, 8.9, 13.1 and 17.1 mm respectively set the closed depth; the remaining gap between panels becomes the display's bend diameter.

The hinge barrel's cross-section, side curvature and the shape at intermediate angles are still not published, so they remain illustrative, not CAD-accurate. TriFold and other models without sourced dimensions keep an illustrative thickness and gap.

Stack

The site uses React, TypeScript, React Router (framework mode) and Tailwind CSS. Build-time prerendering (ssr: false + prerender) produces a static site.

• Three.js + WebGL: textured displays, a lit solid chassis, and continuous hinge geometry for both book and clamshell folds.
• SVG measurement overlays: display dimensions, safe-area insets, cutout bounds and corner radii projected from the same 3D transforms, with readable screen-space labels.
• Synchronized interaction: cover/inner metrics follow the rendered hinge angle; automatic fit, manual pan/zoom and reduced-motion support share the same view state.
• Rendering fallback: flat endpoint backing protects against transparent WebGL compositing; an SVG diagram remains available when the WebGL context fails.

Rendering lives in FoldRenderer3D.tsx, foldGeometry.ts and ProjectedRulers.tsx. See device thickness and artwork limits for the boundary between published dimensions and illustrative geometry.

Device coverage and priorities

Samsung target coverage (WIP): Every Galaxy model released in 2020 or later with an official Galaxy Emulator Skin, plus every Galaxy Fold and Flip with an official skin regardless of release year. This includes discontinued models and the Galaxy A and Note series; flagship status does not affect eligibility. See release evidence and archive policy.

1. Improve the current Galaxy S, Z Fold and Z Flip experience.
2. Improve Galaxy Tab coverage.
3. Expand Galaxy Note and Galaxy A coverage; neither series takes priority over the other yet.

Galaxy Z TriFold has official cover/inner artwork and a sequential two-hinge 3D animation. Main and cover insets are verified in both navigation modes. See TriFold scope.

An official skin permits an artwork preview, not a claim of verified inset data. Devices without captures remain marked Skin preview / pending until measured. Coverage is still in progress; this target is not a claim that every eligible model has already been imported or measured.

Google Pixel coverage includes all 22 in-scope SDK profiles: every Pixel released in 2020 or later with an Android Emulator skin, plus every Pixel Fold. These entries use AOSP skins and Android Emulator captures. They are labelled as emulator evidence, not Pixel hardware measurements. See Pixel coverage.

Galaxy Watch limitation

The Samsung Galaxy Emulator Skin downloads checked on 2026-09-25 contain no Galaxy Watch skins. Galaxy Watch4 and later use Wear OS, so Android WindowInsets can be measured. The current InsetsProbe workflow and device model, however, assume phone navigation modes and cannot represent a watch's round-screen safe area.

The separate Wear OS probe module computes the safe square inside a round window but does not capture or export measurements yet. Galaxy Watch support still needs traceable artwork and a measurement path for round-screen safe areas. Until then, watches stay outside the public catalogue; no values are inferred from product images.

The FTL catalog checked on 2026-09-28 offers a physical Pixel Watch but no Galaxy Watch. Test Lab also does not supply device-skin artwork. See Galaxy Watch platform history and Android's Wear OS screen-shape guidance.

Adding a device

Samsung Galaxy

1. Run python3 scripts/import-samsung-skins.py /path/to/downloads to copy the original artwork and register main/cover screens in app/data/skinCatalog.json, including TriFold. Before publishing, check each model against the 2020 release cutoff (except Fold/Flip). Record boundary and older models in app/data/coverage.ts, with sources in docs/DEVICE_COVERAGE.md.
2. For RTL data, keep raw JSON in measurements/<series>/<device-slug>/, then create app/data/devices/<slug>/index.ts implementing Device (see app/data/types.ts).
3. Register that entry in verifiedEntries in app/data/devices.ts using the existing preview slug. Its screens override preview data; additional skin-only screens stay pending. Routes, sitemap and prerendering use the merged catalogue.

Current public catalogue: 143 models — 120 Galaxy (29 S, 29 Tab, 9 Fold, 8 Flip, 1 TriFold, 3 Note, 41 A) and 23 Pixel. Of the Galaxy models, 78 have verified real-device or RTL insets (21 S, 14 Tab, 8 Fold, 8 Flip, 1 TriFold, 2 Note, 24 A).

All 23 Pixel entries have emulator captures. Physical FTL spot checks remain separate evidence and do not change their published source. The Samsung skin archive retains 126 models; seven pre-2020 models stay outside the public catalogue. Galaxy A52s 5G is public from RTL captures without an official skin.

Fold/Flip entries have static main/cover previews where supplied, and models with a main skin have hinge animation. Models without captures remain previews with pending insets.

Google Pixel

1. Add the model, official Google display specification source and SDK profile to scripts/pixel-devices.json.
2. Keep the probe's raw JSON and manifest.json in measurements/pixel/<slug>/emulator-<date>/.
3. Run python3 scripts/import-emulator-captures.py <slug> to validate rotation-0 captures, copy the AOSP skin and regenerate the Pixel modules.

Keep emulator provenance separate from real-device evidence; missing measurements stay pending. For a hardware comparison, preserve the raw Test Lab result under testlab-<date>/ and record the physical model, build, screen and test matrix. See Pixel hardware validation.

Support

If this saved you a device purchase or an RTL session, you can star the repository, buy me a coffee on Ko-fi or sponsor on GitHub.

Development

See the reference parity notes for design decisions and implementation details.

• Samsung artwork and layout coordinates: public/skins/ and app/data/skins.ts.
• Pixel artwork: AOSP emulator skins and app/data/aospSkins.ts (Apache 2.0; see third-party notices).
• Geometry and asset tests: node --test tests/rendering.test.mjs.
• Changelog (/changelog, /changelog.xml): Data entries come from feat/fix commits (scope none, data or devices) that touch app/data/devices/; Site entries come from main's first-parent history (merged PRs by title, direct feat commits) that touch app/ or public/. pnpm build refreshes it; run pnpm changelog on main and commit app/data/changelog.json so shallow deploy clones keep older entries. Hide or reword an entry by hash in app/data/changelog-overrides.json.