Recursos e APIs

O Android 17 introduz ótimos recursos e APIs novos para desenvolvedores. As seções a seguir resumem esses recursos para ajudar você a começar a usar as APIs relacionadas.

Para uma lista detalhada das APIs novas, modificadas e removidas, leia o Relatório de diferenças da API. Para ver detalhes sobre as novas APIs, acesse a Referência da API do Android. As APIs novas estão em destaque para melhor visibilidade.

Você também precisa analisar as áreas em que as mudanças na plataforma podem afetar seus apps. Para mais informações, consulte as seguintes páginas:

Principal recurso

O Android 17 adiciona os seguintes recursos relacionados à funcionalidade principal do Android.

Novos gatilhos do ProfilingManager

O Android 17 adiciona vários novos acionadores de sistema ao ProfilingManager para ajudar você a coletar dados detalhados para depurar problemas de desempenho.

Os novos acionadores são:

  • TRIGGER_TYPE_COLD_START: o acionador ocorre durante a inicialização a frio do app. Ele fornece um exemplo de pilha de chamadas e um rastreamento do sistema na resposta.
  • TRIGGER_TYPE_OOM: o acionador ocorre quando um app gera um OutOfMemoryError e fornece um despejo de heap Java em resposta.
  • TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: o acionador ocorre quando um app é encerrado devido ao uso anormal e excessivo da CPU e fornece um exemplo de pilha de chamadas em resposta.
  • TRIGGER_TYPE_ANOMALY: detecta anomalias de desempenho do sistema, como chamadas de binder excessivas e uso da memória excessivo.

Para entender como configurar o acionador do sistema, consulte a documentação sobre criação de perfil baseada em acionadores e como recuperar e analisar dados de criação de perfil documentação.

Acionador de criação de perfil para anomalias de apps

O Android 17 apresenta um serviço de detecção de anomalias no dispositivo que monitora comportamentos com uso intenso de recursos e possíveis regressões de compatibilidade. Integrado ao ProfilingManager, esse serviço permite que o app receba artefatos de criação de perfil acionados por eventos específicos detectados pelo sistema.

Use o acionador TRIGGER_TYPE_ANOMALY para detectar problemas de desempenho do sistema como chamadas de binder excessivas e uso da memória excessivo. Quando um app viola os limites de memória definidos pelo SO, o acionador de anomalia permite que os desenvolvedores recebam despejos de heap específicos do app para ajudar a identificar e corrigir problemas de memória. Além disso, para spam de binder excessivo, o acionador de anomalia fornece um perfil de amostragem de pilha em transações de binder.

Esse callback da API ocorre antes de qualquer aplicação obrigatória imposta pelo sistema. Por exemplo, ele pode ajudar os desenvolvedores a coletar dados de depuração antes que o app seja encerrado pelo sistema por exceder os limites de memória.

val profilingManager =
    applicationContext.getSystemService(ProfilingManager::class.java)
val triggers = ArrayList<ProfilingTrigger>()
triggers.add(ProfilingTrigger.Builder(ProfilingTrigger.TRIGGER_TYPE_ANOMALY))
val mainExecutor: Executor = Executors.newSingleThreadExecutor()
val resultCallback = Consumer<ProfilingResult> { profilingResult ->
    if (profilingResult.errorCode != ProfilingResult.ERROR_NONE) {
        // upload profile result to server for further analysis
        setupProfileUploadWorker(profilingResult.resultFilePath)
    }
    profilingManager.registerForAllProfilingResults(mainExecutor,
                                                    resultCallback)
    profilingManager.addProfilingTriggers(triggers)
}

APIs JobDebugInfo

O Android 17 apresenta novas APIs JobDebugInfo para ajudar os desenvolvedores a depurar os jobs do JobScheduler, mostrando por que eles não estão sendo executados, por quanto tempo foram executados e outras informações agregadas.

