Para respeitar a privacidade do usuário, os desenvolvedores de apps são incentivados a solicitar apenas permissões de localização. Apps que precisam de uma posição aproximada geralmente usar o local de rede fundido (FLP, na sigla em inglês) porque ele é rápido e consome menos energia. Em comparação com dispositivos móveis Android, a localização de rede em apps automotivos pode ser mais desafiador. É possível usar duas APIs do Android:
A API LocationManager exige que você use
requestLocationUpdatespara identificar explicitamente o provedor de localização preferido.A API Google Play Services oferece uma maneira mais direta de trabalhar com localização
FusedLocationProviderClient
Muitos apps automotivos usam o FLP da API Google Play Services em vez do
LocationManager: O FLP seleciona o provedor de localização ideal com base no local
critérios e políticas de solicitação (potência e precisão) necessários para o veículo.
Em vez disso, solicite e use explicitamente
NETWORK_PROVIDER
assim como
GPS_PROVIDER para
posições finas, que usa
android.permission.ACCESS_FINE_LOCATION
permissões. No Android 12 (nível 31 da API) e versões mais recentes, a
FUSED_PROVIDER,
antes acessíveis apenas pela API do Google Play Services, é
disponível como 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 gerais,
a estrutura degrada artificialmente a acurácia para se alinhar às expectativas.
não faz sentido para desenvolvedores que segmentam smartphones Android porque, no geral,
disponibilidade é ruim e muitas vezes mais lenta para obter uma posição aproximada.
Local da rede no setor automotivo
O NETWORK_PROVIDER usado em smartphones Android (com os Serviços do Google Mobile)
determina a localização com base em torres de celular próximas, pontos de acesso Wi-Fi e
Beacons Bluetooth (BT). Como resultado, a NETWORK_PROVIDER pode precisar de um
uma conexão com a Internet.
Para apps automotivos, as restrições dos dispositivos são diferentes. Como a navegação global do Gthe o sistema de satélite (GNSS, na sigla em inglês) geralmente está ativado, sem penalidades de aumento no uso de energia e da bateria. Como resultado, o tempo de atividade de IVI não é comprometido. Nós nos esforçamos para minimizar a troca de dados com nossos servidores.
Por isso, muitos apps usam o FLP da API Play em vez de LocationManager.
diretamente, porque o FLP automaticamente realiza a coisa mais inteligente usando a localização
provedor mais capaz de atender aos critérios/políticas de solicitação de local (ou seja, capacidade
e acurácia).
Ao contrário dos dispositivos móveis, os veículos raramente parecem pular de um lugar para outra. A posição do veículo é conhecida sob o capô na maioria das vezes.
Provedor de local de rede (PLN)
A maioria dos veículos não implementa APIs de telefonia necessárias para receber as informações necessárias. em um ID de celular (e intensidade do sinal). Como resultado e como minimizamos os dados uso, não é fornecida nenhuma outra implementação funcional do PLN.
Provedor de localização combinada
O FLP para dispositivos móveis, além de usar de maneira inteligente provedores de rede e GPS como
combina informações de outros sensores para aprimorar ainda mais
qualidade dos locais. A implementação atual do FLP do Automotive no
aproveite as suposições mencionadas acima e use o
GPS_PROVIDER como uma origem subjacente o tempo todo. Ele fudge as posições
do GNSS, adicionando alguns erros para que sejam mais imprecisos quando necessário. Por exemplo:
quando locais aproximadas são fornecidas a um cliente.
Por isso, em alguns casos, pode demorar um pouco 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 subsistema de localização é usado ou depois de ser rebocado.
Criar apps para uso em dispositivos móveis e automotivos
Para aplicativos que segmentam dispositivos móveis e automotivos que não
exigem maior qualidade de precisão, solicite
android.permission.ACCESS_COARSE_LOCATION
apenas e voltar a usar o FLP quando disponível. Como alternativa, use
GPS_PROVIDER diretamente com as mesmas permissões. O framework degrada
precisão da posição do GNSS subjacente para alinhar-se às expectativas da API. Para
Para saber mais, consulte Precisão
em Solicitar permissões de localização.
Além disso, esses aplicativos precisam declarar explicitamente o
android.hardware.location.network
recurso como opcional no manifesto. Exemplo:
<uses-feature android:name="android.hardware.location.network" android:required="false" />
Essa abordagem garante compatibilidade máxima com dispositivos de todos os setores e, assim, a disponibilidade máxima do aplicativo sem diferenças de código para obter quando necessário.