Hoje, estamos lançando a segunda versão Beta do Android 17, continuando nosso trabalho para criar uma plataforma que priorize a privacidade, a segurança e o desempenho refinado. Essa atualização oferece uma variedade de novos recursos, incluindo a API EyeDropper e um seletor de contatos que preserva a privacidade. Também estamos adicionando APIs de alcance avançado, transferência entre dispositivos e muito mais.

Essa versão continua a mudança na nossa cadência de lançamento, seguindo essa versão principal anual do SDK no segundo trimestre com uma atualização secundária do SDK.

Experiência do usuário e interface do sistema

Balões

Os balões são um recurso de modo de janela que oferece uma nova experiência de interface flutuante separada da API de balões de mensagens. Os usuários podem criar um balão de app no smartphone, dispositivo dobrável ou tablet tocando e mantendo pressionado o ícone do app na tela de início. Em telas grandes, há uma barra de balões como parte da barra de tarefas em que os usuários podem organizar, alternar e mover balões para e de pontos fixos na tela.

Siga as diretrizes para oferecer suporte ao modo de várias janelas para garantir que seus apps funcionem corretamente como balões.

Os balões ainda não estão totalmente ativados na versão Beta 2. Procure-os em um build futuro do Android 17.

API EyeDropper

Uma nova API EyeDropper no nível do sistema permite que seu app solicite uma cor de qualquer pixel na tela sem exigir permissões confidenciais de captura de tela.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

Seletor de contatos

Um novo seletor de contatos no nível do sistema via ACTION_PICK_CONTACTS concede acesso de leitura temporário e baseado em sessão apenas aos campos de dados específicos solicitados pelo usuário, reduzindo a necessidade das permissões READ_CONTACTS amplas. Ele também permite seleções dos perfis pessoais ou de trabalho do dispositivo.

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

Compatibilidade mais fácil de captura de ponteiro com touchpads

Anteriormente, os touchpads informavam eventos de maneira muito diferente dos mouses quando um app capturava o ponteiro, informando os locais dos dedos no touchpad em vez dos movimentos relativos que seriam informados por um mouse. Isso dificultava bastante o suporte adequado a touchpads em jogos em primeira pessoa. Agora, por padrão, o sistema reconhece o movimento do ponteiro e os gestos de rolagem quando o touchpad é capturado e os informa como eventos do mouse. Você ainda pode solicitar os dados antigos e detalhados de localização dos dedos solicitando explicitamente a captura no novo modo "absoluto".

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

Limites de repouso do seletor interativo

Ao chamar getInitialRestingBounds na ChooserSession do Android, seu app pode identificar a posição de destino que o seletor ocupa após a conclusão das animações e do carregamento de dados, permitindo melhores ajustes da interface.

Conectividade e entre dispositivos

Transferência de apps entre dispositivos

Uma nova API Handoff permite especificar o estado do aplicativo a ser retomado em outro dispositivo, como um tablet Android. Quando ativado, o sistema sincroniza o estado via CompanionDeviceManager e mostra uma sugestão de transferência no launcher dos dispositivos próximos do usuário. Esse recurso foi projetado para oferecer continuidade perfeita de tarefas, permitindo que os usuários retomem exatamente de onde pararam no fluxo de trabalho em todo o ecossistema Android. A API Handoff oferece suporte a transições nativas de app para app e fallback de app para Web, oferecendo flexibilidade máxima e garantindo uma experiência completa, mesmo que o app nativo não esteja instalado no dispositivo receptor.

APIs de alcance avançado

Estamos adicionando suporte a duas novas tecnologias de alcance:

1. UWB DL-TDOA , que permite que os apps usem UWB para navegação interna. Essa superfície de API é compatível com a especificação FIRA (Fine Ranging Consortium) 4.0 DL-TDOA e permite a navegação interna que preserva a privacidade  (evitando o rastreamento do dispositivo pela âncora).
2. Detecção de proximidade , que permite que os apps usem a nova especificação de alcance que está sendo adotada pela WFA (WiFi Alliance). Essa tecnologia oferece confiabilidade e acurácia aprimoradas em comparação com a especificação de alcance baseada em Wi-Fi Aware.

Melhorias no plano de dados

Para otimizar a qualidade da mídia, seu app agora pode recuperar as taxas máximas de dados alocadas pela operadora para aplicativos de streaming usando getStreamingAppMaxDownlinkKbps e getStreamingAppMaxUplinkKbps.

Funcionalidade principal, privacidade e desempenho

Acesso à rede local

O Android 17 apresenta a permissão de execução ACCESS_LOCAL_NETWORK para proteger os usuários contra acesso não autorizado à rede local. Como isso se enquadra no grupo de permissões NEARBY_DEVICES, os usuários que já concederam outras permissões NEARBY_DEVICES não vão receber a solicitação novamente. Ao declarar e solicitar essa permissão, seu app pode descobrir e se conectar a dispositivos na rede local (LAN), como dispositivos domésticos inteligentes ou receptores de transmissão. Isso impede que apps maliciosos explorem o acesso irrestrito à rede local para rastreamento de usuários e técnicas de impressão digital encobertos. Os apps destinados ao Android 17 ou versões mais recentes agora terão dois caminhos para manter a comunicação com dispositivos LAN: adotar seletores de dispositivos mediados pelo sistema e que preservam a privacidade para ignorar a solicitação de permissão ou solicitar explicitamente essa nova permissão no momento da execução para manter a comunicação de rede local.

Transmissão de mudança de deslocamento de fuso horário

O Android agora oferece uma intent de transmissão confiável, ACTION_TIMEZONE_OFFSET_CHANGED, acionada quando o deslocamento de fuso horário do sistema muda, como durante as transições do horário de verão. Isso complementa as intents de transmissão ACTION_TIME_CHANGED e ACTION_TIMEZONE_CHANGED, que são acionadas quando o carimbo de data/hora Unix muda e quando o ID do fuso horário muda, respectivamente.

