Android 11 AMA: Keine scrollenden Screenshots, schnellere App-Starts und mehr

click fraud protection

Das Android-Entwicklungsteam von Google veranstaltete eine AMA auf Reddit, um Fragen zu Android 11 zu beantworten. Hier ist, was wir über die nächste Android-Betriebssystemversion erfahren haben.

Gestern hat Google veröffentlicht Android 11 Beta 2, wodurch das finalisierte SDK, NDK, App-Oberflächen, Plattformverhalten und Einschränkungen für Nicht-SDK-Schnittstellen für Entwickler bereitgestellt werden. Heute beantwortet Google in der /r/AndroidDev-Community von Reddit Fragen zu Android 11 nachdem ich letzte Woche Fragen beantwortet habe. Hier ist eine Zusammenfassung von allem, was wir aus Googles AMA (Ask Me Anything) gelernt haben.

Eine der am meisten erwarteten Funktionen von Android 11 wird mit dem Betriebssystem nicht verfügbar sein verlässt die Beta-Phase am 8. September: Scrollende Screenshots. Anfänglich Der Start ist für Android 11 geplantGoogle hat nun bestätigt, dass die Funktion „nicht für R geeignet war“. Android 11 Developer Preview 1 und Alle nachfolgenden DP- und Beta-Versionen verfügen über eine Platzhalterschaltfläche zum Erstellen eines scrollbaren Screenshots

manuell mit einem versteckten Entwicklerbefehl aufgetaucht, aber wenn Sie auf die Schaltfläche tippen, wird lediglich eine Toastmeldung angezeigt, die besagt, dass die Funktion „nicht implementiert“ ist.

Die nicht implementierte Scroll-Screenshot-Schaltfläche von Android 11.

Wir hatten gehofft, dass das Feature seinen Weg in eine Beta-Version oder auch nur in die stabile Version finden würde, aber es sieht so aus, als würde das einfach nicht passieren.

Kommentar aus der Diskussion. Wir sind im Android-Engineering-Team. Fragen Sie uns nach Android 11-Updates für die Android-Plattform! (beginnt am 9. Juli).

Diese Nachricht wird einige Benutzer verständlicherweise verärgern. Schließlich haben viele OEMs diese Funktion schon seit Jahren in ihrer eigenen Software integriert. Warum braucht Google also so lange, um sie Pixel-Telefonen hinzuzufügen? Wie Dan Sandler vom System-UI-Team von Google erklärt, besteht das Problem darin, dass Google es richtig machen will. Einige Scroll-Screenshot-Implementierungen emulieren einfach einen Scrollvorgang und fügen dann mehrere Screenshots zusammen, während sich der Bildschirm bewegt. Wenn Sie sich jemals mit der UI-Automatisierung auf Android beschäftigt haben, wissen Sie, dass dies nicht immer funktioniert, da es sich, wie Herr Sandler erwähnt, um Apps handelt kann „ein Standard-RecyclerView verwenden oder eine eigene OpenGL-beschleunigte Scrolling-Engine implementiert haben“. Da Google es vorhat Um diese Funktion nicht nur für Pixel-Smartphones, sondern für das gesamte Android-Ökosystem als Teil von AOSP zu implementieren, müssen sie sicherstellen es wird klappen alle Apps und nicht nur „ein oder zwei handverlesene Apps auf einem bestimmten Gerät“.

Denn das Team musste „seine begrenzten Ressourcen konzentrieren“, insbesondere aufgrund der damit verbundenen Herausforderungen Aufgrund von COVID-19 beschloss das Team, scrollende Screenshots für eine zukünftige Android-Version in den Hintergrund zu rücken.

Neue CDD-Anforderung, um Benutzer über Hintergrundbeschränkungen zu informieren

Es ist kein Geheimnis, dass viele Android-OEMs, insbesondere chinesische, strenge Einschränkungen für Apps haben, die im Hintergrund ausgeführt werden. Einige Entwickler waren so frustriert darüber, dass ihre Apps im Hintergrund abgeschaltet wurden, dass sie sich zusammenschlossen, um eine Website namens „Töte meine App nicht„Um OEMs danach zu bewerten, wie schlecht sie mit Hintergrund-App-Prozessen umgehen. Dieselben Entwickler sogar kürzlich einen Benchmark erstellt So können Benutzer testen, wie aggressiv ihr Gerät Apps im Hintergrund beendet. Der Grund, warum viele OEMs gerne Hintergrund-App-Prozesse beenden, ist kompliziert, aber ich denke, er lässt sich am besten in diesem Kommentar von Redditor /u/ erklären.möglicherweise fraglich. Der Kommentar beschreibt den komplizierten Stand der Android-App-Entwicklung in China und die Art und Weise, wie chinesische Technologieunternehmen dazu beitragen, die Dinge noch weiter zu verkomplizieren, und wie ein Mangel an Google-Diensten dazu beiträgt, dass die Sache noch komplizierter wird Durcheinander.

