Skip to content
Blog

Display Corner Radii: How Flutter Reads Your Android Device's Hardware Screen Shape

Flutter 3.44 exposes Android hardware display corner radii through MediaQuery, so edge-to-edge UI can follow the real curvature of the screen instead of assuming square corners.

Published on • October 29, 2026

AI Assistant

Modern Android hardware does not have square screens. Flagships ship with aggressively curved corners — and a display notch or punch-hole to go with them. For years, a Flutter app drawing content flush to the viewport had no way to ask the device how round the actual glass was, so anything positioned near a corner could sit inside the curved region and get visually clipped.

Flutter 3.44 changed that. As part of the release’s Android support, Flutter now queries the physical and logical corner radii of the device’s display directly from the hardware and exposes the result through MediaQuery.

In this post you will learn what the new API returns, why it matters for edge-to-edge layouts, how to consume it safely in a widget tree, and what to do on platforms where the value is simply not there.

What shipped in Flutter 3.44

The What’s new in Flutter 3.44 post describes the feature under Android support:

To help you build pixel-perfect layouts on modern mobile devices, Flutter now integrates directly with Android hardware to support display corner radii (#179219). Flutter can now query the physical and logical corner radii of the device’s display and expose this information through MediaQuery. This allows your UI to accurately respect the hardware’s geometry, ensuring content is never clipped on aggressively rounded screens.

The community summary at DEV Community puts the same point more bluntly: Flutter “reads display corner radii from Android hardware through MediaQuery, which helps on aggressively rounded screens.”

Two numbers, two units. The distinction matters:

MediaQueryData.displayCornerRadii

final BorderRadius? displayCornerRadii;

The radii of the display corners in logical pixels. This is currently populated only on Android API 31+. On earlier Android versions, iOS, and other platforms, this value is null.

Logical pixels are the device-independent pixels Flutter layouts are already written in — so this is the one you use directly in widget code.

FlutterView.displayCornerRadii

DisplayCornerRadii? get displayCornerRadii;

The radii of the display corners in physical pixels. This is currently populated only on Android API 31+. On earlier Android versions, iOS, and other platforms, this value is null.

The backing type, dart:ui.DisplayCornerRadii, is a simple record of four doubles — topLeft, topRight, bottomRight, bottomLeft — and its documentation notes that “if a corner is square (not rounded), the radius is 0.0.”

Use the MediaQuery form for layout; reach for the FlutterView form when you are doing pixel-level work with a devicePixelRatio conversion.

Why this matters for edge-to-edge UI

Since Android 15, edge-to-edge is the default posture: apps draw behind the status and navigation bars, and system bars float over content. Flutter already helps you avoid the cutout — SafeArea and MediaQuery.padding account for notches, punch-holes, and gesture insets.

Corner curvature is a different problem. MediaQuery.padding tells you how much space the system chrome occupies; it does not tell you the radius of the glass in the top-left corner. On a device with a 60–80 logical-pixel corner radius, an icon or a trailing action button placed 8 dp from the top-left edge can land entirely inside the curved region and be cut off, even though the layout is “correct” by every measurement Flutter gives you.

That is exactly the class of bug displayCornerRadii is designed to eliminate. Typical uses:

  • Corner-aware insets — add extra breathing room in the corners where the hardware curves sharply, beyond what SafeArea provides.
  • Shaped scrims and gradients — clip a background scrim, header, or bottom sheet to the real hardware radius so it visually meets the curve instead of overshooting it.
  • Edge-aligned decorative elements — progress rings, glow effects, and floating action buttons that hug the viewport edge.
  • Custom system-bar treatment — colouring or shaping the area behind translucent bars so no content sits in a dead corner.

Consuming it in a widget tree

The important design decision is that the value is nullable. Never dereference it unconditionally. Give yourself a single access point with a defined fallback:

import 'package:flutter/material.dart';

/// Returns the hardware display corner radii, or [BorderRadius.zero]
/// on platforms and OS versions where Flutter can't provide them.
BorderRadius displayCornersOf(BuildContext context) =>
    MediaQuery.of(context).displayCornerRadii ?? BorderRadius.zero;

class EdgeToEdgeHeader extends StatelessWidget {
  const EdgeToEdgeHeader({super.key, required this.child});

  final Widget child;

  @override
  Widget build(BuildContext context) {
    final corners = displayCornersOf(context);

    // Give icons a little extra room only where the glass actually curves.
    final inset = corners.topLeft.x > 0 ? 20.0 : 8.0;

    return Padding(
      padding: EdgeInsets.fromLTRB(inset, inset, inset, 0),
      child: ClipRRect(
        borderRadius: corners == BorderRadius.zero
            ? BorderRadius.zero
            : BorderRadius.only(
                topLeft: corners.topLeft,
                topRight: corners.topRight,
              ),
        child: child,
      ),
    );
  }
}

A few practical notes:

  • Read it through MediaQuery.of(context) (or a didChangeMetrics/didChangeDependencies override) so the widget rebuilds if the metrics change — foldables and multi-window can move your app to a different physical display.
  • Do not confuse window size with display size. Flutter’s large screen guidance is emphatic that MediaQuery gives you the window size, which is what you should layout against, because multi-window mode can render your app into a space smaller than the physical display. The physical Display object — and by extension hardware corner geometry — is one of the few cases where the physical display is the right reference.
  • Keep the effect subtle. Corner radii are a hardware hint, not a layout constraint. Use them to nudge insets and shape overlays, not to rebuild your grid.

Fallbacks: iOS, older Android, and everything else

The null case is the normal case on most of the ecosystem, so design for it explicitly:

Platform / conditiondisplayCornerRadii
Android, API 31 (Android 12) or newerPopulated
Android, API 30 or oldernull
iOSnull
Web, Windows, macOS, Linuxnull

Three consequences worth internalising:

  1. Your null path is the shipping path for a large share of users. It must look intentional, not broken. BorderRadius.zero plus standard SafeArea behaviour is a perfectly good default.
  2. iOS does not get this API. Apple exposes corner geometry differently, and Flutter documents displayCornerRadii as Android-only today. On iOS, continue to rely on SafeArea, MediaQuery.padding, and your own design-time constants.
  3. Verify on device. Because the value depends on the OS version at runtime, an emulator on the wrong API level will report null and make your implementation look broken when it isn’t. Test on an Android 12+ device with a visibly rounded panel.

Conclusion & Next Steps

Flutter 3.44 gives your app something it never had before: ground truth about the shape of the glass it is drawing on. MediaQueryData.displayCornerRadii reports each corner in logical pixels, FlutterView.displayCornerRadii reports the same geometry in physical pixels, and both are deliberately nullable so non-Android and pre-Android-12 targets degrade to the behaviour you already ship.

Next Steps: add a single displayCornersOf(context) helper with a zero-radius fallback, use it to shape one edge-aligned element such as a header scrim or corner icon, then test on a rounded Android 12+ handset and on iOS to confirm the null path renders identically.

Sources

flutter-android edge-to-edge mediaquery display-corner-radii flutter-3-44