Mudanças de comportamento: apps destinados ao Android 16 ou versões mais recentes

Como nas versões anteriores, o Android 16 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam exclusivamente a apps que segmentam o Android 16 ou versões mais recentes. Se o app for direcionado ao Android 16 ou a versões mais recentes, faça modificações para oferecer suporte a esses comportamentos, quando aplicável.

Consulte também a lista de mudanças de comportamento que afetam todos os apps executados no Android 16, independente da targetSdkVersion do seu app.

Experiência do usuário e interface do sistema

O Android 16 (nível 36 da API) inclui as seguintes mudanças que visam criar uma experiência do usuário mais consistente e intuitiva.

A opção de recusa de ponta a ponta vai ser desativada

O Android 15 impôs a exibição de ponta a ponta para apps destinados ao Android 15 (nível 35 da API), mas o app pode desativar essa opção definindo R.attr#windowOptOutEdgeToEdgeEnforcement como true. Para apps destinados ao Android 16 (nível 36 da API), R.attr#windowOptOutEdgeToEdgeEnforcement foi descontinuado e desativado, e o app não pode desativar a exibição de ponta a ponta.

• Se o app for destinado ao Android 16 (nível da API 36) e estiver em execução em um dispositivo Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement vai continuar funcionando.
• Se o app for destinado ao Android 16 (nível da API 36) e estiver em execução em um dispositivo Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement será desativado.

Para testes no Android 16, verifique se o app oferece suporte à exibição de ponta a ponta e remova qualquer uso de R.attr#windowOptOutEdgeToEdgeEnforcement para que o app também ofereça suporte à exibição de ponta a ponta em um dispositivo Android 15. Para oferecer suporte à exibição de ponta a ponta, consulte as orientações do Compose e das visualizações.

Migração ou desativação necessárias para a volta preditiva

Em apps direcionados ao Android 16 (nível 36 da API) ou mais recente e executados em um dispositivo Android 16 ou mais recente, as animações preditivas do sistema de retorno (voltar para a tela inicial, entre tarefas e entre atividades) são ativadas por padrão. Além disso, onBackPressed não é chamado, e KeyEvent.KEYCODE_BACK não é mais enviado.

Se o app interceptar o evento de retorno e você ainda não tiver migrado para a volta preditiva, atualize o app para usar as APIs de navegação de retorno compatíveis ou desative temporariamente definindo o atributo android:enableOnBackInvokedCallback como false na tag <application> ou <activity> do arquivo AndroidManifest.xml do app.

Animação de volta preditiva à página inicial.

Animação preditiva entre atividades.

Animação preditiva entre tarefas.

APIs de fontes elegantes descontinuadas e desativadas

Os apps destinados ao Android 15 (nível 35 da API) têm o atributo elegantTextHeight TextView definido como true por padrão, substituindo a fonte compacta por uma muito mais legível. É possível substituir isso definindo o atributo elegantTextHeight como false.

O Android 16 descontinua o atributo elegantTextHeight, que será ignorado quando o app for destinado ao Android 16. As "fontes da interface" controladas por essas APIs serão descontinuadas. Por isso, adapte todos os layouts para garantir a renderização de texto consistente e à prova de futuro em árabe, laosiano, birmanês, tâmil, gujarati, canarês, malaiala, odia, télugo ou tailandês.

Comportamento de

elegantTextHeight para apps destinados ao Android 14 (nível 34 da API) e versões anteriores ou para apps destinados ao Android 15 (nível 35 da API) que substituíram o padrão definindo o atributo elegantTextHeight como false.

Comportamento de

elegantTextHeight para apps direcionados ao Android 16 (nível 36 da API) ou ao Android 15 (nível 35 da API) que não substituíram o padrão definindo o atributo elegantTextHeight como false.

Principal recurso

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

Otimização de programação de trabalho com taxa fixa

Antes de segmentar o Android 16, quando o scheduleAtFixedRate perdia uma execução de tarefa por estar fora de um ciclo de vida do processo válido, todas as execuções perdidas eram executadas imediatamente quando o app retornava a um ciclo de vida válido.