O primeiro método das APIs JobDebugInfo expandidas é getPendingJobReasonStats(), que retorna um mapa de motivos pelos quais o job estava em um estado de execução pendente e as respectivas durações cumulativas pendentes. Esse método se une aos métodos getPendingJobReasonsHistory() e getPendingJobReasons() para oferecer insights sobre por que um job programado não está sendo executado como esperado, mas simplifica a recuperação de informações, disponibilizando a duração e o motivo do job em um único método.

Por exemplo, para um jobId especificado, o método pode retornar PENDING_JOB_REASON_CONSTRAINT_CHARGING e uma duração de 60.000 ms, indicando que o job estava pendente por 60.000 ms devido à restrição de carregamento não atendida.

Reduzir bloqueios de ativação com suporte de listener para alarmes allow-while-idle

Android 17 引入了 AlarmManager.setExactAndAllowWhileIdle 的新变体，该变体 接受 OnAlarmListener 而不是 PendingIntent。这种基于回调的新机制非常适合目前依赖于连续唤醒锁来执行定期任务的应用，例如维护套接字连接的消息传递应用。

Privacidade

O Android 17 inclui os seguintes novos recursos para melhorar a privacidade do usuário.

Suporte da plataforma para Encrypted Client Hello (ECH)

O Android 17 introduz suporte da plataforma para o Encrypted Client Hello (ECH), uma melhoria significativa de privacidade para comunicações de rede. O ECH é uma extensão do TLS 1.3 que criptografa a indicação de nome do servidor (SNI, na sigla em inglês) durante o handshake inicial do TLS. Essa criptografia ajuda a proteger a privacidade do usuário, dificultando que intermediários de rede identifiquem o domínio específico a que um app está se conectando.

A plataforma agora inclui as APIs necessárias para que as bibliotecas de rede implementem o ECH. Isso inclui novos recursos em DnsResolver para consultar registros DNS HTTPS que contêm configurações de ECH e novos métodos nos SSLEngines e SSLSockets do Conscrypt para ativar o ECH transmitindo essas configurações ao se conectar a um domínio. Os desenvolvedores podem configurar as preferências de ECH, como ativá-lo de forma oportunista ou obrigar o uso dele, usando o novo <domainEncryption> elemento no arquivo de configuração de segurança de rede, aplicável globalmente ou por domínio.

Espera-se que bibliotecas de rede populares, como HttpEngine, WebView e OkHttp, integrem essas APIs da plataforma em atualizações futuras, facilitando a adoção do ECH pelos apps e aprimorando a privacidade do usuário.

Para mais informações, consulte a documentação do Encrypted Client Hello.

Seletor de contatos do Android

Android 联系人选择工具是一个标准化的可浏览界面，供用户与您的应用分享联系人。该选择工具适用于搭载 Android 17（API 级别 37）或更高版本的设备，可提供一种可保护隐私的替代方案，以取代广泛的 READ_CONTACTS 权限。您的应用无需请求访问用户的整个地址簿，而是指定所需的数据字段（例如电话号码或电子邮件地址），然后用户选择要分享的特定联系人。这样，您的应用便只能读取所选数据，从而确保精细控制，同时提供一致的用户体验，并具有内置搜索、个人资料切换和多选功能，而无需构建或维护界面。

如需了解详情，请参阅联系人选择工具文档。

Segurança

O Android 17 adiciona os seguintes recursos novos para melhorar a segurança de dispositivos e apps.

Modo de Proteção Avançada do Android (AAPM, na sigla em inglês)

Android 高级保护模式为 Android 用户提供了一套强大的新安全功能，标志着在保护用户（尤其是面临较高风险的用户）免遭复杂攻击方面迈出了重要一步。AAPM 是一项选择启用功能，只需进行一项配置设置即可激活。用户可以随时启用该功能，以应用一套主观的安全保护措施。

这些核心配置包括：禁止安装未知来源的应用（旁加载）、限制 USB 数据信号传输，以及强制执行 Google Play 保护机制扫描，从而显著减小设备的攻击面。 开发者可以使用 AdvancedProtectionManager API 与此功能集成，以检测模式的状态，从而使应用能够在用户选择启用此模式时自动采用强化型安全姿态或限制高风险功能。

