DeviceMotion, DeviceOrientation e Vibration são de primeira classe na web móvel — até rodarem dentro de um WebView. O Android System WebView deixou a API de orientação desativada até a v55 e em muitas compilações ainda retorna aceleração zerada a menos que as flags e permissões corretas sejam definidas; Vibration precisa de uma permissão VIBRATE explícita. No iOS, o WKWebView nem expõe requestPermission(), então o fluxo do iOS 13+ bloqueado por gesto jamais inicia. Um runtime próprio do host faz a ponte da camada de sensores: uma API que lê o hardware real em cada motor.
Android: desativado por padrão, silencioso quando «ligado»
A documentação do Chromium é clara: entre as APIs de sensores de hardware, a API de orientação ficou desativada no WebView v33 e só foi habilitada a partir da v55. Geolocalização, captura de mídia e Vibration também são parcialmente condicionadas. E «habilitado» não é «funciona» — muitas compilações do WebView retornam acceleration zerada ou nunca disparam o evento a menos que a página seja servida via https e o app conceda a permissão em tempo de execução. Uma falha comum é um recurso «agite para agir» que simplesmente não dispara porque o contêiner não encaminhou o sensor. Vibration (navigator.vibrate) precisa de android.permission.VIBRATE; sem ela a chamada é uma não-operação silenciosa.
iOS: a API de permissão simplesmente não existe
A partir do iOS 13, o Safari exige DeviceMotionEvent.requestPermission() / DeviceOrientationEvent.requestPermission() — um diálogo disparado por um gesto do usuário — antes que qualquer evento de movimento ou orientação dispare. Mas essa API não é exposta no WKWebView. O próprio rastreador de bugs do WebKit (bug 203287) registra: «A API requestPermission() só é exposta no MobileSafari, não no WKWebView». Assim, dentro do WebView de um app, o fluxo bloqueado por gesto nem pode começar; a página tem de depender de o WebView ter acesso direto, o que depende inteiramente de como o host o configurou. Some o requisito de contexto seguro (sem http://) e a política de iframe allow="gyroscope; accelerometer", e a maioria das páginas integradas não recebe nada.
O que quebra quando os sensores silenciam
- Morrem os recursos de agitar, inclinar e contar passos. Sem eventos
devicemotion, não há UX baseada em gestos. - Ferramentas 360° / AR / nível não retornam nada.
deviceorientationestá ausente ou zerada. - As vibrações ficam silenciosas.
navigator.vibrateé uma não-operação sem a permissão VIBRATE. - Dupla armadilha no iOS 13+. Sem
requestPermission()no WKWebView, o caminho do Safari não roda; o host deve conceder nativamente. - Navegadores integrados divergem. Contêineres de WeChat/Weibo frequentemente não expõem nem a API nem um meio de solicitar, então testar no Safari esconde a falha.
A solução do runtime
Um runtime próprio do host faz a ponte da camada de sensores. O host lê o hardware real — SensorManager no Android, Core Motion no iOS — e expõe uma API uniforme à página: movimento, orientação e feedback háptico que funcionam em cada motor e navegador integrado. A permissão é solicitada uma vez, nativamente, e os valores fluem para a página sem a comporta por motor. Uma superfície de sensores, hardware real, em todo lugar.
| Dimensão | WebView | Runtime próprio do host |
|---|---|---|
| Orientação no Android | Desativada < v55, costuma zerar | Hardware real |
| requestPermission iOS | Não exposto no WKWebView | Concessão nativa |
| Vibration | Precisa de permissão VIBRATE | Háptica nativa |
| Comporta de contexto seguro | Fácil de errar | Tratado nativamente |
| Navegadores integrados | Sem API, sem diálogo | API uniforme |
| Consistência | Por motor | Uniforme |
Um app nativo lê o giroscópio em cada telefone. Um WebView comum em quase nenhum. Um runtime dá à página uma camada de sensores — e o hardware real por trás dela.
Fontes
- Chrome for Developers — Visão geral do WebView (suporte a sensores) — a tabela que mostra orientação desativada no WebView v33 e habilitada a partir da v55, e Vibration condicionada por permissão.
- WebKit Bug 203287 — «requestPermission() só é exposta no MobileSafari, não no WKWebView», com confirmação de um engenheiro do WebKit.
- MDN — DeviceMotionEvent — o requisito de gesto
requestPermission()do iOS 13+ e a restrição de contexto seguro. - MDN — DeviceOrientationEvent — as mesmas regras de permissão e contexto para dados de orientação.
- MDN — Vibration API — suporte de
navigator.vibratee o requisito de permissão VIBRATE no Android.
