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 abaixo se aplicam exclusivamente a apps destinados ao Android 16 ou versões mais recentes. Caso seu app seja 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 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.

Fim da opção de recusar a exibição de ponta a ponta

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 opção de recusar necessária para o botão Voltar preditivo

对于以 Android 16（API 级别 36）或更高版本为目标平台且在 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

“返回主页”预测性返回动画。

预测性跨 activity 动画。

预测性跨任务动画。

APIs de fontes elegantes descontinuadas e desativadas

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

Funcionalidade principal

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

Otimização do agendamento de trabalho de taxa fixa

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 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 exibidos em dispositivos de tela grande.

Layouts adaptáveis

Com os apps Android agora sendo executados em vários dispositivos (como smartphones, tablets, dobráveis, computadores, carros e TVs) e modos de janelas em telas grandes (como tela dividida e janelas para computador), os desenvolvedores precisam criar apps Android que se adaptem a qualquer tamanho de tela e janela, independentemente da orientação do dispositivo. Paradigmas como restringir a orientação e o redimensionamento são muito restritivos no mundo de vários dispositivos de hoje.

Ignorar restrições de orientação, capacidade de redimensionamento e proporção

Para apps direcionados ao Android 16 (nível 36 da API), as restrições de orientação, redimensionamento e proporção não se aplicam mais em telas com largura mínima >= 600 dp. Os apps preenchem toda a janela de exibição, independente da proporção ou da orientação preferida do usuário, e não usam pillarboxing.

Essa mudança introduz um novo comportamento padrão da plataforma. O Android está migrando para um modelo em que os apps precisam se adaptar a várias orientações, tamanhos de tela e proporções. Restrições como orientação fixa ou redimensionamento limitado dificultam a adaptabilidade do app. Deixe seu app adaptável para oferecer a melhor experiência possível aos usuários.

Você também pode testar esse comportamento usando o framework de compatibilidade de apps e ativando a flag de compatibilidade UNIVERSAL_RESIZABLE_BY_DEFAULT.

Mudanças importantes comuns

Ignorar as restrições de orientação, redimensionamento e proporção pode afetar a interface do usuário do app em alguns dispositivos, especialmente elementos projetados para layouts pequenos bloqueados na orientação retrato. Por exemplo, problemas como layouts esticados e animações e componentes fora da tela. Qualquer pressuposto sobre proporção ou orientação pode causar problemas visuais no app. Saiba mais sobre como evitar esses problemas e melhorar o comportamento adaptável do app.

Permitir a rotação do dispositivo resulta em mais recriação de atividades, o que pode resultar na perda do estado do usuário se não for preservado adequadamente. Saiba como salvar corretamente o estado da interface em Salvar estados da interface.

Detalhes de implementação

Os seguintes atributos de manifesto e APIs de tempo de execução são ignorados em dispositivos de tela grande nos modos de tela cheia e várias janelas:

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

Os seguintes valores para screenOrientation, setRequestedOrientation() e getRequestedOrientation() são ignorados:

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

Em relação ao redimensionamento da tela, android:resizeableActivity="false", android:minAspectRatio e android:maxAspectRatio não têm efeito.

Em apps direcionados ao Android 16 (nível 36 da API), as restrições de orientação, redimensionamento e proporção são ignoradas por padrão em telas grandes. Todos os apps que não estiverem totalmente prontos poderão substituir temporariamente esse comportamento ao desativar a opção, o que resulta no comportamento anterior de ser colocado no modo de compatibilidade.

Exceções

As restrições de orientação, redimensionamento e proporção do Android 16 não se aplicam nas seguintes situações:

• Jogos (com base na flag android:appCategory)
• Usuários ativando explicitamente o comportamento padrão do app nas configurações de proporção do dispositivo
• Telas menores que sw600dp

Desativar temporariamente

Para desativar uma atividade específica, declare a propriedade PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY do manifesto:

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

Se muitas partes do seu app não estiverem prontas para o Android 16, você poderá desativar completamente aplicando a mesma propriedade no nível do aplicativo:

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

Importante: a recusa é temporária e não será aplicada ao segmentar o nível da API 37 em uma versão futura do Android. Ou seja, para apps destinados ao nível 37 da API, as restrições de orientação, redimensionamento e proporção são ignoradas em telas de pelo menos sw600dp.

Saúde e fitness

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

Permissões de saúde e fitness

Para apps direcionados ao Android 16 (nível 36 da API) ou mais recentes, as permissões BODY_SENSORS são mais granulares em android.permissions.health, um modelo adotado também pelo Conexão Saúde. No Android 16, qualquer API que antes exigia BODY_SENSORS ou BODY_SENSORS_BACKGROUND agora precisa da permissão android.permissions.health correspondente. Isso afeta os seguintes tipos de dados, APIs e tipos de serviços em primeiro plano:

• HEART_RATE_BPM dos Recursos de Saúde no Wear OS
• Sensor.TYPE_HEART_RATE do Android Sensor Manager
• heartRateAccuracy e heartRateBpm de ProtoLayout no Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH , em que a permissão android.permission.health é necessária em vez de BODY_SENSORS

Se o app usa essas APIs, ele precisa solicitar as permissões granulares respectivas:

• Para monitoramento da frequência cardíaca, SpO2 ou temperatura da pele durante o uso: solicite a permissão granular em android.permissions.health, como READ_HEART_RATE em vez de BODY_SENSORS.
• Para acesso ao sensor em segundo plano: solicite READ_HEALTH_DATA_IN_BACKGROUND em vez de BODY_SENSORS_BACKGROUND.

Essas permissões são as mesmas que protegem o acesso à leitura de dados da Conexão Saúde, o repositório de dados do Android para informações de saúde, condicionamento físico e bem-estar.

Apps para dispositivos móveis

Os apps para dispositivos móveis que migram para usar a READ_HEART_RATE e outras permissões granulares também precisam declarar uma atividade para mostrar a Política de Privacidade do app. Esse é o mesmo requisito da Conexão Saúde.

Importante: se você não fornecer a justificativa para apps para dispositivos móveis, a permissão será revogada.

Conectividade

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

Novas intents para processar a perda de vinculação e mudanças de criptografia

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

Nova maneira de remover a vinculação do 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 36 da API) inclui as seguintes mudanças de segurança.

Bloqueio da versão do MediaStore

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

Intents mais seguras

O recurso Intents mais seguros é uma iniciativa de segurança multifásica projetada para melhorar a segurança do mecanismo de resolução de intents do Android. O objetivo é proteger os apps contra ações maliciosas adicionando verificações durante o processamento de intents e filtrando intents que não atendem a critérios específicos.

No Android 15, o recurso se concentrou no app de envio. Agora, com o Android 16, o controle muda para o app de recebimento, permitindo que os desenvolvedores ativem a resolução de intents estrita usando o manifesto do app.

Duas mudanças importantes estão sendo implementadas:

1. As intents explícitas precisam corresponder ao filtro de intent do componente de destino: se uma intent segmentar explicitamente um componente, ela precisará corresponder ao filtro de intent desse componente.

2. Intents sem uma ação não podem corresponder a nenhum filtro de intent: as intents que não têm uma ação especificada não podem ser resolvidas para nenhum filtro de intent.

Essas mudanças só se aplicam quando vários apps estão envolvidos e não afetam o processamento de intents em um único app.

Impacto

A natureza de ativação significa que os desenvolvedores precisam ativar explicitamente o recurso no manifesto do app para que ele entre em vigor. Como resultado, o impacto do recurso será limitado aos apps cujos desenvolvedores:

• Conhecem o recurso Intents mais seguros e os benefícios dele.
• Escolhem ativamente incorporar práticas de processamento de intents mais rigorosas nos apps.

Essa abordagem de ativação minimiza o risco de quebrar apps atuais que podem depender do comportamento de resolução de intents menos seguro.

Embora o impacto inicial no Android 16 possa ser limitado, a iniciativa Intents mais seguros tem um roteiro para um impacto mais amplo em versões futuras do Android. O plano é tornar a resolução de intents estrita o comportamento padrão.

O recurso Intents mais seguros tem o potencial de melhorar significativamente a segurança do ecossistema Android, dificultando a exploração de vulnerabilidades no mecanismo de resolução de intents por apps maliciosos.

No entanto, a transição para a desativação e a aplicação obrigatória precisa ser gerenciada com cuidado para resolver possíveis problemas de compatibilidade com apps atuais.

Implementação

Os desenvolvedores precisam ativar explicitamente a correspondência de intents mais rigorosa usando o intentMatchingFlags atributo no manifesto do app. Confira um exemplo em que o recurso é ativado para todo o app, mas desativado em um receptor:

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

Observação: o atributo pode ser especificado na tag <application>, bem como nas tags de componente, como <activity>, <activity-alias>, <receiver>, <service>, <provider>, e o atributo no componente pode ser usado para substituir o que está na tag <application>.

Mais informações sobre as flags aceitas:

Nome da flag	Descrição
enforceIntentFilter	Aplica uma correspondência mais rigorosa para intents recebidas.
nenhum	Desativa todas as regras de correspondência especiais para intents recebidas. Ao especificar várias flags, os valores conflitantes são resolvidos dando precedência à flag "nenhum".
allowNullAction	Relaxa as regras de correspondência para permitir que intents sem uma ação correspondam. Essa flag precisa ser usada em conjunto com "enforceIntentFilter" para alcançar um comportamento específico.

Como testar e depurar

