Para respeitar a privacidade do usuário, os desenvolvedores de apps são incentivados a solicitar apenas permissões de localização aproximada. Os apps que precisam de uma posição aproximada geralmente usam a localização de rede (FLP) porque ela é rápida e consome menos energia.
Em comparação com dispositivos móveis Android, a localização de rede em apps automotivos pode ser mais difícil. Você pode usar duas APIs do Android:
A API LocationManager ou LM exige que você identifique explicitamente o provedor de local preferido.
A API do Google Play Services oferece uma maneira mais simples 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 do 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 (energia e precisão) necessárias para o veículo.
Em vez disso, você pode solicitar e usar explicitamente
NETWORK_PROVIDER no LM, bem como
GPS_PROVIDER para posições precisas, que usa
permissões de
android.permission.ACCESS_FINE_LOCATION. Na API 31, o FUSED_PROVIDER, que antes era acessível apenas pela API GPS, agora está disponível como um provedor de localização para o LM. Confira uma implementação mais simples do FLP em FusedLocationProvider.java.
Embora seja possível usar GPS_PROVIDER apenas com direitos de permissão aproximados, o framework reduz artificialmente a acurácia para se alinhar às expectativas. Isso não faz muito sentido para desenvolvedores que segmentam smartphones Android porque a disponibilidade geral é baixa e geralmente mais lenta para obter uma posição aproximada.
Localização de rede em automóveis
O NETWORK_PROVIDER usado em smartphones Android (com os Serviços do Google Mobile) mudou. Agora, além de determinar a localização com base apenas em torres de celular próximas, ele também usa pontos de acesso Wi-Fi ou até mesmo sensores Bluetooth (BT). O uso do
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.
Portanto, muitos apps usam a FLP da API Play em vez da LM diretamente, já que a FLP faz automaticamente a coisa inteligente usando o provedor de localização mais adequado para satisfazer os critérios/políticas de solicitação de localização (principalmente energia e precisão) em segundo plano.
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 sobre um ID de célula (e intensidade do sinal). Como resultado, e porque minimizamos o uso de dados, nenhuma implementação funcional adicional de PNL é fornecida.
Provedor de localização combinada
O FLP móvel, além de usar de forma inteligente provedores de rede e GPS conforme
apropriado, combina 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 proposições mencionadas e usa GPS_PROVIDER como uma fonte subjacente o tempo todo. Ele altera 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, a primeira posição pode levar mais tempo do que o normal para ficar disponível. Por exemplo, na primeira vez que um veículo ou, para ser mais preciso, o subsistema de localização dele é usado ou depois de ser rebocado.
Criar apps para uso em dispositivos móveis e automotivos
Recomendamos que apps destinados a dispositivos móveis e automotivos que não
exigem uma qualidade maior de solicitação de precisão
android.permission.ACCESS_COARSE_LOCATION
apenas e voltem a usar 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 do GNSS subjacente para se alinhar às expectativas da API. Para saber mais, consulte Acurácia.
Além disso, esses apps precisam declarar explicitamente o recurso
android.hardware.location.network
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 todos os setores e, portanto, a máxima disponibilidade de apps sem diferenças de código para receber posições quando necessário.