Native Device APIs

The native framework exposes Android device capabilities three ways — the page picks whichever fits the shape of its code: state bindings recompose automatically, callbacks hand results to vesk cells, and markup elements compile directly to native composables.

Access patterns

• **A — state bindings**: `device.lastPhoto` reads drive recomposition. Use for values that change and should re-render automatically.
• **B — callbacks**: `device.pickImage((uri) => { ... })` hands results to a vesk cell. Use for one-shot actions.
• **C — markup elements**: `<camera video />`, `<battery-status />`, `<qr-scanner />`, `<contacts />` compile to native composables with the same runtime surface.

Script API reference

All device APIs are available on the `device` object in `.vsk` scripts. The full method surface:

Permissions

The build scans the `.vsk` pages (AST walks — no regex) and declares in the Android manifest only the permissions the used device APIs need. `device.*` calls and their element-tag counterparts map through the same `API_PERMISSIONS` table:

Tangible elements

The declarative device elements compile to the same runtime surface as the script `device.*` API. Each tag maps to a composable and feeds the manifest scan:

									
										export component Camera() {
  <camera video ondone={(uri) => { lastShot = uri }} />
  <battery-status />
  <qr-scanner onresult={(text) => { code = text }} />
  <contacts onresult={(list) => { people = list }} />
}
									
								

Available tags: `<photo-picker>`, `<camera>` (with `video` attribute), `<recorder>`, `<file-input>`, `<notification>`, `<battery-status>`, `<network-status>`, `<location>`, `<apps>`, `<contacts>`, `<call-log>`, `<messages>`, `<accounts>`, `<clipboard>`, `<copy-to-clipboard>`, `<vibrate>`, `<torch>`, `<screenshot>`, `<share-text>`, `<share-file>`, `<biometric-auth>`, `<bluetooth>`, `<bluetooth-toggle>`, `<bluetooth-scan>`, `<screen-record>`, `<qr-code>`, `<qr-scanner>`, `<volume>`, `<set-volume>`, `<brightness>`, `<keep-awake>`, `<orientation>`, `<device-info>`, `<storage-status>`, `<sensor>`, `<toast>`, `<sound>`, `<wallpaper>`, `<calendar>`, `<nfc>`, `<sim>`, `<dial>`, `<sms>`, `<email>`, `<open-link>`, `<map>`, `<alarm>`, `<open-settings>`, `<open-app>`, `<speak>`.

• Attributes pass through as named composable args — `<alarm hour='8' minute='30' title='Wake up'>`.
• Missing args fall back to the composable's Kotlin defaults, so `<battery-status/>` alone works.
• Tags feed the same API_PERMISSIONS scan as `device.*` calls.

Media element tiers

Media and device elements split into three tiers by permission requirements:

Drag & drop

Markup-level native drag & drop: a `draggable` element becomes a drag source (payload from its `dragdata` attribute or text content); an `ondrop={(text) => { ... }}` element is a drop target. Payloads also land in other apps (`DRAG_FLAG_GLOBAL`).

									
										export component DragDrop() {
  <div class="grid grid-cols-2 gap-4 p-6">
    <div class="rounded-2xl bg-blue-100 p-6 text-center"
         draggable dragdata="/media/photo.jpg">
      Drag me
    </div>
    <div class="rounded-2xl border-2 border-dashed p-6 text-center"
         ondrop={(text) => { droppedText = text }}>
      Drop here
    </div>
  </div>
}
									
								

Usage analysis

The CLI's `usage.ts` scans the compiled project and the `.vsk` sources to derive exactly what ships in the app:

• `collectDeviceApiUsage(appDir)` — AST+IR walk over .vsk scripts for `device.<api>()` calls and device element tags; drives manifest permissions and runtime grants.
• `collectBrowserApiUsage(appDir)` — finds `fetch`, `localStorage`/`sessionStorage`, `openSqlite`, auth (`signUp`/`signIn`/`signOut`/`currentUser`/`isSignedIn`), `WebSocket`, `EventSource` to decide their manifest needs.
• `collectRuntimeUsage(appDir)` — scans generated Kotlin to pick exactly the runtime helpers actually called (video/audio helpers only when a page uses `<video>`/`<audio>`, the device runtime only when a device API or element appears).

Runtime permission prompts

Dangerous permissions are requested at the point of use through the Compose runtime. When a page triggers a device API that needs runtime consent (camera, microphone, location, contacts), the framework shows the Android system prompt and resumes the callback with the grant result.

									
										export component MediaLab() {
  const &[photoUri] = track('')

  <div class="p-4">
    <button onClick={() => {
      device.capturePhoto((uri) => { photoUri = uri })
    }} class="bg-blue-600 text-white rounded-xl px-4 py-2">
      Take a photo
    </button>
    if (photoUri !== '') {
      <img src={photoUri} class="mt-4 rounded-2xl w-full" />
    }
  </div>
}