Obter localização aproximada

Para respeitar a privacidade do usuário, recomendamos que os desenvolvedores de apps solicitem apenas permissões de localização aproximada. Apps que precisam de uma posição aproximada aproximada geralmente usam o local de rede combinada (FLP, na sigla em inglês) porque é rápido e consome menos energia. Em comparação com dispositivos móveis baseados no Android, a localização da rede em apps automotivos pode ser mais desafiadora. É possível usar duas APIs do Android:

  • A API LocationManager exige que você use requestLocationUpdates para identificar explicitamente o provedor de localização preferido.

  • A API Google Play Services oferece uma maneira mais simples de trabalhar com a localização no FusedLocationProviderClient.

Muitos apps automotivos usam o FLP da API Google Play Services em vez de LocationManager. O FLP seleciona o provedor de localização ideal com base nos critérios e políticas de solicitação de local (energia e precisão) necessários para o veículo.

Em vez disso, você pode solicitar e usar explicitamente NETWORK_PROVIDER, assim como GPS_PROVIDER para posições corretas, que usa permissões android.permission.ACCESS_FINE_LOCATION. No Android 12 (nível 31 da API) e versões mais recentes, o FUSED_PROVIDER, anteriormente acessível apenas pela API Google Play Services, está disponível como um provedor de localização para LocationManager. Confira uma implementação do FLP em FusedLocationProvider.java.

Embora seja possível usar GPS_PROVIDER apenas com direitos de permissão aproximados (o framework prejudica a precisão de forma artificial para se alinhar às expectativas), isso faz pouco sentido para desenvolvedores que segmentam smartphones Android, porque a disponibilidade geral é insatisfatória e geralmente é mais lenta para conseguir uma posição aproximada.

Local da rede em automóveis

O NETWORK_PROVIDER usado em smartphones Android (com os Serviços do Google Mobile) determina a localização com base em torres de celular, pontos de acesso Wi-Fi e beacons de Bluetooth (BT) próximos. Como resultado, o NETWORK_PROVIDER pode exigir uma conexão de dados.

Para apps automotivos, as restrições de dispositivo são diferentes. Como o sistema global de navegação por satélite (GNSS, na sigla em inglês) geralmente está ativado, nenhuma penalidade é incorrida devido ao aumento do uso de bateria e de energia. Como resultado, o tempo de atividade da IVI não é comprometido. Fazemos o possível para minimizar a troca de dados com nossos servidores.

Portanto, muitos apps usam o FLP da API Play em vez de LocationManager diretamente, já que o FLP faz a maneira inteligente usando o provedor de localização mais adequado para atender aos critérios/políticas de solicitação de localização (ou seja, potência e precisão).

Ao contrário dos dispositivos móveis, os veículos raramente parecem pular de um lugar para outro. Na maioria das vezes, a posição do veículo é conhecida sob o capô.

Provedor de localização de rede (PLN)

A maioria dos veículos não implementa as APIs de telefonia necessárias para receber as informações necessárias sobre um ID de celular (e a intensidade do sinal). Como resultado, e como minimizamos o uso de dados, nenhuma outra implementação funcional do PLN é fornecida.

Provedor de localização combinada

O FLP móvel, além de usar de maneira inteligente provedores de rede e GPS conforme adequado, combina informações de outros sensores para melhorar ainda mais a qualidade dos locais. Por outro lado, a implementação atual do FLP do Automotive aproveita as suposições mencionadas acima e usa o GPS_PROVIDER como fonte o tempo todo. Ela alterna as posições do GNSS, adicionando alguns erros para aumentar a precisão quando necessário. Por exemplo, quando locais aproximados são fornecidos a um cliente.

Sendo assim, em pouquíssimas situações, pode haver um tempo mais longo do que o normal para que a primeira posição fique disponível. Por exemplo, na primeira vez que um veículo ou, mais precisamente, o subsistema de localização dele é usado ou depois de um guincho.

Criar aplicativos para segmentar usos automotivos e em dispositivos móveis

Para apps destinados a celulares edispositivos automotivos que não exigem uma qualidade de precisão maior, solicite android.permission.ACCESS_COARSE_LOCATION apenas e recupere o FLP quando disponível. Como alternativa, use GPS_PROVIDER diretamente com as mesmas permissões. O framework reduz a precisão da posição do GNSS subjacente para se alinhar às expectativas da API. Para saber mais, consulte Precisão em Solicitar permissões de localização.

Além disso, esses apps precisam declarar explicitamente o recurso android.hardware.location.network como opcional no manifesto. Por exemplo:

<uses-feature android:name="android.hardware.location.network" android:required="false" />

Essa abordagem garante compatibilidade máxima com dispositivos em várias indústrias e, portanto, disponibilidade máxima do app sem diferenças de código para conseguir posições quando necessário.