MethodHandle Klasse

Definition

[Android.Runtime.Register("java/lang/invoke/MethodHandle", ApiSince=26, DoNotGenerateAcw=true)]
public abstract class MethodHandle : Java.Lang.Object

[<Android.Runtime.Register("java/lang/invoke/MethodHandle", ApiSince=26, DoNotGenerateAcw=true)>]
type MethodHandle = class
    inherit Object

Vererbung

Object

JavaObject

Object

MethodHandle

Attribute

RegisterAttribute

Hinweise

Ein Methodenhandle ist ein typierter, direkt ausführbarer Verweis auf eine zugrunde liegende Methode, einen Konstruktor, ein Feld oder einen ähnlichen Vorgang auf niedriger Ebene mit optionalen Transformationen von Argumenten oder Rückgabewerten. Diese Transformationen sind ziemlich allgemein und umfassen Muster wie #asType Konvertierung, #bindTo Einfügung, java.lang.invoke.MethodHandles#dropArguments delete, und java.lang.invoke.MethodHandles#filterArguments Substitution.

<h1>Method handle contents</h1> Method handles are dynamically and strongly typed according to their parameter and return types. Sie unterscheiden sich nicht durch den Namen oder die definierende Klasse ihrer zugrunde liegenden Methoden. Ein Methodenhandle muss mithilfe eines symbolischen Typdeskriptors aufgerufen werden, der mit dem eigenen #type Typdeskriptor des Methodenhandles übereinstimmt.

Jede Methode behandelt den Typdeskriptor über den #type type Accessor. Dieser Typdeskriptor ist ein java.lang.invoke.MethodType MethodType Objekt, dessen Struktur eine Reihe von Klassen ist, von denen einer der Rückgabetyp der Methode ist (oder void.class wenn keines).

Der Typ eines Methodenhandle steuert die Typen von Aufrufen, die er akzeptiert, und die Arten von Transformationen, die auf sie angewendet werden.

Ein Methodenhandle enthält ein Paar spezieller Aufrufermethoden, die aufgerufen und #invokeExact invokeExactaufgerufen werden#invoke invoke. Beide Invoker-Methoden bieten direkten Zugriff auf die zugrunde liegende Methode, den Konstruktor, das Feld oder einen anderen Vorgang, wie durch Transformationen von Argumenten und Rückgabewerten geändert. Beide Aufrufer akzeptieren Aufrufe, die exakt dem eigenen Typ des Methodenhandle entsprechen. Der einfache, ungenaue Aufrufer akzeptiert auch einen Bereich anderer Anruftypen.

Methodenziehpunkte sind unveränderlich und weisen keinen sichtbaren Zustand auf. Sie können natürlich an zugrunde liegende Methoden oder Daten gebunden werden, die den Zustand aufweisen. Im Hinblick auf das Java Speichermodell verhält sich jedes Methodenhandle so, als ob alle zugehörigen (internen) Felder endgültige Variablen sind. Dies bedeutet, dass alle Für die Anwendung sichtbar gemachten Methodenhandle immer vollständig gebildet werden. Dies gilt auch dann, wenn der Methodenhandle über eine freigegebene Variable in einem Datenrennen veröffentlicht wird.

Methodenhandles können vom Benutzer nicht unterklassigt werden. Implementierungen können (oder nicht) interne Unterklassen erstellen, von MethodHandle denen über den java.lang.Object#getClass Object.getClass Vorgang sichtbar sein können. Der Programmierer sollte keine Schlussfolgerungen über ein Methodenhandle aus seiner spezifischen Klasse ziehen, da die Methode klassenhierarchie (falls vorhanden) von Zeit zu Zeit oder über Implementierungen verschiedener Anbieter ändern kann.

<h1>Methodenhandle kompilieren</h1> Ein Java Methodenaufrufausdrucksbenennung invokeExact oder invoke kann ein Methodenhandle aus Java Quellcode aufrufen. Aus der Sicht des Quellcodes können diese Methoden alle Argumente verwenden, und ihr Ergebnis kann in jeden Rückgabetyp gegossen werden. Formal wird dies erreicht, indem die Aufrufmethoden Object Typen und variablen Arity-Argumente Object zurückgeben, aber sie verfügen über eine zusätzliche Qualität namens <em>signature polymorphism</em> , die diese Freiheit des Aufrufs direkt mit dem JVM-Ausführungsstapel verbindet.