Ungeachtet dessen sind viele App-Entwickler verständlicherweise frustriert über diese Änderungen am Verhalten der Android-Plattform, was dazu geführt hat, dass Entwickler einen Kommentar abgegeben haben Ich frage Google, was sie dagegen unternehmen an die Spitze des Reddit AMA. Hier ist die Antwort von Google:

Kommentar aus der Diskussion. Wir sind im Android-Engineering-Team. Fragen Sie uns nach Android 11-Updates für die Android-Plattform! (beginnt am 9. Juli).

Aus dieser Antwort lässt sich einiges mitnehmen. Erstens möchte Google, dass OEMs gegenüber den Nutzern transparenter über die von ihnen angewendeten Einschränkungen für Hintergrund-Apps sind. Ich habe das (unveröffentlichte) Android 11 Compatibility Definition Document (CDD) überprüft und die folgende vorgeschlagene Ergänzung zu Abschnitt 3.5 – API-Verhaltenskompatibilität gefunden:

Wenn Geräteimplementierungen einen proprietären Mechanismus zum Einschränken von Apps implementieren und dieser Mechanismus restriktiver ist als der „seltene“ Standby-Bucket auf AOSP, dann:

[C-1-5] MUSS Benutzer informieren, wenn App-Einschränkungen automatisch auf eine App angewendet werden. (NEU) Solche Informationen DÜRFEN nicht früher als 24 Stunden vor Inkrafttreten dieser Beschränkungen bereitgestellt werden.

(Hinweis) Force Stop gilt als restriktiver als „Rare“ und MUSS alle Anforderungen unter 3.5.1 erfüllen, einschließlich des neuen 3.5.1/C-1-5

Im Grunde kann Google OEMs kaum davon abhalten, ihre eigenen restriktiven App-Killing-Funktionen zu implementieren. Sie verlangen lediglich, dass OEMs Benutzer informieren, wenn ihre App-Einschränkungen automatisch angewendet werden. Ein OEM könnte einen Dialog anzeigen, dass er die Ausführung von batteriefressenden Hintergrund-Apps unterbindet Hintergrund, und der Benutzer könnte zustimmen, ohne zu bemerken, dass die Apps, die er wirklich im Hintergrund ausführen möchte, dies auch tun betroffen! Google legt den Entwicklern die Verantwortung auf, mit Fällen umzugehen, in denen ihre App unerwartet im Hintergrund beendet wird. Tatsächlich hebt der Reddit-Kommentar das Neue hervor:Gründe für das Beenden des App-Prozesses„API, die Entwicklern mitteilen kann, ob ihre App vom Benutzer oder vom Betriebssystem beendet wurde oder einfach abgestürzt ist.

Andererseits geht Google endlich gegen die unfaire Praxis von OEMs vor, die es bestimmten privilegierten Anwendungen erlauben, ihre Hintergrund-App-Beschränkungen zu umgehen. Dieser mittlere Beitrag des Entwicklers Timothy Asiimwe geht detailliert auf Apps wie WhatsApp, Facebook und andere Apps ein, die automatisch von den strengen Hintergrundbeschränkungen einiger OEM-Software ausgenommen sind. Google sagt, dass sie „verlangen, dass Gerätehersteller keine Zulassungslisten für Top-Apps erstellen“. Wir wissen nicht, wie dies durchgesetzt wird, aber Es ist gut zu wissen, dass OEMs endlich gezwungen sein werden, Drittentwickler gleichberechtigt zu behandeln – egal wie groß oder klein ihre Apps sind Sind.

Schließlich erwähnt Google auch, dass Android 11 „zusätzliche Maßnahmen hinzugefügt hat, um missbräuchliches Verhalten durch sich schlecht verhaltende Apps zu verhindern“, wodurch es für OEMs weniger verlockend wird, Hintergrundprozesse aggressiv zu beenden. Das Unternehmen machte jedoch keine Angaben dazu, was diese „zusätzlichen Maßnahmen“ bedeuten.

Verbesserte Geräte-zu-Gerät-Backups

