Modifiche al comportamento: app che hanno come target Android 16 o versioni successive

Come le versioni precedenti, Android 16 include modifiche al comportamento che potrebbero influire sulla tua app. Le seguenti modifiche al comportamento si applicano esclusivamente alle app che hanno come target Android 16 o versioni successive. Se la tua app ha come target Android 16 o versioni successive, devi modificarla per supportare questi comportamenti, ove applicabile.

Assicurati di esaminare anche l'elenco delle modifiche al comportamento che interessano tutte le app in esecuzione su Android 16, indipendentemente dal targetSdkVersion della tua app.

Esperienza utente e UI di sistema

Android 16 (livello API 36) include le seguenti modifiche volte a creare un'esperienza utente più coerente e intuitiva.

Rimozione della disattivazione della visualizzazione edge-to-edge

Android 15 强制实行全屏显示，但您的应用可以通过将 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 和 Views 指南。

Migrazione o disattivazione richieste per la funzionalità Indietro predittivo

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

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

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

预测性跨 activity 动画。

预测性跨任务动画。

API per caratteri eleganti ritirate e disabilitate

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

Funzionalità di base

Android 16 (livello API 36) include le seguenti modifiche che modificano o espandono varie funzionalità di base del sistema Android.

Ottimizzazione della pianificazione del lavoro a tariffa fissa

Prima di scegliere come target Android 16, quando scheduleAtFixedRate mancava un'esecuzione di attività perché non rientrava in un ciclo di vita del processo valido, tutte le esecuzioni mancate venivano eseguite immediatamente quando l'app tornava a un ciclo di vita valido.

Quando scegli come target Android 16, al massimo una esecuzione mancata di scheduleAtFixedRate viene eseguita immediatamente quando l'app torna a un ciclo di vita valido. Questa modifica del comportamento dovrebbe migliorare il rendimento dell'app. Testa questo comportamento nella tua app per verificare se è interessata. Puoi anche eseguire il test utilizzando il framework di compatibilità delle app e attivando il flag di compatibilità STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS.

Fattori di forma del dispositivo

Android 16 (livello API 36) include le seguenti modifiche per le app quando vengono visualizzate su dispositivi con schermi di grandi dimensioni.

Layout adattivi

Ora che le app Android vengono eseguite su una varietà di dispositivi (ad es. smartphone, tablet, pieghevoli, computer desktop, auto e TV) e modalità di finestre su schermi di grandi dimensioni (ad es. schermo diviso e finestre desktop), gli sviluppatori devono creare app Android che si adattino a qualsiasi dimensione dello schermo e della finestra, indipendentemente dall'orientamento del dispositivo. I paradigmi come la limitazione dell'orientamento e del ridimensionamento sono troppo restrittivi nel mondo multidevice di oggi.

Ignorare le limitazioni relative a orientamento, ridimensionamento e proporzioni

Per le app che hanno come target Android 16 (livello API 36), le limitazioni relative a orientamento, ridimensionamento e proporzioni non si applicano più ai display con larghezza minima >= 600 dp. Le app riempiono l'intera finestra di visualizzazione, indipendentemente dalle proporzioni o dall'orientamento preferito dall'utente, e non viene utilizzato il pillarbox.

Questa modifica introduce un nuovo comportamento standard della piattaforma. Android sta passando a un modello in cui le app devono adattarsi a vari orientamenti, dimensioni del display e proporzioni. Le limitazioni come l'orientamento fisso o il ridimensionamento limitato ostacolano l'adattabilità delle app. Rendi la tua app adattiva per offrire la migliore esperienza utente possibile.

Puoi anche testare questo comportamento utilizzando il framework di compatibilità delle app e attivando il UNIVERSAL_RESIZABLE_BY_DEFAULT flag di compatibilità.

Modifiche che provocano un errore comuni

L'ignorare le limitazioni relative a orientamento, ridimensionamento e proporzioni potrebbe influire sull'interfaccia utente della tua app su alcuni dispositivi, in particolare sugli elementi progettati per layout piccoli bloccati in orientamento verticale: ad esempio, problemi come layout allungati e animazioni e componenti fuori schermo. Qualsiasi ipotesi sulle proporzioni o sull'orientamento può causare problemi visivi con la tua app. Scopri di più su come evitarli e migliorare il comportamento adattivo della tua app.

Consentire la rotazione del dispositivo comporta una maggiore ricreazione dell'attività, che può comportare la perdita dello stato dell'utente se non viene mantenuto correttamente. Scopri come salvare correttamente lo stato dell'interfaccia utente in Salvare gli stati dell'interfaccia utente.

