Para respeitar a privacidade do usuário, recomendamos que os desenvolvedores de apps solicitem apenas permissões de localização aproximadas. Os apps que precisam de uma posição aproximada aproximada geralmente usam a localização da rede (FLP, na sigla em inglês) porque ela é rápida e consome menos energia.
Em comparação com dispositivos móveis baseados em Android, a localização de rede em apps automotivos pode ser mais desafiadora. Você pode usar duas APIs do Android:
A API LocationManager exige que você identifique explicitamente o provedor de local preferido.
A API Google Play Services oferece uma maneira mais simplificada de trabalhar com a localização com a introdução do provedor de localização combinada (FLP, na sigla em inglês).
Muitos apps automotivos usam o FLP da API Google Play Services (GPS) em vez do LM. O FLP seleciona o provedor de localização ideal com base nos critérios e nas políticas de solicitação de localização (potência e precisão) necessários para o veículo.
Em vez disso, solicite e use explicitamente
NETWORK_PROVIDER no LM, bem como
GPS_PROVIDER para posições precisas, que usa
permissões
android.permission.ACCESS_FINE_LOCATION. Na API 31, o FUSED_PROVIDER,
que antes só era acessível pela API GPS, agora está
disponível como um provedor de localização para o LM. Confira uma implementação mais simples
de FLP em
FusedLocationProvider.java.
Embora seja possível usar GPS_PROVIDER com apenas direitos de permissão grosseiros,
o framework degrada artificialmente a precisão para se alinhar às expectativas. Ele
não faz muito sentido para desenvolvedores que segmentam smartphones Android, porque a
disponibilidade geral é ruim e, muitas vezes, mais lenta para conseguir uma posição aproximada.
Local da rede no setor automotivo
O NETWORK_PROVIDER usado em smartphones Android (com os Serviços Móveis do Google) mudou
de determinar a localização com base apenas em torres de celular próximas para
usar também pontos de acesso Wi-Fi ou até sensores de Bluetooth (BT). O uso de
NETWORK_PROVIDER pode exigir uma conexão de dados.
Para apps automotivos, as restrições de dispositivo são diferentes. Como o GNSS normalmente está ativado, não há penalidades devido ao aumento do uso de energia e da bateria. Como resultado, o tempo de atividade do IVI não é comprometido. Nosso objetivo é minimizar os dados trocados com nossos servidores.
Muitos apps usam a FLP da API Play em vez da LM diretamente, porque a FLP faz a coisa inteligente automaticamente usando o provedor de localização mais capaz de satisfazer os critérios/políticas de solicitação de localização (ou seja, energia e precisão) por trás.
Ao contrário dos dispositivos móveis, os veículos raramente parecem pular de um lugar para outro. A posição do veículo é conhecida na maioria das vezes.
Provedor de local de rede
A maioria dos veículos não implementa as APIs de telefonia necessárias para receber as informações necessárias em um ID de célula (e intensidade do sinal). Como resultado, e porque minimizamos o uso de dados, nenhuma implementação funcional adicional de NLP é fornecida.
Provedor de localização combinada
Além de usar de forma inteligente provedores de rede e GPS, o FLP para dispositivos móveis mescla informações de outros sensores para melhorar ainda mais a qualidade dos locais. A implementação atual da FLP do Automotive, por outro lado, aproveita as suposições mencionadas e usa
GPS_PROVIDER como fonte subjacente o tempo todo. Ele falsifica as posições
do GNSS, adicionando alguns erros para ser mais impreciso quando necessário. Por exemplo,
quando locais aproximados são fornecidos a um cliente.
Por isso, em alguns casos, pode levar mais tempo do que o normal para que a primeira posição fique disponível. Por exemplo, a primeira vez que um veículo ou, para ser mais preciso, o subsistema de localização é usado ou após ser rebocado.
Criar apps para uso em dispositivos móveis e automóveis
Recomendamos que os apps segmentados para dispositivos móveis e automotivos que não
exigem uma qualidade mais alta de solicitação de precisão
android.permission.ACCESS_COARSE_LOCATION
somente usem o FLP
quando disponível. Como último recurso, use GPS_PROVIDER diretamente
com as mesmas permissões. O framework reduz a precisão da posição
GNSS subjacente para se alinhar às expectativas da API. Para saber mais, consulte Precisão.
Além disso, esses apps precisam declarar explicitamente o
recurso android.hardware.location.network
como opcional no manifesto.
Exemplo:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
Essa abordagem garante a máxima compatibilidade com dispositivos em todas as verticais e, portanto, a máxima disponibilidade do app sem diferenças de código para receber posições quando necessário.