Android manifest setup

The Extentos Android SDK ships an AndroidManifest.xml that the Android manifest merger folds into your app at build time. Some entries are zero-config (the library declares them for you); the capability permissions stay app-owned because they gate features only your app knows it needs.

What the library declares for you

These are merged in automatically — you do not add them:

Conflict on networkSecurityConfig? If your app already declares its own android:networkSecurityConfig, the merger reports a conflict. Resolve it by adding tools:replace="android:networkSecurityConfig" to your app manifest's <application> tag (and add xmlns:tools="http://schemas.android.com/tools" to the <manifest> root if it isn't there).

What you add

The library leaves capability permissions to you, so your manifest declares only what your app actually uses. Add the ones matching the capabilities you call:

<!-- Photo / video capture -->
<uses-permission android:name="android.permission.CAMERA" />

<!-- Voice, transcription, audio chunks, the assistant -->
<uses-permission android:name="android.permission.RECORD_AUDIO" />

<!-- Reaching the managed gateway / simulator / telemetry -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- Background mic capture via the bundled foreground service (Android 14+) -->
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MICROPHONE" />

Camera or display apps also add the Meta credential entries

Permissions aren't the whole manifest. An app using the vendor transport must also carry the two Meta DAT <meta-data> elements inside <application>, or MWDAT can't initialize:

<application …>
    <meta-data android:name="com.meta.wearable.mwdat.APPLICATION_ID"
               android:value="@string/meta_application_id" />
    <meta-data android:name="com.meta.wearable.mwdat.CLIENT_TOKEN"
               android:value="@string/meta_client_token" />
</application>

The string resources come from app/src/main/res/values/extentos_meta_credentials.xml, which generateConnectionModule writes from the credentials you stored in your dashboard project — there is no runtime injection path through ExtentosConfig. See credentials. Voice-only apps skip this — they have no DAT dependency.

For the runtime-request flow and which capability needs which permission, see the getPermissions MCP tool and Permissions.

The bundled foreground service

For background-surviving microphone capture (a voice assistant or live transcription that must keep listening while your app is backgrounded), the library declares a foreground service for you:

<service
    android:name="com.extentos.glasses.core.service.GlassesForegroundService"
    android:foregroundServiceType="microphone"
    android:exported="false" />

You don't declare it — you start it from an Activity, after RECORD_AUDIO has been granted at runtime:

import com.extentos.glasses.core.service.GlassesForegroundService

// In your permission-grant callback, once RECORD_AUDIO is PERMISSION_GRANTED:
GlassesForegroundService.start(this)   // 'this' is any Context

// Later, when you no longer need background capture:
GlassesForegroundService.stop(this)

start is idempotent. Do not call it from Application.onCreate — Android 14+ requires the RECORD_AUDIO grant to be in place before startForeground(...) runs, or the app crashes at service-create time. See Lifecycle for the full wiring.

Camera-only or strictly foreground apps don't need the service at all — the declaration is harmless if unused. A camera-type foreground service (rare; for surviving videoFrames in the background) requires you to subclass GlassesForegroundService and declare your own <service android:foregroundServiceType="camera" />.

Building on iOS too? Permissions there are Info.plist keys, not manifest entries — see the iOS SDK pages.

Related