Geheimnisse der API von Android-Geräten. Yandex-Bericht

Eine der größten Herausforderungen bei der Android-Entwicklung ist die Fragmentierung. Fast jeder Hersteller ändert Android an seine Bedürfnisse. Entwickler Andrey Makeev listete die Unterschiede zwischen Herstellerimplementierungen und dem ursprünglichen Android Open Source-Projekt auf. Aus dem Bericht erfahren Sie, wie Sie von den einzelnen Funktionen der Firmware auf verschiedenen Geräten profitieren können.


- Ich programmiere seit der Schule und entwickle es seit drei Jahren für Android. Davon verbrachte ich ein Jahr in Yandex und nahm an Projekten wie Launcher und Phone teil.



Ich möchte darüber sprechen, wie die Fragmentierung der API von Android-Geräten aussieht - von außen, von Seiten der Anwendungsentwickler und von innen, aus Sicht der Entwickler der Plattform und der Telefone.

Mein Bericht besteht aus zwei Teilen. Lassen Sie uns zunächst darüber sprechen, wie die API extern fragmentiert ist. Dann werden wir den Code durchgehen - wir werden herausfinden, wie das einzigartige Merkmal des abstrakten Telefons realisiert wird, wie die Entwicklung aufgebaut ist.

Die API-Fragmentierung ist einer der Parameter, mit denen Sie ein Gerät fragmentieren können. Das offensichtlichste und einfachste ist die Fragmentierung gemäß dem Android SDK. Wir begegnen ihr jeden Tag, buchstäblich von den ersten Tagen der Entwicklung für Android an. Wir wissen, welche und in welcher Version der API es erschien, dass es entfernt wurde, dass es gesichert wurde, aber es ist noch verfügbar und welche bereits verschwunden ist. In der Regel verwenden wir verschiedene Support-Bibliotheken von Google, um unser Leben zu vereinfachen. Es wurde bereits viel für uns getan.





In unserem Code sieht es ungefähr so ​​aus: Wir aktivieren einige Funktionen, einige deaktivieren - je nachdem, in welcher Version des SDK wir uns gerade befinden. Wenn Sie welche verwenden, tun sie normalerweise dasselbe, aber im Inneren.

Wir werden uns nicht auf diese Art der Fragmentierung konzentrieren. Die Nachteile sind allen bekannt - wir sind gezwungen, eine ganze Flotte von Geräten mit unterschiedlichen Versionen zu behalten, um zumindest unsere Anwendung zu testen. Außerdem müssen wir zusätzlichen Code schreiben. Dies ist besonders unpraktisch, als Sie gerade mit der Entwicklung für Android begonnen haben, und es stellt sich plötzlich heraus: Sie müssen lernen, was vor zwei oder drei Jahren dort war, um einige alte Geräte zu unterstützen. Positive Aspekte: API entwickelt sich, Technologie entwickelt sich weiter, Android gewinnt neue Benutzer, es wird sowohl für Entwickler als auch für Benutzer bequemer.

Wie arbeiten wir damit? Wir verwenden auch Bibliotheken und freuen uns sehr, wenn wir ältere Versionen nicht unterstützen. Ich denke, im Leben aller, die dies seit mehr als einem Jahr tun, gab es einen solchen Moment. Das ist nur Glück. Dies ist eine offensichtliche und einfache Fragmentierungsoption. Als nächstes folgt die Fragmentierung vom Typ Android. Es gibt mehrere von ihnen. Android TV spricht für sich selbst, Android Auto ist hauptsächlich für Autoradios, Android Things - für IoT und ähnliche eingebettete Geräte gedacht. W is Wear OS, die frühere Android Watch, achten Sie auf Android. Wir werden versuchen zu überlegen, wie dies von Seiten des Entwicklers aussieht. Und am interessantesten ist, dass wir versuchen zu überlegen, wie es von innen aussieht.



Nehmen Sie zwei Beispiele von developer.android.com. Das erste ist Wear OS. Was brauchen wir, um einen Antrag zu stellen? Wir fügen eine compileOnly-Abhängigkeit zu build.gradle hinzu und schreiben zwei zusätzliche Zeilen in das Manifest: Verwendungsfunktion android.hardware.type.watch und Verwendungsbibliothek, die demselben Paketnamen entspricht wie die Bibliothek, die wir verbunden haben.



