Para respeitar a privacidade do usuário, recomendamos que os desenvolvedores de apps solicitem apenas permissões de localização aproximada. Os apps que precisam de uma posição aproximada geralmente usam a localização de rede combinada (FLP, na sigla em inglês) porque ela é rápida e consome menos energia. Em comparação com dispositivos móveis baseados no 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ê use
requestLocationUpdatespara identificar explicitamente o provedor de localização preferido.A API Google Play Services oferece uma maneira mais simples de trabalhar com a localização em
FusedLocationProviderClient.
Muitos apps automotivos usam a FLP da API Google Play Services em vez de LocationManager. A FLP seleciona o provedor de localização ideal com base nos critérios e políticas de solicitação de localização (energia e precisão) necessários para o veículo.
Você pode optar por solicitar e usar explicitamente NETWORK_PROVIDER
e GPS_PROVIDER para
posições precisas, que usam permissões android.permission.ACCESS_FINE_LOCATION. No Android 12 (nível 31 da API) e mais recentes, o FUSED_PROVIDER,
que antes só podia ser acessado pela API Google Play Services, está
disponível como um provedor de localização para LocationManager. Confira uma
implementação da FLP em FusedLocationProvider.java.
Embora seja possível usar GPS_PROVIDER apenas com direitos de permissão aproximada, o framework degrada artificialmente a precisão 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 apps automotivos
O NETWORK_PROVIDER usado em smartphones Android (com o Google Mobile Services) determina a localização com base em torres de celular, pontos de acesso Wi-Fi e beacons Bluetooth (BT) próximos. Como resultado, NETWORK_PROVIDER pode exigir uma conexão de dados.
Para apps automotivos, as restrições de dispositivos são diferentes. Como o sistema global de navegação por satélite (GNSS) geralmente está ativado, não há penalidades devido ao aumento do uso de energia e 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 de LocationManager diretamente porque a FLP seleciona automaticamente o melhor provedor de localização para atender aos critérios ou políticas da solicitação, como energia e precisão.
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 localização de rede (NLP)
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, como minimizamos o uso de dados, nenhuma implementação funcional adicional de NLP é fornecida.
Provedor de localização combinada
A FLP móvel combina informações de outros sensores para melhorar a qualidade da localização, além de usar provedores de rede e GPS. Por outro lado, a FLP automotiva usa GPS_PROVIDER como fonte subjacente. Ela ajusta as posições do GNSS, adicionando um erro intencional para degradar a precisão quando um cliente solicita locais aproximados.
Assim, em alguns casos, pode haver um tempo maior do que o normal para a primeira posição 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.
Projetar apps para uso em dispositivos móveis e automotivos
Para apps destinados a dispositivos móveis e automotivos que não
exigem uma maior qualidade de precisão, solicite
android.permission.ACCESS_COARSE_LOCATION apenas e volte a usar a
FLP quando disponível. Como alternativa, use GPS_PROVIDER diretamente com as mesmas permissões. O framework degrada a precisão da posição do GNSS subjacente para se alinhar às expectativas da API. Para saber mais, consulte Precisão
em Solicitar permissões de localização.
Além disso, esses apps 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 ajuda a alcançar maior compatibilidade com dispositivos em diferentes formatos e, portanto, a disponibilidade máxima do app sem diferenças de código para receber posições quando necessário.