Clientseitige Lizenzüberprüfung zu Ihrer Anwendung hinzufügen

Nachdem du ein Publisher-Konto und eine Entwicklungsumgebung eingerichtet hast (siehe Einrichtung der Lizenzierung), kannst du die Lizenzüberprüfung für Ihre App mit der License Verification Library (LVL) überprüfen.

Das Hinzufügen der Lizenzüberprüfung mit der LVL umfasst folgende Aufgaben:

1. Lizenzierungsberechtigung hinzufügen: Manifest deiner App hinzufügen
2. Richtlinie implementieren: Sie können eine der in der LVL bereitgestellten vollständigen Implementierungen auswählen oder Ihre eigene Implementierung erstellen.
3. Implementieren eines Verschleierungsgeräts, wenn im Policy Folgendes im Cache gespeichert werden: Lizenzantwortdaten.
4. Fügen Sie Code zum Prüfen der Lizenz in der Haupt-App Ihrer App hinzu. Aktivität.
5. DeviceLimiter implementieren (optional und nicht empfohlen für für die meisten Anwendungen).

In den folgenden Abschnitten werden diese Aufgaben beschrieben. Wenn Sie mit dem Integration ist, sollten Sie Ihre Anwendung erfolgreich kompilieren können und mit dem Testen beginnen, wie unter Test einrichten Umgebung.

Eine Übersicht über den vollständigen Satz von Quelldateien in der LVL finden Sie unter Zusammenfassung der LVL-Klassen und Schnittstellen.

Lizenzierungsberechtigung hinzufügen

Wenn Sie über die Google Play App eine Lizenzprüfung an den muss Ihre Anwendung die entsprechende Berechtigung anfordern, com.android.vending.CHECK_LICENSE Wenn Ihre Anwendung die Lizenzberechtigung nicht erklärt, sondern eine Lizenzüberprüfung einleitet, gibt die LVL eine Sicherheitsausnahme aus.

Deklarieren Sie eine <uses-permission>, um die Lizenzberechtigung in Ihrer App anzufordern -Element als untergeordnetes Element von <manifest> zu:

<uses-permission android:name="com.android.vending.CHECK_LICENSE" />

So deklariert die LVL-Beispielanwendung die Berechtigung beispielsweise:

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android" ...">
    <!-- Devices >= 3 have version of Google Play that supports licensing. -->
    <uses-sdk android:minSdkVersion="3" />
    <!-- Required permission to check licensing. -->
    <uses-permission android:name="com.android.vending.CHECK_LICENSE" />
    ...
</manifest>

Hinweis: Derzeit können Sie die Parameter CHECK_LICENSE im Manifest des LVL-Bibliotheksprojekts angeben, da sie von den SDK-Tools nicht mit den Manifesten Anwendungen. Stattdessen müssen Sie die Berechtigung in jedem abhängigen im Manifest der Anwendung.

Richtlinie implementieren

Der Google Play-Lizenzierungsservice bestimmt nicht selbst, einem bestimmten Nutzer mit einer bestimmten Lizenz Zugriff auf Ihre Anwendung gewährt werden soll. Diese Verantwortung bleibt stattdessen einer Policy-Implementierung überlassen, die Sie bereitstellen. in Ihrer Anwendung.

Die Richtlinie ist eine von der LVL deklarierte Schnittstelle, die dafür vorgesehen ist, Ihr Logik zum Zulassen oder Ablehnen des Nutzerzugriffs auf Basis des Ergebnisses Lizenzüberprüfung durchgeführt. Um die LVL verwenden zu können, muss Ihre Anwendung eine Implementierung von Policy.

Die Policy-Schnittstelle deklariert zwei Methoden: allowAccess() und processServerResponse(), die von einem LicenseChecker aufgerufen werden -Instanz beim Verarbeiten einer Antwort vom Lizenzserver. Außerdem wird ein Enum namens LicenseResponse, das die Lizenzantwort angibt -Wert, der in Aufrufen an processServerResponse() übergeben wird.

• Mit processServerResponse() können Sie die unbearbeitete Antwort vorverarbeiten. vom Lizenzierungsserver empfangene Daten, bevor bestimmt wird, ob Zugriff haben.

  Bei einer typischen Implementierung werden einige oder alle Felder aus der Lizenz extrahiert. und die Daten lokal in einem nichtflüchtigen Speicher speichern, z. B. SharedPreferences Speicher, damit die Daten über Anwendungsaufrufe und Geräte-Einschaltzyklen zugänglich sind. Beispiel: Policy würde den Zeitstempel der letzten erfolgreichen Lizenzprüfung beibehalten, der die Anzahl der Wiederholungen, den Gültigkeitszeitraum der Lizenz und ähnliche Informationen anstatt die Werte jedes Mal zurückzusetzen, wenn die Anwendung eingeführt.

  Beim lokalen Speichern von Antwortdaten muss der Policy sicherstellen, dass die Daten verschleiert (siehe Obfuscator implementieren) unten).

• allowAccess() bestimmt, ob dem Nutzer Zugriff gewährt wird auf basierend auf den verfügbaren Lizenzantwortdaten (aus dem Lizenzierungsserver oder aus dem Cache) oder andere anwendungsspezifische Informationen enthält. Für kann die Implementierung von allowAccess() zusätzliche Kriterien wie Nutzung oder andere von einem Back-End-Server. In allen Fällen muss eine Implementierung von allowAccess() sollte nur true zurückgeben, wenn der Nutzer für die Verwendung des wie vom Lizenzierungsserver festgelegt, oder wenn eine vorübergehende Netzwerk- oder Systemproblem, wodurch die Lizenzüberprüfung nicht abgeschlossen werden kann. In In solchen Fällen kann Ihre Implementierung die Anzahl der Wiederholungsantworten vorübergehend Zugriff gewähren, bis die nächste Lizenzüberprüfung abgeschlossen ist.

Um das Hinzufügen von Lizenzierungen zu Ihrer Anwendung zu vereinfachen und Illustration zur Gestaltung einer Policy liefern. Die LVL enthält zwei vollständige Policy-Implementierungen, die ohne Änderung oder an Ihre Bedürfnisse anpassen:

• ServerManagedPolicy, eine flexible Policy das vom Server bereitgestellte Einstellungen und im Cache gespeicherte Antworten verwendet, um den Zugriff Netzwerkbedingungen und
• StrictPolicy, die keine Antworten im Cache speichert und erlaubt den Zugriff nur, wenn der Server eine lizenzierte Antwort.

