What permissions does LiveKit Flutter need on ios ?

Thanks for reaching out, Ahmed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

does it require bluetooth access /

Thanks — you're asking whether LiveKit Flutter requires Bluetooth access on iOS. Short answer: no. Details: • LiveKit Flutter requires microphone (

NSMicrophoneUsageDescription

) and, if you use video, camera (

NSCameraUsageDescription

) permissions in your Info.plist. • Bluetooth-specific permission keys are not required for LiveKit to work with Bluetooth headsets. iOS handles audio routing (including Bluetooth) through the system audio session and AVFoundation; that works without adding Bluetooth permission entries. • If your app implements additional Bluetooth features beyond audio routing (e.g., scanning or controlling BT peripherals), then you would need the appropriate Bluetooth permissions for those features — but that is separate from LiveKit’s core audio/video functionality. If you tell me whether your app will only play audio, capture microphone audio, or use video as well, I can give the exact Info.plist lines to add. Sources: [Flutter iOS] SoundWaveformWidget / AudioVisualizerWidget Not Working (Miss... | client-sdk-android | livekit/livekit_composite | DeepWiki | LiveKit Docs | Fix Flutter iOS AudioVisualizerWidget missing plugin exception | LiveKit

Is bluetooth permission needed for Android ?

Short answer: No — Bluetooth permission is not required for the LiveKit Flutter SDK on Android. Details: • LiveKit’s Flutter SDK uses the Android client SDK for audio/video. Bluetooth audio routing (e.g., using a Bluetooth headset) is handled automatically by the platform and the SDK’s audio handling code without needing

BLUETOOTH

or

BLUETOOTH_ADMIN

permissions. • Required permissions for core LiveKit functionality on Android are: ◦

RECORD_AUDIO

— microphone capture ◦

CAMERA

— video capture (if you use video) ◦

INTERNET

and

ACCESS_NETWORK_STATE

— networking ◦

FOREGROUND_SERVICE

— optional for background operation When you would need Bluetooth permissions: • Only if your app itself performs direct Bluetooth operations beyond normal audio routing (for example, scanning for, pairing with, or controlling Bluetooth peripherals). In that case you’d add the appropriate Android Bluetooth permissions for those features — but that’s separate from LiveKit’s core audio/video needs. If you want, tell me whether you’re seeing any Bluetooth-related audio routing issues (Android version, device) and I can help troubleshoot. Sources: client-sdk-android | livekit/livekit_composite | DeepWiki

does it require any of these ?

Permission.bluetooth,
Permission.bluetoothConnect,

Thanks — good clarifying question. No, LiveKit Flutter does not require

Permission.bluetooth

or

Permission.bluetoothConnect

. • Android: LiveKit’s audio routing to Bluetooth headsets is handled by the platform and the SDK’s audio code without requesting `BLUETOOTH`/`BLUETOOTH_ADMIN` or the newer runtime

BLUETOOTH_CONNECT

permission. Only add those permissions if your app itself performs Bluetooth operations (scanning, pairing, controlling devices). • iOS: Bluetooth-specific runtime permission keys are not required for LiveKit’s audio/video features. iOS routes audio to connected Bluetooth devices via the system audio session without extra app permissions. If you plan to implement direct Bluetooth operations in your app (scan/pair/control), tell me what you need to do and I’ll list the exact permissions and manifest/Info.plist entries you should add.

Does LiveKit require UIBackgroundModes audio in ios to keep audio playing

Thanks — you’re asking whether LiveKit Flutter requires the iOS UIBackgroundModes audio capability (the "audio" entry in Info.plist) to keep audio playing when the app is backgrounded. Short answer: LiveKit itself does not explicitly require adding UIBackgroundModes = audio, but if your app needs to continue sending/receiving or playing audio while in the background, iOS typically requires the background-audio mode. In other words: • If you only need normal in-app audio/video while the app is foregrounded: you do not need UIBackgroundModes = audio. • If you need audio to continue playing or receiving (e.g., maintain a call audio stream) when the app is backgrounded or the screen is locked: you will generally need to enable UIBackgroundModes with the

audio

value in your Info.plist so iOS allows continuous audio in the background. Additional notes: • LiveKit integrates with iOS audio session management (AVAudioSession) and provides audio-processing controls (for example,

bypassVoiceProcessing

), but those do not replace the platform requirement to declare background audio if you want background behavior. • Background audio behavior also depends on how you configure your AVAudioSession category/mode and whether your app’s use case fits iOS background-audio policies (e.g., VoIP or media playback). Make sure your AVAudioSession is configured appropriately for continuous capture/playback. • If your app only needs to route audio to Bluetooth headsets or switch audio output while foregrounded, you do not need UIBackgroundModes = audio specifically for Bluetooth routing. If you want, tell me: • Whether you need to keep an active call (two-way audio) when users background the app, or • You only need background playback (one-way audio), and I’ll give the recommended Info.plist entry and the AVAudioSession configuration guidance to match your use case. Sources: client-sdk-flutter | livekit/livekit_composite | DeepWiki

• I need to keep an active call (two-way audio) when users background the app, or

Thanks — you said you need to keep an active two‑way call when users background the app. Here’s what to do and why. Summary • LiveKit itself doesn’t force a specific Info.plist key, but iOS requires the background-audio capability for apps that must continue audio capture/playback while backgrounded. To keep a two‑way call active when the app goes to background, enable UIBackgroundModes = audio and configure the AVAudioSession appropriately. What to add to Info.plist • Add the background mode for audio: ◦ Key:

UIBackgroundModes

◦ Value: include

audio

AVAudioSession configuration (high level) • Use an AVAudioSession category/mode that allows simultaneous capture and playback while backgrounded. Typical choices: ◦ Category:

AVAudioSessionCategoryPlayAndRecord

(or

playAndRecord

in Swift) ◦ Mode:

voiceChat

or

videoChat

depending on your use • Ensure the session is active and configured before starting the LiveKit connection so iOS grants the app the proper audio behavior when backgrounded. Other important notes • Background audio entitlement usage must match your app behavior and Apple policy. Apps that capture microphone audio in background may be reviewed for appropriate use. • LiveKit provides audio-session and processing controls (for example, bypassing iOS voice processing). Those controls do not remove the need to declare background audio when you want continuous background capture/playback. • Bluetooth routing: enabling background audio does not change Bluetooth handling. iOS routes audio to connected Bluetooth devices through the audio session without extra Bluetooth permissions. • Test on real devices and on the iOS versions you target—background behavior can vary by OS version and device. If you’d like, I can: • Provide the exact Info.plist XML snippet to paste in. • Give a small Swift code snippet that configures

AVAudioSession

for

playAndRecord

+

voiceChat

and activates it before connecting to LiveKit. Which would you prefer?

what about VoIP in this case

Thanks — you asked about VoIP for keeping a two‑way call active when the app is backgrounded. Here’s what you need to know and what to do. Short answer • LiveKit does not require a specific VoIP protocol, but on iOS you should enable the VoIP background mode (and typically the audio background mode) so your app can reliably keep two‑way audio alive and be woken for incoming calls while backgrounded. Why enable VoIP/background modes • iOS normally suspends apps in the background. Declaring the VoIP background mode (and

audio

) lets the system give your app the higher-priority scheduling and networking needed for sustained real‑time audio. • VoIP background mode helps prevent silent suspension of the audio session and allows your app to be woken by signaling (important for incoming calls). What to add in Info.plist • Add UIBackgroundModes with both

voip

and

audio

entries, for example:

<key>UIBackgroundModes</key>
<array>
  <string>voip</string>
  <string>audio</string>
</array>

AVAudioSession and app behavior • Configure your AVAudioSession for simultaneous capture/playback: ◦ Category:

playAndRecord

◦ Mode:

voiceChat

(or

videoChat

for video) • Activate the audio session before connecting to LiveKit so the system treats your app as actively using audio. • LiveKit provides audio-processing controls (e.g.,

bypassVoiceProcessing

) but those do not replace the need to declare background modes. Notes and Apple review • VoIP background mode must match actual app behavior. Apple may review background mode usage; ensure your app legitimately needs background real‑time audio and follows App Store guidelines. • You do not need a special VoIP protocol (like SIP) for LiveKit — WebRTC-based calls work with these background modes enabled. Android contrast • Android does not use the iOS VoIP background mode. For reliable background calling on Android, run a foreground service with an ongoing notification during calls. If you want, I can: • Provide the exact Info.plist XML snippet (above included) ready to paste. • Give a short Swift snippet to configure and activate AVAudioSession for

playAndRecord

+

voiceChat

before connecting to LiveKit. Which would you prefer? Sources: client-sdk-android | livekit/livekit_composite | DeepWiki | Client SDKs | livekit/livekit_composite | DeepWiki | client-sdk-flutter | livekit/livekit_composite | DeepWiki