Diese Seite wurde von der Cloud Translation API übersetzt.

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 anpassen, 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 vom targetSdkVersion Ihrer App.

Nutzerfreundlichkeit und System-UI

Android 16 (API-Level 36) enthält die folgenden Änderungen, die für eine einheitlichere, intuitive Nutzererfahrung sorgen sollen.

Deaktivierung von Edge-to-Edge-Anzeigen nicht mehr möglich

Android 15: Edge-to-Edge-Anzeige für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind: Für Apps, die auf Android 15 (API-Level 35) ausgerichtet sind, wird die Edge-to-Edge-Anzeige erzwungen. Sie können die Funktion jedoch deaktivieren, indem Sie R.attr#windowOptOutEdgeToEdgeEnforcement auf true setzen. Bei Apps, die auf Android 16 (API-Level 36) ausgerichtet sind, ist R.attr#windowOptOutEdgeToEdgeEnforcement eingestellt und deaktiviert. Deine App kann nicht deaktivieren, dass sie randlos angezeigt wird.

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.

Wenn Sie Ihre App unter Android 16 testen, muss sie Edge-to-Edge unterstützen. Entfernen Sie alle Verwendungen von R.attr#windowOptOutEdgeToEdgeEnforcement, damit Ihre App auch auf einem Android 15-Gerät Edge-to-Edge unterstützt. Informationen zur Unterstützung von Edge-to-Edge finden Sie in den Anleitungen zu Compose und Views.

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

Bei Apps, die auf Android 16 (API‑Level 36) oder höher ausgerichtet sind und auf einem Gerät mit Android 16 oder höher ausgeführt werden, sind die Systemanimationen für das vorhersagbare Zurückgehen (Zurück zum Startbildschirm, Aufgabenübergang und Aktivitätsübergang) standardmäßig aktiviert. Außerdem wird onBackPressed nicht aufgerufen und KeyEvent.KEYCODE_BACK wird nicht mehr gesendet.

Wenn Ihre App das Zurück-Ereignis abfängt und Sie noch nicht auf die Vorhersage für „Zurück“ migriert haben, aktualisieren Sie Ihre App, damit sie unterstützte APIs für die Zurück-Navigation verwendet, oder deaktivieren Sie die Vorhersage für „Zurück“ vorübergehend, indem Sie das Attribut android:enableOnBackInvokedCallback in der Datei AndroidManifest.xml Ihrer App im Tag <application> oder <activity> auf false festlegen.

Die Animation für die intelligente „Zurück“-Touchgeste, die zum Startbildschirm führt.

Die vorausschauende Aktivitätsanimation.

Die vorhersagende Animation für mehrere Aufgaben.

Elegant Font APIs eingestellt und deaktiviert

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

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

Hauptfunktion

Android 16 (API-Level 36) umfasst die folgenden Änderungen, die verschiedene Kernfunktionen des Android-Systems modifizieren oder erweitern.

Optimierung der Arbeitsplanung mit festem Tarif

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ßen Bildschirmen angezeigt werden.

Adaptive Layouts

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备方向如何。在当今的多设备世界中，限制屏幕方向和可调整尺寸等范式过于严格。

忽略屏幕方向、可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，Android 16 包含对系统管理屏幕方向、尺寸调整能力和宽高比限制的方式的变更。在最小宽度大于或等于 600dp 的显示屏上，这些限制不再适用。应用还会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖条模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸可调整性等限制会阻碍应用的适应性，因此我们建议让应用具备自适应能力，以提供尽可能出色的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素，例如布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

系统会忽略 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>

Gesundheit und Fitness

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

Berechtigungen für Gesundheit und Fitness

Für Apps, die auf Android 16 (API‑Level 36) oder höher ausgerichtet sind, werden für BODY_SENSORS-Berechtigungen detailliertere Berechtigungen unter android.permissions.health verwendet, die auch von Health Connect genutzt werden. Ab Android 16 ist für alle APIs, für die bisher BODY_SENSORS oder BODY_SENSORS_BACKGROUND erforderlich war, stattdessen die entsprechende android.permissions.health-Berechtigung erforderlich. Dies betrifft die folgenden Datentypen, APIs und Arten von Vordergrunddiensten:

HEART_RATE_BPM aus den Gesundheitsdiensten unter Wear OS
Sensor.TYPE_HEART_RATE aus dem Android Sensor Manager
heartRateAccuracy und heartRateBpm aus ProtoLayout unter Wear OS
FOREGROUND_SERVICE_TYPE_HEALTH, wobei die entsprechende Berechtigung android.permission.health anstelle von BODY_SENSORS erforderlich ist

Wenn Ihre App diese APIs verwendet, sollten die entsprechenden detaillierten Berechtigungen angefordert werden:

Für die Überwachung von Herzfrequenz, SpO2 oder Hauttemperatur während der Nutzung: Fordern Sie die detaillierte Berechtigung unter android.permissions.health an, z. B. READ_HEART_RATE anstelle von BODY_SENSORS.
Für den Sensorzugriff im Hintergrund: Fordern Sie READ_HEALTH_DATA_IN_BACKGROUND anstelle von BODY_SENSORS_BACKGROUND an.

Diese Berechtigungen sind dieselben, die den Zugriff auf das Lesen von Daten aus Health Connect, dem Android-Datenspeicher für Gesundheits-, Fitness- und Wellnessdaten, schützen.

Mobile Apps

Bei mobilen Apps, die zur Verwendung von READ_HEART_RATE und anderen detaillierten Berechtigungen migriert werden, muss auch eine Aktivität deklariert werden, um die Datenschutzerklärung der App anzuzeigen. Das ist dieselbe Anforderung wie bei Health Connect.

Konnektivität

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

Neue Intents für den Umgang mit Verlust der Bindung und Änderungen an der Verschlüsselung

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 der Bluetooth-Kopplung

Alle Apps, die auf Android 16 ausgerichtet sind, können jetzt Bluetooth-Geräte über eine öffentliche API in CompanionDeviceManager entkoppeln. Wenn ein Companion-Gerät als CDM-Verknüpfung verwaltet wird, kann die App die Entfernung der Bluetooth-Verknüpfung über die neue removeBond(int) API auf dem verknüpften Gerät auslösen. Die App kann die Änderungen des Kopplungsstatus überwachen, indem sie das Bluetooth-Geräte-Broadcast-Ereignis ACTION_BOND_STATE_CHANGED überwacht.

Sicherheit

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

Sperrung der MediaStore-Version

Bei Apps, die auf Android 16 oder höher ausgerichtet sind, ist MediaStore#getVersion() jetzt für jede App eindeutig. Dadurch werden identifizierende Eigenschaften aus dem Versionsstring entfernt, um Missbrauch und Verwendung für Fingerprinting-Techniken zu verhindern. Apps dürfen keine Annahmen über das Format dieser Version treffen. Apps sollten Versionsänderungen bereits bei der Verwendung dieser API verarbeiten und in den meisten Fällen sollte ihr aktuelles Verhalten nicht geändert werden müssen, es sei denn, der Entwickler hat versucht, zusätzliche Informationen abzuleiten, die über den beabsichtigten Umfang dieser API hinausgehen.

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:

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

Flag Name	Description
enforceIntentFilter	Enforces stricter matching for incoming intents
none	Disables all special matching rules for incoming intents. When specifying multiple flags, conflicting values are resolved by giving precedence to the "none" flag
allowNullAction	Relaxes the matching rules to allow intents without an action to match. This flag to be used in conjunction with "enforceIntentFilter" to achieve a specific behavior

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:")

Datenschutz

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

Berechtigung für das lokale Netzwerk

Auf Geräte im LAN kann von jeder App zugegriffen werden, die die Berechtigung INTERNET hat. Dadurch können Apps problemlos eine Verbindung zu lokalen Geräten herstellen. Dies hat jedoch auch Auswirkungen auf den Datenschutz, z. B. in Bezug auf die Erstellung eines Fingerabdrucks des Nutzers und die Verwendung als Proxy für den Standort.

Das Projekt „Local Network Protections“ zielt darauf ab, die Privatsphäre des Nutzers zu schützen, indem der Zugriff auf das lokale Netzwerk durch eine neue Laufzeitberechtigung eingeschränkt wird.

Release-Plan

Diese Änderung wird zwischen zwei Releases bereitgestellt, nämlich 25Q2 und TBD. Entwickler müssen diese Anleitung für das 2. Quartal 2025 unbedingt befolgen und Feedback geben, da diese Schutzmaßnahmen in einem späteren Android-Release erzwungen werden. Außerdem müssen sie Szenarien aktualisieren, die auf implizitem lokalen Netzwerkzugriff basieren. Dazu müssen sie die folgende Anleitung befolgen und sich auf die Ablehnung und den Widerruf der neuen Berechtigung durch Nutzer vorbereiten.

Positiv beeinflussen

Derzeit ist LNP eine Opt-in-Funktion. Das bedeutet, dass nur die Apps betroffen sind, für die sie aktiviert wurde. In der Opt-in-Phase sollen App-Entwickler herausfinden, welche Teile ihrer App auf impliziten Zugriff auf das lokale Netzwerk angewiesen sind, damit sie sich auf die Berechtigungsanforderungen für die nächste Version vorbereiten können.

Apps sind betroffen, wenn sie über Folgendes auf das lokale Netzwerk des Nutzers zugreifen:

Direkte oder bibliotheksbasierte Verwendung von Raw Sockets für lokale Netzwerkadressen (z.B. mDNS- oder SSDP-Diensterkennungsprotokoll)
Verwendung von Klassen auf Framework-Ebene, die auf das lokale Netzwerk zugreifen (z.B. NsdManager)