Für die meisten Anwendungen ist die Verwendung von ServerManagedPolicy stark wird empfohlen. ServerManagedPolicy ist die LVL-Standardeinstellung und ist in der LVL-Beispielanwendung.

Richtlinien für benutzerdefinierte Richtlinien

Bei der Implementierung der Lizenzierung können Sie eine der vollständigen Richtlinien verwenden die in der LVL (ServerManagedPolicy oder StrictPolicy) angegeben sind, oder Sie können eine benutzerdefinierte Richtlinie. Für jede Art von benutzerdefinierter Richtlinie gibt es mehrere wichtige Konzepte Punkte, die Sie bei Ihrer Implementierung verstehen und berücksichtigen sollten.

Der Lizenzierungsserver wendet allgemeine Anfragebeschränkungen an, um eine Überbeanspruchung zu verhindern. die zu einem Denial-of-Service-Angriff führen könnten. Wenn eine Anwendung Anfragelimit überschreiten, gibt der Lizenzierungsserver eine 503-Antwort zurück, die als allgemeiner Serverfehler an Ihre Anwendung übergeben. Das bedeutet, dass keine Lizenzantwort steht dem Nutzer zur Verfügung, bis das Limit zurückgesetzt wird. auf unbestimmte Zeit auf den Nutzer auswirken kann.

Wenn Sie eine benutzerdefinierte Richtlinie entwerfen, empfehlen wir für Policy Folgendes:

1. Die letzte erfolgreiche Lizenzantwort wird im Cache gespeichert (und korrekt verschleiert) im lokalen nichtflüchtigen Speicher.
2. Gibt die im Cache gespeicherte Antwort für alle Lizenzprüfungen zurück, solange der im Cache gespeicherte Antwort ist gültig, anstatt eine Anfrage an den Lizenzierungsserver zu senden. Gültigkeit der Antwort gemäß der vom Server bereitgestellten VT festlegen wird dringend empfohlen. Siehe Serverantwortextras .
3. Verwendet einen exponentiellen Backoff-Zeitraum. Bei wiederholten Anfragen führt dies zu Fehler. Hinweis: Der Google Play-Client versucht, die Anfrage automatisch noch einmal auszuführen. -Anfragen daher ab, sodass dein Policy in den meisten Fällen keinen erneuten Versuch unternehmen muss.
4. Bietet einen „Kulanzzeitraum“ mit der der Nutzer auf Ihre nur für einen begrenzten Zeitraum oder für eine begrenzte Anzahl von Nutzungen bewerben, während eine Lizenzüberprüfung durchgeführt wird den Vorgang wiederholen. Der Kulanzzeitraum hat den Vorteil, dass der Nutzer Zugriff bis zum nächsten Die Lizenzüberprüfung kann erfolgreich durchgeführt werden. Sie profitieren davon, feste Beschränkung des Zugriffs auf Ihre Anwendung, wenn keine gültige Lizenzantwort vorhanden ist verfügbar.

Es ist wichtig, dass du dein Policy gemäß den oben aufgeführten Richtlinien entwickelst. weil es die bestmögliche Nutzererfahrung bietet und gleichzeitig effektive Kontrolle über Ihre Anwendung.

Beachten Sie, dass jeder Policy die vom Lizenzierungsserver bereitgestellten Einstellungen verwenden kann, um beim Verwalten von Gültigkeit und Caching, Kulanzzeitraum für Wiederholungsversuche und mehr. Extrahieren des die vom Server bereitgestellten Einstellungen sind einfach und zu nutzen, wird empfohlen. Die Implementierung von ServerManagedPolicy enthält ein Beispiel dafür, wie Sie zu extrahieren und zu verwenden. Eine Liste der Servereinstellungen und Informationen zu Informationen zur Verwendung finden Sie unter Serverantwort Extras.

ServerManagedPolicy

Die LVL enthält eine vollständige und empfohlene Implementierung der Policy ServerManagedPolicy. Die Implementierung ist in das LVL-Klassen und dient als Standard-Policy in der Bibliothek.

ServerManagedPolicy übernimmt alle Aufgaben für die Lizenzierung und Wiederholungsversuche. Antworten. Alle Antwortdaten werden lokal in einem SharedPreferences-Datei und verschleiert sie mit dem Obfuscator-Implementierung der Anwendung. Dadurch wird die Lizenzantwort -Daten sind sicher und bleiben auch nach dem Ausschalten des Geräts erhalten. ServerManagedPolicy bietet konkrete Implementierungen der Interface-Methoden processServerResponse() und allowAccess() und auch umfasst eine Reihe von Methoden und Typen zur Verwaltung von Lizenzen Antworten.

Eine wichtige Funktion von ServerManagedPolicy ist die Verwendung von die vom Server bereitgestellten Einstellungen als Grundlage für die Lizenzierung in einem Erstattungsfrist für die Bewerbung und unterschiedliche Netzwerk- und Fehlerbedingungen. Wenn eine App zur Lizenzprüfung den Google Play-Server kontaktiert, fügt im Feld "Extras" eines bestimmten Ordners Lizenzantworttypen. Beispielsweise stellt der Server empfohlene Werte für die Gültigkeitszeitraum der Lizenz der Anwendung, Kulanzzeitraum für Wiederholungsversuche und maximal zulässige Anzahl Anzahl der Wiederholungen. ServerManagedPolicy extrahiert die Werte aus der Lizenzantwort mit der Methode processServerResponse() und Prüfungen in der Methode allowAccess() an. Eine Liste der vom Server bereitgestellten Daten von ServerManagedPolicy verwendeten Einstellungen, siehe Serverantwort Extras.

Für mehr Komfort, optimale Leistung und die Vorteile der Lizenzeinstellungen vom Google Play-Server, mit ServerManagedPolicy als Die Lizenzierung von Policy wird dringend empfohlen.

Wenn Sie Bedenken hinsichtlich der Sicherheit der Lizenzantwortdaten haben, lokal in SharedPreferences gespeichert ist, können Sie eine stärkere Verschleierung verwenden. oder ein strengeres Policy-Element entwerfen, in dem keine Lizenzdaten gespeichert werden. Die LVL enthält ein Beispiel für ein solches Policy. Weitere Informationen finden Sie unter StrictPolicy.