Letzten Monat haben wir eine Änderung in der Dokumentation von Android 11 entdeckt deutete auf die Unterstützung besserer lokaler Datensicherungen hin. In Android 11 ignoriert das System das Attribut „allowBackup Manifest“ für jede App, die auf API-Level 30 abzielt, wenn der Benutzer eine „Gerät-zu-Gerät“-Migration von App-Dateien initiiert. Googler Eliot Stock sagt, dass diese Funktion es Telefonherstellern „viel einfacher machen soll, Geräte-zu-Gerät-Migrationstools“ wie „Samsungs hervorragendes Smart Switch-Produkt“ zu entwickeln Helfen Sie dabei, „aus Benutzersicht eine zuverlässigere Übertragung von Apps zwischen Geräten sicherzustellen.“ Leider gilt dies nicht für Cloud-basierte Backups, da Google „Softwareentwicklern die Kontrolle über das, was“ geben möchte passiert mit ihren App-Daten.“ Daher respektiert Android 11 weiterhin das Attribut „allowBackup“ für jede cloudbasierte Sicherung und Wiederherstellung, beispielsweise über das integrierte Google Drive des Google Play-Dienstes Sicherung. Schließlich räumt Google ein, dass die Backup-Obergrenze von 25 MB pro App für einige Entwickler möglicherweise nicht ausreicht, und sucht daher nach Möglichkeiten, dieses Problem zu lösen. Lokale Backups auf einem PC werden jedoch nicht in Betracht gezogen und Google bekräftigt seinen Plan dazu ADB-Backup auslaufen lassen in einer zukünftigen Android-Version.

Kommentar aus der Diskussion. Wir sind im Android-Engineering-Team. Fragen Sie uns nach Android 11-Updates für die Android-Plattform! (beginnt am 9. Juli).

Entwickler werden ermutigt, reibungslose Datenmigrationsmethoden zu implementieren. Der neue Block Store-Bibliothek, das Teil der Google Identity Services-Bibliothek ist, soll die Anmeldung bei wiederhergestellten Apps erleichtern aus der Cloud auf neue Geräte, aber es liegt an den Entwicklern, zu entscheiden, ob sie dies implementieren möchten oder nicht Bibliothek.

Schnellere App-Startgeschwindigkeiten mit I/O Read Ahead Process (IORap)

Google experimentiert ständig mit Möglichkeiten, die Leistung von Android zu verbessern. Eine der wenig bekannten Funktionen, die sie in Android 10 hinzugefügt haben, heißt Unspecialized App Process Pool (USAP). Durch diese Funktion entfällt das Forken von Zygote während des App-Startvorgangs, wodurch die durchschnittliche App-Startgeschwindigkeit auf einem Pixel-2-Gerät etwa 5 ms einspart. Die Funktion ist derzeit verfügbar in AOSP standardmäßig deaktiviert, und Google erklärt, dass die zusätzliche Speichernutzung noch getestet werden muss. Interessanter ist jedoch eine neue Funktion für Android 11 namens I/O Read Ahead Process (IORap). Laut Google, wird diese Funktion zu „mehr als 5 % schnelleren Kaltstarts führen, wobei Heldenfälle 20 % schneller erreicht werden.“ Dieses Feature „ruft Anwendungsartefakte (wie Code und Ressourcen) während des Startvorgangs vorab ab“, um den App-Start zu beschleunigen Geschwindigkeiten.

Google hat auch „Verbesserungen an den Profilen vorgenommen, die zur Optimierung des Boot-Klassenpfads und des System-Images verwendet werden“. Dadurch wird die App-Leistung verbessert und die mit dem System verbundenen Speicher- und Speicherkosten gesenkt Artefakte. Diese Änderungen kommen vor allem Geräten mit mehr RAM zugute, Google hat jedoch nicht angegeben, wo die Grenze liegt, bei der wir die meisten Vorteile sehen werden.

Änderungen beim Scoped Storage von Android 11 – Warum ist der Zugriff auf /Downloads eingeschränkt?