Wie bei virtuellen Methoden üblich, rufen Aufrufe auf Quellebene zu invokeExact und invoke kompilieren sie in eine invokevirtual Anweisung. Ungewöhnlichererweise muss der Compiler die tatsächlichen Argumenttypen aufzeichnen und kann keine Methodenaufrufe für die Argumente ausführen. Stattdessen muss sie entsprechend ihren eigenen, nicht konvertierten Typen auf den Stapel verschoben werden. Das Methodenhandle-Objekt selbst wird vor den Argumenten auf den Stapel verschoben. Der Compiler ruft dann das Methodenhandle mit einem symbolischen Typdeskriptor auf, der das Argument und die Rückgabetypen beschreibt.

Um einen vollständigen symbolischen Typdeskriptor auszustellen, muss der Compiler auch den Rückgabetyp bestimmen. Dies basiert auf einer Umwandlung auf dem Methodenaufrufausdruck, falls vorhanden, oder anderenfalls Object , wenn der Aufruf ein Ausdruck ist oder andernfalls void , wenn der Aufruf eine Anweisung ist. Die Umwandlung kann in einen Grundtyp (aber nicht void) erfolgen.

Als Eckfall erhält ein uncasted-Argument null einen symbolischen Typdeskriptor von java.lang.Void. Die Mehrdeutigkeit mit dem Typ Void ist harmlos, da keine Verweise vom Typ Void vorhanden sind, mit Ausnahme des NULL-Verweises.

<h1>Method handle invocation</h1> The first time a invokevirtual instruction is linked, by symbolically resolving the names in the instruction and verifying that the method call is statically legal. Dies gilt für Aufrufe invokeExact und invoke. In diesem Fall wird der vom Compiler ausgegebene symbolische Typdeskriptor auf die richtige Syntax überprüft, und die darin enthaltenen Namen werden aufgelöst. Daher wird eine invokevirtual Anweisung, die einen Methodenhandle aufruft, immer verknüpfen, solange der symbolische Typdeskriptor syntaktisch wohlgeformt ist und die Typen vorhanden sind.

Wenn die Methode nach dem Verknüpfen ausgeführt wird, wird der Typ des invokevirtual empfangenden Methodenhandles zuerst vom JVM überprüft, um sicherzustellen, dass sie mit dem symbolischen Typdeskriptor übereinstimmt. Wenn die Typ-Übereinstimmung fehlschlägt, bedeutet dies, dass die Methode, die der Aufrufer aufruft, nicht für das einzelne Methodenhandle vorhanden ist, das aufgerufen wird.

Im Fall von invokeExact, muss der Typdeskriptor des Aufrufs (nach dem Auflösen symbolischer Typnamen) genau mit dem Methodentyp des Empfangsmethodenhandle übereinstimmen. Im Fall von "Nur", "inexact invoke" muss der aufgelöste Typdeskriptor ein gültiges Argument für die Methode des Empfängers #asType asType sein. Daher ist klar invoke weniger zulässig als invokeExact.

Nach dem Typabgleich ruft ein Aufruf direkt invokeExact und sofort die zugrunde liegende Methode des Methodenhandles auf (oder ein anderes Verhalten, wie der Fall sein kann).

Ein Aufruf von "Plain invoke " funktioniert genauso wie ein Aufruf von invokeExact" , wenn der vom Aufrufer angegebene symbolische Typdeskriptor exakt mit dem eigenen Typ des Methodenhandles übereinstimmt. Wenn ein Typkonflikt auftritt, wird versucht, invoke den Typ des Empfangsmethodenhandle anzupassen, wie durch einen Aufruf von #asType asType, um ein genau aufrufbares Methodenhandle M2abzurufen. Dies ermöglicht eine leistungsfähigere Aushandlung des Methodentyps zwischen Aufrufer und Angerufenen.

(<em>Hinweis:</em> Der angepasste Methodenziehpunkt M2 ist nicht direkt feststellbar, und Daher sind Implementierungen nicht erforderlich, um sie zu materialisieren.)