Importieren Sie sie einfach in Ihre Activity-Klasse, um ServerManagedPolicy zu verwenden, erstellen Sie ein und übergeben beim Erstellen der Instanz einen Verweis auf die Instanz. LicenseChecker Weitere Informationen finden Sie unter LicenseChecker instanziieren und LicenseCheckerCallback.

Strenge Richtlinie

Die LVL enthält eine alternative vollständige Implementierung der Policy-Schnittstelle namens StrictPolicy. Die StrictPolicy-Implementierung bietet eine restriktivere als ServerManagedPolicy, da sie dem Nutzer keinen Zugriff wenn keine Lizenzantwort vom Server des Zeitpunkt des Zugriffs, der angibt, dass der Nutzer lizenziert ist.

Die Hauptfunktion von StrictPolicy ist, dass keine Lizenzantwortdaten lokal in einem nichtflüchtigen Speicher. Da keine Daten gespeichert werden, Wiederholungsanfragen werden nicht verfolgt und im Cache gespeicherte Antworten können nicht zum Ausführen verwendet werden Lizenzüberprüfungen. Policy gewährt nur unter folgenden Bedingungen Zugriff:

• Die Lizenzantwort wird vom Lizenzierungsserver empfangen und
• Die Lizenzantwort gibt an, dass der Nutzer über eine Lizenz für den Zugriff auf die .

Die Verwendung von StrictPolicy ist angemessen, wenn Ihr Hauptanliegen darin besteht, sicherzustellen, Nutzer dürfen in allen möglichen Fällen nur auf die Anwendung zugreifen, Für den Nutzer wurde bestätigt, dass er zum Zeitpunkt der Verwendung eine Lizenz hat. Darüber hinaus enthält der Die Richtlinie bietet etwas mehr Sicherheit als ServerManagedPolicy, da Es gibt keine Daten, die lokal zwischengespeichert werden, und böswillige Nutzer können sie nicht manipulieren mit den im Cache gespeicherten Daten und erhalten Zugriff auf die Anwendung.

Gleichzeitig stellt diese Policy eine Herausforderung für normale Nutzer dar, da sie bedeutet, dass sie nicht auf die App zugreifen können, wenn kein Netzwerk vorhanden ist. (Mobilfunk- oder WLAN-Verbindung) verfügbar. Ein weiterer Nebeneffekt ist, dass Ihre App mehr Anfragen zur Lizenzüberprüfung an den Server, da die Verwendung eines im Cache gespeicherte Antwort nicht möglich ist.

Insgesamt stellt diese Richtlinie einen Kompromiss in Bezug auf die Nutzerfreundlichkeit dar für absolute Sicherheit und Zugriffskontrolle. Kompromisse sorgfältig abwägen bevor du dieses Policy verwendest.

Importieren Sie StrictPolicy einfach in Ihre Activity-Klasse, erstellen Sie eine Instanz und beim Erstellen der LicenseChecker einen Verweis darauf übergeben. Weitere Informationen finden Sie unter LicenseChecker und LicenseCheckerCallback instanziieren .

Bei einer typischen Policy-Implementierung müssen die Lizenzantwortdaten für einer Anwendung in einem nichtflüchtigen Speicher abgelegt, sodass sie Anwendungsaufrufe und das Aus- und Einschalten von Geräten. Ein Policy würde beispielsweise den Zeitstempel der letzten erfolgreichen Lizenzüberprüfung, die Anzahl der Wiederholungen Gültigkeit der Lizenz und ähnliche Informationen in einem permanenten Speicher anstatt die Werte bei jedem Start der Anwendung zurückzusetzen. Die Standard-Policy in LVL enthalten, ServerManagedPolicy, speichert Lizenzantwort in einer SharedPreferences-Instanz, um sicherzustellen, dass die Daten persistent sind.

Weil die Policy gespeicherte Lizenzantwortdaten verwendet, um zu bestimmen, ob um den Zugriff auf die Anwendung zu erlauben oder zu verbieten, muss sichergestellt werden, dass jegliche dass die Daten sicher sind und von einem Root-Nutzer auf einem . Insbesondere muss die Policy die Daten vor dem Speichern immer verschleiern. mit einem Schlüssel, der für die Anwendung und das Gerät eindeutig ist. Verschleierung mit ein anwendungs- und gerätespezifischer Schlüssel wichtig ist, wird verhindert, dass die verschleierten Daten zwischen Anwendungen geteilt und Geräte.

Die LVL unterstützt die Anwendung beim Speichern der Lizenzantwortdaten in einem auf sichere, dauerhafte Weise. Zunächst stellt er ein Obfuscator-Objekt bereit, Schnittstelle, mit der Ihre Anwendung den Verschleierungsalgorithmus ihrer für gespeicherte Daten. Darauf aufbauend stellt die LVL die Hilfsklasse PreferenceObfuscator, der die meisten Vorgänge beim Aufrufen der Obfuscator-Klasse der Anwendung erstellt und die verschleierten Daten in einem SharedPreferences-Instanz.

Die LVL bietet eine vollständige Obfuscator-Implementierung namens AESObfuscator, der zur Verschleierung von Daten die AES-Verschlüsselung verwendet. Sie können ohne AESObfuscator in Ihrer Anwendung zu verwenden, an Ihre Bedürfnisse anpassen können. Wenn du ein Policy (z. B. ServerManagedPolicy), die Lizenzantwortdaten unter Verwendung von AESObfuscator im Cache speichert. für die Obfuscator-Implementierung wird dringend empfohlen. Weitere Informationen finden Sie im nächsten Abschnitt.

AES-Obfuscator

Die LVL enthält eine vollständige und empfohlene Implementierung der Obfuscator AESObfuscator. Die Implementierung ist in das LVL-Beispielanwendung und dient als Standard-Obfuscator in der Bibliothek.

AESObfuscator bietet eine sichere Verschleierung von Daten, indem AES genutzt wird, um die Daten beim Schreiben oder Lesen aus dem Speicher verschlüsseln und entschlüsseln. Obfuscator aktiviert die Verschlüsselung mithilfe von drei bereitgestellten Datenfeldern. durch die Anwendung:

1. Salt – ein Array von zufälligen Byte, die für jede (Un-)Verschleierung verwendet werden.
2. Ein Anwendungs-ID-String, in der Regel der Paketname der Anwendung.
3. Ein Geräte-ID-String, der aus möglichst vielen gerätespezifischen Quellen abgeleitet wird wie möglich, um sie so einzigartig zu machen.

