Verhaltensänderungen: Apps, die auf Android 16 oder höher ausgerichtet sind

Wie bei früheren Versionen enthält Android 16 Verhaltensänderungen, die sich auf Ihre App auswirken können. Die folgenden Verhaltensänderungen gelten ausschließlich für Apps, die auf Android 16 oder höher ausgerichtet sind. Wenn Ihre App auf Android 16 oder höher ausgerichtet ist, sollten Sie sie gegebenenfalls so ändern, dass sie diese Verhaltensweisen unterstützt.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die sich auf alle Apps auswirken die unter Android 16 ausgeführt werden, unabhängig von der targetSdkVersion Ihrer App.

Nutzererfahrung und System-UI

Android 16 (API-Level 36) enthält die folgenden Änderungen, die eine einheitlichere und intuitivere Nutzererfahrung ermöglichen sollen.

Deaktivierung der Option „Nur Foto, ohne Rand“ wird entfernt

Unter Android 15 wurde die randlose Darstellung erzwungen für Apps, die auf Android 15 (API Level 35) ausgerichtet sind. Ihre App konnte dies jedoch deaktivieren, indem Sie R.attr#windowOptOutEdgeToEdgeEnforcement auf true gesetzt haben. Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, ist R.attr#windowOptOutEdgeToEdgeEnforcement veraltet und deaktiviert. Ihre App kann die randlose Darstellung nicht deaktivieren.

• Wenn Ihre App auf Android 16 (API-Level 36) ausgerichtet ist und auf einem Android 15-Gerät ausgeführt wird, funktioniert R.attr#windowOptOutEdgeToEdgeEnforcement weiterhin.
• Wenn Ihre App auf Android 16 (API-Level 36) ausgerichtet ist und auf einem Android 16-Gerät ausgeführt wird, ist R.attr#windowOptOutEdgeToEdgeEnforcement deaktiviert.

Für Tests unter Android 16 muss Ihre App die randlose Darstellung unterstützen. Entfernen Sie alle Verwendungen von R.attr#windowOptOutEdgeToEdgeEnforcement, damit Ihre App die randlose Darstellung auch auf einem Android 15-Gerät unterstützt. Weitere Informationen zur Unterstützung der randlosen Darstellung finden Sie in den Richtlinien für Compose und Views.

Migration oder Deaktivierung für die intelligente „Zurück“-Geste erforderlich

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.

Elegant Font APIs eingestellt und deaktiviert

Bei Apps, die auf Android 15 (API‑Level 35) ausgerichtet sind, ist das Attribut elegantTextHeight TextView standardmäßig auf true gesetzt. Dadurch wird die kompakte Schriftart durch eine Schriftart ersetzt, die viel besser lesbar ist. Sie können dies überschreiben, indem Sie das Attribut elegantTextHeight auf false festlegen.

In Android 16 wird das Attribut elegantTextHeight eingestellt. Es wird ignoriert, sobald Ihre App auf Android 16 ausgerichtet ist. Die von diesen APIs gesteuerten „UI-Schriftarten“ werden eingestellt. Sie sollten daher alle Layouts anpassen, um eine konsistente und zukunftssichere Textwiedergabe in Arabisch, Laotisch, Birmanisch, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu oder Thailändisch zu gewährleisten.

Hauptfunktion

Android 16 (API-Level 36) enthält die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems ändern oder erweitern.

Optimierung der Arbeitsplanung mit fester Rate

Vor der Ausrichtung auf Android 16 wurde bei scheduleAtFixedRate eine Aufgabenausführung verpasst, wenn sich die App nicht in einem gültigen Prozesslebenszyklus befand. In diesem Fall wurden alle verpassten Ausführungen sofort ausgeführt, sobald die App zu einem gültigen Lebenszyklus zurückkehrte.

Wenn Sie Ihre App auf Android 16 ausrichten, wird bei einer verpassten Ausführung von scheduleAtFixedRate höchstens eine Ausführung sofort ausgeführt, wenn die App zu einem gültigen Lebenszyklus zurückkehrt. Durch diese Verhaltensänderung soll sich die App-Leistung verbessern. Testen Sie dieses Verhalten in Ihrer App, um festzustellen, ob sie davon betroffen ist. Sie können auch das App-Kompatibilitäts-Framework verwenden und das STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS-Kompatibilitätsflag aktivieren.

Formfaktoren von Geräten

Android 16 (API-Level 36) enthält die folgenden Änderungen für Apps, die auf Geräten mit großem Bildschirm angezeigt werden.

Adaptive Layouts

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 (API level 36), orientation, resizability, and aspect ratio restrictions no longer apply on displays with smallest width >= 600dp. Apps 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. Make your app adaptive to deliver the best possible user experience.

You can also test this behavior by using the app compatibility framework 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 (API level 36), 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>

Gesundheit und Fitness

Android 16 (API-Level 36) enthält die folgenden Änderungen in Bezug auf Gesundheits- und Fitnessdaten.

