Native device access

DV.Platform is how an application reaches the device it runs on: native APIs through FFI and JNI, never platform channels.

Every getter below exists in packages/dartvel_flutter/lib/dartvel_flutter.dart. Members listed as planned have no binding yet.

DV.Platform holds the native capabilities the framework registers for the current target. A desktop binds clipboard, window controls and file associations; a phone does not. A browser has a different set. Calling a capability the target lacks throws a typed error that names the missing binding.

Bindings are registered through dart:ffi (Linux, Windows, macOS, embedded) or jnigen-generated JNI (Android), and through dart:js_interop with package:web (web). No MethodChannel, EventChannel or BasicMessageChannel is used anywhere.

DV.Platform.currentPlatform   // android, ios, macos, windows, linux, web, ...
DV.Platform.isAndroid, isIOS, isWeb, isLinux, isMacOS, isWindows
DV.Platform.isTV, isWatch, isFoldable
DV.Platform.breakpoint        // desktop, tablet, mobile
DV.Platform.orientation

DV.Platform.screen.screenWidth, screenHeight
DV.Platform.screen.safeAreas
DV.Platform.window.setTitle(), .maximize(), .minimize(), .restore(), .setSize()

Every DV.Platform member is lowerCamel, like the rest of DV.*: DV.Platform.camera, DV.Platform.window, DV.Platform.fileStorage, DV.Platform.notifications. The older capitalised names (Camera, Window, Tray, FileStorage, Notifications and the rest) still compile as @Deprecated aliases for one release. DV.Platform.notifications unifies the notifications service and device-local notifications under the standard lowerCamel convention.

DV.Platform.camera, media, location, bluetooth, nfc, clipboard, share
DV.Platform.sensors, biometrics, deepLinks, haptics, contacts
DV.Platform.notifications, permissions, browserExtension, network
DV.Platform.install, display, fileStorage, device

DV.Platform.associations  // file associations
DV.Platform.dragDrop
DV.Platform.tray, Menus, Shortcuts, Printing

DV.Platform.surface        // DVRenderSurface.gui or .terminal
DV.Platform.terminal
DV.Platform.useRenderSurface(...)

DV.Platform.fileStorage    // DV.FileStorage on the device disk
DV.Platform.notifications  // proxy to DV.Notifications & local notifications

Availability per member (shipped / partial / planned). Partial means the getter exists but the underlying native binding covers only some operations or platforms.

Platforms with bindings: terminal backend linked

Platforms with bindings: all (desktop controls partial)

Platforms with bindings: macOS, Windows, Linux: separators, headers, check and radio marks, submenus, update in place

Platforms with bindings: macOS, Windows, Linux (exitPolicy explicit)

Platforms with bindings: macOS 13+, Windows, Linux

Platforms with bindings: Linux, Windows, macOS bindings; availability depends on the desktop session

Platforms with bindings: Linux, Windows, macOS native bindings

Platforms with bindings: desktop (Linux, Windows, macOS)

Platforms with bindings: Android, iOS, some web

Platforms with bindings: all: Android, iOS, macOS, Windows, Linux, embedded Linux, web (OPFS); pickers on Android, desktop and web

Platforms with bindings: Android, web; use fileStorage

Platforms with bindings: Android 31+, some others

Platforms with bindings: needs Activity / entitlement

Platforms with bindings: web, Linux, Windows, macOS (varies)

Platforms with bindings: Android, iOS, some web

Platforms with bindings: needs Activity / iOS entitlement

Platforms with bindings: needs Activity / entitlement

Platforms with bindings: all (policy framework)

Platforms with bindings: Chromium / Firefox extensions

Platforms with bindings: all (signal: online / metered / offline / unknown)

Runtime permissions are requested through DV.Platform.permissions. The framework asks at the point the capability is first called. Each permission is mapped to a policy entry in pubspec.yaml. A refusal produces a typed error.

DV.Platform.permissions.request('microphone')

A camera call checks the camera permission; a microphone call checks the microphone permission. There is no global "allow all" prompt.

DV.Platform covers what the framework registers. Going further requires native modules or direct bindings.

The framework binds native APIs through FFI (C libraries: libX11, GTK, GDBus on Linux; Win32 on Windows; CoreGraphics on macOS) and through JNI (jnigen-generated bindings on Android). Each platform file in the framework lists the bindings that are registered and the ones that are deliberately absent, with the reason stated.

No Flutter MethodChannel is used for any native integration. All bindings go through dart:ffi or package:jni, per the native integration rule.

Native UI that Flutter cannot render is embedded through platform views. Their lifecycle and routing are framework concerns; applications declare what they need.

A planned feature: selecting the render mode (hardware, software, hybrid) at build time. Selection is not yet implemented.

These members are referenced in the spec but have no binding registered today. They are listed honestly as Planned.

nfc.readTag needs Android Activity dispatch or iOS CoreNFC entitlement.

biometrics.authenticate / .canAuthenticate needs Activity (Android) or LAContext (iOS).

bluetooth.isEnabled needs runtime-granted permission since API 31.

Additional media/capture bindings requiring Activity context or specific entitlements.

Native modules via DV.Modules: mount a Dartvel module inside a native app (see /docs/adopting and the native-app section below).

GETTING STARTED

APP

DATA

BACKEND

OPERATIONS

SHIPPING

REFERENCE

Native device access

What it is

Members

Platform identity

Screen and window

Device namespaces

Desktop-only

Surface

File, storage and notifications proxies

Platform support

Permissions

Beyond DV.Platform

Native binding graph

Platform channels / FFI

Platform views

DVPreferredRenderingMode

Planned (not shipped)