Dettagli di implementazione

I seguenti attributi del manifest e API di runtime vengono ignorati sui dispositivi con schermi di grandi dimensioni in modalità a schermo intero e multi-finestra:

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

I seguenti valori per screenOrientation, setRequestedOrientation() e getRequestedOrientation() vengono ignorati:

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

Per quanto riguarda il ridimensionamento del display, android:resizeableActivity="false", android:minAspectRatio e android:maxAspectRatio non hanno alcun effetto.

Per le app che hanno come target Android 16 (livello API 36), le limitazioni relative a orientamento, ridimensionamento e proporzioni dell'app vengono ignorate per impostazione predefinita sugli schermi di grandi dimensioni, ma ogni app non completamente pronta può sostituire temporaneamente questo comportamento disattivandolo (il che comporta il comportamento precedente di essere inserita in modalità di compatibilità).

Eccezioni

Le limitazioni relative a orientamento, ridimensionamento e proporzioni di Android 16 non si applicano nelle seguenti situazioni:

• Giochi (in base al android:appCategory flag)
• Utenti che attivano esplicitamente il comportamento predefinito dell'app nelle impostazioni delle proporzioni del dispositivo
• Schermi più piccoli di sw600dp

Disattivare temporaneamente

Per disattivare un'attività specifica, dichiara la proprietà del manifest PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY:

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

Se troppe parti della tua app non sono pronte per Android 16, puoi disattivarla completamente applicando la stessa proprietà a livello di applicazione:

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

Importante: la disattivazione è temporanea e non verrà applicata quando il livello API target è 37 in una release futura di Android. Ciò significa che, per le app che hanno come target il livello API 37, le limitazioni relative a orientamento, ridimensionamento e proporzioni vengono ignorate sui display di almeno sw600dp.

Salute e fitness

Android 16 (livello API 36) include le seguenti modifiche relative ai dati sulla salute e sul fitness.

Autorizzazioni per salute e fitness

Per le app che hanno come target Android 16 (livello API 36) o versioni successive, le autorizzazioni BODY_SENSORS utilizzano autorizzazioni più granulari in android.permissions.health, che vengono utilizzate anche da Connessione Salute. A partire da Android 16, qualsiasi API che in precedenza richiedeva BODY_SENSORS o BODY_SENSORS_BACKGROUND richiede invece l'autorizzazione android.permissions.health corrispondente. Ciò influisce sui seguenti tipi di dati, API e tipi di servizi in primo piano:

• HEART_RATE_BPM da Servizi per la salute su Wear OS
• Sensor.TYPE_HEART_RATE da Android Sensor Manager
• heartRateAccuracy e heartRateBpm da ProtoLayout su Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH dove è necessaria la rispettiva autorizzazione android.permission.health al posto di BODY_SENSORS

Se la tua app utilizza queste API, deve richiedere le rispettive autorizzazioni granulari:

• Per il monitoraggio durante l'utilizzo di frequenza cardiaca, SpO2 o temperatura cutanea: richiedi l'autorizzazione granulare in android.permissions.health, ad esempio READ_HEART_RATE anziché BODY_SENSORS.
• Per l'accesso ai sensori in background, richiedi READ_HEALTH_DATA_IN_BACKGROUND anziché BODY_SENSORS_BACKGROUND.

Queste autorizzazioni sono le stesse che proteggono l'accesso alla lettura dei dati da Health Connect, l'archivio dati Android per i dati relativi a salute, fitness e benessere.

App mobile

Le app mobile che eseguono la migrazione per utilizzare READ_HEART_RATE e altre autorizzazioni granulari devono anche dichiarare un'attività per visualizzare le norme sulla privacy dell'app. Si tratta dello stesso requisito di Health Connect.

Importante: se non fornisci la motivazione per le app mobile, l'autorizzazione verrà revocata.

Connettività

Android 16 (livello API 36) include le seguenti modifiche nello stack Bluetooth per migliorare la connettività con i dispositivi periferici.

Nuovi intent per gestire la perdita dell'associazione e le modifiche alla crittografia

Nell'ambito della gestione migliorata della perdita del legame, Android 16 introduce anche due nuovi intent per fornire alle app una maggiore consapevolezza della perdita del legame e delle modifiche alla crittografia.

Le app che hanno come target Android 16 ora possono:

• Ricevere un'intenzione ACTION_KEY_MISSING quando viene rilevata la perdita del legame remoto, in modo da poter fornire un feedback più informativo agli utenti e intraprendere azioni appropriate.
• Ricevere un'intenzione ACTION_ENCRYPTION_CHANGE ogni volta che cambia lo stato della crittografia del collegamento. Sono incluse la modifica dello stato della crittografia, la modifica dell'algoritmo di crittografia e la modifica delle dimensioni della chiave di crittografia. Le app devono considerare il legame ripristinato se il link viene criptato correttamente al momento della ricezione dell'intent ACTION_ENCRYPTION_CHANGE in un secondo momento.

Adattamento alle diverse implementazioni degli OEM

Sebbene Android 16 introduca questi nuovi intent, la loro implementazione e la loro trasmissione possono variare in base ai diversi produttori di dispositivi (OEM). Per garantire che la tua app offra un'esperienza coerente e affidabile su tutti i dispositivi, gli sviluppatori devono progettare la gestione della perdita di legame in modo che si adatti in modo graduale a queste potenziali variazioni.

Consigliamo i seguenti comportamenti delle app:

• Se viene trasmesso l'intent ACTION_KEY_MISSING:

  Il link ACL (Asynchronous Connection-Less) verrà scollegato dal sistema, ma le informazioni sul legame del dispositivo verranno conservate (come descritto qui).

  L'app deve utilizzare questo intent come indicatore principale per il rilevamento della perdita del legame e guidare l'utente a verificare che il dispositivo remoto sia nel raggio d'azione prima di avviare l'eliminazione o la nuova accoppiata del dispositivo.

  Se un dispositivo si disconnette dopo aver ricevuto ACTION_KEY_MISSING, la tua app deve essere cauta nel riconnettersi, poiché il dispositivo potrebbe non essere più associato al sistema.

• Se l'intent ACTION_KEY_MISSING NON viene trasmesso:

  Il link ACL rimarrà connesso e le informazioni sul legame del dispositivo verranno rimosse dal sistema, come accade in Android 15.

  In questo scenario, l'app dovrebbe continuare a utilizzare i meccanismi di gestione della perdita di pacchetti esistenti, come nelle release Android precedenti, per rilevare e gestire gli eventi di perdita di pacchetti.

Nuovo modo per rimuovere l'accoppiamento Bluetooth

Tutte le app che hanno come target Android 16 ora possono disaccoppiare i dispositivi Bluetooth utilizzando un'API pubblica in CompanionDeviceManager. Se un dispositivo complementare viene gestito come associazione CDM, l'app può attivare la rimozione del legame Bluetooth utilizzando la nuova API removeBond(int) sul dispositivo associato. L'app può monitorare le modifiche dello stato del legame ascoltando l'evento di trasmissione del dispositivo Bluetooth ACTION_BOND_STATE_CHANGED.

Sicurezza

Android 16 (livello API 36) include le seguenti modifiche alla sicurezza.

Blocco della versione di MediaStore

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

Intenti più sicuri

La funzionalità Intent più sicuri è un'iniziativa di sicurezza in più fasi progettata per migliorare la sicurezza del meccanismo di risoluzione degli intent di Android. L'obiettivo è proteggere le app da azioni dannose aggiungendo controlli durante l'elaborazione degli intent e filtrando gli intent che non soddisfano criteri specifici.

In Android 15, la funzionalità si concentrava sull'app di invio, mentre in Android 16, il controllo passa all'app di ricezione, consentendo agli sviluppatori di attivare la risoluzione degli intent rigorosa utilizzando il file manifest dell'app.

Verranno implementate due modifiche principali:

1. Gli intent espliciti devono corrispondere al filtro per intent del componente di destinazione: se un intent seleziona esplicitamente come target un componente, deve corrispondere al filtro per intent di quel componente.

2. Gli intent senza un'azione non possono corrispondere a nessun filtro per intent: gli intent per cui non è specificata un'azione non devono essere risolti in nessun filtro per intent.

Queste modifiche si applicano solo quando sono coinvolte più app e non influiscono sulla gestione degli intent all'interno di una singola app.

Impatto

Poiché è una funzionalità di attivazione, gli sviluppatori devono attivarla esplicitamente nel file manifest dell'app affinché abbia effetto. Di conseguenza, l'impatto della funzionalità sarà limitato alle app i cui sviluppatori:

• Sono a conoscenza della funzionalità Intent più sicuri e dei suoi vantaggi.
• Scelgono attivamente di incorporare pratiche di gestione degli intent più rigorose nelle loro app.