Wie setzen wir etwas um? Wir erstellen eine Aktivität, nur in diesem Fall geben wir keine Standardaktivität aus, mit der wir gewohnt sind, und nicht einmal eine zusammengesetzte, sondern WearableActivity, und rufen dafür spezifische Methoden auf, in diesem Fall setAmbientEnabled (). Wir haben also eine compileOnly-Abhängigkeit, das heißt, sie gelangt nicht in den Verlauf unserer Anwendung. Uses-Bibliothek, die das Betriebssystem anscheinend dazu zwingt, diese Klassen und diesen Code zur Laufzeit auf dem Gerät und den neuen Klassen, die wir verwenden, mit uns zu verbinden.



Android Things API ist praktisch nicht anders. Wir schreiben keine Verwendungsfunktion vor, sondern nur Verwendungsbibliothek, compileOnly-Abhängigkeit.



Wir erstellen Aktivitäten. In diesem Fall gilt dies nur für die Android Things-API, die PeripheralManager-Klasse. Wir befragen den GPIO und versuchen zu versprechen.



Wie verhält sich eine solche App auf Ihrem Handy? Es gibt zwei Möglichkeiten.



Wenn wir angegeben haben, dass die Verwendungsbibliothek android: required = "true" ist, haben wir die obligatorischen Anforderungen des PackageManager für die Installation der Anwendung nicht erfüllt und sie wird grundsätzlich nicht installiert. Wenn wir android: required = ”false” angegeben haben, wird die Anwendung installiert. Wenn wir jedoch versuchen, auf die PeripheralManager-Klasse zuzugreifen, erhalten wir NoClassDefFoundError, da es in Standard-Android keine solche Klasse gibt.

Was sind die Schlussfolgerungen? Wir verbinden die compileOnly-Abhängigkeit nur, um während der Assembly mit ihr in Kontakt zu treten, und die von uns verwendeten Klassen warten auf dem Gerät auf uns. Sie werden über bestimmte Zeilen im Manifest verbunden. Manchmal schreiben wir eine Funktion vor, die häufiger benötigt wird, um bei Google Play ein Gerät zu unterscheiden, auf das diese Anwendung verteilt werden kann oder nicht.

Ich konnte die negativen Seiten dieser Art der Fragmentierung nicht herausgreifen. Nur diejenigen, die sich entwickelt haben, werden viele Geschichten darüber erzählen, wie sie auf völlig unverständliche, unbekannte Fehler gestoßen sind, denen sie am Telefon nicht begegnet sind. Die positive Seite ist, dass dies zusätzliche Märkte, zusätzliche Benutzer, zusätzliche Erfahrung sind, es ist immer gut.

Wie arbeite ich damit? Schreiben Sie weitere Bewerbungen. Die allgemeine Empfehlung lautet, mehr als eine Version der Anwendung für alle Arten von Android zu schreiben, aber immer noch andere. Es sollte weniger für eine Uhr geben, für Android-Dinge ist praktisch nichts von dem, was auf dem Telefon geschrieben ist, geeignet und so weiter. Und nutzen Sie die Bibliotheken, die uns Android-Entwickler und manchmal auch Geräteentwickler zur Verfügung stellen.

Die am wenigsten untersuchte Art der Fragmentierung ist die Produzentenfragmentierung. Jeder Hersteller, der den Quellcode erhalten hat - in seltenen Fällen handelt es sich um AOSP, häufiger wird er von den Hardwareentwicklern irgendwie geändert -, nimmt Änderungen daran vor. In der Regel erfahren wir über die negativen Auswirkungen dieser Art der Fragmentierung von nicht den besten Kanälen - von negativen Bewertungen bei Google Play, weil jemand etwas kaputt gemacht hat. Oder wir lernen dies aus der Crash-Analyse, wenn plötzlich etwas auf unverständliche Weise abstürzt, nur auf bestimmten Geräten. Im besten Fall lernen wir dies aus unserer Qualitätssicherung, wenn beim Testen auf einem bestimmten Gerät etwas kaputt gegangen ist.