Ao segmentar o Android 16, no máximo uma execução perdida de scheduleAtFixedRate é executada imediatamente quando o app retorna a um ciclo de vida válido. Essa mudança de comportamento deve melhorar o desempenho do app. Teste esse comportamento no seu app para verificar se ele é afetado. Também é possível testar usando o framework de compatibilidade de apps e ativando a flag de compatibilidade STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Formatos de dispositivos

O Android 16 (nível 36 da API) inclui as seguintes mudanças para apps quando mostrados em dispositivos de tela grande.

Layouts adaptáveis

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口化模式），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备屏幕方向如何。在当今的多设备世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，屏幕方向、尺寸可调整性和宽高比限制不再适用于最小宽度 >= 600dp 的显示屏。无论宽高比或用户偏好的屏幕方向如何，应用都会填满整个显示窗口，且不会采用竖条模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素，例如布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

对于显示屏可调整大小性，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 没有影响。

对于以 Android 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用的屏幕方向、可调整尺寸性和宽高比限制，但尚未完全准备就绪的每个应用都可以选择停用此行为，从而暂时替换此行为（这会导致应用恢复到之前放置在兼容模式下的行为）。

例外情况

在以下情况下，Android 16 的屏幕方向、尺寸调整能力和宽高比限制不适用：

• 游戏（基于 android:appCategory 标志）
• 用户在设备的宽高比设置中明确选择启用应用的默认行为
• 小于 sw600dp 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY 清单属性：

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

如果您的应用有太多部分尚未准备好支持 Android 16，您可以在应用级别应用相同的属性，从而完全选择不启用该功能：

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

重要提示： 此选择停用是临时性的，在未来的 Android 版本中以 API 级别 37 为目标平台时，此选择停用将不再适用。也就是说，对于以 API 级别 37 为目标的应用，在至少为 sw600dp 的显示屏上，系统会忽略屏幕方向、尺寸可调整性和宽高比限制。

Saúde e fitness

O Android 16 (nível da API 36) inclui as seguintes mudanças relacionadas a dados de saúde e condicionamento físico.

Permissões de saúde e fitness

对于以 Android 16（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• HEART_RATE_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
• FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度： 请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、 健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须 声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

**重要提示：** 如果未能为移动应用提供理由，系统将撤消相应 权限。

Conectividade

O Android 16 (nível 36 da API) inclui as seguintes mudanças na pilha Bluetooth para melhorar a conectividade com dispositivos periféricos.

Novas intents para lidar com perda de vinculação e mudanças na criptografia

Como parte do Processamento de perda de vínculo aprimorado, o Android 16 também apresenta duas novas intents para dar aos apps mais consciência da perda de vínculo e mudanças de criptografia.

Os apps destinados ao Android 16 agora podem:

• Receber uma intent ACTION_KEY_MISSING quando a perda de vínculo remoto é detectada, permitindo que eles forneçam feedback mais informativo ao usuário e realizem ações adequadas.
• Receba uma intent ACTION_ENCRYPTION_CHANGE sempre que o status de criptografia do link mudar. Isso inclui a mudança de status de criptografia, de algoritmo de criptografia e de tamanho da chave de criptografia. Os apps precisam considerar a vinculação restaurada se o link for criptografado ao receber a intent ACTION_ENCRYPTION_CHANGE mais tarde.

Como se adaptar a diferentes implementações de OEM

Embora o Android 16 apresente essas novas intents, a implementação e a transmissão delas podem variar de acordo com os diferentes fabricantes de dispositivos (OEMs). Para garantir que o app ofereça uma experiência consistente e confiável em todos os dispositivos, os desenvolvedores precisam projetar o processamento de perda de vínculo para se adaptar a essas variações.

Recomendamos os seguintes comportamentos do app:

• Se a intent ACTION_KEY_MISSING for transmitida:

  O link ACL (Asynchronous Connection-Less) será desconectado pelo sistema, mas as informações de vinculação do dispositivo serão mantidas, conforme descrito aqui.

  Seu app precisa usar essa intent como o indicador principal para a detecção de perda de conexão e orientar o usuário a confirmar se o dispositivo remoto está no alcance antes de iniciar o esquecimento ou o novo pareamento do dispositivo.

  Se um dispositivo se desconectar depois que o ACTION_KEY_MISSING for recebido, o app precisará ter cuidado ao se reconectar, porque o dispositivo pode não estar mais vinculado ao sistema.

• Se a intent ACTION_KEY_MISSING NÃO for transmitida:

  O link ACL vai permanecer conectado, e as informações de vinculação do dispositivo serão removidas pelo sistema, assim como no comportamento do Android 15.

  Nesse cenário, o app precisa continuar com os mecanismos de processamento de perda de vínculo existentes, como nas versões anteriores do Android, para detectar e gerenciar eventos de perda de vínculo.

Nova maneira de remover a vinculação Bluetooth

Todos os apps destinados ao Android 16 agora podem desvincular dispositivos Bluetooth usando uma API pública em CompanionDeviceManager. Se um dispositivo complementar estiver sendo gerenciado como uma associação de CDM, o app poderá acionar a remoção de pareamento Bluetooth usando a nova API removeBond(int) no dispositivo associado. O app pode monitorar as mudanças de estado de vinculação ouvindo o evento de transmissão do dispositivo Bluetooth ACTION_BOND_STATE_CHANGED.

Segurança

O Android 16 (nível da API 36) inclui as seguintes mudanças de segurança.

Bloqueio da versão do MediaStore

Para apps destinados ao Android 16 ou mais recente, o MediaStore#getVersion() agora será exclusivo para cada app. Isso elimina as propriedades de identificação da string de versão para evitar abuso e uso para técnicas de impressão digital. Os apps não podem fazer suposições sobre o formato dessa versão. Os apps já precisam processar mudanças de versão ao usar essa API e, na maioria dos casos, não precisam mudar o comportamento atual, a menos que o desenvolvedor tenha tentado inferir informações adicionais que estão além do escopo pretendido dessa API.

Intents mais seguras

“更安全的 intent”功能是一项多阶段安全计划，旨在提高 Android 的 intent 解析机制的安全性。其目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的影响。

在 Android 15 中，此功能侧重于发送应用，而现在在 Android 16 中，控制权转移到了接收应用，开发者可以使用应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器匹配：如果 intent 显式以某个组件为目标，则应与该组件的 intent 过滤器匹配。

2. 没有操作的 intent 无法与任何 intent 过滤器匹配：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

由于此功能是选择启用，因此开发者必须在应用清单中明确启用此功能，才能使其生效。因此，此功能的影响将仅限于以下应用：

• 了解“更安全的 intent”功能及其优势。
• 主动选择将更严格的 intent 处理实践融入到其应用中。

这种选择启用方法可最大限度地降低破坏可能依赖于当前安全性较低的 intent 解析行为的现有应用的风险。

虽然在 Android 16 中的初始影响可能有限，但“更安全的 intent”计划制定了在未来的 Android 版本中扩大影响的路线图。 该计划最终将使严格的 intent 解析成为默认行为。

“更安全的 intent”功能通过使恶意应用更难利用 intent 解析机制中的漏洞，有可能显著增强 Android 生态系统的安全性。

不过，向选择退出和强制执行的过渡必须经过仔细管理，以解决与现有应用潜在的兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。 以下示例展示了如何为整个应用选择启用此功能，但在接收器上停用/选择停用此功能：

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

注意： 可以在 <application> 标记以及组件标记（例如 <activity>、<activity-alias>、<receiver>、<service>、<provider>）上指定该属性，并且可以使用组件上的属性替换 <application> 标记上的属性

详细了解支持的标志：

标志名称	说明
enforceIntentFilter	对传入 intent 强制执行更严格的匹配
none	停用传入 intent 的所有特殊匹配规则。指定多个标志时，系统会优先使用“none”标志来解决冲突值
allowNullAction	放宽匹配规则，允许没有操作的 intent 进行匹配。此标志应与“enforceIntentFilter”结合使用，以实现特定行为

测试和调试