Wenn du AESObfuscator verwenden möchtest, musst du es zuerst in deine Aktivität importieren. Als privat deklarieren Statisches letztes Array, um die Salt-Byte zu speichern und zufällig mit 20 zu initialisieren erzeugte Bytes.

// Generate 20 random bytes, and put them here.
private val SALT = byteArrayOf(
        -46, 65, 30, -128, -103, -57, 74, -64, 51, 88,
        -95, -45, 77, -117, -36, -113, -11, 32, -64, 89
)

...
    // Generate 20 random bytes, and put them here.
    private static final byte[] SALT = new byte[] {
     -46, 65, 30, -128, -103, -57, 74, -64, 51, 88, -95,
     -45, 77, -117, -36, -113, -11, 32, -64, 89
     };
    ...

Deklarieren Sie als Nächstes eine Variable, die eine Gerätekennung enthalten soll, und generieren Sie einen Wert für irgendwie brauchen. Die in der LVL enthaltene Beispielanwendung die Systemeinstellungen für die android.Settings.Secure.ANDROID_ID für jedes Gerät eindeutig.

Je nachdem, welche APIs Sie verwenden, muss Ihre Anwendung möglicherweise zusätzliche Berechtigungen anfordern, um gerätespezifische Informationen zu erhalten. Wenn Sie beispielsweise TelephonyManager abfragen möchten, die Geräte-IMEI oder zugehörige Daten enthält, muss die App auch android.permission.READ_PHONE_STATE in ihrem Manifest.

Bevor Sie neue Berechtigungen anfordern, um allein gerätespezifische Informationen zur Verwendung in deinem Obfuscator findest du Wie sich dies auf deine App oder deren Filterung bei Google Play auswirken kann da einige Berechtigungen dazu führen können, dass die SDK-Build-Tools zugehöriges <uses-feature>).

Erstellen Sie schließlich eine Instanz von AESObfuscator, übergeben Sie das Salt Anwendungs-ID und Geräte-ID. Sie können die Instanz direkt beim Erstellen von Policy und LicenseChecker. Beispiel:

    ...
    // Construct the LicenseChecker with a Policy.
    private val checker = LicenseChecker(
            this,
            ServerManagedPolicy(this, AESObfuscator(SALT, packageName, deviceId)),
            BASE64_PUBLIC_KEY
    )
    ...

    ...
    // Construct the LicenseChecker with a Policy.
    checker = new LicenseChecker(
        this, new ServerManagedPolicy(this,
            new AESObfuscator(SALT, getPackageName(), deviceId)),
        BASE64_PUBLIC_KEY // Your public licensing key.
        );
    ...

Ein vollständiges Beispiel finden Sie in der LVL-Beispielanwendung unter MainActivity.

Lizenz aus einer Aktivität prüfen

Nachdem Sie ein Policy zur Verwaltung des Zugriffs auf Ihre Anwendung implementiert haben, Der nächste Schritt besteht darin, Ihrer Anwendung eine Lizenzprüfung hinzuzufügen, die eine Abfrage initiiert an den Lizenzierungsserver senden und den Zugriff auf die Anwendung Lizenzantwort. Der Aufwand für das Hinzufügen der Lizenzüberprüfung und Die Antwort erfolgt in Ihrer Activity-Hauptquelldatei.

So fügen Sie die Lizenzprüfung hinzu und verarbeiten die Antwort:

1. Importe hinzufügen
2. LicenseCheckerCallback als private innere Klasse implementieren
3. Erstellen Sie einen Handler für das Posten von LicenseCheckerCallback an den UI-Thread.
4. LicenseChecker und LicenseCheckerCallback instanziieren
5. checkAccess() aufrufen, um die Lizenzprüfung zu starten
6. Betten Sie Ihren öffentlichen Schlüssel für die Lizenzierung ein.
7. Rufen Sie die Methode "onDestroy()" von LicenseChecker auf, um IPC-Verbindungen zu trennen.

In den folgenden Abschnitten werden diese Aufgaben beschrieben.

Lizenzprüfung und -antwort – Übersicht

In den meisten Fällen sollten Sie die Lizenzprüfung auf der Hauptseite Ihrer Anwendung Activity in der Methode onCreate(). Dieses wird die Lizenzüberprüfung durchgeführt, wenn der Nutzer Ihre App direkt startet. wird sofort aufgerufen. In einigen Fällen können Sie Lizenzüberprüfungen in anderen und Standorte. Wenn Ihre App beispielsweise mehrere Aktivitäten Komponenten, die andere Anwendungen mit Intent starten können, können Sie in diesen Aktivitäten Lizenzprüfungen hinzufügen.

Eine Lizenzüberprüfung umfasst zwei Hauptschritte:

• Ein Aufruf einer Methode zur Initiierung der Lizenzprüfung – in der LVL ist dies Aufruf der Methode checkAccess() eines LicenseChecker-Objekts, das die Sie erstellen.
• Ein Callback, der das Ergebnis der Lizenzprüfung zurückgibt. In der LVL ist dies einer von Ihnen implementierten LicenseCheckerCallback-Schnittstelle. Die deklariert die beiden Methoden allow() und dontAllow(), die von der Bibliothek basierend auf dem Ergebnis der Lizenzüberprüfung. Diese beiden Methoden implementieren Sie mit jeder Logik, um dem Nutzer den Zugriff auf Ihre Anwendung zu gestatten oder nicht zu verbieten. Beachten Sie, dass nicht festgelegt ist, ob der Zugriff erlaubt wird, sondern Dies liegt in der Verantwortung deiner Policy-Implementierung. Vielmehr sind diese geben einfach das Anwendungsverhalten an, wie zugelassen und den Zugriff zu verweigern (und Anwendungsfehler zu beheben).

  Die Methoden allow() und dontAllow() geben einen „Grund“ an. für ihre Antwort, die einer der Policy-Werte LICENSED sein kann, NOT_LICENSED oder RETRY. Sie sollten insbesondere den Fall berücksichtigen, Die Methode empfängt die RETRY-Antwort für dontAllow() und stellt dem Nutzer ein „Wiederholen“ angezeigt wird. Dies kann daran liegen, dass der Dienst während der

Abbildung 1: Übersicht über ein typische Interaktion bei der Lizenzprüfung

Das Diagramm oben zeigt, wie eine typische Lizenzüberprüfung abläuft:

1. Code in der Hauptaktivität der Anwendung instanziiert LicenseCheckerCallback und LicenseChecker. Beim Erstellen von LicenseChecker wird der Code übergeben. Context, die zu verwendende Policy-Implementierung und der Den öffentlichen Schlüssel des Verlags- oder Webpublisherkontos zur Lizenzierung als Parameter verwenden.
2. Der Code ruft dann die Methode checkAccess() für die LicenseChecker-Objekt. Die Methodenimplementierung ruft den Policy auf, um zu bestimmen, ob eine gültige Lizenzantwort lokal, in SharedPreferences.
   • Wenn ja, ruft die Implementierung checkAccess() allow().
   • Andernfalls initiiert LicenseChecker eine Anfrage zur Lizenzprüfung, die gesendet wird. mit dem Lizenzierungsserver.

   Hinweis:Der Lizenzierungsserver gibt immer LICENSED, wenn du eine Lizenzprüfung für einen Anwendungsentwurf durchführst.

3. Wenn eine Antwort eingeht, erstellt LicenseChecker einen LicenseValidator, der überprüft die signierten Lizenzdaten und extrahiert die Felder der Antwort. übergibt sie zur weiteren Auswertung an Policy.
   • Wenn die Lizenz gültig ist, speichert Policy die Antwort im Cache. SharedPreferences und benachrichtigt den Validator, der dann die Methode allow() für das Objekt LicenseCheckerCallback.
   • Wenn die Lizenz ungültig ist, benachrichtigt Policy den Validator, der Methode dontAllow() für LicenseCheckerCallback
4. Bei einem wiederherstellbaren lokalen Fehler oder Serverfehler, z. B. wenn das Netzwerk nicht zum Senden der Anfrage verfügbar ist, übergibt LicenseChecker eine RETRY-Antwort an mit der processServerResponse()-Methode des Policy-Objekts.

   Außerdem erhalten die Callback-Methoden allow() und dontAllow() eine Fehlermeldung. reason-Argument. Der Grund für die Methode allow() ist normalerweise Policy.LICENSED oder Policy.RETRY und der Grund dontAllow() ist normalerweise Policy.NOT_LICENSED oder Policy.RETRY. Diese Antwortwerte sind nützlich, Eine angemessene Antwort für den Nutzer, z. B. durch eine „Wiederholen“-Anfrage Schaltfläche, wenn dontAllow() mit Policy.RETRY antwortet. Das kann daran liegen, dass der Dienst nicht verfügbar.

5. Bei einem Anwendungsfehler, z. B. wenn die Anwendung versucht, Lizenz eines ungültigen Paketnamens prüfen. LicenseChecker gibt einen Fehler aus. Antwort auf den applicationError() von LicenseCheckerCallback .

Neben der Initiierung der Lizenzüberprüfung und der Bearbeitung des die in den folgenden Abschnitten beschrieben werden, muss Ihre Anwendung um eine Richtlinienimplementierung bereitzustellen und, falls die Policy speichert Antwortdaten (z. B. ServerManagedPolicy), eine Obfuscator-Implementierung.

Importe hinzufügen

Öffnen Sie zuerst die Klassendatei der Hauptaktivität der Anwendung und importieren Sie LicenseChecker und LicenseCheckerCallback aus dem LVL-Paket.

import com.google.android.vending.licensing.LicenseChecker
import com.google.android.vending.licensing.LicenseCheckerCallback

import com.google.android.vending.licensing.LicenseChecker;
import com.google.android.vending.licensing.LicenseCheckerCallback;

Wenn Sie die mit der LVL bereitgestellte Standard-Policy-Implementierung verwenden, ServerManagedPolicy hinzufügen, importieren Sie ihn ebenfalls zusammen mit dem AESObfuscator. Wenn Sie mit einem benutzerdefinierten Policy oder Obfuscator, importieren Sie diese stattdessen.

import com.google.android.vending.licensing.ServerManagedPolicy
import com.google.android.vending.licensing.AESObfuscator

import com.google.android.vending.licensing.ServerManagedPolicy;
import com.google.android.vending.licensing.AESObfuscator;

LicenseCheckerCallback als private innere Klasse implementieren

LicenseCheckerCallback ist eine von der LVL zur Verarbeitung bereitgestellte Schnittstelle Ergebnis der Lizenzüberprüfung Um die Lizenzierung mithilfe der LVL zu unterstützen, müssen Sie LicenseCheckerCallback implementieren und um den Zugriff auf die Anwendung zuzulassen oder zu verbieten.

Das Ergebnis einer Lizenzprüfung ist immer ein Aufruf an eine der LicenseCheckerCallback-Methoden, die auf der Validierung der Antwort basieren Nutzlast, dem Server-Antwortcode selbst und jeder zusätzlichen Verarbeitung, von deinem Policy. Ihre Anwendung kann die Methoden auf jede beliebige Weise implementieren. In Im Allgemeinen sollten die Methoden einfach gehalten und auf die Verwaltung der Benutzeroberfläche Status- und Anwendungszugriff. Wenn Sie eine weitere Verarbeitung der Lizenz wünschen z. B. durch Kontaktaufnahme mit einem Back-End-Server oder Anwenden benutzerdefinierter Einschränkungen, sollten Sie diesen Code in Ihre Policy einbinden, anstatt indem wir sie in die LicenseCheckerCallback-Methoden einfügen.

In den meisten Fällen sollten Sie die Implementierung LicenseCheckerCallback als private Klasse innerhalb der Hauptklasse Ihrer Anwendung Übungskurs.

Die Methoden allow() und dontAllow() implementieren als erforderlich. Für den Anfang können Sie einfache Verhaltensweisen bei der Ergebnisverarbeitung in der Methoden, wie z. B. die Anzeige des Lizenzergebnisses in einem Dialogfeld. So erhalten Sie damit Ihre Anwendung schneller ausgeführt wird, und Sie können beim Debugging helfen. Später, nachdem Sie die gewünschten Verhaltensweisen festgelegt haben, können Sie komplexere Abläufe hinzufügen.

Einige Vorschläge zum Umgang mit nicht lizenzierten Antworten in dontAllow() enthalten:

• „Noch einmal versuchen“ anzeigen für den Nutzer zur Verfügung, z. B. über eine Schaltfläche neue Lizenzprüfung, wenn die bereitgestellte reason Policy.RETRY ist.
• Die Meldung „Diese App kaufen“ anzeigen Dialogfeld mit einer Schaltfläche, Der Nutzer wird per Deep-Link zur Detailseite der App bei Google Play weitergeleitet, wo der Nutzer die Nutzer die Anwendung kaufen können. Weitere Informationen zum Einrichten solcher finden Sie unter Verknüpfungen mit Ihren Produkten.
• Toast-Benachrichtigung anzeigen, die darauf hinweist, dass die Funktionen der App eingeschränkt, da sie nicht lizenziert ist.

Das folgende Beispiel zeigt, wie die LVL-Beispielanwendung LicenseCheckerCallback mit Methoden, die die Lizenzprüfung anzeigen, führt zu einem Dialogfeld.

private inner class MyLicenseCheckerCallback : LicenseCheckerCallback {

    override fun allow(reason: Int) {
        if (isFinishing) {
            // Don't update UI if Activity is finishing.
            return
        }
        // Should allow user access.
        displayResult(getString(R.string.allow))
    }

    override fun dontAllow(reason: Int) {
        if (isFinishing) {
            // Don't update UI if Activity is finishing.
            return
        }
        displayResult(getString(R.string.dont_allow))

        if (reason == Policy.RETRY) {
            // If the reason received from the policy is RETRY, it was probably
            // due to a loss of connection with the service, so we should give the
            // user a chance to retry. So show a dialog to retry.
            showDialog(DIALOG_RETRY)
        } else {
            // Otherwise, the user isn't licensed to use this app.
            // Your response should always inform the user that the application
            // isn't licensed, but your behavior at that point can vary. You might
            // provide the user a limited access version of your app or you can
            // take them to Google Play to purchase the app.
            showDialog(DIALOG_GOTOMARKET)
        }
    }
}

private class MyLicenseCheckerCallback implements LicenseCheckerCallback {
    public void allow(int reason) {
        if (isFinishing()) {
            // Don't update UI if Activity is finishing.
            return;
        }
        // Should allow user access.
        displayResult(getString(R.string.allow));
    }

    public void dontAllow(int reason) {
        if (isFinishing()) {
            // Don't update UI if Activity is finishing.
            return;
        }
        displayResult(getString(R.string.dont_allow));

        if (reason == Policy.RETRY) {
            // If the reason received from the policy is RETRY, it was probably
            // due to a loss of connection with the service, so we should give the
            // user a chance to retry. So show a dialog to retry.
            showDialog(DIALOG_RETRY);
        } else {
            // Otherwise, the user isn't licensed to use this app.
            // Your response should always inform the user that the application
            // isn't licensed, but your behavior at that point can vary. You might
            // provide the user a limited access version of your app or you can
            // take them to Google Play to purchase the app.
            showDialog(DIALOG_GOTOMARKET);
        }
    }
}

Außerdem solltest du den applicationError() implementieren -Methode, die von der LVL aufgerufen wird, damit Ihre Anwendung Fehler verarbeiten kann, die nicht kann wiederholt werden. Eine Liste solcher Fehler finden Sie unter Server Antwortcodes finden Sie in der Referenz zur Lizenzierung. Sie können die Methode auf die gewünschte Weise an. In den meisten Fällen sollte den Fehlercode protokollieren und dontAllow() aufrufen.

Handler für das Posten von LicenseCheckerCallback erstellen zum UI-Thread hinzufügen,

Im Rahmen einer Lizenzüberprüfung leitet die LVL die Anfrage an die Google Play-Abteilung weiter. -Anwendung, die die Kommunikation mit dem Lizenzierungsserver übernimmt. Die LVL übergibt die Anfrage über den asynchronen IPC (mit Binder), sodass Die eigentliche Verarbeitung und Netzwerkkommunikation findet nicht in einem Thread statt. die von Ihrer Anwendung verwaltet werden. Wenn die Google Play App das Ergebnis empfängt, wird eine Callback-Methode über IPC aufgerufen, die wiederum in einem IPC-Thread-Pool im Prozess Ihrer Anwendung ausgeführt wird.

Die Klasse LicenseChecker verwaltet die IPC-Kommunikation Ihrer Anwendung mit der Google Play App, einschließlich des Aufrufs, der die Anfrage sendet, den Callback, der die Antwort empfängt. LicenseChecker verfolgt auch eine offene Lizenz und verwaltet deren Zeitlimits.

Damit es Zeitüberschreitungen ordnungsgemäß verarbeiten und auch eingehende Antworten verarbeiten kann ohne Auswirkungen auf den UI-Thread Ihrer Anwendung zu haben, erzeugt LicenseChecker einen Hintergrund-Thread bei der Instanziierung. Im Thread übernimmt er die gesamte Verarbeitung Ergebnisse der Lizenzüberprüfung, ob das Ergebnis eine vom Server empfangene Antwort ist oder ein Zeitüberschreitungsfehler. Am Ende der Verarbeitung ruft die LVL Ihre LicenseCheckerCallback-Methoden aus dem Hintergrundthread.

Für Ihre Anwendung bedeutet dies Folgendes:

1. Ihre LicenseCheckerCallback-Methoden werden in vielen Fällen über eine im Hintergrund.
2. Diese Methoden können dann weder den Status aktualisieren noch eine Verarbeitung im UI-Thread, es sei denn, Sie erstellen im UI-Thread einen Handler und lassen Ihren Callback werden an den Handler gesendet.

Wenn Sie möchten, dass Ihre LicenseCheckerCallback-Methoden den UI-Thread aktualisieren, eine Handler in der Hauptaktivität onCreate()-Methode, wie unten dargestellt. In diesem Beispiel ist die Methode der LVL-Beispielanwendung LicenseCheckerCallback-Methoden (siehe oben) rufen displayResult() auf, um UI-Thread über die Handler-Funktion aktualisieren post()-Methode.

    private lateinit var handler: Handler

    override fun onCreate(savedInstanceState: Bundle?) {
        ...
        handler = Handler()
    }

    private Handler handler;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        ...
        handler = new Handler();
    }

Anschließend können Sie in Ihren LicenseCheckerCallback-Methoden Handler-Methoden verwenden, um Runnable- oder Message-Objekte an den Handler übermitteln. Hier sehen Sie, wie das Beispiel Die in der LVL enthaltene Anwendung sendet ein Runnable an einen Handler im UI-Thread. um den Lizenzstatus anzuzeigen.

private fun displayResult(result: String) {
    handler.post {
        statusText.text = result
        setProgressBarIndeterminateVisibility(false)
        checkLicenseButton.isEnabled = true
    }
}