Für Traffic zu und von einer lokalen Netzwerkadresse ist die Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich. In der folgenden Tabelle sind einige häufige Fälle aufgeführt:

Low-Level-Netzwerkbetrieb von Apps	Berechtigung für das lokale Netzwerk erforderlich
Ausgehende TCP-Verbindung herstellen	Ja
Eingehende TCP-Verbindungen akzeptieren	Ja
Senden eines UDP-Unicast, ‑Multicast oder ‑Broadcast	Ja
Eingehendes UDP-Unicast, ‑Multicast oder ‑Broadcast empfangen	Ja

Diese Einschränkungen sind tief im Netzwerk-Stack implementiert und gelten daher für alle Netzwerk-APIs. Dazu gehören Sockets, die in nativem oder verwaltetem Code erstellt wurden, Netzwerkbibliotheken wie Cronet und OkHttp sowie alle APIs, die darauf basieren. Wenn Sie versuchen, Dienste im lokalen Netzwerk aufzulösen (d.h. solche mit dem Suffix „.local“), ist die Berechtigung für das lokale Netzwerk erforderlich.

Ausnahmen von den oben genannten Regeln:

Wenn sich der DNS-Server eines Geräts in einem lokalen Netzwerk befindet, ist für den Traffic zu oder von ihm (über Port 53) keine Berechtigung für den Zugriff auf das lokale Netzwerk erforderlich.
Für Anwendungen, die Output Switcher als In-App-Auswahl verwenden, sind keine Berechtigungen für das lokale Netzwerk erforderlich (weitere Informationen folgen im 4. Quartal 2025).

Entwicklerleitfaden (Opt-in)

So aktivieren Sie Einschränkungen für das lokale Netzwerk:

Flashen Sie das Gerät mit einem Build mit 25Q2 Beta 3 oder höher.
Installieren Sie die zu testende App.

AppCompat-Flag in adb umschalten:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

Gerät neu starten

Der Zugriff Ihrer App auf das lokale Netzwerk ist jetzt eingeschränkt und jeder Versuch, auf das lokale Netzwerk zuzugreifen, führt zu Socket-Fehlern. Wenn Sie APIs verwenden, die lokale Netzwerkoperationen außerhalb Ihres App-Prozesses ausführen (z. B. NsdManager), sind sie während der Opt-in-Phase nicht betroffen.

Um den Zugriff wiederherzustellen, müssen Sie Ihrer App die Berechtigung für NEARBY_WIFI_DEVICES erteilen.

Die App muss die Berechtigung NEARBY_WIFI_DEVICES in ihrem Manifest deklarieren.
Gehen Sie zu Einstellungen > Apps > [Name der App] > Berechtigungen > Geräte in der Nähe > Zulassen.

Der Zugriff Ihrer App auf das lokale Netzwerk sollte jetzt wiederhergestellt sein und alle Ihre Szenarien sollten wie vor der Aktivierung der App funktionieren.

Sobald die Durchsetzung des Schutzes des lokalen Netzwerks beginnt, wirkt sich das auf den Netzwerkverkehr der App aus.

Berechtigung	Ausgehende LAN-Anfrage	Ausgehende/eingehende Internetanfrage	Eingehende LAN-Anfrage
Gewährt	Microsoft Works	Microsoft Works	Microsoft Works
Nicht gewährt	Pannen	Microsoft Works	Pannen

Verwenden Sie den folgenden Befehl, um das App-Compat-Flag zu deaktivieren:

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Fehler

Fehler, die durch diese Einschränkungen entstehen, werden an den aufrufenden Socket zurückgegeben, wenn er „send“ oder eine „send“-Variante für eine lokale Netzwerkadresse aufruft.

Beispiele für Fehler:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Definition des lokalen Netzwerks

Ein lokales Netzwerk in diesem Projekt bezieht sich auf ein IP-Netzwerk, das eine für Broadcasts geeignete Netzwerkschnittstelle wie WLAN oder Ethernet verwendet, jedoch keine Mobilfunk- (WWAN) oder VPN-Verbindungen.

Die folgenden Netzwerke gelten als lokale Netzwerke:

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
Direkt verbundene Routen
Stichleitungsnetzwerke wie Thread
Mehrere Subnetze (noch nicht festgelegt)

Außerdem werden sowohl die Multicast-Adressen (224.0.0.0/4, ff00::/8) als auch die IPv4-Broadcast-Adresse (255.255.255.255) als lokale Netzwerkadressen klassifiziert.

App-eigene Fotos

Wenn Nutzer auf Geräten mit Android 16 oder höher von einer App, die auf SDK 36 oder höher ausgerichtet ist, um Berechtigungen für Fotos und Videos gebeten werden und den Zugriff auf ausgewählte Medien einschränken, werden alle Fotos, die der App gehören, in der Bildauswahl vorab ausgewählt angezeigt. Nutzer können die Auswahl dieser Elemente jederzeit aufheben. Dadurch wird der Zugriff der App auf diese Fotos und Videos widerrufen.