본문으로 건너뛰기
cccskills
무료GitHub에 공개

flutter-macos-permission-handler-camera-failure

Fix silent camera/microphone failure on Flutter macOS when using permission_handler plugin. Use when: (1) Camera screen shows placeholder but no error on macOS, (2) CameraPermissionError state is emitted but cause is unclear, (3) permission_handler checkCameraStatus() or checkMicrophoneStatus() throws exceptions on macOS desktop, (4) Camera works on iOS/Android but fails silently on macOS. The permission_handler plugin doesn't work reliably on macOS - bypass it and let macOS handle permissions at the system level.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md5.7 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Flutter macOS permission_handler Camera Failure

Problem

Camera/microphone permission checks using the permission_handler Flutter plugin throw exceptions on macOS desktop, causing permission gates to emit error states. The camera screen never renders, but the user sees a placeholder UI with no clear error message.

Context / Trigger Conditions

Use this skill when:

  • Flutter app works on iOS/Android but camera fails on macOS
  • Permission gate shows loading or error state on macOS
  • Logs show CameraPermissionError state being emitted
  • Permission.camera.status or Permission.microphone.status throws exceptions
  • Camera placeholder UI appears but VideoRecorderScreen (or equivalent) never initializes
  • No camera-related logs appear after navigation to camera screen

Key diagnostic pattern:

🔐 CameraPermissionGate initState
🔐 Building with state: CameraPermissionInitial
🔐 Triggering permission refresh
🔐 Permission state changed: CameraPermissionError  <-- This is the tell

Root Cause

The permission_handler plugin uses platform channels that don't work reliably on macOS desktop. When checkCameraStatus() or checkMicrophoneStatus() is called:

  • On iOS/Android: Returns proper permission status
  • On macOS: Throws exception → BLoC catches → Emits error state → Screen blocked

macOS handles camera/microphone permissions at the system level - the first time an app tries to access the camera, macOS shows its own permission dialog.

Solution

Bypass permission_handler on macOS and assume permissions are authorized:

Future<void> _onRefresh(
  CameraPermissionRefresh event,
  Emitter<CameraPermissionState> emit,
) async {
  // On macOS desktop, permission_handler doesn't work reliably.
  // macOS handles camera permissions at the system level when the app
  // actually tries to access the camera, showing its own permission dialog.
  if (!kIsWeb && Platform.isMacOS) {
    emit(const CameraPermissionLoaded(CameraPermissionStatus.authorized));
    return;
  }

  // Normal permission check for iOS/Android
  try {
    final status = await checkPermissions();
    emit(CameraPermissionLoaded(status));
  } catch (e) {
    emit(const CameraPermissionError());
  }
}

Required imports:

import 'dart:io';
import 'package:flutter/foundation.dart';

Verification

After implementing the fix:

  1. Logs should show: 🔐 macOS detected - bypassing permission_handler, assuming authorized
  2. Permission state changes to CameraPermissionLoaded with status authorized
  3. Camera screen actually renders and camera initialization logs appear
  4. macOS shows its native permission dialog on first camera access (if not already granted)

Debugging Layers

When debugging silent camera failures, check these layers in order:

  1. Permission layer: Is the camera screen even being rendered? Check permission gate state.
  2. Initialization layer: Is initialize() being called? Check for initialization logs.
  3. Device detection layer: Are camera devices found? Check listDevices() results.
  4. Controller layer: Does camera controller initialize? Check for controller errors.

Add logging at each layer to trace where the flow stops.

Related Fixes

When implementing this fix, also add:

  1. Error tracking in camera service: Add initializationError getter to report why camera failed (no devices, permission denied by macOS, etc.)

  2. UI error display: Pass error messages to placeholder widgets so users see what's wrong

  3. Try-catch around native calls: CameraMacOS.instance.listDevices() can also throw - wrap in try-catch and set error state

Example: Complete Fix

// In CameraPermissionBloc
Future<void> _onRefresh(...) async {
  if (!kIsWeb && Platform.isMacOS) {
    log('macOS detected - bypassing permission_handler');
    emit(const CameraPermissionLoaded(CameraPermissionStatus.authorized));
    return;
  }
  // ... normal flow for mobile
}

// In CameraMacOSService
@override
Future<void> initialize() async {
  try {
    _videoDevices = await CameraMacOS.instance.listDevices(...);
  } catch (e) {
    _initializationError = 'Failed to detect cameras: $e';
    return;
  }

  if (_videoDevices?.isEmpty ?? true) {
    _initializationError = 'No camera found. Please connect a camera.';
    return;
  }
  // ... continue initialization
}

Notes

  • This is a platform-specific workaround, not a bug in your code
  • macOS Ventura+ has stricter permission handling; the native dialog will still appear
  • Test on actual macOS hardware, not just simulators
  • The camera_macos or camera_macos_plus packages handle the native permission dialog
  • Consider adding a "Camera permission required" UI that appears if macOS denies access

References

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Fix ArgoCD ExternalSecret deployment failing with "namespace X is not permitted in project Y". Use when: (1) ExternalSecret shows OutOfSync in ArgoCD but won't sync, (2) ArgoCD application status shows "namespace X is not permitted in project 'infrastructure'", (3) ExternalSecret targets a namespace managed by a different ArgoCD project, (4) Using apps-of-apps pattern with separate infrastructure and application projects.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

Art direction for any content — reads text, PDF, Word, HTML, PPT, then proposes 2-3 creative directions with photography style, mood, and visual language. After selection, generates AI image prompts and visual briefs section-by-section. Use when the user shares content and needs visual direction, image sourcing, or creative direction for any material.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

Fix "Null check operator used on a null value" errors when an object is set to null during an async await. Use when: (1) Object reference is nullified while awaiting, (2) Code accesses object with ! after await returns, (3) Cancel/dispose operations run concurrently with async operations on same object. Solution: capture local reference before await.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

Add custom metadata headers (x-amz-meta-*) to AWS v4 signed requests for GCS S3-compatible API. Use when: (1) Adding custom metadata to GCS uploads via S3 API, (2) Getting signature mismatch errors after adding new headers, (3) x-amz-meta-* headers being ignored or causing 403 errors. Custom headers MUST be included in canonical headers and signed headers list.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

Fix password/secret authentication failures caused by trailing newlines when creating Google Cloud secrets (or similar) with bash here-strings. Use when: (1) Password authentication fails with correct password, (2) Secret created with `<<< "value"` syntax, (3) Error like "password authentication failed" or "invalid token" despite correct value. Bash here-strings (`<<<`) add a trailing newline that corrupts secrets.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

Fix silent video/media processing failures caused by URL extraction code that filters on file extensions (.mp4, .webm, .webp). Use when: (1) Media moderation, transcoding, or analysis silently skips files from Blossom or content-addressed storage servers, (2) URL extraction from Nostr event tags (imeta, r tags) drops URLs without recognized extensions, (3) CDN fallback URLs append .mp4 but the actual server uses extensionless content-addressed paths like /{sha256}. Common in Nostr video events (kind 34236) where different clients use different URL formats.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

divinevideo/divine-mobile2662026년 10월 19일 업데이트

divinevideo의 스킬 모두 보기

이 스킬의 문제 신고