启用强制执行后，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息，例如 "Intent does not match component's intent filter:" 和 "Access blocked:" ，并带有标记 "PackageManager." 。这表示可能存在影响应用的问题，需要引起 注意。

Logcat 过滤器：

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Filtragem de syscalls da GPU

为了加固 Mali GPU Surface，我们已在生产版本中屏蔽了已废弃或仅用于 GPU 开发的 Mali GPU IOCTL。 此外，用于 GPU 性能剖析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策，请参阅 SAC 更新。

此项变更适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 release 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。

测试

如果您看到类似以下内容的 SELinux 拒绝，则您的应用很可能受到了此项变更的影响：

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

如果您的应用需要使用被屏蔽的 IOCTL，请提交 bug 并将其分配给 [e-mail]。

常见问题解答

1. 此项政策变更是否适用于所有 OEM？ 此项变更将采用选择启用模式，但任何想要使用此加固方法的原始设备制造商(OEM)都可以使用。如需了解如何实现此项变更，请参阅实现文档。

2. 是否必须在 OEM 代码库中进行更改才能实现此项变更，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本提供。供应商可以选择在其代码库中启用此项变更，以便应用此项变更。

3. SoC 是否负责让 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何变更与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 IOCTL 列表。 例如，ARM 会在驱动程序更新后更新其发布的 IOCTL 列表。 不过，OEM 应确保将更新纳入其 SEPolicy，并根据需要将任何选定的自定义 IOCTL 添加到列表中。

4. 此项变更是否会自动应用于所有在售 Pixel 设备，还是需要用户执行操作来切换某些内容以应用此项变更？ 此项变更适用于所有使用 Mali GPU 的在售 Pixel 设备（Pixel 6-9）。无需用户执行任何操作即可应用此项变更。

5. 使用此政策是否会影响内核驱动程序的性能？ 我们已使用 GFXBench 在 Mali GPU 上对此政策进行了测试，未观察到 GPU 性能发生任何可衡量的变化。

6. IOCTL 列表是否需要与当前的用户空间和内核驱动程序版本保持一致？是，允许的 IOCTL 列表必须与用户空间和内核驱动程序支持的 IOCTL 同步。如果用户空间或内核驱动程序中的 IOCTL 发生更新，则必须更新 SEPolicy IOCTL 列表以进行匹配。

7. ARM 已将 IOCTL 分类为“受限”/“检测”，但我们希望在生产用例中使用其中的一些 IOCTL，并/或拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置，决定如何对其使用的 IOCTL 进行分类。 ARM 的列表可用于帮助决定这些内容，但每个 OEM/SoC 的用例可能有所不同。

Privacidade

O Android 16 (nível da API 36) inclui as seguintes mudanças de privacidade.

Permissão de rede local

Qualquer app com a permissão INTERNET pode acessar dispositivos na LAN. Isso facilita a conexão de apps a dispositivos locais, mas também tem implicações de privacidade, como a formação de uma impressão digital do usuário e a atuação como um proxy de localização.

O projeto de proteções de rede local visa proteger a privacidade do usuário, restringindo o acesso à rede local por trás de uma nova permissão de execução.

Plano de lançamento

Essa mudança será implementada entre duas versões, 25Q2 e 26Q2 , respectivamente. É fundamental que os desenvolvedores sigam estas orientações para a 25Q2 e compartilhem feedback, porque essas proteções serão aplicadas em uma versão mais recente do Android. Além disso, eles precisarão atualizar os cenários que dependem do acesso implícito à rede local usando as orientações a seguir e se preparar para a rejeição e revogação da nova permissão pelo usuário.

Impacto

Na fase atual, a LNP é um recurso opcional, o que significa que apenas os apps que ativarem essa opção serão afetados. O objetivo da fase de ativação é que os desenvolvedores de apps entendam quais partes do app dependem do acesso implícito à rede local para que possam se preparar para proteger a permissão na próxima versão.

Os apps serão afetados se acessarem a rede local do usuário usando:

• Uso direto ou de biblioteca de soquetes brutos em endereços de rede local (por exemplo, protocolo de descoberta de serviço mDNS ou SSDP)
• Uso de classes de nível de framework que acessam a rede local (por exemplo, NsdManager)