private void displayResult(final String result) {
        handler.post(new Runnable() {
            public void run() {
                statusText.setText(result);
                setProgressBarIndeterminateVisibility(false);
                checkLicenseButton.setEnabled(true);
            }
        });
    }

LicenseChecker und LicenseCheckerCallback instanziieren

In der Hauptaktivitäts- Methode onCreate(), private Instanzen von LicenseCheckerCallback und LicenseChecker erstellen Du musst Instanziieren Sie zuerst LicenseCheckerCallback, da Sie eine Referenz übergeben müssen zu dieser Instanz hinzufügen, wenn Sie den Konstruktor für LicenseChecker aufrufen.

Wenn Sie LicenseChecker instanziieren, müssen Sie die folgenden Parameter übergeben:

• Die Anwendung Context
• Ein Verweis auf die Implementierung von Policy für die Lizenzprüfung. In In den meisten Fällen würden Sie die Standard-Policy-Implementierung verwenden, die von der LVL bereitgestellt wird, ServerManagedPolicy.
• Die Zeichenfolgenvariable, die den öffentlichen Schlüssel Ihres Verlags- oder Webpublisherkontos enthält. Lizenzierung.

Wenn Sie ServerManagedPolicy verwenden, müssen Sie nicht auf den Kurs zugreifen direkt, sodass Sie sie im LicenseChecker-Konstruktor instanziieren können, wie im Beispiel unten gezeigt. Beachten Sie, dass Sie eine Referenz an eine neue Obfuscator-Instanz beim Erstellen von ServerManagedPolicy.

Das folgende Beispiel zeigt die Instanziierung von LicenseChecker und LicenseCheckerCallback aus der onCreate()-Methode einer Aktivität .

class MainActivity : AppCompatActivity() {
    ...
    private lateinit var licenseCheckerCallback: LicenseCheckerCallback
    private lateinit var checker: LicenseChecker

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ...
        // Construct the LicenseCheckerCallback. The library calls this when done.
        licenseCheckerCallback = MyLicenseCheckerCallback()

        // Construct the LicenseChecker with a Policy.
        checker = LicenseChecker(
                this,
                ServerManagedPolicy(this, AESObfuscator(SALT, packageName, deviceId)),
                BASE64_PUBLIC_KEY // Your public licensing key.
        )
        ...
    }
}

public class MainActivity extends Activity {
    ...
    private LicenseCheckerCallback licenseCheckerCallback;
    private LicenseChecker checker;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
        // Construct the LicenseCheckerCallback. The library calls this when done.
        licenseCheckerCallback = new MyLicenseCheckerCallback();

        // Construct the LicenseChecker with a Policy.
        checker = new LicenseChecker(
            this, new ServerManagedPolicy(this,
                new AESObfuscator(SALT, getPackageName(), deviceId)),
            BASE64_PUBLIC_KEY // Your public licensing key.
            );
        ...
    }
}

LicenseChecker ruft die LicenseCheckerCallback-Methoden über die UI auf. Thread nur dann, wenn eine gültige Lizenzantwort lokal im Cache gespeichert ist. Wenn die an den Server gesendet wird, stammen die Callbacks immer vom auch bei Netzwerkfehlern.

Rufen Sie checkAccess() auf, um die Lizenzprüfung zu starten.

Fügen Sie in Ihrer Hauptaktivität einen Aufruf der checkAccess()-Methode des LicenseChecker-Instanz. Übergeben Sie im Aufruf einen Verweis auf Ihre LicenseCheckerCallback-Instanz als Parameter. Wenn Sie sich mit vor dem Anruf spezielle UI-Effekte oder die Statusverwaltung haben, um checkAccess() über eine Wrapper-Methode aufzurufen. Zum Beispiel hat die LVL Beispielanwendung ruft checkAccess() aus einem Wrapper-Methode doCheck():

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        ...
        // Call a wrapper method that initiates the license check
        doCheck()
        ...
    }
    ...
    private fun doCheck() {
        checkLicenseButton.isEnabled = false
        setProgressBarIndeterminateVisibility(true)
        statusText.setText(R.string.checking_license)
        checker.checkAccess(licenseCheckerCallback)
    }

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ...
        // Call a wrapper method that initiates the license check
        doCheck();
        ...
    }
    ...
    private void doCheck() {
        checkLicenseButton.setEnabled(false);
        setProgressBarIndeterminateVisibility(true);
        statusText.setText(R.string.checking_license);
        checker.checkAccess(licenseCheckerCallback);
    }

Öffentlichen Schlüssel für die Lizenzierung einbetten

Für jede App wird der Google Play-Dienst automatisch generiert ein 2048-Bit-RSA-Schlüsselpaar mit öffentlichem/privatem Schlüssel, das für Lizenzierung und In-App-Abrechnung. Das Schlüsselpaar ist eindeutig dem . Das Schlüsselpaar ist zwar der Anwendung zugeordnet, nicht mit dem Schlüssel identisch ist, den Sie zum Signieren Ihrer Anwendungen verwenden oder davon abgeleitet haben.

Die Google Play Console macht den öffentlichen Schlüssel zur Lizenzierung für alle Der Entwickler hat sich in der Play Console angemeldet, aber der private Schlüssel bleibt erhalten. an einem sicheren Ort vor allen Nutzern ausgeblendet werden. Wenn eine Anwendung ein Lizenzüberprüfung für eine in Ihrem Konto veröffentlichte Anwendung, den Lizenzierungsserver signiert die Lizenzantwort mit dem privaten Schlüssel des Schlüsselpaars Ihrer Anwendung. Wenn die LVL die Antwort erhält, verwendet sie den öffentlichen Schlüssel, der von der Anwendung, um die Signatur der Lizenzantwort zu überprüfen.

Um einer Anwendung eine Lizenzierung hinzuzufügen, benötigen Sie die für die Lizenzierung und kopieren Sie ihn in Ihre Anwendung. So finden Sie den öffentlichen Schlüssel Ihrer Anwendung für die Lizenzierung:

1. Rufen Sie die Google Play Console auf und melden Sie sich an. Achten Sie darauf, dass Sie sich in dem Konto anmelden, von dem aus die Anwendung verwendet wird. Lizenzierung veröffentlicht (oder wird veröffentlicht).
2. Gehen Sie auf der Seite mit den Anwendungsdetails zu Dienste und APIs und klicken Sie darauf.
3. Klicken Sie im Menü Dienste und APIs finden Sie den Lizenzierung und In-App-Abrechnung. Ihr öffentlicher Schlüssel für Lizenzierung in den Your License Key For this Application (Ihr Lizenzschlüssel für diese Anwendung).