Berechtigungen für Gesundheits- und Fitnessdaten

For apps targeting Android 16 (API level 36) or higher, BODY_SENSORS permissions use more granular permissions under android.permissions.health, which Health Connect also uses. As of Android 16, any API previously requiring BODY_SENSORS or BODY_SENSORS_BACKGROUND requires the corresponding android.permissions.health permission instead. This affects the following data types, APIs, and foreground service types:

• HEART_RATE_BPM from Health Services on Wear OS
• Sensor.TYPE_HEART_RATE from Android Sensor Manager
• heartRateAccuracy and heartRateBpm from ProtoLayout on Wear OS
• FOREGROUND_SERVICE_TYPE_HEALTH where the respective android.permission.health permission is needed in place of BODY_SENSORS

If your app uses these APIs, it should 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 as READ_HEART_RATE instead of BODY_SENSORS.
• For background sensor access: request READ_HEALTH_DATA_IN_BACKGROUND instead of BODY_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.

Konnektivität

Android 16 (API-Level 36) enthält die folgenden Änderungen am Bluetooth-Stack, um die Konnektivität mit Peripheriegeräten zu verbessern.

Neue Intents für den Umgang mit Verbindungsverlusten und Verschlüsselungsänderungen

Im Rahmen der Verbesserten Verarbeitung von Verbindungsverlusten werden in Android 16 außerdem zwei neue Intents eingeführt, um Apps besser über Verbindungsverluste und Verschlüsselungsänderungen zu informieren.

Für Apps, die auf Android 16 ausgerichtet sind, ist jetzt Folgendes möglich:

• Sie erhalten eine ACTION_KEY_MISSING-Intent, wenn ein Verlust der Remote-Bindung erkannt wird. So können Sie Nutzern informativeres Feedback geben und entsprechende Maßnahmen ergreifen.
• Sie erhalten eine ACTION_ENCRYPTION_CHANGE-Intent, wenn sich der Verschlüsselungsstatus des Links ändert. Dazu gehören Änderungen des Verschlüsselungsstatus, des Verschlüsselungsalgorithmus und der Größe des Verschlüsselungsschlüssels. Apps müssen davon ausgehen, dass die Verknüpfung wiederhergestellt wurde, wenn die Verknüpfung nach Erhalt der ACTION_ENCRYPTION_CHANGE-Intent erfolgreich verschlüsselt wurde.

Anpassung an unterschiedliche OEM-Implementierungen

Diese neuen Intents werden in Android 16 eingeführt, ihre Implementierung und Übertragung kann jedoch je nach Gerätehersteller (OEM) variieren. Damit Ihre App auf allen Geräten einheitlich und zuverlässig funktioniert, sollten Entwickler die Verarbeitung von Verbindungsverlusten so gestalten, dass sie sich an diese potenziellen Abweichungen anpasst.

Wir empfehlen folgende App-Verhaltensweisen:

• Wenn die ACTION_KEY_MISSING-Intent gesendet wird:

  Die ACL-Verbindung (Asynchronous Connectionless) wird vom System getrennt, die Informationen zur Bindung für das Gerät bleiben jedoch erhalten (wie hier beschrieben).

  Ihre App sollte diese Intent als primäres Signal für die Erkennung von Verbindungsverlusten verwenden und den Nutzer auffordern, zu bestätigen, dass sich das Remotegerät in Reichweite befindet, bevor das Gerät vergessen oder neu gekoppelt wird.

  Wenn die Verbindung eines Geräts nach dem Empfang von ACTION_KEY_MISSING getrennt wird, sollte deine App vorsichtig sein, bevor sie eine neue Verbindung herstellt, da das Gerät möglicherweise nicht mehr mit dem System verbunden ist.

• Wenn die ACTION_KEY_MISSING-Intent NICHT gesendet wird:

  Die ACL-Verbindung bleibt bestehen und die Informationen zur Kopplung des Geräts werden vom System entfernt, genau wie bei Android 15.

  In diesem Fall sollte Ihre App die vorhandenen Mechanismen zur Verarbeitung von Verbindungsverlusten wie in früheren Android-Releases fortsetzen, um Verbindungsverluste zu erkennen und zu verwalten.

Neue Möglichkeit zum Entfernen einer Bluetooth-Verbindung

All apps targeting Android 16 are now able to unpair bluetooth devices using a public API in CompanionDeviceManager. If a companion device is being managed as a CDM association, then the app can trigger bluetooth bond removal by using the new removeBond(int) API on the associated device. The app can monitor the bond state changes by listening to the bluetooth device broadcast event ACTION_BOND_STATE_CHANGED.

Sicherheit

Android 16 (API-Level 36) enthält die folgenden Sicherheitsänderungen.

Version von MediaStore gesperrt

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.

Sicherere Intents

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

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

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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

Filterung von GPU-Systemaufrufen