O tráfego para e de um endereço de rede local exige permissão de acesso à rede local. A tabela a seguir lista alguns casos comuns:

Operação de rede de baixo nível do app	Permissão de rede local necessária
Fazer uma conexão TCP de saída	sim
Aceitar conexões TCP recebidas	sim
Enviar uma transmissão UDP unicast, multicast, broadcast	sim
Receber uma transmissão UDP unicast, multicast, broadcast	sim

Essas restrições são implementadas profundamente na pilha de rede e, portanto, se aplicam a todas as APIs de rede. Isso inclui soquetes criados em código nativo ou gerenciado, bibliotecas de rede como Cronet e OkHttp e todas as APIs implementadas sobre elas. A tentativa de resolver serviços na rede local (ou seja, aqueles com um sufixo .local) exigirá permissão de rede local.

**Observação** :o tráfego originado de Webviews do Android que exigem acesso à rede local vai herdar o estado de permissão do app host.

Exceções às regras acima:

• Se o servidor DNS de um dispositivo estiver em uma rede local, o tráfego de ou para ele (na porta 53) não exigirá permissão de acesso à rede local.
• Os aplicativos que usam o Output Switcher como seletor no app não vão precisar de permissões de rede local (mais orientações serão fornecidas no quarto trimestre de 2025).

Observação: muitos cenários de transmissão de mídia dependem do acesso à rede local e serão afetados por essa mudança. No entanto, nem todos os apps que oferecem transmissão precisarão solicitar a nova permissão. As futuras APIs e orientações para lidar com cenários de transmissão serão fornecidas no quarto trimestre de 2025.

Orientação para desenvolvedores (ativação)

Para ativar as restrições de rede local, faça o seguinte:

1. Atualize o dispositivo para uma versão com o Android 25Q2 Beta 3 ou mais recente.
2. Instale o app a ser testado.

3. Ative a flag Appcompat no adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reinicialize o dispositivo

Agora, o acesso do app à rede local está restrito, e qualquer tentativa de acesso à rede local vai gerar erros de soquete. Se você estiver usando APIs que realizam operações de rede local fora do processo do app (por exemplo, NsdManager), elas não serão afetadas durante a fase de ativação.

Para restaurar o acesso, conceda ao app a permissão NEARBY_WIFI_DEVICES.

1. Verifique se o app declara a permissão NEARBY_WIFI_DEVICES no manifesto.
2. Acesse Configurações > Apps > [Nome do aplicativo] > Permissões > Dispositivos por perto > Permitir.

Observação: Em uma versão futura do Android, esse recurso será protegido por uma nova permissão no grupo de permissões de dispositivos por perto.

Agora, o acesso do app à rede local será restaurado, e todos os cenários vão funcionar como antes da ativação do app.

Quando a aplicação da proteção de rede local começar, o tráfego de rede do app será afetado da seguinte maneira.

Permissão	Solicitação de LAN de saída	Solicitação de saída/entrada da Internet	Solicitação de LAN de entrada
Concedido	funciona	funciona	funciona
Não concedido	Falhas	funciona	Falhas

Use o comando a seguir para desativar a flag de compatibilidade do app

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erros

Os erros decorrentes dessas restrições serão retornados ao soquete de chamada sempre que ele invocar o envio ou uma variante de envio para um endereço de rede local.

Exemplo de erros:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definição de rede local

Uma rede local neste projeto se refere a uma rede IP que utiliza uma interface de rede com capacidade de transmissão, como Wi-Fi ou Ethernet, mas exclui conexões de rede celular (WWAN) ou VPN.

As seguintes são consideradas redes locais:

IPv4 :

• 169.254.0.0/16 // Link local
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6 :

• Link-local
• Rotas conectadas diretamente
• Redes stub como Thread
• Várias sub-redes (TBD)

Além disso, os endereços multicast (224.0.0.0/4, ff00::/8) e o endereço de transmissão IPv4 (255.255.255.255) são classificados como endereços de rede local.

Fotos do app

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。