Mudanças de comportamento: todos os apps

A plataforma Android 17 inclui mudanças de comportamento que podem afetar seu app. As mudanças a seguir se aplicam a todos os apps quando executados no Android 17, independente da targetSdkVersion. Teste o app e modifique-o conforme necessário para oferecer suporte a essas mudanças, se necessário.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 17.

Observação: esta página lista algumas das mudanças mais importantes. Para mais detalhes, consulte as notas da versão do Android 17.

Principal recurso

O Android 17 (nível da API 37) inclui as seguintes mudanças que modificam ou expandem vários recursos principais do sistema Android.

Limites de memória para apps

O Android 17 apresenta limites de memória para apps com base na RAM total do dispositivo para criar um ambiente mais estável e determinístico para seus apps e usuários do Android. Esses limites se concentram em vazamentos de memória e outros outliers antes que eles causem instabilidade em todo o sistema, resultando em renderização lenta da interface, consumo elevado da bateria e encerramento de apps. Embora prevemos um impacto mínimo na grande maioria das sessões de apps, recomendamos as práticas recomendadas de memória a seguir, incluindo o estabelecimento de uma linha de base para a memória.

Você pode determinar se a sessão do app foi afetada chamando getDescription em ApplicationExitInfo. Se o app foi afetado, o motivo de saída será REASON_OTHER e a descrição vai conter a string "MemoryLimiter:AnonSwap", além de outras informações. Você também pode usar a criação de perfil baseada em acionadores com TRIGGER_TYPE_ANOMALY para receber despejos de heap coletados quando o limite de memória é atingido.

A documentação Gerenciar a memória do app fornece informações para ajudar a diagnosticar problemas de memória do app e otimizar o consumo de recursos.

Testar o comportamento do app nas restrições de memória

Você pode usar Android Debug Bridge (adb) para ajustar ou desativar os limites de memória em qualquer dispositivo que os imponha. O comando de shell am fornece três subcomandos para ajustar os limites de memória. Esses comandos não têm efeito em um dispositivo que não impõe limites de memória.

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

Instrui o limitador de memória a ignorar alguns ou todos os processos. A transmissão de um UID (ID de usuário do Android) instrui o limitador de memória a ignorar a aplicação em todos os processos associados a esse UID. Você também pode transmitir all (ignorar todos os apps) ou none (não ignorar nenhum app). A transmissão de none substitui todas as chamadas anteriores para am memory-limiter ignore.

Se você instruir o limitador de memória a ignorar um UID, ainda poderá aplicar um limite de memória manual a um processo no app chamando am memory-limiter manual.

manual

Instrui o sistema a impor uma restrição de memória ao processo com o PID (ID do processo) especificado. A restrição de memória é especificada como um número inteiro de MB. Por exemplo, a transmissão de 30 especifica que o processo está limitado a 30 MB de memória. A transmissão de max remove todos os limites de memória nesse processo. A transmissão de none remove todos os limites manuais definidos no processo, restaurando o limite padrão do sistema (se houver).

status

Informa o status atual do limitador de memória. O status inclui os limites de memória impostos a processos visíveis e não visíveis.

Privacidade

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

Proteção de OTP por SMS

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以编程方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信助理应用、关联设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 OTP 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

注意 ：如果您的应用以 Android 17（API 级别 37）或更高版本为目标平台，此 保护也会扩展到标准短信。如需了解详情，请参阅 标准短信的 OTP 保护在 行为变更： 以 Android 17 为目标平台的应用文档中。

Segurança

O Android 17 inclui as seguintes melhorias na segurança de dispositivos e apps.

Plano de descontinuação de usesClearTraffic

我们计划在未来的版本中弃用 usesCleartextTraffic 元素。需要建立未加密 (HTTP) 连接的应用应迁移为使用网络安全配置文件，该文件可让您指定应用需要与哪些网域建立明文连接。

请注意，网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24，您应执行以下两项操作：

• 将 usesCleartextTraffic 属性设置为 true
• 使用网络配置文件

如果应用的最低 API 级别为 24 或更高，您可以使用网络配置文件，而无需设置 usesCleartextTraffic。

Restrição das concessões implícitas de URI

目前，如果应用启动的 intent 具有 URI，且该 URI 具有操作 ACTION_SEND、ACTION_SEND_MULTIPLE或 ACTION_IMAGE_CAPTURE，则系统会自动向目标应用授予读取和 写入 URI 权限。从 Android 18 开始，系统将 不再自动授予这些权限。因此，我们建议应用明确授予相关 URI 权限，而不是依赖系统授予这些权限。

如需检测应用中这些 intent 的使用情况，请将 StrictMode 与 detectImplicitUriPermissionGrant() 结合使用，以触发违规行为：

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

或者，您也可以监控包含消息 Please set the grant explicitly in the app 的已记录异常，该消息会在系统隐式设置授予时显示。您可以使用以下 adb 命令监控这些日志：

adb logcat | grep "Please set the grant explicitly in the app"

如需明确授予必要的权限，请将 FLAG_GRANT_READ_URI_PERMISSION标志添加到ACTION_SEND和 ACTION_SEND_MULTIPLEintent：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

