Hoje, estamos lançando a segunda versão Beta do Android 17, continuando nosso trabalho para criar uma plataforma que priorize privacidade, segurança e desempenho refinado. Essa atualização oferece uma série 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.

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

Experiência do usuário e interface do sistema

Balões

O recurso de modo de janelas Bubbles oferece uma nova experiência de interface flutuante separada da API de balões de mensagens. Os usuários podem criar uma bolha de app no smartphone, dispositivo dobrável ou tablet tocando e mantendo pressionado o ícone do app no acesso rápido. Em telas grandes, há uma barra de balões como parte da barra de tarefas em que os usuários podem organizar, mover e mover balões para e de pontos de fixação na tela.

Siga as diretrizes para oferecer suporte ao modo de várias janelas e 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 essas opções em uma versão futura do Android 17.

API EyeDropper

Uma nova API EyeDropper no nível do sistema permite que o app solicite uma cor de qualquer pixel na tela sem exigir permissões sensíveis 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 amplas READ_CONTACTS. Também permite seleções nos 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

Antes, os touchpads informavam eventos de maneira muito diferente dos mouses quando um app capturava o ponteiro. Eles informavam os locais dos dedos no pad 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 do mouse. Você ainda pode solicitar os dados antigos e detalhados de localização do dedo pedindo 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 descanso 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 na interface.

Conectividade e entre dispositivos

Transferência de apps entre dispositivos

Uma nova API Handoff permite especificar o estado do aplicativo para 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 iniciador dos dispositivos por perto do usuário. Esse recurso foi criado para oferecer continuidade perfeita das tarefas, permitindo que os usuários retomem exatamente de onde pararam no fluxo de trabalho em todo o ecossistema Android. O Handoff é compatível com transições nativas de app para app e fallback de app para Web, oferecendo máxima flexibilidade e garantindo uma experiência completa mesmo que o app nativo não esteja instalado no dispositivo de recebimento.

APIs avançadas de intervalo

Estamos adicionando suporte a duas novas tecnologias de alcance:

1. UWB DL-TDOA, que permite que os apps usem UWB para navegação em ambientes internos. Essa superfície de API está em conformidade com a especificação DL-TDOA 4.0 da FIRA (Fine Ranging Consortium) e permite a navegação interna com preservação da 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 mais confiabilidade e precisão em comparação com a especificação de alcance baseada no Wifi 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 outra solicitação. Ao declarar e solicitar essa permissão, seu app pode descobrir e se conectar a dispositivos na rede local (LAN), como dispositivos de casa inteligente 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 direcionados ao Android 17 ou versões mais recentes agora têm dois caminhos para manter a comunicação com dispositivos LAN: adotar seletores de dispositivos mediados pelo sistema e que preservam a privacidade para pular a solicitação de permissão ou solicitar explicitamente essa nova permissão no tempo de execução para manter a comunicação de rede local.

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

O Android agora oferece uma intent de transmissão confiável, ACTION_TIMEZONE_OFFSET_CHANGED, acionada quando a compensação 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 e o ID do fuso horário mudam, respectivamente.

Gerenciamento e priorização de NPUs

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 descontinuada.

Compatibilidade com ICU 78 e Unicode 17

As bibliotecas principais de internacionalização foram atualizadas para ICU 78, ampliando o suporte a novos scripts, caracteres e blocos de emojis, além de permitir a formatação direta de objetos time.

Proteção de OTP por SMS

O Android está ampliando a proteção de senhas únicas por SMS, atrasando automaticamente o acesso a mensagens de texto com senhas únicas. Antes, a proteção se concentrava principalmente no formato SMS Retriever, em que a entrega de mensagens que contêm um hash do SMS Retriever é adiada por três horas na maioria dos apps. No entanto, alguns apps, como o app de SMS padrão, etc., e o app correspondente 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 com um OTP só ficam acessíveis após um atraso de três horas para 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 vai 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 criada 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 forma 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 SMS com o OTP só fica acessível 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 app de SMS padrão, o assistente e os apps complementares de dispositivos conectados, etc., não vão ter essa isenção.

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 continuidade da funcionalidade.

A programação do Android 17

Vamos passar rapidamente dessa versão Beta para a etapa de estabilidade da plataforma, prevista para março. Nessa etapa, vamos disponibilizar as APIs finais do SDK/NDK. A partir desse momento, seu app poderá segmentar o SDK 37 e ser 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 vamos introduzir mudanças planejadas no comportamento de interrupção de apps. Planejamos lançar uma versão secundária do SDK no quarto trimestre com mais APIs e recursos.

Começar a usar o Android 17

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

Se você já participa do programa Android Beta, vai receber uma atualização over the air para a versão Beta 2.

Se você tem o Android 26Q1 Beta e quer usar a versão estável final do 26Q1 e sair da versão Beta, ignore a atualização OTA para o 26Q2 Beta 2 e aguarde o lançamento do 26Q1.

Queremos saber sua opinião. Por isso, relate 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 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 qualquer problema no rastreador na página de feedback.
• Teste a compatibilidade do app atual, saiba se ele é afetado por mudanças no Android 17 e instale o app em um dispositivo ou emulador com o Android 17 para testá-lo extensivamente.

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

OTA 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 antecipado no canal Canary ou um desenvolvedor de apps testando a versão Beta 2, participe das nossas comunidades e envie feedback. Estamos ouvindo.