Para respeitar a privacidade do usuário, os desenvolvedores de aplicativos são incentivados a solicitar apenas permissões de localização aproximadas. Os aplicativos que precisam de uma posição aproximada aproximada geralmente usam o local de rede (FLP) porque é rápido e consome menos energia.
Em comparação com dispositivos móveis baseados em Android, a localização de rede em aplicativos automotivos pode ser mais desafiadora. Você pode usar duas APIs Android:
A API LocationManager exige que você identifique explicitamente o provedor de localização preferencial.
A API do Google Play Services oferece uma maneira mais simplificada de trabalhar com localização com a introdução do Fused Location Provider (FLP).
Muitos aplicativos automotivos usam FLP da API Google Play Services (GPS) em vez de LM. A FLP seleciona o fornecedor de localização ideal com base nos critérios e políticas de solicitação de localização (potência e precisão) exigidas pelo veículo.
Em vez disso, você pode optar por solicitar e usar 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 , anteriormente acessível apenas através da API GPS, agora está disponível como provedor de localização para LM. Você pode visualizar uma implementação mais simples do FLP em FusedLocationProvider.java .
Embora seja possível usar GPS_PROVIDER apenas com direitos de permissão grosseiros, a estrutura degrada artificialmente a precisão para se alinhar às expectativas. Faz pouco sentido para desenvolvedores que visam telefones Android porque a disponibilidade geral é baixa e muitas vezes mais lenta para obter uma posição grosseira.
Localização de rede no setor automotivo
O NETWORK_PROVIDER usado em telefones Android (com Google Mobile Services) mudou de determinar a localização com base apenas em torres de celular próximas para também usar pontos de acesso Wi-Fi ou até mesmo beacons Bluetooth (BT). O uso de NETWORK_PROVIDER pode exigir uma conexão de dados.
Para aplicativos automotivos, as restrições de dispositivo são diferentes. Como o GNSS está normalmente ligado, nenhuma penalidade será incorrida devido ao aumento de energia e uso da bateria. Como resultado, o tempo de atividade do IVI não é comprometido. Nós nos esforçamos para minimizar a troca de dados com nossos servidores.
Muitos aplicativos, portanto, usam o FLP da Play API em vez do LM diretamente, pois o FLP faz automaticamente a coisa inteligente ao usar o provedor de localização mais capaz de satisfazer os critérios/políticas de solicitação de localização (ou seja, potência e precisão) nos bastidores.
Ao contrário dos dispositivos móveis, os veículos raramente parecem saltar de um lugar para outro. A posição do veículo é conhecida sob o capô na maioria das vezes.
Provedor de localização de rede
A maioria dos veículos não implementa APIs de telefonia necessárias para obter as informações necessárias sobre um Cell ID (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 fundido
O FLP móvel, além de usar de forma inteligente os provedores de rede e GPS conforme apropriado, funde informações de outros sensores para melhorar ainda mais a qualidade dos locais. A implementação atual do FLP da Automotive, por outro lado, aproveita as suposições acima 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 localizações aproximadas são fornecidas a um cliente.
Como tal, em muito poucos casos pode demorar mais do que o normal para que a primeira posição esteja disponível. Por exemplo, na primeira vez que um veículo ou, para ser mais preciso, o seu subsistema de localização é utilizado ou após ser rebocado.
Projete aplicativos para usos móveis e automotivos
Recomendamos que os aplicativos destinados a dispositivos móveis e automotivos que não exigem uma qualidade de precisão mais alta solicitem apenas android.permission.ACCESS_COARSE_LOCATION e voltem a usar o FLP quando disponível. Alternativamente, como último recurso, use GPS_PROVIDER diretamente com as mesmas permissões. A estrutura degrada 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 aplicativos devem declarar explicitamente o recurso android.hardware.location.network como opcional em seu manifesto. Por exemplo:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
Essa abordagem garante compatibilidade máxima com dispositivos em todos os setores e, portanto, disponibilidade máxima do aplicativo sem diferenças de código para obter posições quando necessário.