Zu diesem Thema habe ich eine wundervolle Geschichte aus unserem Entwicklungs-Launcher. Wir haben einen Fehlerbericht erhalten, in dem sich die Aktivität nicht auf den gesamten Bildschirm erstreckte und unser bevorzugtes Standard-Hintergrundbild überhaupt nicht angezeigt wurde. Es wurde nicht entschlüsselt, ein leeres Fenster zeigte sich. Wir hatten nicht einmal Geräte, um es zu reproduzieren. Durch das Strecken auf den Bildschirm konnten wir immer noch ein Low-End-Gerät finden, auf dem es nicht funktionierte, und alles mit Android ganz einfach reparieren: resizeableActivity = "true" im Manifest. Mit der Tapete wurde alles viel komplizierter. Ungefähr zwei Tage lang haben wir versucht, detailliertere Informationen zu erhalten. Am Ende fanden sie heraus, dass auf einer Reihe von Geräten entweder der Codec zum Decodieren von progressivem JPEG mit Fehlern implementiert wurde, wenn mehrere Komprimierungsalgorithmen für die Ergebnisse des jeweils anderen verwendet wurden. In diesem Fall haben wir gerade einen Flusen-Check geschrieben, der beim Erstellen der Anwendung fehlschlägt, wenn wir das in der apk selbst progressiv codierte Hintergrundbild in die apk selbst einfügen. Alle Hintergrundbilder neu codiert, die Situation im Backend wiederholt, das den Rest der Hintergrundbilder verteilt, und alles funktioniert hervorragend. Aber es hat uns ungefähr zwei Tage gekostet.



Im Code sieht es ungefähr so ​​aus. Unangenehm, aber leider so. Normalerweise erscheinen diese Zeilen nach einem langen Debugging.



Welche Garantien gibt uns Google, um sicherzustellen, dass die API nicht so stark beschädigt wird, dass Anwendungen im Prinzip nicht funktionieren? Zunächst gibt es eine CDD, die beschreibt, was möglich ist und was nicht geändert werden kann, was abwärtskompatibel ist und was nicht. Dies ist ein Dokument von mehreren Dutzend Seiten mit allgemeinen Empfehlungen, die natürlich nicht alle Fälle abdecken. Um weitere Fälle abzudecken, gibt es CTS, das ausgefüllt werden muss, damit das Telefon eine Zertifizierung von Google erhält und Google-Dienste von Google verwendet werden können. Dies ist ein Satz von ungefähr 350.000 automatisierten Tests. Es gibt auch einen CTS-Verifizierer, eine reguläre APK, die Sie auf Ihr Telefon setzen können, um eine Reihe von Überprüfungen durchzuführen. Übrigens, wenn Sie ein Telefon mit Ihren Händen kaufen, können Sie es so überprüfen.

Mit dem Aufkommen von Treble erschien das VTS-Projekt, es ist wahrscheinlicher für Entwickler niedrigerer Ebenen. Es überprüft die Treiber-APIs, die ab Project Treble versioniert sind und ähnliche Tests durchlaufen. Darüber hinaus sind die Telefonentwickler selbst gesunde Menschen, die möchten, dass Android-Anwendungen für sie gut funktionieren, aber das ist eine mittelmäßige Hoffnung. Die negative Seite ist, dass wir auf unvorhergesehene Fehler stoßen, die erst vorhergesagt werden können, wenn die Anwendung auf dem Gerät gestartet wurde. Auch hier sind wir gezwungen zu kaufen, zusätzlich zu der Tatsache, dass verschiedene Versionen der API, gibt es auch zusätzliche Geräte von verschiedenen Herstellern, um nach ihnen zu suchen.

Aber es gibt positive Aspekte. Zumindest fallen die von Herstellern am häufigsten implementierten Funktionen in Android selbst. Jemand kann sich daran erinnern, dass die Standard-Fingerabdruck-API später angezeigt wurde als Geräte, die den Bildschirm mit einem Fingerabdruck entsperren konnten. Laut XDA-Entwicklern möchte die Android-API nun auch mit der Kamera im Gesicht entsperren, dies ist jedoch noch nicht korrekt. Wir werden dies wahrscheinlich mit Ihnen herausfinden.

Darüber hinaus können Geräteentwickler selbst, wenn sie nicht standardmäßige APIs erstellen, und viele Bibliotheken veröffentlichen, um mit ihrer API für normale Entwickler zu arbeiten. Und wenn Sie dies noch nie zuvor getan haben, empfehle ich Ihnen, die Statistiken zur Verwendung Ihrer Anwendung durchzugehen, die beliebtesten Hersteller zu ermitteln und sich die Entwicklerportale ihrer Websites anzusehen. Ich denke, Sie werden angenehm überrascht sein, dass viele APIs mit interessanten Hardwarefunktionen, Sicherheitsfunktionen, Cloud-Diensten oder etwas anderem Interessantem haben. Und auf den ersten Blick scheint es wild, separate Funktionen für einzelne Geräte zu schreiben, aber neben Geräten gibt es auch Hersteller von noch kleineren Prozessoren, die auch ihre APIs implementieren. Zum Beispiel hat Qualcomm eine wunderbare Hardwarebeschleunigung zum Erkennen von Bildern von der Kamera, die Sie durchaus verwenden können, sie haben sogar eine gute Beschreibung von ihnen.

