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 mudanças a seguir, que têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.

A opção de desativar a exibição de ponta a ponta vai ser removida

Android 15 强制要求以 Android 15（API 级别 35）为目标平台的应用采用边到边模式，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择退出此模式。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已废弃并停用，并且您的应用无法选择停用边到边模式。

• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，R.attr#windowOptOutEdgeToEdgeEnforcement 会继续运行。
• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会处于停用状态。

如需在 Android 16 中进行测试，请确保您的应用支持无边框，并移除对 R.attr#windowOptOutEdgeToEdgeEnforcement 的任何使用，以便您的应用在 Android 15 设备上也支持无边框。如需支持边到边，请参阅 Compose 和视图指南。

Migração ou desativação necessária para o gesto de voltar preditivo

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

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 行为。

Principal recurso

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

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

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

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。

Formatos de dispositivo

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

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 36 da API) 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 权限会使用 android.permissions.health 下更精细的权限，Health Connect 也会使用这些权限。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• Wear OS 上的健康服务中的 HEART_RATE_BPM
• Sensor.TYPE_HEART_RATE（来自 Android 传感器管理器）
• Wear OS 上的 heartRateAccuracy 和 heartRateBpm（来自 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。

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

移动应用

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

重要提示： 如果未能提供移动应用的理由，将导致权限被撤消。

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 lidar com perda de vínculo e mudanças na 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 conexão Bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

Segurança

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

Bloqueio de versão do MediaStore

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

Intents mais seguras

O recurso Safer Intents é uma iniciativa de segurança em várias fases 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 concentrava no app de envio. Agora, com o Android 16, o controle passa para o app de recebimento, permitindo que os desenvolvedores ativem a resolução de intent 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: 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 ativá-lo explicitamente no manifesto do app para que ele entre em vigor. Como resultado, o impacto do recurso será limitado aos apps em que os desenvolvedores:

• Conhecer o recurso de intents mais seguras e os benefícios dele.
• Escolher ativamente incorporar práticas mais rígidas de processamento de intents nos apps.

Essa abordagem de ativação minimiza o risco de corromper apps que dependem do comportamento atual de resolução de intents, que é menos seguro.

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

O recurso de intents mais seguras tem o potencial de melhorar significativamente a segurança do ecossistema Android, dificultando que apps mal-intencionados explorem vulnerabilidades no mecanismo de resolução de intents.

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 atributo intentMatchingFlags no manifesto do app. Veja um exemplo em que o recurso é ativado para todo o app, mas desativado/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 compatíveis:

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 sinalizações, os valores conflitantes são resolvidos dando precedência à sinalização "none"
allowNullAction	Flexibiliza as regras de correspondência para permitir intents sem uma ação correspondente. Essa flag deve ser usada em conjunto com "enforceIntentFilter" para alcançar um comportamento específico.

Como testar e depurar

Quando a restrição estiver ativa, os apps vão funcionar corretamente se o autor da chamada da intent tiver preenchido a intent de forma adequada. 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 requer atenção.

Filtro do Logcat:

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

Filtragem de syscall da GPU

To harden the Mali GPU surface, Mali GPU IOCTLs that have been deprecated or are intended solely for GPU development have been blocked in production builds. Additionally, IOCTLs used for GPU profiling have been restricted to the shell process or debuggable applications. Refer to the SAC update for more details on the platform-level policy.

This change takes place on Pixel devices using the Mali GPU (Pixel 6-9). Arm has provided official categorization of their IOCTLs in Documentation/ioctl-categories.rst of their r54p2 release. This list will continue to be maintained in future driver releases.

This change does not impact supported graphics APIs (including Vulkan and OpenGL), and is not expected to impact developers or existing applications. GPU profiling tools such as the Streamline Performance Analyzer and the Android GPU Inspector won't be affected.

Testing

If you see a SELinux denial similar to the following, it is likely your application has been impacted by this change:

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

If your application needs to use blocked IOCTLs, please file a bug and assign it to [e-mail].

FAQ

1. Does this policy change apply to all OEMs? This change will be opt-in, but available to any OEMs who would like to use this hardening method. Instructions for implementing the change can be found in the implementation documentation.

2. Is it mandatory to make changes in the OEM codebase to implement this, or does it come with a new AOSP release by default? The platform-level change will come with a new AOSP release by default. Vendors may opt-in to this change in their codebase if they would like to apply it.

3. Are SoCs responsible for keeping the IOCTL list up to date? For example, if my device uses an ARM Mali GPU, would I need to reach out to ARM for any of the changes? Individual SoCs must update their IOCTL lists per device upon driver release. For example, ARM will update their published IOCTL list upon driver updates. However, OEMs should make sure that they incorporate the updates in their SEPolicy, and add any selected custom IOCTLs to the lists as needed.

4. Does this change apply to all Pixel in-market devices automatically, or is a user action required to toggle something to apply this change? This change applies to all Pixel in-market devices using the Mali GPU (Pixel 6-9). No user action is required to apply this change.