<h1>Aufrufüberprüfung</h1> In typischen Programmen wird der Methodenhandle-Abgleich in der Regel erfolgreich ausgeführt. Wenn jedoch eine Übereinstimmung fehlschlägt, löst das JVM entweder direkt WrongMethodTypeException(im Fall von invokeExact) oder indirekt wie bei einem fehlgeschlagenen Aufruf asType (im Fall von invoke).

Ein Methodentypkonflikt, der als Verknüpfungsfehler in einem statisch typierten Programm angezeigt werden kann, kann daher in einem Programm, das Methodenhandles verwendet, als dynamisch WrongMethodTypeException angezeigt werden.

Da Methodentypen "live" Class -Objekte enthalten, berücksichtigt der Methodentypabgleich sowohl Typennamen als auch Klassenladeprogramme. Selbst wenn ein Methodenhandle M in einem Klassenladeprogramm L1 erstellt und in einem anderen L2verwendet wird, sind Methodenhandle-Aufrufe typsicher, da der symbolische Typdeskriptor des Aufrufers, wie in aufgelöst L2, mit dem symbolischen Typdeskriptor der ursprünglichen Angerufenen-Methode abgeglichen wird, wie in aufgelöst L1. Die Auflösung erfolgt beim L1M Erstellen und Zuweisen des Typs, während die Auflösung erfolgt L2 , wenn die invokevirtual Anweisung verknüpft ist.

Abgesehen von der Überprüfung von Typdeskriptoren ist die Funktion eines Methodenhandle zum Aufrufen seiner zugrunde liegenden Methode uneingeschränkt. Wenn ein Methodenhandle für eine nicht öffentliche Methode durch eine Klasse gebildet wird, die Zugriff auf diese Methode hat, kann das resultierende Handle an beliebiger Stelle von jedem Aufrufer verwendet werden, der einen Verweis darauf erhält.

Anders als bei der Core Reflection-API, bei der der Zugriff jedes Mal überprüft wird, wenn eine reflektierende Methode aufgerufen wird, erfolgt die Methodenbehandlung bei der Zugriffsüberprüfung, wenn der Methodenhandle erstellt wird. Im Fall von ldc (siehe unten) wird die Zugriffsüberprüfung als Teil der Verknüpfung des Konstantenpooleintrags ausgeführt, der dem Konstantenmethodenhandle zugrunde liegt.

Daher sollten umgangen mit nicht öffentlichen Methoden oder Methoden in nicht öffentlichen Klassen im Allgemeinen geheim gehalten werden. Sie sollten nicht an nicht vertrauenswürdigen Code übergeben werden, es sei denn, ihre Verwendung aus dem nicht vertrauenswürdigen Code wäre harmlos.

<h1-Methode>behandelt erstellung</h1> Java Code kann ein Methodenhandle erstellen, das direkt auf jede Methode, einen Konstruktor oder ein Feld zugreift, auf die für diesen Code zugegriffen werden kann. Dies erfolgt über eine reflektierende, funktionsbasierte API, die aufgerufen java.lang.invoke.MethodHandles.Lookup MethodHandles.Lookup wird, z. B. kann ein statischer Methodenhandle abgerufen werden.java.lang.invoke.MethodHandles.Lookup#findStatic Lookup.findStatic Es gibt auch Konvertierungsmethoden aus Core Reflection-API-Objekten, z java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflect. B. .

Wie Klassen und Zeichenfolgen können Methodenhandles, die barrierefreien Feldern, Methoden und Konstruktoren entsprechen, auch direkt im Konstantenpool einer Klassendatei als Konstanten dargestellt werden, die von Bytecodes ldc geladen werden sollen. Ein neuer Typ von Konstantenpooleintrag , CONSTANT_MethodHandlebezieht sich direkt auf einen zugeordneten CONSTANT_Methodref, CONSTANT_InterfaceMethodrefoder CONSTANT_Fieldref konstanten Pooleintrag. (Ausführliche Informationen zu Methodenhandlekonstanten finden Sie in den Abschnitten 4.4.8 und 5.4.3.5 der spezifikation des Java virtuellen Computers.)

