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 usa o local da rede (FLP) porque é 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ê identifique explicitamente as provedor de localização.
A API Google Play Services oferece uma maneira mais simplificada de a trabalhar com localização com a introdução do provedor de localização combinada (FLP).
Muitos apps automotivos usam o FLP da API Google Play Services (GPS) em vez do ML. O FLP seleciona o provedor de localização ideal com base na solicitação de local os critérios e as políticas (potência e precisão) necessários para o veículo.
Em vez disso, solicite e use explicitamente
NETWORK_PROVIDER no LM e
GPS_PROVIDER para posições finas, que usa
android.permission.ACCESS_FINE_LOCATION
permissões. Na API 31, a API FUSED_PROVIDER,
que antes eram acessíveis apenas pela API GPS, agora é
disponível como provedor de localização para o LM. É possível conferir um modelo
implementação do FLP,
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)
mudou de determinar a localização com base apenas nas torres de celular próximas para
use pontos de acesso Wi-Fi ou até mesmo sensores de Bluetooth (BT). Uso de
NETWORK_PROVIDER pode exigir uma conexão de dados.
Para apps automotivos, as restrições dos dispositivos são diferentes. Como o GNSS normalmente está ativado, nenhuma penalidade é causada pelo aumento do uso de energia e da bateria. Como 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 do LM diretamente como FLP faz a coisa mais inteligente usando o provedor de localização mais capaz de atender aos critérios/políticas de solicitação de local (ou seja, potência e precisão) de acordo com o capô.
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
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
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 haver um tempo maior 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
Recomendamos que os apps segmentados para dispositivos móveis e automotivos que não
exigem solicitações de maior qualidade e precisão
android.permission.ACCESS_COARSE_LOCATION
apenas e voltar a usar o FLP
quando disponíveis. Como último recurso, use GPS_PROVIDER diretamente
com as mesmas permissões. O framework degrada a precisão dos dados
Posição do GNSS para alinhamento com as expectativas da API. Para saber mais, consulte Precisão.
Além disso, esses aplicativos precisam declarar explicitamente o
android.hardware.location.network
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.