5. Will use of this policy impact the performance of the kernel driver? This policy was tested on the Mali GPU using GFXBench, and no measurable change to GPU performance was observed.

6. Is it necessary for the IOCTL list to align with the current userspace and kernel driver versions? Yes, the list of allowed IOCTLs must be synchronized with the IOCTLs supported by both the userspace and kernel drivers. If the IOCTLs in the user space or kernel driver are updated, the SEPolicy IOCTL list must be updated to match.

7. ARM has categorized IOCTLs as 'restricted' / 'instrumentation', but we want to use some of them in production use-cases, and/or deny others. Individual OEMs/SoCs are responsible for deciding on how to categorize the IOCTLs they use, based on the configuration of their userspace Mali libraries. ARM's list can be used to help decide on these, but each OEM/SoC's use-case may be different.

Privacidade

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

Permissão de rede local

Devices on the LAN can be accessed by any app that has the INTERNET permission. This makes it easy for apps to connect to local devices but it also has privacy implications such as forming a fingerprint of the user, and being a proxy for location.

The Local Network Protections project aims to protect the user's privacy by gating access to the local network behind a new runtime permission.

Release plan

This change will be deployed between two releases, 25Q2 and 26Q2 respectively. It is imperative that developers follow this guidance for 25Q2 and share feedback because these protections will be enforced at a later Android release. Moreover, they will need to update scenarios which depend on implicit local network access by using the following guidance and prepare for user rejection and revocation of the new permission.

Impact

At the current stage, LNP is an opt-in feature which means only the apps that opt in will be affected. The goal of the opt-in phase is for app developers to understand which parts of their app depend on implicit local network access such that they can prepare to permission guard them for the next release.

Apps will be affected if they access the user's local network using:

• Direct or library use of raw sockets on local network addresses (e.g. mDNS or SSDP service discovery protocol)
• Use of framework level classes that access the local network (e.g. NsdManager)

Traffic to and from a local network address requires local network access permission. The following table lists some common cases:

App Low Level Network Operation	Local Network Permission Required
Making an outgoing TCP connection	yes
Accepting incoming TCP connections	yes
Sending a UDP unicast, multicast, broadcast	yes
Receiving an incoming UDP unicast, multicast, broadcast	yes

These restrictions are implemented deep in the networking stack, and thus they apply to all networking APIs. This includes sockets created in native or managed code, networking libraries like Cronet and OkHttp, and any APIs implemented on top of those. Trying to resolve services on the local network (i.e. those with a .local suffix) will require local network permission.

Note: Traffic originating from Android Webviews that require local network access will inherit permission state from the host app

Exceptions to the rules above:

• If a device's DNS server is on a local network, traffic to or from it (at port 53) doesn't require local network access permission.
• Applications using Output Switcher as their in-app picker won't need local network permissions (more guidance to come in 2025Q4).

Note: Many media casting scenarios depend on access to the local network and will be impacted by this change. However, not all apps which offer casting will need to request the new permission. Future APIs and guidance for dealing with casting scenarios will be provided in 25Q4.

Developer Guidance (Opt-in)

To opt into local network restrictions, do the following:

1. Flash the device to a build with 25Q2 Beta 3 or later.
2. Install the app to be tested.

3. Toggle the Appcompat flag in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Reboot The device

Now your app's access to the local network is restricted and any attempt to access the local network will lead to socket errors. If you are using APIs that perform local network operations outside of your app process (ex: NsdManager), they won't be impacted during the opt-in phase.

To restore access, you must grant your app permission to NEARBY_WIFI_DEVICES.

1. Ensure the app declares the NEARBY_WIFI_DEVICES permission in its manifest.
2. Go to Settings > Apps > [Application Name] > Permissions > Nearby devices > Allow.

Note: In a future Android release, this feature will be guarded by a new permission in the Nearby devices permission group

Now your app's access to the local network should be restored and all your scenarios should work as they did prior to opting the app in.

Once enforcement for local network protection begins, here is how the app network traffic will be impacted.

Permission	Outbound LAN Request	Outbound/Inbound Internet Request	Inbound LAN Request
Granted	Works	Works	Works
Not Granted	Fails	Works	Fails

Use the following command to toggle-off the App-Compat flag

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errors

Errors arising from these restrictions will be returned to the calling socket whenever it invokes send or a send variant to a local network address.

Example errors:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Local Network Definition

A local network in this project refers to an IP network that utilizes a broadcast-capable network interface, such as Wi-Fi or Ethernet, but excludes cellular (WWAN) or VPN connections.

The following are considered local networks:

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
• Directly-connected routes
• Stub networks like Thread
• Multiple-subnets (TBD)

Additionally, both multicast addresses (224.0.0.0/4, ff00::/8) and the IPv4 broadcast address (255.255.255.255) are classified as local network addresses.

Fotos do app

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