Methodenhandles, die von Nachschlagevorgängen oder konstanten Lasten von Methoden oder Konstruktoren mit dem Variablenvariablenmodifizierer Bit (0x0080) erzeugt werden, weisen eine entsprechende Variable arity auf, als ob sie mit Hilfe von #asVarargsCollector asVarargsCollector.

Ein Methodenverweis kann entweder auf eine statische oder nicht statische Methode verweisen. Im nicht statischen Fall enthält der Methodenhandletyp ein explizites Empfängerargument, das vor anderen Argumenten vorangestellt ist. Im Typ des Methodenhandles wird das anfängliche Empfängerargument entsprechend der Klasse eingegeben, unter der die Methode ursprünglich angefordert wurde. (Wenn z. B. ein nicht statischer Methodenhandle abgerufen ldcwird, ist der Empfängertyp die Klasse, die im Konstantenpooleintrag benannt ist.)

Methodenhandlekonstanten unterliegen demselben Linkzeitzugriff überprüft die entsprechenden Bytecodeanweisungen, und die ldc Anweisung löst entsprechende Verknüpfungsfehler aus, wenn das Bytecodeverhalten solche Fehler auslöst.

Als Korollar dieser Elemente ist der Zugriff auf geschützte Member nur auf Empfänger der zugreifenden Klasse oder auf eine seiner Unterklassen beschränkt, und die zugreifende Klasse muss wiederum eine Unterklasse (oder gleichgeordnetes Paket) der definierenden Klasse des geschützten Elements sein. Wenn ein Methodenverweis auf eine geschützte, nicht statische Methode oder ein Feld einer Klasse außerhalb des aktuellen Pakets verweist, wird das Empfängerargument auf den Typ der zugreifenden Klasse beschränkt.

Wenn ein Methodenhandle für eine virtuelle Methode aufgerufen wird, wird die Methode immer im Empfänger nachschlagen (d. a. das erste Argument).

Eine nicht virtuelle Methodenimplementierung kann auch erstellt werden. Diese führen keine virtuelle Suche basierend auf dem Empfängertyp aus. Ein solches Methodenhandle simuliert die Wirkung einer invokespecial Anweisung auf dieselbe Methode.

<h1>Verwendungsbeispiele</h1> Hier sind einige Beispiele für die Verwendung: <Blockquote>

{@code
            Object x, y; String s; int i;
            MethodType mt; MethodHandle mh;
            MethodHandles.Lookup lookup = MethodHandles.lookup();
            // mt is (char,char)String
            mt = MethodType.methodType(String.class, char.class, char.class);
            mh = lookup.findVirtual(String.class, "replace", mt);
            s = (String) mh.invokeExact("daddy",'d','n');
            // invokeExact(Ljava/lang/String;CC)Ljava/lang/String;
            assertEquals(s, "nanny");
            // weakly typed invocation (using MHs.invoke)
            s = (String) mh.invokeWithArguments("sappy", 'p', 'v');
            assertEquals(s, "savvy");
            // mt is (Object[])List
            mt = MethodType.methodType(java.util.List.class, Object[].class);
            mh = lookup.findStatic(java.util.Arrays.class, "asList", mt);
            assert(mh.isVarargsCollector());
            x = mh.invoke("one", "two");
            // invoke(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList("one","two"));
            // mt is (Object,Object,Object)Object
            mt = MethodType.genericMethodType(3);
            mh = mh.asType(mt);
            x = mh.invokeExact((Object)1, (Object)2, (Object)3);
            // invokeExact(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList(1,2,3));
            // mt is ()int
            mt = MethodType.methodType(int.class);
            mh = lookup.findVirtual(java.util.List.class, "size", mt);
            i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
            // invokeExact(Ljava/util/List;)I
            assert(i == 3);
            mt = MethodType.methodType(void.class, String.class);
            mh = lookup.findVirtual(java.io.PrintStream.class, "println", mt);
            mh.invokeExact(System.out, "Hello, world.");
            // invokeExact(Ljava/io/PrintStream;Ljava/lang/String;)V
            }

</blockquote> Each of the above calls to invokeExact or plain invoke generates a single invokevirtual instruction with the symbolische type descriptor indicated in the following comment. In diesen Beispielen wird davon ausgegangen, dass die Hilfsmethode assertEquals eine Methode ist, die ihre Argumente aufruft java.util.Objects#equals(Object,Object) Objects.equals , und bestätigt, dass das Ergebnis wahr ist.