Um den öffentlichen Schlüssel zu Ihrer Anwendung hinzuzufügen, kopieren Sie einfach den Schlüsselstring und fügen ihn ein aus dem Feld in Ihre Anwendung als Wert der String-Variablen BASE64_PUBLIC_KEY Achten Sie beim Kopieren darauf, den gesamten Schlüsselstring ausgewählt, ohne Zeichen auszulassen.

Hier ist ein Beispiel aus der LVL-Beispielanwendung:

private const val BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... " //truncated for this example
class LicensingActivity : AppCompatActivity() {
    ...
}

public class MainActivity extends Activity {
    private static final String BASE64_PUBLIC_KEY = "MIIBIjANBgkqhkiG ... "; //truncated for this example
    ...
}

onDestroy()-Methode des LicenseChecker aufrufen um IPC-Verbindungen zu trennen

Um die LVL vor der Anwendung bereinigen zu lassen, Context-Änderungen, fügen Sie einen Aufruf zum LicenseChecker hinzu onDestroy()-Methode aus dem onDestroy()-Implementierung. Der Aufruf führt dazu, dass LicenseChecker, um alle offenen IPC-Verbindungen zu Google Play ordnungsgemäß zu schließen ILicensingService der Anwendung und entfernt alle lokalen Verweise auf den Dienst und Handler.

Fehler beim Aufrufen der Methode onDestroy() von LicenseChecker kann im Lebenszyklus Ihrer Anwendung zu Problemen führen. Wenn zum Beispiel der Parameter der Nutzer während einer Lizenzprüfung die Bildschirmausrichtung ändert, wird die App Context wurde gelöscht. Wenn Ihre Anwendung nicht die IPC-Verbindung von LicenseChecker nicht ordnungsgemäß schließen, stürzt deine Anwendung ab wenn die Antwort eingeht. Wenn der Nutzer Ihre App beendet, Ihre Anwendung stürzt während einer Lizenzüberprüfung ab, wenn der erhalten, es sei denn, die Funktion Die onDestroy()-Methode von LicenseChecker, um die Verbindung zum Dienst zu trennen.

Hier ist ein Beispiel aus der in der LVL enthaltenen Beispielanwendung, wobei mChecker ist die Instanz LicenseChecker:

    override fun onDestroy() {
        super.onDestroy()
        checker.onDestroy()
        ...
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        checker.onDestroy();
        ...
    }

Wenn Sie LicenseChecker erweitern oder ändern, müssen Sie möglicherweise auch Die finishCheck()-Methode von LicenseChecker, um offene IPCs zu bereinigen Verbindungen.

DeviceLimiter implementieren

In einigen Fällen kann es sinnvoll sein, die Anzahl der tatsächlichen Policy Geräte, die eine einzelne Lizenz verwenden dürfen. Dies würde verhindern, wie das Verschieben einer lizenzierten Anwendung auf mehrere Geräte und die Verwendung der App auf den Geräten mit derselben Konto-ID. Außerdem würde dadurch eine Nutzer aus "Teilen" der Anwendung, indem Sie die Kontoinformationen die mit der Lizenz verknüpft sind, an andere Personen, die sich dann in diesem Konto auf ihren Geräten und greifen auf die Lizenz für die Anwendung zu.

Die LVL unterstützt die Lizenzierung pro Gerät durch Bereitstellung einer DeviceLimiter-Schnittstelle definiert, die eine einzelne Methode deklariert, allowDeviceAccess(). Wenn ein LicenseValidator eine Antwort verarbeitet vom Lizenzierungsserver, ruft er allowDeviceAccess() auf und übergibt Nutzer-ID-String, der aus der Antwort extrahiert wurde.

Wenn Sie keine Gerätebeschränkung unterstützen möchten, ist keine Arbeit erforderlich – Die LicenseChecker-Klasse verwendet automatisch eine Standardeinstellung -Implementierung namens NullDeviceLimiter. Wie der Name schon sagt, ist ein „No-Op“-Prinzip Klasse, deren allowDeviceAccess()-Methode einfach Folgendes zurückgibt: Eine LICENSED-Antwort für alle Nutzer und Geräte.

Code verschleiern

Um die Sicherheit Ihrer Anwendung zu gewährleisten, insbesondere bei kostenpflichtigen Lizenzierung und/oder benutzerdefinierte Einschränkungen und Schutzmaßnahmen, sehr wichtig, um Ihren Anwendungscode zu verschleiern. Korrekte Verschleierung Ihrer erschwert es böswilligen Nutzern, den Code der Anwendung zu dekompilieren Bytecode ändern, z. B. durch Entfernen der Lizenzprüfung, und dann neu kompilieren.

Für Android-Apps sind verschiedene Verschleierungsprogramme verfügbar, darunter: ProGuard, die auch Code-Optimierungsfunktionen. Verwendung von ProGuard oder einem ähnlichen Programm zur Verschleierung Ihr Code wird für alle Anwendungen dringend empfohlen, die Google Google Play-Lizenzierung

Lizenzierte Anwendungen veröffentlichen

Wenn du mit dem Testen deiner Lizenzimplementierung fertig bist, kannst du die App bei Google Play zu veröffentlichen. Folgen Sie den normalen Schritten zum Vorbereiten, Signieren und Veröffentlichen der Anwendung.

Support

Bei Fragen oder Problemen bei der Implementierung oder Bereitstellung in Ihren Anwendungen veröffentlichen möchten, nutzen Sie bitte die Supportressourcen, die in der Tabelle unten. Indem Sie Ihre Anfragen an das richtige Forum weiterleiten, erhalten Sie schneller Unterstützung benötigen.

Tabelle 2: Supportressourcen für Entwickler für den Google Play-Lizenzierungsservice.

Allgemeine Informationen zum Posten in den oben aufgeführten Gruppen finden Sie im Abschnitt Community-Ressourcen. auf der Seite „Supportressourcen für Entwickler“.

Zusätzliche Ressourcen

Die in der LVL enthaltene Beispielanwendung liefert ein vollständiges Beispiel dafür, um eine Lizenzüberprüfung zu starten und das Ergebnis zu verarbeiten, Klasse MainActivity.