Apps, die auf Android 11 abzielen und die Absicht ACTION_OPEN_DOCUMENT_TREE verwenden, um Zugriff auf bestimmte externe Verzeichnisse anzufordern Der Speicher kann Benutzer nicht mehr um Zugriff auf das Stammverzeichnis des externen Speichers (/data/media/{user}) bitten, den Download Verzeichnis (/data/media{user}/Download) oder eines der app-spezifischen Datenverzeichnisse auf dem externen Speicher (/Android/data oder /Android/obb). Warum ist der Zugriff auf das Download-Verzeichnis eingeschränkt? Laut Google Roxanna AliabadiDies liegt daran, dass der Download-Ordner „am stärksten gefährdet ist, private Informationen zu enthalten“. Als Beispiel: Benutzer, die ihre Steuer herunterladen Retouren oder Kontoauszüge sollten sich keine Sorgen über die Möglichkeit machen müssen, dass Apps ihren kontinuierlichen Lesezugriff auf die missbrauchen Verzeichnis. Google sagt, dass die Dokumentenauswahl „aktualisierten Text“ haben wird, um anzuzeigen, dass Android bestimmte Ordner eingeschränkt hat ausgewählt werden.“ Dadurch wird hoffentlich die Verwirrung darüber verringert, warum Apps keinen Zugriff auf bestimmte Verzeichnisse gewähren können mehr.

Weitere Informationen zu den bevorstehenden Änderungen der Scoped Storage- und Play-Richtlinien finden Sie unter siehe diesen Artikel.

Verschiedene Themen

  • Googles Haltung zum Rooten/Modding
    • Jeff Bailey vom AOSP-Team von Google bekräftigt die Haltung des Unternehmens zur Unterstützung von Wahlmöglichkeiten. Google wird „weiterhin sicherstellen, dass Modding/Rooting der Pixel-Gerätereihe möglich ist“, wird aber auch „die Entscheidung von OEMs unterstützen, ihre Geräte nicht zuzulassen.“ gerootet werden müssen.“ Darüber hinaus gibt Google Softwareentwicklern die Möglichkeit, „die Ausführung ihrer Software auf gerooteten Geräten nicht zuzulassen“, und bezieht sich dabei auf die jüngsten Änderungen in Erkennung von Softwaremanipulationen der SafetyNet Attestation API.
  • Was ist mit „Öffnen und auf Standard setzen“ passiert?
    • Android 10 gemacht Es ist ein bisschen nervig, eine App als Standardhandler festzulegen für bestimmte Links, die laut Google durchgeführt wurden, um Benutzer vor „ausbeuterischen Apps“ zu schützen. Google hat einen Rückzieher gemacht über diese Änderung nach Überdenken und nahm „hinter den Kulissen“ eine Reihe von Änderungen vor, um den Benutzer zu schützen.
  • Verwenden Sie die Vulkan-Grafik-API zum Rendern der Benutzeroberfläche?
    • Google plant schließlich die Verwendung die Vulkan Graphics API zum Rendern der Benutzeroberfläche, was zu einigen Leistungsverbesserungen führen wird. Das ist wird noch ausgewertet, aber das Unternehmen hatte keine Einzelheiten mitzuteilen.
  • Fehlender CallScreeningService auf vielen Geräten
    • Android-Apps können das implementieren CallScreeningService-API um neue eingehende und ausgehende Anrufe abzufangen und so den Anrufer zu identifizieren und den Anruf entweder anzunehmen oder abzulehnen. Obwohl es sich um eine offiziell dokumentierte API handelt, gibt es laut Entwickler /u/ offenbar viele OEMs, die sie nicht richtig implementieren._zeromod_. Google bestätigt dass diese API durch die Compatibility Test Suite (CTS) validiert wird, eine automatisierte Testsuite, die alle Geräte bestehen müssen, um als Android-kompatibel zu gelten. Aus irgendeinem Grund gibt diese API null zurück, wenn sie auf Geräten von OEMs wie Huawei, Vivo, Xiaomi oder Samsung aufgerufen wird. Daher ist es wahrscheinlich, dass diese OEMs einen Fehler in ihrer Software haben.
  • Keine Pläne für ein Audio-Plugin-Framework
    • Ein Entwickler fragte Google, ob sie planen, ein Audio-Plugin-Framework wie Apples Audio Units zu implementieren, aber die Antwort ist, dass es unwahrscheinlich ist, dass dies in naher Zukunft geschieht.

Sie können alle Antworten des Android-Engineering-Teams lesen Hier. Das Team spricht in einigen Kommentaren ein wenig über Java, Kotlin, das Android-Build-System, die CameraX-API und andere Themen. Es gibt auch mehrere Kommentare zu Wear OS, Android TV und Android Auto, aber Google wiederholt sich größtenteils ihre bestehende Arbeit auf diesen Plattformen und fordert die Entwickler auf, im Laufe der Zeit auf dem Laufenden zu bleiben, um weitere Informationen zu erhalten "Android jenseits von Telefonen„Woche ab dem 10. August.