<h1>Exceptions</h1> The methods invokeExact and invoke are declared to throw java.lang.Throwable Throwable, which is to say that there is no static restriction on what a method handle can throw. Da die JVM nicht zwischen aktivierten und deaktivierten Ausnahmen (außer durch ihre Klasse) unterscheidet, gibt es keine besondere Auswirkung auf bytecode-Shape von der Abschreibung von überprüften Ausnahmen für Methodenhandaufrufe. In Java Quellcode müssen Methoden, die Methoden zum Verarbeiten von Methoden ausführen, entweder explizit ausgelöst werden, oder sonst müssen alle Ausgelösten lokal erfasst Throwablewerden, nur diejenigen, die im Kontext legal sind, und umschließen, die illegal sind.

<h1>"sigpoly">Signature polymorphism</h1> Das ungewöhnliche Kompilierungs- und Verknüpfungsverhalten von invokeExact und nur wird invoke vom Begriff <em>signatur polymorphism</em> referenziert. Wie in der Java Sprachspezifikation definiert, ist eine polymorphe Signaturmethode, die mit einer vielzahl von Anrufsignaturen und Rückgabetypen arbeiten kann.

Im Quellcode wird unabhängig vom angeforderten symbolischen Typdeskriptor ein Aufruf einer polymorphen Signaturmethode kompiliert. Wie üblich gibt der Java Compiler eine invokevirtual Anweisung mit dem angegebenen symbolischen Typdeskriptor für die benannte Methode aus. Ungewöhnlich ist, dass der symbolische Typdeskriptor vom tatsächlichen Argument und Rückgabetypen abgeleitet wird, nicht von der Methodendeklaration.

Wenn der JVM Bytecode verarbeitet, der signaturen polymorphe Aufrufe enthält, wird er unabhängig von seinem symbolischen Typdeskriptor erfolgreich einen solchen Aufruf verknüpfen. (Um die Typsicherheit beizubehalten, schützt das JVM solche Anrufe mit geeigneten dynamischen Typprüfungen, wie an anderer Stelle beschrieben.)

Bytecode-Generatoren, einschließlich des Compiler-Back-Ends, sind erforderlich, um untransformierte symbolische Typdeskriptoren für diese Methoden auszugeben. Tools zur Ermittlung symbolischer Verknüpfungen sind erforderlich, um solche untransformierten Deskriptoren zu akzeptieren, ohne Verknüpfungsfehler zu melden.

<h1>Interoperation between method handles and the Core Reflection API</h1> Using factory methods in the java.lang.invoke.MethodHandles.Lookup Lookup API, any class member represented by a Core Reflection API object can be converted to a behaviorly equivalent method handle. So kann z. B. ein reflektierendes java.lang.reflect.Method Method Objekt mithilfe java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflecteines Methodenhandles in ein Methodenhandle konvertiert werden. Die resultierenden Methodenhandles bieten im Allgemeinen direkteren und effizienteren Zugriff auf die zugrunde liegenden Klassenmber.

Wenn die Core Reflection-API verwendet wird, um die polymorphen Signaturmethoden invokeExact oder einfache invoke Methoden in dieser Klasse anzuzeigen, werden sie als gewöhnliche nicht polymorphe Methoden angezeigt. Ihr reflektierendes Erscheinungsbild, wie es von java.lang.Class#getDeclaredMethod Class.getDeclaredMethodihnen betrachtet wird, ist von ihrem speziellen Status in dieser API nicht betroffen. Beispielsweise werden genau diese Modifiziererbits gemeldet, java.lang.reflect.Method#getModifiers Method.getModifiers die für jede in ähnlicher Weise deklarierte Methode erforderlich sind, einschließlich in diesem Fall native und varargs Bits.

Wie bei jeder reflektierten Methode können diese Methoden (wenn reflektiert) über java.lang.reflect.Method#invoke java.lang.reflect.Method.invokeaufgerufen werden. Solche reflektierenden Aufrufe führen jedoch nicht zu Methodenhandleaufrufen. Ein solcher Aufruf, wenn das erforderliche Argument übergeben wird (ein einzelnes Argument vom Typ Object[]), ignoriert das Argument und löst ein UnsupportedOperationException.