Assinatura de APKs PQC

O Android agora oferece suporte a um esquema híbrido de assinatura de APK para proteger a identidade de assinatura do seu app contra a possível ameaça de ataques que usam computação quântica. Esse recurso apresenta um novo esquema de assinatura de APK, que permite parear uma chave de assinatura clássica (como RSA ou EC) com um novo algoritmo de criptografia pós-quântica (PQC, na sigla em inglês) (ML-DSA).

Essa abordagem híbrida garante que seu app permaneça seguro contra futuros ataques quânticos, mantendo a compatibilidade total com versões mais antigas do Android e dispositivos que dependem da verificação de assinatura clássica.

Impacto nos desenvolvedores

  • Apps que usam a Assinatura de apps do Google Play:se você usa a Assinatura de apps do Google Play, aguarde que o Google Play ofereça a opção de fazer upgrade de uma assinatura híbrida usando uma chave PQC gerada pelo Google Play, garantindo que seu app esteja protegido sem exigir gerenciamento manual de chaves.
  • Apps que usam chaves autogerenciadas:os desenvolvedores que gerenciam as próprias chaves de assinatura podem usar ferramentas de build do Android atualizadas (como o apksigner) para fazer a rotação para uma identidade híbrida, combinando uma chave PQC com uma nova chave clássica. (Você precisa criar uma nova chave clássica. Não é possível reutilizar a antiga.)

Conectividade

O Android 17 adiciona os seguintes recursos para melhorar a conectividade de dispositivos e apps.

Redes de satélite restritas

Implementa otimizações para permitir que os apps funcionem de maneira eficaz em redes de satélite de baixa largura de banda.

Experiência do usuário e interface do sistema

O Android 17 inclui as seguintes mudanças para melhorar a experiência do usuário.

Stream de volume dedicada do Google Assistente

Android 17 为 Google 助理应用引入了专用的 Google 助理音量流， 以便使用 USAGE_ASSISTANT 进行播放。此项更改将 Google 助理音频与标准媒体流分离，让用户可以单独控制这两个音量。这样便可实现以下场景：将媒体播放静音，同时保持 Google 助理响应的可听性，反之亦然。

有权访问新的 MODE_ASSISTANT_CONVERSATION 音频模式的 Google 助理应用可以进一步提高音量控制的一致性。Google 助理应用可以使用此模式向系统提供有关活跃 Google 助理会话的提示，确保可以在活跃 USAGE_ASSISTANT 播放之外或使用连接的蓝牙外设控制 Google 助理流。

Handoff

O Handoff é um novo recurso e API que chegará ao Android 17 e que os desenvolvedores de apps podem integrar para oferecer continuidade entre dispositivos aos usuários. Ele permite que o usuário inicie uma atividade de app em um dispositivo Android e a transfira para outro. O Handoff é executado em segundo plano no dispositivo de um usuário e mostra as atividades disponíveis dos outros dispositivos próximos do usuário em vários pontos de entrada, como a tela de início e a barra de tarefas, no dispositivo receptor.

Os apps podem designar o Handoff para iniciar o mesmo app Android nativo, se ele estiver instalado e disponível no dispositivo receptor. Nesse fluxo de app para app, o usuário é vinculado diretamente à atividade designada. Como alternativa, o Handoff de app para Web pode ser oferecido como uma opção de fallback ou implementado diretamente com o Handoff de URL.

O suporte ao Handoff é implementado por atividade. Para ativar o Handoff, chame o setHandoffEnabled() método da atividade. Outros dados podem precisar ser transmitidos com a transferência para que a atividade recriada no dispositivo receptor possa restaurar o estado apropriado. Implemente o onHandoffActivityDataRequested() callback para retornar um HandoffActivityData objeto que contém detalhes que especificam como o Handoff precisa processar e recriar a atividade no dispositivo receptor.

Atualização em tempo real: API de cores semânticas