Um die Mali-GPU-Oberfläche zu härten, wurden Mali-GPU-IOCTLs, die veraltet sind oder ausschließlich für die GPU-Entwicklung vorgesehen sind, in Produktions-Builds blockiert. Außerdem wurden IOCTLs, die für das GPU-Profiling verwendet werden, auf den Shell-Prozess oder debugfähige Anwendungen beschränkt. Weitere Informationen zur Richtlinie auf Plattformebene finden Sie im SAC-Update.

Diese Änderung betrifft Pixel-Geräte mit der Mali-GPU (Pixel 6–9). Arm hat in der Version r54p2 in Documentation/ioctl-categories.rst eine offizielle Kategorisierung der IOCTLs vorgenommen. Diese Liste wird auch in zukünftigen Treiberversionen gepflegt.

Diese Änderung hat keine Auswirkungen auf unterstützte Grafik-APIs (einschließlich Vulkan und OpenGL) und wird sich voraussichtlich nicht auf Entwickler oder bestehende Anwendungen auswirken. GPU-Profiling-Tools wie Streamline Performance Analyzer und Android GPU Inspector sind nicht betroffen.

Test

Wenn Sie eine SELinux-Verweigerung sehen, die der folgenden ähnelt, ist Ihre Anwendung wahrscheinlich von dieser Änderung betroffen:

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

Wenn Ihre Anwendung blockierte IOCTLs verwenden muss, melden Sie bitte einen Fehler und weisen Sie ihn android-partner-security@google.com zu.

FAQ

1. Gilt diese Richtlinienänderung für alle OEMs? Diese Änderung ist optional, aber für alle OEMs verfügbar, die diese Härtungsmethode verwenden möchten. Eine Anleitung zur Implementierung der Änderung finden Sie in der Implementierungsdokumentation.

2. Müssen Änderungen an der OEM-Codebasis vorgenommen werden, um diese Änderung zu implementieren, oder ist sie standardmäßig in einem neuen AOSP-Release enthalten? Die Änderung auf Plattformebene ist standardmäßig in einem neuen AOSP-Release enthalten. Anbieter können diese Änderung in ihre Codebasis aufnehmen, wenn sie sie anwenden möchten.

3. Sind SoCs dafür verantwortlich, die IOCTL-Liste auf dem neuesten Stand zu halten? Wenn mein Gerät beispielsweise eine ARM Mali-GPU verwendet, muss ich mich dann bei Änderungen an ARM wenden? Einzelne SoCs müssen ihre IOCTL-Listen pro Gerät nach der Treiberveröffentlichung aktualisieren. ARM aktualisiert beispielsweise die veröffentlichte IOCTL-Liste nach Treiberupdates. OEMs sollten jedoch darauf achten, dass sie die Updates in ihre SEPolicy einbeziehen und ausgewählte benutzerdefinierte IOCTLs nach Bedarf zu den Listen hinzufügen.

4. Gilt diese Änderung automatisch für alle im Handel erhältlichen Pixel-Geräte oder muss ein Nutzer etwas tun, um diese Änderung anzuwenden? Diese Änderung gilt für alle im Handel erhältlichen Pixel-Geräte mit der Mali-GPU (Pixel 6–9). Es ist keine Nutzeraktion erforderlich, um diese Änderung anzuwenden.

5. Wirkt sich die Verwendung dieser Richtlinie auf die Leistung des Kernel-Treibers aus? Diese Richtlinie wurde auf der Mali-GPU mit GFXBench getestet. Es wurden keine messbaren Änderungen an der GPU-Leistung festgestellt.

6. Muss die IOCTL-Liste mit den aktuellen Versionen des Userspace- und Kernel-Treibers übereinstimmen? Ja, die Liste der zulässigen IOCTLs muss mit den IOCTLs synchronisiert werden, die sowohl vom Userspace- als auch vom Kernel-Treiber unterstützt werden. Wenn die IOCTLs im Userspace- oder Kernel-Treiber aktualisiert werden, muss die SEPolicy-IOCTL-Liste entsprechend aktualisiert werden.

7. ARM hat IOCTLs als „eingeschränkt“ / „Instrumentierung“ kategorisiert, aber wir möchten einige davon in Produktionsanwendungsfällen verwenden und/oder andere ablehnen. Einzelne OEMs/SoCs sind dafür verantwortlich, wie sie die von ihnen verwendeten IOCTLs kategorisieren, basierend auf der Konfiguration ihrer Mali-Bibliotheken im Userspace. Die Liste von ARM kann bei der Entscheidung helfen, aber der Anwendungsfall jedes OEM/SoC kann unterschiedlich sein.

Datenschutz

Android 16 (API-Level 36) enthält die folgenden Änderungen in Bezug auf den Datenschutz.

Berechtigung für das lokale Netzwerk

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:

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.

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

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.

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.

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.

App-eigene Fotos

When prompted for photo and video permissions by an app targeting SDK 36 or higher on devices running Android 16 or higher, users who choose to limit access to selected media will see any photos owned by the app pre-selected in the photo picker. Users can deselect any of these pre-selected items, which will revoke the app's access to those photos and videos.