Quando a aplicação está ativa, os apps funcionam corretamente se o autor da chamada de intent tiver preenchido a intent corretamente. No entanto, as intents bloqueadas vão acionar mensagens de registro de aviso como "Intent does not match component's intent filter:" e "Access blocked:" com a tag "PackageManager." Isso indica um possível problema que pode afetar o app e exige atenção.

Filtro do Logcat:

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

Filtragem de chamadas de sistema da GPU

Para reforçar a superfície da GPU Mali, os IOCTLs da GPU Mali que foram descontinuados ou destinados apenas ao desenvolvimento de GPU foram bloqueados em builds de produção. Além disso, as IOCTLs usadas para criação de perfil de GPU foram restritas ao processo de shell ou a aplicativos depuráveis. Consulte a atualização do SAC para mais detalhes sobre a política no nível da plataforma.

Essa mudança ocorre em dispositivos Pixel que usam a GPU Mali (Pixel 6 a 9). A Arm forneceu a categorização oficial dos IOCTLs em Documentation/ioctl-categories.rst da versão r54p2. Essa lista vai continuar sendo atualizada em versões futuras de drivers.

Essa mudança não afeta as APIs gráficas compatíveis (incluindo Vulkan e OpenGL) e não deve impactar desenvolvedores ou aplicativos atuais. Ferramentas de criação de perfil da GPU, como o Streamline Performance Analyzer e o Android GPU Inspector, não serão afetadas.

Teste

Se você encontrar uma negação do SELinux semelhante a esta, é provável que seu aplicativo tenha sido afetado por essa mudança:

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

Se o aplicativo precisar usar IOCTLs bloqueados, registre um bug e atribua-o a [e-mail].

Perguntas frequentes

1. Essa mudança na política se aplica a todos os OEMs? Essa mudança será opcional, mas estará disponível para qualquer OEM que queira usar esse método de reforço da proteção. As instruções para implementar a mudança estão na documentação de implementação.

2. É obrigatório fazer mudanças na base de código do OEM para implementar isso, ou ele vem com uma nova versão do AOSP por padrão? A mudança no nível da plataforma virá com uma nova versão do AOSP por padrão. Os fornecedores podem ativar essa mudança no codebase se quiserem aplicá-la.

3. Os SoCs são responsáveis por manter a lista de IOCTLs atualizada? Por exemplo, se meu dispositivo usa uma GPU ARM Mali, preciso entrar em contato com a ARM para fazer alguma mudança? Os SoCs individuais precisam atualizar as listas de IOCTL por dispositivo após o lançamento do driver. Por exemplo, a ARM vai atualizar a lista de IOCTLs publicada quando houver atualizações de driver. No entanto, os OEMs precisam incorporar as atualizações na SEPolicy e adicionar os IOCTLs personalizados selecionados às listas, conforme necessário.

4. Essa mudança se aplica automaticamente a todos os dispositivos Pixel disponíveis no mercado ou é necessário que o usuário faça alguma ação para ativar algo e aplicar a mudança? Essa mudança se aplica a todos os dispositivos Pixel no mercado que usam a GPU Mali (Pixel 6 a 9). Nenhuma ação do usuário é necessária para aplicar essa mudança.

5. O uso dessa política afeta o desempenho do driver do kernel? Essa política foi testada na GPU Mali usando o GFXBench, e não foi observada nenhuma mudança mensurável no desempenho da GPU.

6. É necessário que a lista de IOCTLs esteja alinhada com as versões atuais do espaço do usuário e do driver do kernel? Sim, a lista de IOCTLs permitidos precisa ser sincronizada com os IOCTLs compatíveis com os drivers de espaço do usuário e do kernel. Se os IOCTLs no espaço do usuário ou no driver do kernel forem atualizados, a lista de IOCTLs da SEPolicy também precisará ser atualizada para corresponder.

7. A ARM categorizou IOCTLs como "restritas" / "instrumentação", mas queremos usar algumas delas em casos de uso de produção e/ou negar outras. Os OEMs/SoCs individuais são responsáveis por decidir como categorizar os IOCTLs que usam, com base na configuração das bibliotecas Mali do espaço do usuário. A lista da ARM pode ser usada para ajudar a decidir sobre isso, mas o caso de uso de cada OEM/SoC pode ser diferente.

Privacidade

O Android 16 (nível 36 da API) 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 pertencentes ao app

Quando um app destinado ao SDK 36 ou mais recente solicitar permissões de fotos e vídeos em dispositivos com o Android 16 ou versões mais recentes, os usuários que optarem por limitar o acesso à mídia selecionada vão encontrar as fotos pertencentes ao app pré-selecionadas no seletor de fotos. Os usuários podem desmarcar qualquer um desses itens pré-selecionados, o que revoga o acesso do app a essas fotos e vídeos.