Questo approccio di attivazione riduce al minimo il rischio di interrompere le app esistenti che potrebbero fare affidamento sul comportamento di risoluzione degli intent corrente, meno sicuro.

Sebbene l'impatto iniziale in Android 16 possa essere limitato, l'iniziativa Intent più sicuri prevede una roadmap per un impatto più ampio nelle future release di Android. L'obiettivo è rendere la risoluzione degli intent rigorosa il comportamento predefinito.

La funzionalità Intent più sicuri ha il potenziale per migliorare significativamente la sicurezza dell'ecosistema Android, rendendo più difficile per le app dannose sfruttare le vulnerabilità nel meccanismo di risoluzione degli intent.

Tuttavia, la transizione all'esclusione e all'applicazione obbligatoria deve essere gestita con attenzione per risolvere i potenziali problemi di compatibilità con le app esistenti.

Implementazione

Gli sviluppatori devono attivare esplicitamente la corrispondenza degli intent più rigorosa utilizzando l'attributo intentMatchingFlags nel file manifest dell'app. Ecco un esempio in cui la funzionalità è di attivazione per l'intera app, ma è disattivata/di esclusione su un ricevitore:

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

Nota: l'attributo può essere specificato nel tag <application> e nei tag dei componenti come <activity>, <activity-alias>, <receiver>, <service>, <provider>. L'attributo del componente può essere utilizzato per sostituire quello del tag <application>

Ulteriori informazioni sui flag supportati:

Nome del flag	Descrizione
enforceIntentFilter	Applica una corrispondenza più rigorosa per gli intent in entrata
none	Disattiva tutte le regole di corrispondenza speciali per gli intent in entrata. Quando si specificano più flag, i valori in conflitto vengono risolti dando la precedenza al flag "none"
allowNullAction	Rilassa le regole di corrispondenza per consentire la corrispondenza degli intent senza un'azione. Questo flag deve essere utilizzato insieme a "enforceIntentFilter" per ottenere un comportamento specifico

Test e debug

Quando l'applicazione è attiva, le app dovrebbero funzionare correttamente se il chiamante dell'intent ha compilato correttamente l'intent. Tuttavia, gli intent bloccati attiveranno messaggi di log di avviso come "Intent does not match component's intent filter:" e "Access blocked:" con il tag "PackageManager." Ciò indica un potenziale problema che potrebbe influire sull'app e richiede attenzione.

Filtro logcat:

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

Filtro delle chiamate di sistema della 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 的用例可能有所不同。

Privacy

Android 16 (livello API 36) include le seguenti modifiche alla privacy.

Autorizzazione di accesso alla rete locale

Le app con l'autorizzazione INTERNET possono accedere ai dispositivi sulla LAN. In questo modo, le app possono connettersi facilmente ai dispositivi locali, ma ci sono anche implicazioni per la privacy, ad esempio la creazione di un'impronta digitale dell'utente e l'utilizzo come proxy per la posizione.

Il progetto Protezioni della rete locale mira a proteggere la privacy dell'utente limitando l'accesso alla rete locale tramite una nuova autorizzazione di runtime.

Piano di rilascio

Questa modifica verrà implementata tra due release, rispettivamente 25Q2 e 26Q2. È fondamentale che gli sviluppatori seguano queste indicazioni per 25Q2 e condividano feedback, perché queste protezioni verranno applicate in una release di Android successiva. Inoltre, dovranno aggiornare gli scenari che dipendono dall'accesso implicito alla rete locale seguendo le indicazioni riportate di seguito e prepararsi al rifiuto e alla revoca dell'autorizzazione da parte degli utenti.

Impatto

Nella fase attuale, LNP è una funzionalità di attivazione, il che significa che solo le app che la attivano saranno interessate. L'obiettivo della fase di attivazione è consentire agli sviluppatori di app di comprendere quali parti della loro app dipendono dall'accesso implicito alla rete locale, in modo che possano prepararsi a proteggerle con le autorizzazioni per la prossima release.

Le app saranno interessate se accedono alla rete locale dell'utente utilizzando:

• L'utilizzo diretto o tramite libreria di socket non elaborati sugli indirizzi della rete locale (ad es. protocollo Service Discovery mDNS o SSDP)
• L'utilizzo di classi a livello di framework che accedono alla rete locale (ad es. NsdManager)