Gerenciamento e priorização de NPU

Os apps destinados ao Android 17 que precisam acessar diretamente a NPU precisam declarar FEATURE_NEURAL_PROCESSING_UNIT no manifesto para evitar o bloqueio do acesso à NPU. Isso inclui apps que usam o delegado LiteRT NPU, SDKs específicos do fornecedor e a NNAPI obsoleta.

Suporte ao ICU 78 e ao Unicode 17

As bibliotecas principais de internacionalização foram atualizadas para o ICU 78, expandindo o suporte a novos scripts, caracteres e blocos de emoji, e permitindo a formatação direta de objetos de tempo.

Proteção de OTP por SMS

O Android está expandindo a proteção de OTP por SMS atrasando automaticamente o acesso a mensagens SMS com OTP. Anteriormente, a proteção era focada principalmente no formato do SMS Retriever, em que a entrega de mensagens que contêm um hash do SMS Retriever é atrasada para a maioria dos apps por três horas. No entanto, alguns apps, como o App de SMS padrão, etc., e o app que corresponde ao hash estão isentos desse atraso. Essa atualização estende a proteção a todas as mensagens SMS com OTP. Para a maioria dos apps, as mensagens SMS que contêm um OTP só poderão ser acessadas após um atraso de três horas para ajudar a evitar o sequestro de OTP. A transmissão SMS_RECEIVED_ACTION será retida e as consultas de banco de dados do provedor de SMS serão filtradas. A mensagem SMS estará disponível para esses apps após o atraso. 

Acesso atrasado a mensagens SMS no formato WebOTP

Se o app tiver permissão para ler mensagens SMS, mas não for o destinatário pretendido do OTP (conforme determinado pela verificação de domínio), a mensagem SMS no formato WebOTP só poderá ser acessada após três horas. Essa mudança foi projetada para melhorar a segurança do usuário, garantindo que apenas os apps associados ao domínio mencionado na mensagem possam ler o código de verificação de maneira programática. Essa mudança se aplica a todos os apps, independentemente do nível desejado da API.

Acesso atrasado a mensagens SMS padrão com OTP

Para mensagens SMS que contêm um OTP que não usa os formatos WebOTP ou SMS Retriever, o SMS OTP só poderá ser acessado após três horas para a maioria dos apps. Essa mudança só se aplica a apps destinados ao Android 17 (nível 37 da API) ou versões mais recentes.

Alguns apps, como o SMS padrão, o app assistente e os apps complementares de dispositivos conectados, etc., serão isentos desse atraso.

Todos os apps que dependem da leitura de mensagens SMS para extração de OTP precisam fazer a transição para o uso das APIs SMS Retriever ou SMS User Consent para garantir a funcionalidade contínua.

Programação do Android 17

Vamos passar rapidamente dessa versão Beta para o marco de estabilidade da plataforma, previsto para março. Nesse marco, vamos entregar as APIs finais do SDK/NDK. A partir desse momento, seu app poderá segmentar o SDK 37 e publicar no Google Play para ajudar você a concluir os testes e coletar feedback dos usuários nos meses anteriores à disponibilidade geral do Android 17.

Um ano de lançamentos

Planejamos que o Android 17 continue recebendo atualizações em uma série de lançamentos trimestrais. O próximo lançamento no segundo trimestre é o único em que apresentamos mudanças de comportamento planejadas que causam falhas no app. Planejamos ter um lançamento secundário do SDK no quarto trimestre com mais APIs e recursos.

Começar a usar o Android 17

Você pode registrar qualquer dispositivo Pixel com suporte para receber essa e futuras atualizações do Android Beta over the air. Se você não tiver um dispositivo Pixel, poderá usar as imagens do sistema de 64 bits com o Android Emulator no Android Studio.

Se você estiver no programa Android Beta, vai receber uma atualização over the air para a versão Beta 2.

Se você tiver a versão Beta 26Q1 do Android e quiser usar a versão estável final do 26Q1 e sair da versão Beta, ignore a atualização over the air para a versão Beta 2 do 26Q2 e aguarde o lançamento do 26Q1.

Estamos buscando seu feedback. Por isso, informe problemas e envie solicitações de recursos na página de feedback. Quanto mais cedo recebermos seu feedback, mais melhorias poderão ser incluídas no nosso trabalho na versão final.

Para ter a melhor experiência de desenvolvimento com o Android 17, recomendamos que você use a versão de pré-lançamento mais recente do Android Studio (Panda). Depois de configurar, faça o seguinte:

• Compile com o novo SDK, teste em ambientes de CI e informe problemas no nosso Issue Tracker na página de feedback.
• Teste seu app atual para verificar a compatibilidade, saiba se ele é afetado por mudanças no Android 17 e instale o app em um dispositivo ou emulador com o Android 17 e teste-o extensivamente.

Vamos atualizar as imagens do sistema de pré-lançamento/Beta e o SDK regularmente durante todo o ciclo de lançamento do Android 17. Depois de instalar um build Beta, você vai receber automaticamente atualizações futuras

over the air para todos os pré-lançamentos e versões Beta posteriores.

Para informações completas, acesse o site para desenvolvedores do Android 17.

Participe da conversa

À medida que avançamos para a estabilidade da plataforma e a disponibilidade geral do Android 17 ainda este ano, seu feedback continua sendo nosso recurso mais valioso. Seja você um usuário pioneiro no canal Canary ou um desenvolvedor de apps que testa na versão Beta 2, considere participar das nossas comunidades e enviar feedback. Estamos ouvindo.