Com o Android 17, a Atualização em tempo real lança as APIs de coloração semântica para oferecer suporte a cores com significado universal.

As seguintes classes oferecem suporte à coloração semântica:

Colorir

  • Verde: associado à segurança. Essa cor deve ser usada quando você quiser informar às pessoas que estão em uma situação segura.
  • Laranja: para designar cautela e marcar perigos físicos. Essa cor deve ser usada quando os usuários precisam prestar atenção para definir uma melhor configuração de proteção.
  • Vermelho: geralmente indica perigo, pare. Ele deve ser apresentado quando as pessoas precisam de atenção urgente.
  • Azul: cor neutra para conteúdo que é informativo e precisa se destacar de outros conteúdos.

O exemplo a seguir mostra como aplicar estilos semânticos ao texto em uma notificação:

  val ssb = SpannableStringBuilder()
        .append("Colors: ")
        .append("NONE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_UNSPECIFIED), 0)
        .append(", ")
        .append("INFO", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_INFO), 0)
        .append(", ")
        .append("SAFE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_SAFE), 0)
        .append(", ")
        .append("CAUTION", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_CAUTION), 0)
        .append(", ")
        .append("DANGER", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_DANGER), 0)

    Notification.Builder(context, channelId)
          .setSmallIcon(R.drawable.ic_icon)
          .setContentTitle("Hello World!")
          .setContentText(ssb)
          .setOngoing(true)
              .setRequestPromotedOngoing(true)

API UWB Downlink-TDoA para Android 17

借助下行链路到达时间差 (DL-TDoA) 测距功能，设备可以通过测量信号的相对到达时间来确定其相对于多个锚点的相对位置。

以下代码段演示了如何初始化 测距管理器、验证设备功能以及启动 DL-TDoA 会话：

Kotlin

class RangingApp {

    fun initDlTdoa(context: Context) {
        // Initialize the Ranging Manager
        val rangingManager = context.getSystemService(RangingManager::class.java)

        // Register for device capabilities
        val capabilitiesCallback = object : RangingManager.RangingCapabilitiesCallback {
            override fun onRangingCapabilities(capabilities: RangingCapabilities) {
                // Make sure Dl-TDoA is supported before starting the session
                if (capabilities.uwbCapabilities != null && capabilities.uwbCapabilities!!.isDlTdoaSupported) {
                    startDlTDoASession(context)
                }
            }
        }
        rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback)
    }

    fun startDlTDoASession(context: Context) {

        // Initialize the Ranging Manager
        val rangingManager = context.getSystemService(RangingManager::class.java)

        // Create session and configure parameters
        val executor = Executors.newSingleThreadExecutor()
        val rangingSession = rangingManager.createRangingSession(executor, RangingSessionCallback())
        val rangingRoundIndexes = byteArrayOf(0)
        val config: ByteArray = byteArrayOf() // OOB config data
        val params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes)

        val rangingDevice = RangingDevice.Builder().build()
        val rawTagDevice = RawRangingDevice.Builder()
            .setRangingDevice(rangingDevice)
            .setDlTdoaRangingParams(params)
            .build()

        val dtTagConfig = RawDtTagRangingConfig.Builder(rawTagDevice).build()

        val preference = RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
            .setSessionConfig(SessionConfig.Builder().build())
            .build()

        // Start the ranging session
        rangingSession.start(preference)
    }
}

private class RangingSessionCallback : RangingSession.Callback {
    override fun onDlTdoaResults(peer: RangingDevice, measurement: DlTdoaMeasurement) {
        // Process measurement results here
    }
}

Java

public class RangingApp {