Somit kann jeder von Ihnen auch von dieser Art der Fragmentierung profitieren. Was machen wir damit? In keinem Fall können Sie Fehler melden und Fehlerberichte an Geräteentwickler und sogar an Android-Entwickler senden. Denn wenn APIs, die es wert waren, den CTS-Test zu schreiben, beschädigt wurden, wird er geschrieben - und es gab solche Präzedenzfälle - und danach wurde die API zuverlässiger.

Lernen Sie Android, lernen Sie, was Hersteller anbieten, schwören Sie nicht mit ihnen - arbeiten Sie mit ihnen.

Wie sieht es von innen aus? Wie kann ich eine Funktion implementieren, die für unser Telefon einzigartig ist, und diese API aus einer regulären Android-Anwendung verwenden?



Ein bisschen Theorie. Wie beschreiben Android-Entwickler selbst das interne AOSP-Gerät? Die oberste Ebene ist eine Anwendung, die entweder von Ihnen oder von den Entwicklern des Telefons selbst geschrieben wurde. Sie hat keine hohen Rechte und verwendet lediglich Standard-APIs. Dies ist ein Framework. Hierbei handelt es sich um Klassen, die nicht Teil Ihrer Anwendung sind, z. B. Aktivität, Paket, Bundle. Sie sind Teil des Systems und werden als Framework bezeichnet. Die Klassen, die Ihnen auf dem Gerät zur Verfügung stehen. Als nächstes folgen die Systemdienste. Dies verbindet Sie mit dem System: ActivityManagerService, WindowManagerService, PackageManagerService, die die interne Seite der Interaktion mit dem System implementieren.

Als nächstes folgt die Hardware-Abstraktionsschicht. Dies ist die oberste Treiberschicht, die die gesamte Logik für die Anzeige auf dem Bildschirm, für die Interaktion mit Bluetooth und dergleichen enthält. Der Kernel ist die unterste Ebene der Treiber, die Systemverwaltung. Diejenigen, die wissen, was der Kern ist und vor was sie stehen, müssen es nicht sagen, aber Sie können lange sprechen.



Wie sieht es auf dem Gerät aus? Unsere Anwendung interagiert nicht nur mit dem Standard-Framework, sondern kann auch mit dem benutzerdefinierten Framework des Herstellers interagieren. Über dieses Framework kann es auch mit benutzerdefinierten Diensten kommunizieren. Wenn es sich um festverdrahtete oder Low-Level-Funktionen handelt, wird HAL für sie und gegebenenfalls sogar für Treiber auf Kernel-Ebene geschrieben.



Wie schreiben wir unser Feature? Der Plan ist einfach: Sie müssen ein Framework schreiben, das sich nicht sehr von den Bibliotheken unterscheidet, die die meisten Android-Entwickler geschrieben haben. Ich denke, Sie alle wissen das. Sie müssen einen Systemdienst schreiben, bei dem es sich um eine normale Anwendung handelt, und zwar nur mit nicht ganz normalen Rechten im System. Und wenn nötig, können Sie HAL schreiben, aber wir lassen dies weg. Sie können Ihre eigenen Treiber auf Kernel-Ebene schreiben, aber wir werden dies jetzt auch nicht berücksichtigen. Und schreiben Sie eine Client-Anwendung, die all dies nutzt.



Damit wir mit dem System interagieren können, müssen wir einen Vertrag abschließen, und dafür gibt es bereits einen guten Mechanismus für AIDL-Schnittstellen. Es ist nur eine Art Schnittstelle, auf deren Grundlage das System eine zusätzliche Klasse generiert, die wir erweitern können, über die die Interprozesskommunikation zwischen Ihrer Anwendung und den Systemdiensten ausgeführt wird.



Als nächstes schreiben wir ein Framework, unsere Bibliothek, die die Implementierung dieser Schnittstelle enthält, und geben alle Aufrufe an diese weiter. Wenn Sie interessiert sind, funktionieren ActivityManager, PackageManager und WindowManager ähnlich. Es gibt etwas mehr Logik als wir hier implementiert haben, aber das Wesentliche ist genau das.



