Android 11 wird mit einer neuen „App-Kompatibilität“-Einstellung in der Entwickleroption ausgestattet sein, die es App-Entwicklern erleichtert, Verhaltensänderungen der Plattform zu testen.
Jedes Jahr stellt Google auf der Google I/O einige der aufregendsten Änderungen vor, die mit der nächsten Android-Version einhergehen. Während die meisten Benutzer Android-Versionen nach den visuellen Änderungen beurteilen, die sich auf ihr Erlebnis auswirken, bringt jedes Android-Update auch eine Menge davon mit sich Änderungen an APIs Und Plattformverhalten. Für App-Entwickler ist es wichtig, diese Änderungen zur Kenntnis zu nehmen und ihre Apps darauf vorzubereiten, da sie die Art und Weise, wie ihre Apps von Endbenutzern genutzt werden können, grundlegend verändern können. Mit der nächsten Android-Version, Android 11, wird Google es Entwicklern mit einer neuen „App-Kompatibilität“-Einstellung in den Entwickleroptionen einfacher machen, ihre Apps zu testen und auf bevorstehende Änderungen vorzubereiten.
Jedes Mal, wenn Google eine neue Android-Version veröffentlicht, sind App-Entwickler daran interessiert, diese aktiv zu pflegen Ihre Anwendungen müssen sich über die neuen Änderungen und die dazugehörige Dokumentation informieren Änderungen. Sie können dann entscheiden, ob sie ihre App aktualisieren möchten, um diese neuen API-Funktionen hinzuzufügen, wenn sie möchten, oder die Nutzung bestehender APIs auf neuere APIs migrieren, ein Weg, der optional sein kann oder auch nicht. App-Entwickler müssen die Ziel-API ihrer Apps nicht sofort aktualisieren, aber sie müssen es irgendwann tun, um die Anforderungen zu erfüllen Verschiebung der Ziel-API-Anforderungen des Google Play Store. Anschließend müssen Entwickler ihre App auch tatsächlich auf der neuen Android-Version testen. Dies kann auf einem emulierten Gerät, einem in der Cloud gehosteten Gerät oder einem lokalen Gerät erfolgen. Tests sind Teil der Entwicklungsroutine, aber Tests werden noch wichtiger, wenn es um große Änderungen geht.
Wenn Google außerdem größere Verhaltensänderungen auf der Plattform einführen möchte, setzt es die Änderung nicht sofort in der neuen Android-Version um. Dies soll Benutzer davor schützen, dass viele ihrer Apps kaputt gehen und ihre Funktionalität verlieren, und es gibt Entwicklern auch mehr Zeit, ihre Apps zu aktualisieren. Bei Android 7 Nougat hat sich Google beispielsweise dafür entschieden Beschränken Sie einige implizite Übertragungen um den Akku zu schonen. Mit Android 8 Oreo, Google Apps wurden vollständig daran gehindert, implizite Rundfunkempfänger zu registrieren. Doch vor der Veröffentlichung von Android 8 Oreo wollte Google, dass sich die Entwickler auf ein Szenario vorbereiten, in dem ihre Apps keine impliziten Rundfunkempfänger mehr registrieren können. Und dafür könnten Entwickler Verwenden Sie einen ADB-Befehl in Android 7 Nougat, um einen Zustand zu simulieren, in dem implizite Broadcasts nicht verfügbar sind:
adb shell cmd appops set RUN_IN_BACKGROUND ignoreADB-Befehle wie der obige sind ein Beispiel dafür, wie Google es App-Entwicklern ermöglicht, zu testen, wie sich ihre Apps bei Verhaltensänderungen der Android-Plattform verhalten würden.
Ein weiteres aktuelles Beispiel ist, wie in Android Q Beta 2 Google hat Entwickler gebeten, Scoped Storage zu testen auf ihren Apps, indem Sie diesen ADB-Befehl ausführen:
adb shell cmd appops set your-package-name android: legacy_storage default && \Als App-Entwickler kann man davon ausgehen, dass Sie mit ADB-Befehlen vertraut sind und nicht besonders abgeneigt sind, sie zum Testen dieser Plattformänderungen zu verwenden. Aber es gibt immer Raum für Verbesserungen, und Google vereinfacht diesen Testprozess durch die Einführung einer einfachen Benutzeroberfläche zur Steuerung dieser Änderungen.
Mit dem Neuen PlatformCompat-Projektmüssen Entwickler nicht mehr bei jeder neuen Änderung des Plattformverhaltens ADB-Befehle ausführen. Mit Android 11 verfügt Android über ein neues Untermenü in den Entwickleroptionen, mit dem Sie neue Verhaltensänderungen der Plattform schnell für jede App umschalten können, ohne dass ADB-Shell-Befehle gesendet werden müssen. Für jede Ziel-API-Ebene wird es unterschiedliche Abschnitte geben – beispielsweise API-Ebene > 29 Es verfügt über einen eigenen Satz von Verhaltensänderungen, die umgeschaltet werden können, während API-Level > 30 über einen eigenen Satz von Verhaltensänderungen verfügen Änderungen.
Im Screenshot oben, der den Abschnitt „App-Kompatibilität“ zeigt (von einem im Quellcode erstellten AOSP, der auf einem Emulator ausgeführt wird), wird „Default Der Abschnitt „Aktivierte Änderungen“ enthält API-Änderungen für Android 11, die standardmäßig für alle Apps unabhängig von ihrem Ziel aktiviert werden SDK. Der Abschnitt „Aktiviert für targetSDKversion > 29“ enthält Android 11-API-Änderungen, die nur für Apps aktiviert sind, die auf Android 11/API-Level 30 abzielen.
Obwohl diese besondere Änderung die Endbenutzer nicht direkt begeistern wird, erleichtert sie die Arbeit der App-Entwickler, und das ist immer gut so.
Vielen Dank an den anerkannten XDA-Entwickler luca020400 für den Tipp und die Bereitstellung des beigefügten Screenshots.
Weitere Berichterstattung zu Android 11:
- Android 11 hebt möglicherweise endlich die 4-GB-Dateigrößenbeschränkung von Android für Videoaufnahmen auf
- Die Planung im Dunkelmodus könnte in Android 11 verfügbar sein
- Ab Android 11 R hört der Flugmodus möglicherweise endlich auf, Bluetooth-Audio abzuschalten
- Google stellt die AsyncTask-API von Android in Android 11 ein
- Google wird Dateimanager-Entwickler dazu verpflichten, ein Formular einzureichen, um in Android 11 umfassenden Zugriff auf den Dateispeicher zu erhalten
- Android 11 bringt möglicherweise endlich eine richtige, native Wireless ADB-Implementierung