Come le release precedenti, Android 16 include modifiche del comportamento che potrebbero influire sulla tua app. Le seguenti modifiche del 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 in modo da 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 interfaccia utente di sistema
Android 16 (livello API 36) include le seguenti modifiche volte a creare un'esperienza utente più coerente e intuitiva.
Ritiro del consenso per la visualizzazione edge-to-edge
Android 15 enforced edge-to-edge for apps targeting Android 15 (API
level 35), but your app could opt-out by setting
R.attr#windowOptOutEdgeToEdgeEnforcement
to true
. For apps
targeting Android 16,
R.attr#windowOptOutEdgeToEdgeEnforcement
is deprecated and disabled, and your
app can't opt-out of going edge-to-edge.
For testing in Android 16 Beta 2, ensure your app supports edge-to-edge and
remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement
. To support
edge-to-edge, see the Compose and Views guidance. Let
us know about concerns in our issue tracker on the feedback page.
Migrazione o disattivazione richiesta per il ritorno predittivo
For apps targeting Android 16 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.
API dei caratteri eleganti ritirate e disattivate
Per le app che hanno come target Android 15 (livello API 35), l'attributo
elegantTextHeight
TextView
è impostato su true
per default, sostituendo il carattere compatto con uno molto più leggibile. Puoi eseguire l'override impostando l'attributo elegantTextHeight
su false
.
Android 16 ritira l'attributo
elegantTextHeight
,
che verrà ignorato quando la tua app avrà come target Android 16. I " caratteri UI" controllati da queste API non saranno più disponibili, pertanto devi adattare i layout per garantire un rendering del testo coerente e adatto al futuro in arabo, lao, birmano, tamil, gujarati, kannada, malayalam, oriya, telugu o thai.