Wir haben das Framework implementiert. Wir müssen einen Systemdienst schreiben, der unsere Daten von der Systemseite empfängt. In diesem Fall senden und lesen wir Ganzzahlen. Wir erstellen eine Klasse, die auch die Schnittstelle erweitert, die auf der vorherigen Folie aus AIDL generiert wurde. Wir erstellen ein Feld, in das wir Werte schreiben, lesen, einen Setter schreiben, einen Getter. Das einzige ist, dass es nicht genug Schlösser gibt, aber sie passten nicht sehr gut auf den Schlitten, sie sollten gemacht werden.



Damit dieser Systemdienst verfügbar ist, müssen wir ihn im Systemdienstmanager registrieren. In diesem Fall handelt es sich um dieselbe Klasse, die für normale Anwendungen nicht verfügbar ist. Es ist genau für diejenigen verfügbar, die sich in der Plattform in den Systempartitionen befinden. Wir registrieren den Dienst einfach in Application.onCreate () und stellen ihn unter dem Namen der von uns erstellten Klasse zur Verfügung.

Was benötigen wir, damit onCreate () grundsätzlich gestartet und unser Dienst in den Speicher geladen werden kann? Wir schreiben in das Manifest in Anwendung Android: persistent = "true". Dies bedeutet, dass dies ein dauerhafter Prozess ist, der ständig im Speicher sein muss, da er Systemfunktionen ausführt.



Auch im Manifest selbst können wir android: sharedUserId angeben, in diesem Fall System, aber es kann eine Vielzahl unterschiedlicher IDs sein. Sie ermöglichen es der Anwendung, umfassendere Rechte im System zu erhalten und mit verschiedenen APIs und Diensten zu interagieren, die für normale Anwendungen nicht verfügbar sind.

In diesem Fall haben wir zum Beispiel so etwas nicht verwendet.



Wir haben ein Framework geschrieben, einen Systemdienst. Wir werden die Mechanismen im Inneren weglassen, dies ist ein etwas kompliziertes Thema, es verdient einen separaten Bericht.

Wie kann das Framework für Anwendungsentwickler bereitgestellt werden? Zwei Formate. Wir können vollwertige Klassen ausgeben und eine vollwertige Bibliothek erstellen, die Sie in Ihre Anwendung kompilieren, und die gesamte Logik wird Teil Ihrer Dexes.

Sie können das Framework auch in Form von Stub-Klassen verteilen, auf die Sie nur zur Kompilierungszeit verlinken können, und erwarten, dass diese Klassen ähnlich wie in früheren Beispielen aus verschiedenen Android-Versionen auf dem Gerät selbst auf Sie warten. Sie können es entweder über ein reguläres Maven-Repository, das jeder kennt, oder über Android Studio sdkmanager verteilen, ähnlich wie Sie neue Versionen des SDK installieren. Es ist schwer zu sagen, welche Methode bequemer ist. Für mich persönlich ist es bequemer, Maven zu verbinden.



Wir schreiben eine einfache Bewerbung. Auf vertraute Weise verbinden wir die compileOnly-Abhängigkeit, nur jetzt ist es unsere Bibliothek. Wir schreiben eine Verwendungsbibliothek vor, die wir geschrieben und auf dem Gerät installiert haben. Wir schreiben Aktivität, erhalten Zugriff auf diese Klassen und interagieren mit dem System. Es wäre also möglich, absolut alle Funktionen zu implementieren: Datenübertragung auf einige zusätzliche Geräte, zusätzliche Hardwarefunktionen usw.

Somit stellen alle Entwickler den Entwicklern einzigartige Funktionen des Geräts zur Verfügung. Manchmal sind dies private APIs, die nur Partnern zur Verfügung stehen. Manchmal sind sie öffentlich und solche, die Sie auf Entwicklerportalen finden können. Es gibt andere Möglichkeiten, solche Dinge zu implementieren, aber ich habe eine Methode beschrieben, die in Google und unter Android-Entwicklern als die wichtigste angesehen wird.

Sie sollten Geräteentwickler nicht als Personen behandeln, die Ihre Anwendungen beschädigen. Dies sind die gleichen Entwickler, sie schreiben den gleichen Code auf ungefähr der gleichen Ebene. Schreibe Fehlerberichte, sie helfen wirklich, ich analysiere sie oft. Schreiben Sie mehr Anwendungen und nutzen Sie die Möglichkeiten, die sowohl Android als auch das Gerät selbst bieten. Ich habe alles