    public void initDlTdoa(Context context) {

        // Initialize the Ranging Manager
        RangingManager rangingManager = context.getSystemService(RangingManager.class);

        // Register for device capabilities
        RangingManager.CapabilitiesCallback capabilitiesCallback = new RangingManager.RangingCapabilitiesCallback() {
            @Override
            public void onRangingCapabilities(RangingCapabilities capabilities) {
                // Make sure Dl-TDoA is supported before starting the session
                if (capabilities.getUwbCapabilities() != null && capabilities.getUwbCapabilities().isDlTdoaSupported()) {
                    startDlTDoASession(context);
                }
            }
        };
        rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback);
    }

    public void startDlTDoASession(Context context) {
        RangingManager rangingManager = context.getSystemService(RangingManager.class);

        // Create session and configure parameters
        Executor executor = Executors.newSingleThreadExecutor();
        RangingSession rangingSession = rangingManager.createRangingSession(executor, new RangingSessionCallback());
        byte[] rangingRoundIndexes = new byte[] {0};
        byte[] config = new byte[0]; // OOB config data
        DlTdoaRangingParams params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes);

        RangingDevice rangingDevice = new RangingDevice.Builder().build();
        RawRangingDevice rawTagDevice = new RawRangingDevice.Builder()
                .setRangingDevice(rangingDevice)
                .setDlTdoaRangingParams(params)
                .build();

        RawDtTagRangingConfig dtTagConfig = new RawDtTagRangingConfig.Builder(rawTagDevice).build();

        RangingPreference preference = new RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
                .setSessionConfig(new SessionConfig.Builder().build())
                .build();

        // Start the ranging session
        rangingSession.start(preference);
    }

    private static class RangingSessionCallback implements RangingSession.Callback {

        @Override
        public void onDlTdoaResults(RangingDevice peer, DlTdoaMeasurement measurement) {
            // Process measurement results here
        }
    }
}

带外 (OOB) 配置

以下代码段提供了 Wi-Fi 和 BLE 的 DL-TDoA OOB 配置数据示例：

Java

// Wifi Configuration
byte[] wifiConfig = {
    (byte) 0xDD, (byte) 0x2D, (byte) 0x5A, (byte) 0x18, (byte) 0xFF, // Header
    (byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
    (byte) 0x02, (byte) 0x00, // Profile ID
    (byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
    (byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
    (byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
    (byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
    (byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
    (byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
    (byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
    (byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01  // Session ID
};

// BLE Configuration
byte[] bleConfig = {
    (byte) 0x2D, (byte) 0x16, (byte) 0xF4, (byte) 0xFF, // Header
    (byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
    (byte) 0x02, (byte) 0x00, // Profile ID
    (byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
    (byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
    (byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
    (byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
    (byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
    (byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
    (byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
    (byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01  // Session ID
};

如果您无法使用 OOB 配置（因为缺少该配置），或者需要更改 OOB 配置中没有的默认值，则可以使用 DlTdoaRangingParams.Builder 构建参数，如以下代码段所示。您可以使用这些参数来代替 DlTdoaRangingParams.createFromFiraConfigPacket()：

Kotlin

val dlTdoaParams = DlTdoaRangingParams.Builder(1)
    .setComplexChannel(UwbComplexChannel.Builder()
            .setChannel(9).setPreambleIndex(10).build())
    .setDeviceAddress(deviceAddress)
    .setSessionKeyInfo(byteArrayOf(0x01, 0x02, 0x03, 0x04))
    .setRangingIntervalMillis(240)
    .setSlotDuration(UwbRangingParams.DURATION_2_MS)
    .setSlotsPerRangingRound(20)
    .setRangingRoundIndexes(byteArrayOf(0x01, 0x05))
    .build()

Java

DlTdoaRangingParams dlTdoaParams = new DlTdoaRangingParams.Builder(1)
    .setComplexChannel(new UwbComplexChannel.Builder()
            .setChannel(9).setPreambleIndex(10).build())
    .setDeviceAddress(deviceAddress)
    .setSessionKeyInfo(new byte[]{0x01, 0x02, 0x03, 0x04})
    .setRangingIntervalMillis(240)
    .setSlotDuration(UwbRangingParams.DURATION_2_MS)
    .setSlotsPerRangingRound(20)
    .setRangingRoundIndexes(new byte[]{0x01, 0x05})
    .build();