Da invokevirtual Anweisungen Methodenhandles unter jedem symbolischen Typdeskriptor nativ aufrufen können, steht diese reflektierende Ansicht mit der normalen Darstellung dieser Methoden über Bytecodes in Konflikt. Daher können diese beiden systemeigenen Methoden, wenn sie reflektierend betrachtet Class.getDeclaredMethodwerden, nur als Platzhalter angesehen werden.

Zum Abrufen einer Aufrufermethode für einen bestimmten Typdeskriptor, verwenden java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvokeroder java.lang.invoke.MethodHandles#invoker MethodHandles.invoker. Die java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual API kann auch ein Methodenhandle zum Aufrufen invokeExact oder Einfaches invokezurückgeben, für jeden angegebenen Typdeskriptor.

<h1>Interoperation zwischen Methodenhandles und Java generics</h1> A-Methodenhandle kann für eine Methode, einen Konstruktor oder ein Feld abgerufen werden, das mit Java generischen Typen deklariert wird. Wie bei der Core Reflection-API wird der Typ des Methodenhandles aus der Löschung des Quellebenentyps erstellt. Wenn ein Methodenhandle aufgerufen wird, können die Typen der Argumente oder der Rückgabewert-Umwandlungstyp generische Typen oder Typinstanzen sein. Wenn dies der Fall ist, ersetzt der Compiler diese Typen durch ihre Löschungen, wenn er den symbolischen Typdeskriptor für die invokevirtual Anweisung erstellt.

Methodenhandles stellen ihre funktionsähnlichen Typen in Bezug auf Java parametrisierten (generischen) Typen nicht dar, da es drei Nichtübereinstimmungen zwischen funktionsähnlichen Typen und parametrisierten Java Typen gibt. <ul><li>Method types range over all possible arities, from no arguments to the maximum number of allowed arguments. Generika sind nicht variadisch und können dies nicht darstellen.</li Li-Methodentypen><>können Argumente von Grundtypen angeben, die Java generische Typen nicht reichen können.</li li><>Höhere Ordnungsfunktionen über Methodenziehpunkte (Kombinatoren) sind häufig generisch für eine Vielzahl von Funktionstypen, einschließlich derjenigen von mehreren Aritäten. Es ist unmöglich, eine solche Generizität mit einem Java Typparameter darzustellen.</li></ul>

<h1>"maxarity">Arity Limits</h1> The JVM erzwingt alle Methoden und Konstruktoren jeglicher Art eine absolute Grenze von gestapelten Argumenten von 255. Dieser Grenzwert kann in bestimmten Fällen restriktiver erscheinen: <ul><li>A long oder double Argumentanzahl (für Zwecke von Aritätsgrenzwerten) als zwei Argumentplätze. <Li>Eine nicht statische Methode verwendet ein zusätzliches Argument für das Objekt, für das die Methode aufgerufen wird. <li>A-Konstruktor verwendet ein zusätzliches Argument für das Objekt, das erstellt wird. <li>Since a method handle' die invoke Methode (oder eine andere signatur-polymorphe Methode) ist nicht virtuell, es verwendet ein zusätzliches Argument für das Methodenhandle selbst, zusätzlich zu allen nicht-virtuellen Empfängerobjekten. </ul> Diese Grenzwerte bedeuten, dass bestimmte Methodenhandles nicht erstellt werden können, nur aufgrund des JVM-Grenzwerts für gestapelte Argumente. Wenn beispielsweise eine statische JVM-Methode genau 255 Argumente akzeptiert, kann kein Methodenhandle erstellt werden. Versuche, Methodenhandles mit unmöglichen Methodentypen zu erstellen, führen zu einem IllegalArgumentException. Insbesondere ein Methodenhandle" der Typ darf nicht über eine Arität des exakten Maximums 255 verfügen.

Java Dokumentation für java.lang.invoke.MethodHandle.

Teile dieser Seite sind Änderungen auf der Grundlage von Arbeiten, die von der Android Open Source Project erstellt und gemeinsam verwendet und gemäß den in der 2.5 Attribution License beschriebenen Begriffen verwendet werden.