A tradução do artigo foi preparada especificamente para os alunos do curso "Android-developer. Curso básico " . Lembramos também que continuamos a se inscrever no curso avançado "Specialization Android-developer"
Estamos no 10º ano de desenvolvimento do Android (o Android Q deve ser a versão 10.0). De acordo com o Beta 4, o Android Q oficialmente possui uma
API de nível 29 . Embora o
Beta 5 já exista e o Beta 6 seja esperado, a API foi marcada como final e agora é a hora de ver como o Android Q afetará os aplicativos e quais alterações precisam ser feitas para oferecer suporte total ao Android Q.
Alterações importantes (nem todas) apresentadas no Android Q podem ser divididas em duas categorias: a)
Confidencialidade e segurança , b)
Experiência do usuário .
Do tradutor: “Dividimos a tradução em duas partes, correspondentes a essas categorias. Assim, na primeira parte, falaremos sobre privacidade e segurança ".1) Confidencialidade e segurança
a) Iniciando atividades em segundo plano
Você não pode mais iniciar uma Atividade quando seu aplicativo estiver em segundo plano.
- O que afeta: todos os aplicativos em execução no Q (independentemente do SDK de destino). Uma exceção será lançada se o Android Q for a versão de destino do aplicativo; e Activity não serão iniciados se o Android Q não for o SDK de destino para o aplicativo, mas funcionar em um dispositivo com Android Q.
- Exceções: serviços vinculados, como acessibilidade, preenchimento automático, etc. Se o aplicativo receber um
PendingIntent do sistema, podemos usá-lo para iniciar a Atividade. Se o aplicativo tiver a permissão SYSTEM_ALERT_WINDOW (removida no Android GO) ou o aplicativo recentemente chamado finish() para Activity (não é recomendável confiar nele. “Recentemente” pode ser muito ambíguo), seu aplicativo estará livre dessa restrição. - Abordagem recomendada: Atividade de ativação de notificação
val fullScreenIntent = Intent(this, CallActivity::class.java) val fullScreenPendingIntent = PendingIntent.getActivity(this, 0, fullScreenIntent, PendingIntent.FLAG_UPDATE_CURRENT) val notificationBuilder = NotificationCompat.Builder(this, CHANNEL_ID) .... .setPriority(NotificationCompat.PRIORITY_HIGH) .setCategory(NotificationCompat.CATEGORY_CALL) .setFullScreenIntent(fullScreenPendingIntent, true)
Adicione
Fullscreen PendingIntent à notificação. Agora que a notificação funcionou, o sistema iniciará uma Intenção em tela cheia.
Portanto, se queremos iniciar o Activity em segundo plano, primeiro crie uma notificação que será exibida ao usuário. Nesta notificação, adicione
Fullscreen PendingIntent . Além disso, adicione a permissão
USE_FULL_SCREEN_INTENT ao seu manifesto. Agora que a notificação funcionou, o sistema iniciará uma Intenção em tela cheia.
- Armadilhas: O sistema decide quando exibir uma notificação e quando mostrar uma Atividade. Se o usuário estiver usando o dispositivo ativamente, uma notificação pop-up será exibida. Se o dispositivo estiver em repouso ou quando o usuário interagir com a notificação, a Atividade em tela cheia será iniciada. Por exemplo, como ao receber uma ligação (notificações pop-up enquanto estiver usando o telefone, caso contrário, Atividade em tela cheia).
b) identificadores de hardware
O acesso a identificadores de dispositivos não redefiníveis foi revogado no Android Q.
- O que afeta: todos os aplicativos em execução no Q (independentemente do SDK de destino). Uma exceção será lançada se Q for o SDK de destino; e retornará
null se o SDK de destino for menor que Q - Evitar: o endereço do Mac agora está aleatório e o IMEI (
TelephonyManager.getDeviceId() ) e o número de série não estão mais disponíveis. Agora eles são "permissões privilegiadas" e estão disponíveis apenas para aplicativos do operador. - Abordagem recomendada: use identificadores redefiníveis, como ID de publicidade, ID da instância ou GUID (Globally Unique ID). Consulte Práticas recomendadas para identificadores exclusivos para obter mais informações sobre qual identificador usar nesse caso.
c) Definição de localização de fundo
A partir do Android Q, o sistema fará a distinção entre solicitações de localização feitas em primeiro plano e em segundo plano.
A solicitação de permissão para acessar o local agora terá 3 opções: Permitir o tempo todo, Permitir apenas ao usar o aplicativo (acessar apenas em primeiro plano) e Negar (sem acesso).
- O que afeta: depende do SDK de destino. Se Q for o SDK de destino para o aplicativo, será necessário solicitar uma nova permissão de localização em segundo plano. Se o aplicativo tiver um SDK de destino diferente, ele receberá automaticamente essa permissão se já tiver direitos de acesso ao local.
Imagem retirada da documentação do desenvolvedor do Android- Abordagem recomendada: se o aplicativo exigir acesso único ao local do usuário para executar algumas tarefas, use o serviço de primeiro plano com o parâmetro foregroundServiceType especificado como
location no arquivo de manifesto do aplicativo.
<service android:name="MyNavigationService" android:foregroundServiceType="location" ... />
Se o aplicativo precisar de acesso constante ao local do dispositivo, por exemplo, para cercas geográficas, ele poderá configurar uma solicitação para permitir o acesso ao local em segundo plano. Outros aspectos do aplicativo (por exemplo, como o local é extraído e usado) não precisam ser alterados. Para solicitar acesso a um local em segundo plano, adicione a permissão
ACCESS_BACKGROUND_LOCATION ao manifesto:
<manifest> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> </manifest>
Solicitar acesso ao local em segundo plano
Lembrete exibido pelo sistema sobre o acesso a um local em segundo planoAlgumas coisas importantes a serem lembradas: o usuário pode ser lembrado após conceder ao aplicativo acesso ao local do dispositivo em segundo plano e, como qualquer outra permissão, o usuário pode revogar a permissão. Isso é especialmente importante para aplicativos em que Q não é um SDK de destino, mas em execução em dispositivos com Android Q, porque obteria a resolução de segundo plano padrão se tivesse permissão de localização. Verifique se o aplicativo lida com esses scripts normalmente. Por esse motivo, sempre que um aplicativo inicia um serviço ou solicita um local, verifique se o usuário ainda permite que o aplicativo acesse informações de local.
Nisso, a primeira parte do artigo chegou ao fim e, como prometido, falaremos sobre as experiências do usuário na
segunda parte .