Pular para o conteúdo principal

Uso Real e Armadilhas Conhecidas

Última atualização: 16 de julho de 2026

Câmera e galeria: usadas de verdade, mas cada tela pede de novo​

Câmera e galeria concedidas no onboarding são reaproveitadas em vários pontos do app, mas nenhuma tela confia no estado pedido no onboarding, cada uma faz sua própria checagem/pedido em tempo real (o que é o comportamento correto para permissões de SO, elas sempre podem ter mudado desde o onboarding):

  • Leitor de código de barras do controle de inventário, já documentado em Loja / Gestão Operacional, usa expo-camera diretamente.
  • Foto de perfil da loja (features/store/store-profile.controller.ts), sugestões (features/store/subscreens/suggestions/store-suggestions.controller.ts), anexos de cliente, assinatura de venda e conclusão de atividade usam expo-image-picker, que tem seu próprio sistema de permissão, tecnicamente separado do expo-media-library que o onboarding usa, mas que consulta o mesmo runtime permission do sistema operacional.

Localização: usada de verdade em otimização de rota​

features/client/activity/subscreens/route-optimization/activity-route-optimization.controller.ts e as telas de execução/detalhe de atividade da carteira de clientes pedem localização e fazem geocodificação de endereço, sempre revalidando a permissão em tempo real em vez de confiar no estado do onboarding.

Notificações: pedida no onboarding, mas sem nenhum consumidor no código​

Este é o gap mais claro do fluxo. expo-notifications (Notifications.getPermissionsAsync/requestPermissionsAsync) só aparece em services/permissions.service.ts. Não há, em nenhum outro lugar do projeto, chamada para getExpoPushTokenAsync, registerForPushNotificationsAsync, addNotificationReceivedListener, setNotificationHandler ou scheduleNotificationAsync. A tela "Central de Notificações" da tab Loja (documentada em Loja / Gestão Operacional) é só uma lista de itens mockados, não tem nenhuma relação com a API expo-notifications.

Ou seja, o app pede ao vendedor permissão para enviar notificações do sistema, mas hoje não existe nenhum código que de fato dispare, agende ou escute uma notificação local ou push. Vale confirmar com o time se essa infraestrutura está planejada, se é feita inteiramente do lado nativo/backend sem o SDK do Expo, ou se é resíduo de um plano que não avançou.

Galeria: pedida no onboarding, mas bloqueada no manifest do Android 13+​

app.json remove explicitamente do Android as permissões modernas de mídia:

"android": {
  "blockedPermissions": [
    "android.permission.READ_MEDIA_IMAGES",
    "android.permission.READ_MEDIA_VIDEO"
  ]
}

Confirmado no manifest gerado (android/app/src/main/AndroidManifest.xml):

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" tools:node="remove"/>
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" tools:node="remove"/>

Como o passo "Arquivos e fotos" do onboarding depende de expo-media-library, que por sua vez depende dessas permissões no Android 13+, esse passo provavelmente nunca fica "concedido" de verdade em dispositivos mais novos. O restante do app não é afetado na prática, porque quem de fato lida com seleção de fotos usa expo-image-picker, que no Android 13+ pode operar via Photo Picker do sistema sem exigir nenhuma runtime permission. Mas o passo de onboarding em si fica, no mínimo, redundante ou preso como pendente nesses aparelhos.

Código morto: uma tela e uma rota inteiras deste fluxo ficaram órfãs​

Existe uma segunda implementação do mesmo onboarding, em formato de tela roteada em vez de modal: features/permission/permission.tsx (PermissionsScreen). O histórico do projeto mostra que ela foi a implementação original, substituída depois pelo PermissionModal global, mas a limpeza ficou incompleta:

  • app/_layout.tsx ainda declara <Stack.Screen name="permissions" />.
  • storage/navigation/navigation.storage.ts ainda trata /permissions como rota pública restaurável: 
    const PUBLIC_RESTORABLE_PATHS = new Set(["/onboarding", "/permissions"]);
  • Mas não existe nenhum arquivo app/permissions.tsx ou app/permissions/index.tsx no projeto. Uma busca pela pasta app/ inteira confirma isso.

Ou seja, hoje /permissions é uma rota registrada que não tem para onde apontar: se algo tentasse navegar até ela, cairia no not-found do Expo Router. Nenhum outro arquivo do projeto de fato faz essa navegação, então o problema não aparece na prática, mas o componente PermissionsScreen em si virou código inalcançável. Some a isso features/permission/permission.controller.ts, presente no projeto mas com 0 bytes, um placeholder de separação controller/view que nunca chegou a ser preenchido.

Se for fazer limpeza técnica neste fluxo, o caminho é: remover features/permission/permission.tsx, features/permission/permission.controller.ts, o Stack.Screen name="permissions" em app/_layout.tsx, e a entrada "/permissions" em PUBLIC_RESTORABLE_PATHS. Ou, alternativamente, decidir reconectar essa tela a algum ponto de entrada real, se fizer sentido ter uma versão em tela cheia além do modal.

Nenhum teste automatizado cobre este fluxo​

Não existem testes para permissions.service.ts nem para permission.modal.tsx/permission.tsx. O único teste com "permission" no nome do projeto, features/sale/subscreens/sale-details/sale-details.permissions.test.ts, cobre uma coisa completamente diferente: regras de negócio de habilitar/desabilitar botões de editar/excluir/exportar venda conforme o status do pedido, sem nenhuma relação com permissões nativas de dispositivo.