Laut einer Reihe von Commits in AOSP könnte Google damit beginnen, den Zugriff auf undokumentierte oder versteckte APIs in Android P einzuschränken. Viele Marken-Apps nutzen versteckte APIs, um die Funktionalität zu erweitern, sodass der Effekt weitreichend sein kann.
Update 28.02.18: Google hat heute einen Blogbeitrag veröffentlicht, in dem die Änderungen bestätigt werden. Weitere Details am Ende des Artikels.
Während einige Android-Enthusiasten es sind spekulieren Nach welchem Nachtisch die nächste Android-Version benannt wird, gibt es hinter den Kulissen einige interessante Entwicklungen. Wir haben einen entdeckt wenige erwähnenswerte bevorstehende Funktionen in Android P, aber eine neuere Entdeckung im Android Open Source Project (AOSP) hat sich als weitaus interessanter erwiesen. Gemäß diesen jüngsten Commits kann es sein, dass Anwendungen nicht auf APIs zugreifen können, die im Android SDK nicht dokumentiert sind (z. B. APIs, die durch das Javadoc-Attribut @hide gekennzeichnet sind).
Warum das wichtig ist
Das Android Software Development Kit (SDK) stellt Entwicklern API-Bibliotheken und Tools zur Verfügung, die sie zum Testen und Erstellen neuer Android-Anwendungen benötigen. Mit jeder neuen Version von Android kommt eine ganze Reihe neuer APIs, die Entwicklern über das Android SDK zur Verfügung stehen. Welche APIs für eine App verfügbar sind, hängt davon ab, welche „compileSDKVersion“ der Entwickler festlegt. Deshalb Google neue Play Store-Anforderungen sind so wichtig, dass Anwendungen aktualisiert und auf die Verwendung neuerer APIs migriert werden müssen.
Google-Hosts Dokumentationsseiten für jede Klasse und alle ihre Methoden, die in jeder API-Ebene verfügbar sind. Dies sind die dokumentierten APIs, die im offiziellen Android SDK verfügbar sind. Sie können die Liste der Kurse ganz einfach mit einer Android-App durchsuchen, beispielsweise mit der kürzlich veröffentlichten Android SDK Search-App von Android Engineer Jake Wharton.
Kostenlos.
4.1.
Allerdings sind nicht alle APIs, die in jeder Android-Version verfügbar sind, von Google dokumentiert oder im offiziellen Android SDK verfügbar. Es gibt oft nützliche APIs undokumentiert, sind aber dennoch sehr nützlich. Es wird nicht empfohlen, dass Entwickler ihre Apps mit undokumentierten oder versteckten APIs erstellen. Viele tun dies jedoch, weil es einfach keine Alternative gibt, wenn sie eine bestimmte Funktion anbieten möchten. Entwickler, die versteckte oder undokumentierte APIs verwenden, können sich ebenfalls einen Wettbewerbsvorteil verschaffen. da sie Funktionen bieten können, die ihre Konkurrenten bieten – die sich an die von Android angebotenen APIs halten SDK – nicht möglich.
Ich kann zwar keine Liste von Apps bereitstellen, die undokumentierte APIs verwenden (Entwickler geben sie wahrscheinlich nicht weiter). welche sie verwenden, weil es ihren Konkurrenten einen Vorsprung verschaffen würde), ist die Liste wahrscheinlich eher groß. Daher würde ich zu dem Schluss kommen, dass ein Verbot des Zugriffs auf versteckte APIs von Bedeutung wäre. Mark Murphy, Gründer von Commonsware, stimmt zu:
Ich stimme der Einschätzung zu, dass ein Massenverbot des Zugriffs auf mit @hide-Annotationen versehene Elemente eine große Sache sein wird, wenn das zustande kommt. Hoffentlich greifen nur wenige Apps als Teil der Schlüsselfunktionalität auf diese Elemente zu. Ich vermute jedoch, dass viele Marken-Apps sie gelegentlich direkt oder über eine Bibliothek verwenden.
Was passiert in Android P?
Diese bevorstehenden Änderungen wurden zuerst von XDA Senior Recognized Developer zur Kenntnis genommen rovo89, der Entwickler des Xposed-Framework. Er wies mich auf zwei Commits hin, eines davon welche ist gewesen zusammengeführt, das ein neues Build-Tool namens „hiddenapi“ einführt. Dieses Tool ändert die Zugriffsflags aller Klassenmitglieder in einer DEX-Datei, wenn Ihre Signaturen erscheinen auf einer Eingabe-Greylist oder Blacklist. Wenn dies der Fall ist, werden die markierten Methoden als interne APIs mit Einschränkungen behandelt Zugang. Der andere Commit beschreibt, wie die API-Blacklist funktioniert; es verhindert den Zugriff auf Boot-Klasse Methoden und Felder, die durch das oben genannte „hiddenapi“ gekennzeichnet sind und auf die Entwickler durch statische Verknüpfung, Reflektion und JNI zugreifen können.
Laut rovo89 ist das Endergebnis dieser beiden Änderungen in Android P das Folgende:
Wenn diese Commits zusammengeführt werden, würde dies bedeuten, dass Apps keine versteckten APIs mehr verwenden/auf diese zugreifen können Klassen, Methoden und Felder, die in AOSP mit @hide annotiert sind und daher nicht Teil des sind offizielles SDK. Dies wäre für Xposed-Module kein Problem, da ich diese Commits problemlos zurücksetzen oder dies auch für Module zulassen könnte Zugriff auf diese APIs. Aber es gibt viele Apps, die sich versteckte APIs zunutze machen, und diese würden dabei scheitern Zukunft.
Tatsächlich zeigen weitere Zusagen, dass dies möglicherweise das ist, was Google plant. Das begehen gibt folgendes an:
Obwohl dieser bestimmte Commit nicht zusammengeführt wurde, da er zugunsten von drei kleineren Commits aufgegeben wurde, beschreibt die Commit-Nachricht den Zweck dieser Änderungen. Ein weiterer Satz begeht zeigen, dass Google Entwicklern, die nicht öffentliche APIs verwenden möchten, Alternativen vorschlagen wird:
Allerdings gibt es oft keine Alternativen zu bestimmten versteckten APIs. Wir von XDA können hier aus Erfahrung sprechen Leider bedeutet diese Änderung möglicherweise das Ende einiger innovativer Apps oder erfordert möglicherweise, dass einige namhafte Apps ihre Anzahl reduzieren Funktionalität. Diese bevorstehende Änderung scheint im Geiste der jüngsten zu ähneln hartes Durchgreifen gegen Barrierefreiheitsdienste (Das war zum Glück pausierte wie Google innovative Einsatzmöglichkeiten bewertete). Während die meisten Apps, die undokumentierte APIs verwenden, dies aus harmlosen Gründen tun, gibt es möglicherweise einige Apps, die sie für schändliche Zwecke missbraucht haben.
Aus diesem Grund sperrt Google möglicherweise den Zugriff auf alle versteckten APIs in Android P, um Benutzer vor den wenigen zu schützen, die sie missbrauchen. Es ist schwer zu sagen, welche Auswirkungen dies auf Benutzer haben wird, aber wenn Sie Entwickler sind Wenn Sie darüber nachdenken, in AOSP nach einer innovativen Verwendung einer versteckten API zu suchen, dann sollten Sie das vielleicht tun überdenken.
Update: Google bestätigt
In einem Blogeintrag Heute, 28. Februar, veröffentlicht, hat Google diese Änderungen bestätigt. Unter Berufung auf Absturzrisiken für Nutzer und die anschließende Zwingung von Entwicklern zur Bereitstellung von Notfalllösungen, Google gibt an, dass das Unternehmen schrittweise dazu übergegangen ist, Entwickler davon abzuhalten, auf Nicht-SDKs zuzugreifen Schnittstellen. Ab Android P werden die Einschränkungen auf die Java-Sprachschnittstellen des SDK ausgeweitet.
Das Unternehmen gibt an, dass „einige Nicht-SDK-Methoden und -Felder eingeschränkt werden“, ohne jedoch näher darauf einzugehen, welche davon eingeschränkt werden. Die Einschränkung wird sich zunächst auf Schnittstellen konzentrieren, die selten genutzt werden, eine Zeit lang wird das Unternehmen dies jedoch zulassen Entwickler sollen weiterhin Nicht-SDK-Methoden und -Felder verwenden, bei denen der Übergang zu einer SDK-Methode technisch möglich ist herausfordernd. Irgendwann werden die Einschränkungen jedoch ausgeweitet, sodass Entwickler von Apps, die Nicht-SDK-Methoden verwenden, als Vorbereitung auf Android P so schnell wie möglich umsteigen sollten. Was Methoden ohne SDK-Alternative betrifft, fordert Google die Entwickler auf, auf ihrem zu posten Bug-Tracker mit weiteren Informationen.
Die nächste Entwicklervorschau, die angeblich bald erscheint, wird es Entwicklern ermöglichen, bestehende Apps vor der endgültigen Veröffentlichung anhand der Blacklist oder Greylist zu testen.