A segunda versão Beta do Android 17

Hoje, estamos lançando a segunda versão Beta do Android 17, continuando nosso trabalho para criar uma plataforma que prioriza privacidade, segurança e 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, 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 gerais. 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 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 de mouse. Você ainda pode solicitar os dados de localização detalhados dos dedos antigos 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 depois que as animações e o carregamento de dados são concluídos, 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 de tarefas sem interrupções, permitindo que os usuários retomem exatamente de onde pararam no fluxo de trabalho em todo o ecossistema Android. É importante ressaltar que a transferência oferece suporte a transições nativas de app para app e fallback de app para Web, proporcionando 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 adotada pela WFA (WiFi Alliance). Essa tecnologia oferece maior confiabilidade e precisão 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 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 da NPU LiteRT, 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 e não usam os formatos WebOTP ou SMS Retriever, o OTP SMS só poderá ser acessado após três horas para a maioria dos apps. Essa mudança se aplica apenas 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á ser destinado ao SDK 37 e publicado 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 poderemos incluir 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 atualizações futuras

over the air para todas as prévias 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.