elegantTextHeight
per le app che hanno come target Android 14 (livello API 34) e versioni precedenti o per le app che hanno come target Android 15 (livello API 35)
che ha sostituito il valore predefinito impostando l'attributo elegantTextHeight
su false
.
elegantTextHeight
per le app che hanno come target Android
16 o per le app che hanno come target Android 15 (livello API 35) che non hanno override il valore predefinito impostando l'attributo elegantTextHeight
su
false
.Funzionalità di base
Android 16 (livello API 36) include le seguenti modifiche che modificano o ampliano varie funzionalità di base del sistema Android.
Ottimizzazione della pianificazione del lavoro con tariffa fissa
Prior to targeting Android 16, when scheduleAtFixedRate
missed a task execution due to being outside a valid
process lifecycle, all missed executions immediately
execute when the app returns to a valid lifecycle.
When targeting Android 16, at most one missed execution of
scheduleAtFixedRate
is immediately executed when the app
returns to a valid lifecycle. This behavior change is expected to improve app
performance. Test this behavior in your app to check if your app is impacted.
You can also test by using the app compatibility framework
and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS
compat flag.
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
With Android apps now running on a variety of devices (such as phones, tablets, foldables, desktops, cars, and TVs) and windowing modes on large screens (such as split screen and desktop windowing), developers should build Android apps that adapt to any screen and window size, regardless of device orientation. Paradigms like restricting orientation and resizability are too restrictive in today's multidevice world.
Ignore orientation, resizability, and aspect ratio restrictions
For apps targeting Android 16, Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply. Apps also fill the entire display window, regardless of aspect ratio or a user's preferred orientation, and pillarboxing isn't used.
This change introduces a new standard platform behavior. Android is moving toward a model where apps are expected to adapt to various orientations, display sizes, and aspect ratios. Restrictions like fixed orientation or limited resizability hinder app adaptability, so we recommend making your app adaptive to deliver the best possible user experience.
You can also test this behavior by using the
[app compatibility framework][a16-kilo-14] and
enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT
compat flag.
Common breaking changes
Ignoring orientation, resizability, and aspect ratio restrictions might impact your app's UI on some devices, especially elements that were designed for small layouts locked in portrait orientation: for example, issues like stretched layouts and off-screen animations and components. Any assumptions about aspect ratio or orientation can cause visual issues with your app. Learn more about how to avoid them and improve your app's adaptive behaviour.
Allowing device rotation results in more activity re-creation, which can result in losing user state if not properly preserved. Learn how to correctly save UI state in Save UI states.
Implementation details
The following manifest attributes and runtime APIs are ignored across large screen devices in full-screen and multi-window modes:
screenOrientation
resizableActivity
minAspectRatio
maxAspectRatio
setRequestedOrientation()
getRequestedOrientation()
The following values for screenOrientation
, setRequestedOrientation()
, and
getRequestedOrientation()
are ignored:
portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape
Regarding display resizability, android:resizeableActivity="false"
,
android:minAspectRatio
, and android:maxAspectRatio
have no effect.
For apps targeting Android 16, app orientation, resizability, and aspect ratio constraints are ignored on large screens by default, but every app that isn't fully ready can temporarily override this behavior by opting out (which results in the previous behavior of being placed in compatibility mode).
Exceptions
The Android 16 orientation, resizability, and aspect ratio restrictions don't apply in the following situations:
- Games (based on the
android:appCategory
flag) - Users explicitly opting in to the app's default behavior in aspect ratio settings of the device
- Screens that are smaller than
sw600dp
Opt out temporarily
To opt out a specific activity, declare the
PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY
manifest property:
<activity ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
...
</activity>
If too many parts of your app aren't ready for Android 16, you can opt out completely by applying the same property at the application level:
<application ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>
Salute e fitness
Android 16 (livello API 36) include le seguenti modifiche relative ai dati di salute e fitness.
Autorizzazioni per salute e fitness
For apps targeting Android 16 or higher,
BODY_SENSORS
permissions are transitioning to the
granular permissions under android.permissions.health
also used by Health
Connect. Any API previously requiring BODY_SENSORS
or
BODY_SENSORS_BACKGROUND
now requires the corresponding
android.permissions.health
permission. This affects the following data types,
APIs, and foreground service types:
HEART_RATE_BPM
from Wear Health ServicesSensor.TYPE_HEART_RATE
from Android Sensor ManagerheartRateAccuracy
andheartRateBpm
from WearProtoLayout
FOREGROUND_SERVICE_TYPE_HEALTH
where the respectiveandroid.permission.health
permission is needed in place ofBODY_SENSORS
If your app uses these APIs, it should now request the respective granular permissions:
- For while-in-use monitoring of Heart Rate, SpO2, or Skin Temperature:
request the granular permission under
android.permissions.health
, such asREAD_HEART_RATE
instead ofBODY_SENSORS
. - For background sensor access: request
READ_HEALTH_DATA_IN_BACKGROUND
instead ofBODY_SENSORS_BACKGROUND
.
These permissions are the same as those that guard access to reading data from Health Connect, the Android datastore for health, fitness, and wellness data.
Mobile apps
Mobile apps migrating to use the READ_HEART_RATE
and other granular
permissions must also declare an activity to display
the app's privacy policy. This is the same requirement as Health Connect.
Connettività
Android 16 (livello API 36) include le seguenti modifiche allo stack Bluetooth per migliorare la connettività con i dispositivi periferici.
Nuovi intent per gestire la perdita di obbligazioni e le modifiche alla crittografia
As part of the Improved bond loss handling, Android 16 also introduces 2 new intents to provide apps with greater awareness of bond loss and encryption changes.
Apps targeting Android 16 can now:
- Receive an
ACTION_KEY_MISSING
intent when remote bond loss is detected, allowing them to provide more informative user feedback and take appropriate actions. - Receive an
ACTION_ENCRYPTION_CHANGE
intent whenever encryption status of the link changes. This includes encryption status change, encryption algorithm change, and encryption key size change. Apps must consider the bond restored if the link is successfully encrypted upon receivingACTION_ENCRYPTION_CHANGE
intent later.
If your app currently uses custom mechanisms for bond loss handling, migrate to
the new intent ACTION_KEY_MISSING
to detect and manage bond loss
events. We recommend your app guide the user to confirm the remote device is in
range before initiating device forgetting and re-pairing.
Moreover, if a device disconnects after ACTION_KEY_MISSING
intent
is received, your app should be mindful about reconnecting to the device as that
device may no longer be bonded with the system.
Sicurezza
Android 16 (livello API 36) include le seguenti modifiche alla sicurezza.
Blocco della versione di MediaStore
For apps targeting Android 16 or higher, MediaStore#getVersion()
will now
be unique to each app. This eliminates identifying properties from the version
string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't
make any assumptions around the format of this version. Apps should already
handle version changes when using this API and in most cases shouldn't need to
change their current behavior, unless the developer has attempted to infer
additional information that is beyond the intended scope of this API.