对于 ACTION_IMAGE_CAPTURE intent，请同时添加FLAG_GRANT_READ_URI_PERMISSION 和 FLAG_GRANT_WRITE_URI_PERMISSION 标志：

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Limites de keystore por app

应用应避免在 Android 密钥库中创建过多的密钥，因为它是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，密钥数量上限为 50,000 个；对于所有其他应用，密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标，其密钥数量上限均为 20 万。

如果应用尝试创建超出限制的密钥，则创建会失败并显示 KeyStoreException。异常的消息字符串包含有关密钥限制的信息。如果应用针对异常调用 getNumericErrorCode()，则返回值取决于应用的目标 API 级别：

• 如果应用以 Android 17（API 级别 37）或更高版本为目标平台，getNumericErrorCode() 会返回新的 ERROR_TOO_MANY_KEYS 值。
• 所有其他应用：getNumericErrorCode() 返回 ERROR_INCORRECT_USAGE。

Bloquear o tráfego de loopback entre perfis unificados

A partir do Android 17, o tráfego de loopback entre perfis não é mais permitido por padrão. O tráfego de loopback no mesmo perfil não é afetado. Essa mudança se aplica a todos os apps executados no Android 17 ou mais recente, independentemente do nível da API a que o app se destina.

Experiência do usuário e interface do sistema

O Android 17 inclui as seguintes mudanças que visam criar uma experiência do usuário mais consistente e intuitiva.

Restauração da visibilidade padrão do IME após a rotação

A partir do Android 17, quando a configuração do dispositivo muda (por exemplo, devido à rotação) e isso não é processado pelo próprio app, a visibilidade anterior do IME não é restaurada.

Se o app passar por uma mudança de configuração que ele não processa e precisar que o teclado fique visível após a mudança, você precisará solicitar isso explicitamente. É possível fazer essa solicitação de uma das seguintes maneiras:

• Defina o atributo android:windowSoftInputMode como stateAlwaysVisible.
• Solicite o teclado de software de maneira programática no método onCreate() da atividade ou adicione o método onConfigurationChanged().

Contribuição humana

O Android 17 inclui as seguintes mudanças que afetam a forma como os apps interagem com dispositivos de entrada humana, como teclados e touchpads.

Os touchpads oferecem eventos relativos por padrão durante a captura de ponteiro

从 Android 17 开始，如果应用使用 View.requestPointerCapture() 请求捕获指针，并且用户使用触控板，系统会识别用户触摸操作产生的指针移动和滚动手势，并以与捕获的鼠标产生的指针和滚轮移动相同的方式将这些信息报告给应用。在大多数情况下，这使得支持捕获鼠标的应用无需为触控板添加特殊的处理逻辑。如需了解详情，请参阅 View.POINTER_CAPTURE_MODE_RELATIVE 的文档。

之前，系统不会尝试识别触控板的手势，而是以类似于触摸屏触摸的格式将原始的绝对手指位置传递给应用。如果应用仍需要此绝对数据，则应改为使用 View.POINTER_CAPTURE_MODE_ABSOLUTE 调用新的 View.requestPointerCapture(int) 方法。

Mídia

O Android 17 inclui as seguintes mudanças no comportamento de mídia.

Reforço da proteção de áudio em segundo plano

A partir do Android 17, o framework de áudio aplica restrições às interações de áudio em segundo plano, incluindo reprodução de áudio, solicitações de foco de áudio e APIs de mudança de volume, para garantir que essas mudanças sejam iniciadas intencionalmente pelo usuário.

Se o app tentar chamar APIs de áudio enquanto não estiver em um ciclo de vida válido, as APIs de reprodução de áudio e mudança de volume falharão silenciosamente, sem gerar uma exceção ou fornecer uma mensagem de falha. A API de seleção de áudio falha com o código de resultado AUDIOFOCUS_REQUEST_FAILED.

**Observação** :as restrições são mais rigorosas se um app for destinado ao Android 17 (nível da API 37). Para esses apps, o serviço em primeiro plano precisa ter recursos de uso durante o uso (WIU, na sigla em inglês), a menos que o app tenha a permissão de alarme exata e esteja interagindo com streams de áudio USAGE_ALARM.

Para mais informações, incluindo estratégias de mitigação, consulte Reforço da proteção de áudio em segundo plano.

Conectividade

O Android 17 inclui as seguintes mudanças para melhorar a conectividade do dispositivo.

Novo pareamento autônomo para perdas de vinculação Bluetooth

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙配对信息丢失问题。

以前，如果配对信息丢失，用户必须手动前往“设置”取消配对，然后重新配对外围设备。此功能以 Android 16 的安全改进为基础，允许系统在后台重新建立配对信息，而无需用户手动前往“设置”取消配对并重新配对外围设备。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

• 新的配对上下文： ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，允许应用区分 标准配对请求和自主系统发起的重新配对尝试。
• 有条件的密钥更新：只有在重新配对成功且新连接达到或超过之前配对信息的安全级别时，才会替换现有安全密钥。
• 修改后的 intent 时间：现在，只有在自主重新配对尝试失败时，才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复配对信息，则可以减少应用中不必要的错误处理。
• 用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保用户了解重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理配对信息转换。如需测试此行为，请使用以下任一方法模拟远程配对信息丢失：

• 从外围设备中手动移除配对信息
• 在“设置”>“已连接的设备”中手动取消配对设备