Il traffico da e verso un indirizzo della rete locale richiede l'autorizzazione di accesso alla rete locale. La tabella seguente elenca alcuni casi comuni:

Operazione di rete di basso livello dell'app	Autorizzazione di rete locale richiesta
Creazione di una connessione TCP in uscita	sì
Accettazione di connessioni TCP in entrata	sì
Invio di un pacchetto UDP unicast, multicast, broadcast	sì
Ricezione di un pacchetto UDP unicast, multicast, broadcast in entrata	sì

Queste limitazioni sono implementate in profondità nello stack di rete e pertanto si applicano a tutte le API di rete. Sono inclusi i socket creati in codice nativo o gestito, le librerie di rete come Cronet e OkHttp e tutte le API implementate su di esse. Per provare a risolvere i servizi sulla rete locale (ovvero quelli con suffisso .local) è necessaria l'autorizzazione di rete locale.

Nota: il traffico proveniente dalle WebView di Android che richiedono l'accesso alla rete locale erediterà lo stato dell'autorizzazione dall'app host

Eccezioni alle regole riportate sopra:

• Se il server DNS di un dispositivo si trova su una rete locale, il traffico da o verso il server (alla porta 53) non richiede l'autorizzazione di accesso alla rete locale.
• Le applicazioni che utilizzano Output Switcher come selettore in-app non avranno bisogno delle autorizzazioni di rete locale (ulteriori indicazioni saranno disponibili nel quarto trimestre del 2025).

Nota: molti scenari di trasmissione di contenuti multimediali dipendono dall'accesso alla rete locale e saranno interessati da questa modifica. Tuttavia, non tutte le app che offrono la trasmissione dovranno richiedere la nuova autorizzazione. Le future API e indicazioni per la gestione degli scenari di trasmissione saranno fornite nel quarto trimestre del 2025.

Indicazioni per gli sviluppatori (attivazione)

Per attivare le limitazioni della rete locale:

1. Esegui il flashing del dispositivo a una build con 25Q2 Beta 3 o versioni successive.
2. Installa l'app da testare.

3. Attiva/disattiva il flag Appcompat in adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Riavvia il dispositivo

Ora l'accesso dell'app alla rete locale è limitato e qualsiasi tentativo di accesso alla rete locale genererà errori di socket. Se utilizzi API che eseguono operazioni di rete locale al di fuori del processo dell'app (ad es. NsdManager), non saranno interessate durante la fase di attivazione.

Per ripristinare l'accesso, devi concedere all'app l'autorizzazione NEARBY_WIFI_DEVICES.

1. Assicurati che l'app dichiari l'autorizzazione NEARBY_WIFI_DEVICES nel file manifest.
2. Vai a Impostazioni > App > [Nome dell'applicazione] > Autorizzazioni > Dispositivi nelle vicinanze > Consenti.

Nota: in una release di Android futura, questa funzionalità sarà protetta da una nuova autorizzazione nel gruppo di autorizzazioni Dispositivi nelle vicinanze

Ora l'accesso dell'app alla rete locale dovrebbe essere ripristinato e tutti gli scenari dovrebbero funzionare come prima dell'attivazione dell'app.

Una volta avviata l'applicazione della protezione della rete locale, ecco come verrà interessato il traffico di rete dell'app.

Autorizzazione	Richiesta LAN in uscita	Richiesta internet in uscita/in entrata	Richiesta LAN in entrata
Concessa	Funziona	Funziona	Funziona
Non concessa	Fallimenti	Funziona	Fallimenti

Utilizza il comando seguente per disattivare il flag App-Compat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errori

Gli errori derivanti da queste limitazioni verranno restituiti al socket chiamante ogni volta che richiama send o una variante di send a un indirizzo della rete locale.

Esempi di errori:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definizione di rete locale

In questo progetto, una rete locale si riferisce a una rete IP che utilizza un'interfaccia di rete con funzionalità di trasmissione, come Wi-Fi o Ethernet, ma esclude le connessioni cellulari (WWAN) o VPN.

Le seguenti sono considerate reti locali:

IPv4:

• 169.254.0.0/16 // Locale rispetto al collegamento
• 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:

• Locale rispetto al collegamento
• Route connesse direttamente
• Reti stub come Thread
• Più subnet (TBD)

Inoltre, sia gli indirizzi multicast (224.0.0.0/4, ff00::/8) sia l'indirizzo di trasmissione IPv4 (255.255.255.255) sono classificati come indirizzi di rete locale.

Foto di proprietà dell'app

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