LVL-Klassen und -Schnittstellen
In Tabelle 1 sind alle Quelldateien der Lizenzüberprüfung aufgeführt.
Bibliothek (LVL), die über das Android SDK verfügbar ist. Alle Dateien gehören zu
com.android.vending.licensing
-Paket.
Kategorie | Name | Beschreibung |
---|---|---|
Lizenzprüfung und Ergebnis | Lizenzprüfung | Klasse, die Sie instanziieren (oder abgeleitete Klassen), um eine Lizenzprüfung zu initiieren. |
LicenseCheckerCallback | Schnittstelle, die Sie zum Verarbeiten der Ergebnisse der Lizenzprüfung implementieren. | |
Richtlinie | Richtlinie | Schnittstelle, die Sie implementieren, um zu bestimmen, ob Sie Zugriff auf die Anwendung basierend auf der Lizenzantwort. |
ServerManagedPolicy | Standardimplementierung von Policy . Verwendet Einstellungen der
Lizenzierungsserver zur Verwaltung der lokalen Speicherung
von Lizenzdaten, Lizenzgültigkeit,
noch einmal versuchen. |
|
Strenge Richtlinie | Alternative Policy -Implementierung. Erzwingt die Lizenzierung auf Grundlage eines direkten
Lizenzantwort nur vom Server. Kein Caching oder erneute Anfrage. |
|
Datenverschleierung (optional) |
Verschleierungshilfe | Schnittstelle, die implementiert wird, wenn Sie ein Policy verwenden (z. B.
ServerManagedPolicy), die Lizenzantwortdaten in einem nichtflüchtigen Speicher im Cache speichert.
Wendet einen Verschleierungsalgorithmus an, um Daten zu codieren und zu decodieren, die geschrieben oder
gelesen werden. |
AES-Obfuscator | Standard-Obfuscator-Implementierung, die die AES-Verschlüsselung/-Entschlüsselung verwendet zur Verschleierung/Entschleierung von Daten. | |
Gerätebeschränkung (optional) |
DeviceLimiter | Schnittstelle, die Sie implementieren, wenn Sie die Verwendung eines App auf einem bestimmten Gerät. Aufgerufen von LicenseValidator. Implementieren DeviceLimiter wird für die meisten Anwendungen nicht empfohlen, da hierfür ein Backend-Server und kann dazu führen, dass der Nutzer keinen Zugriff mehr auf lizenzierte Anwendungen hat, es sei denn, sie wurden mit Sorgfalt entwickelt. |
NullDeviceLimiter | Standardmäßige DeviceLimiter-Implementierung, die No-Op ist (ermöglicht Zugriff auf alle Geräte). | |
Library Core, keine Integration erforderlich | Antwortdaten | Klasse, die die Felder einer Lizenzantwort enthält. |
LicenseValidator | Klasse, die eine von der Lizenzierung erhaltene Antwort entschlüsselt und verifiziert Server. | |
ValidationException | Klasse, die Fehler anzeigt, die bei der Validierung der Integrität von Daten auftreten von einem Obfuscator verwaltet wird. | |
PreferenceObfuscator | Dienstprogrammklasse, die verschleierte Daten in den
SharedPreferences Händler. |
|
Lizenzierungsservice | Einweg-IPC-Schnittstelle, über die eine Lizenzüberprüfungsanfrage an den Google Play-Client. | |
ILicenseResultListener | Einweg-IPC-Callback-Implementierung, über die die Anwendung ein asynchrone Antwort vom Lizenzierungsserver. |
Serverantwort
In Tabelle 2 sind alle Lizenzantwortfelder aufgeführt, die vom Lizenzierungsserver.
Feld | Beschreibung |
---|---|
responseCode |
Der vom Lizenzierungsserver zurückgegebene Antwortcode. Die Antwortcodes sind die unter Serverantwortcodes beschrieben sind. |
signedData |
Eine Stringverkettung mit den vom Lizenzierungsserver zurückgegebenen Daten:
responseCode|nonce|packageName|versionCode|userId|timestamp:extras
|
signature |
Die Signatur von signedData mit einem anwendungsspezifischen Schlüssel.
|
Serverantwortcodes
In Tabelle 3 sind alle Lizenzantwortcodes aufgeführt, die vom Lizenzierungsserver. Im Allgemeinen sollte eine Anwendung alle diese Antworten verarbeiten, Codes. Standardmäßig stellt die LicenseValidator-Klasse in der LVL alle wie Sie diese Antwortcodes handhaben müssen.
Antwortcode | Ganzzahlwertdarstellung | Beschreibung | Unterzeichnet? | Extras | Kommentare |
---|---|---|---|---|---|
LICENSED |
0 |
Die Anwendung ist für den Nutzer lizenziert. Der Nutzer hat die App oder autorisiert ist, die Alpha- oder Betaversion herunterzuladen und zu installieren der Anwendung. | Ja | VT , GT , GR |
Zugriff gemäß Policy -Einschränkungen zulassen. |
LICENSED_OLD_KEY |
2 |
Die Anwendung ist für den Nutzer lizenziert, aber es gibt eine aktualisierte Anwendung. Version verfügbar, die mit einem anderen Schlüssel signiert ist. | Ja | VT , GT , GR , UT |
Lassen Sie optional den Zugriff gemäß Policy -Einschränkungen zu.
Kann anzeigen, dass das vom installierten Schlüsselpaar Anwendungsversion ist ungültig oder manipuliert. Die App kann Zugriff gewähren oder den Nutzer darüber informieren, dass ein Upgrade verfügbar ist, und die weitere Nutzung einschränken. bis zur Umstellung. |
NOT_LICENSED |
1 |
Die App ist nicht für den Nutzer lizenziert. | Nein | Zugriff nicht erlauben. | |
ERROR_CONTACTING_SERVER |
257 |
Lokaler Fehler: Die Google Play App konnte nicht auf den Lizenzierungsserver, möglicherweise wegen Problemen mit der Netzwerkverfügbarkeit. | Nein | Wiederholen Sie die Lizenzprüfung gemäß den Wiederholungsbeschränkungen von Policy . |
|
ERROR_SERVER_FAILURE |
4 |
Serverfehler: Der Schlüssel der Anwendung konnte vom Server nicht geladen werden. für die Lizenzierung. | Nein | Wiederholen Sie die Lizenzprüfung gemäß den Wiederholungsbeschränkungen von Policy .
|
|
ERROR_INVALID_PACKAGE_NAME |
258 |
Lokaler Fehler: Die Anwendung hat eine Lizenzprüfung für ein Paket angefordert. der nicht auf dem Gerät installiert ist. | Nein | Wiederholen Sie die Lizenzprüfung nicht.
Wird in der Regel durch einen Entwicklungsfehler verursacht. |
|
ERROR_NON_MATCHING_UID |
259 |
Lokaler Fehler: Die Anwendung hat eine Lizenzprüfung für ein Paket angefordert. dessen UID (Paket, Nutzer-ID-Paar) nicht mit der des anfordernden . | Nein | Wiederholen Sie die Lizenzprüfung nicht.
Wird in der Regel durch einen Entwicklungsfehler verursacht. |
|
ERROR_NOT_MARKET_MANAGED |
3 |
Serverfehler: Die Anwendung (Paketname) wurde von nicht erkannt. Google Play | Nein | Wiederholen Sie die Lizenzprüfung nicht.
Kann darauf hinweisen, dass die Anwendung nicht veröffentlicht wurde über Google Play bereitgestellt werden oder dass es einen Entwicklungsfehler in der Lizenzierung gibt, Implementierung. |
Hinweis: Wie dokumentiert in Testumgebung einrichten können Sie den Antwortcode manuell für den Anwendungsentwickler und alle registrierten Testnutzer über die Google Play Console
Hinweis:Bisher konnten Sie Apps testen, indem Sie Hochladen eines unveröffentlichten "Entwurfs" Version. Diese Funktion ist nicht mehr unterstützt; müssen Sie sie als Alpha- oder Betaversion veröffentlichen, Kanal. Weitere Informationen finden Sie unter App-Entwürfe werden nicht mehr unterstützt.
Extras der Serverantwort
Um Ihre Anwendung bei der Verwaltung des Zugriffs auf die Anwendung für die Erstattung der Anwendung zu unterstützen und andere Informationen zur Verfügung stellen, enthält der Lizenzierungsserver verschiedene in den Lizenzantworten. Insbesondere bietet der Dienst empfohlene Werte für die Gültigkeitszeitraum der Lizenz der Anwendung, Kulanzzeitraum für Wiederholungsversuche, maximal zulässige Anzahl von Wiederholungen und andere Einstellungen. Wenn Ihre App APK verwendet Erweiterungsdateien enthält, enthält die Antwort auch die Dateinamen, Größen und URLs. Der Server hängt die Einstellungen als Schlüssel/Wert-Paare in der Lizenzantwort „extras“ ein.
Jede Policy
-Implementierung kann die Extras-Einstellungen aus der Lizenz extrahieren.
und verwenden Sie sie bei Bedarf. Die LVL-Standardimplementierung Policy
, ServerManagedPolicy
, dient als funktionierende
Implementierung und eine Abbildung, wie das Abrufen, Speichern und Verwenden
Einstellungen.
Extra | Beschreibung |
---|---|
VT |
Zeitstempel für die Gültigkeit der Lizenz. Gibt Datum und Uhrzeit an, zu der die aktuelle (im Cache gespeicherte) Lizenzantwort läuft ab und muss auf dem Lizenzierungsserver noch einmal überprüft werden. Weitere Informationen finden Sie im Abschnitt weiter unten zur Gültigkeitsdauer der Lizenz. |
GT |
Zeitstempel des Kulanzzeitraums. Gibt das Ende des Zeitraums an, in dem ein
Die Richtlinie lässt möglicherweise Zugriff auf die Anwendung zu, auch wenn der Antwortstatus ist
RETRY Der Wert wird vom Server verwaltet, ein typischer Wert wäre jedoch 5. oder mehr Tage. Weitere Informationen finden Sie im Abschnitt Wiederholungszeitraum und maximale Wiederholungsanzahl. |
GR |
Maximale Anzahl von Wiederholungsversuchen. Gibt an, wie viele aufeinanderfolgende RETRY -Lizenzprüfungen durchgeführt werden sollen
sollte Policy zulassen, bevor der Nutzerzugriff auf die Anwendung verweigert wird.
Der Wert wird vom Server verwaltet, ein typischer Wert wäre jedoch „10“. oder höher liegen. Weitere Informationen finden Sie im Abschnitt Wiederholungszeitraum und maximale Wiederholungsanzahl. |
UT |
Zeitstempel aktualisieren. Gibt den Tag und die Uhrzeit an, zu der die letzte Aktualisierung auf
diese Anwendung hochgeladen und veröffentlicht wurde. Der Server gibt diese zusätzliche
nur für |
FILE_URL1 oder FILE_URL2 |
Die URL für eine Erweiterungsdatei (1 ist für die Hauptdatei, 2 für die Patchdatei). Hiermit können Sie laden Sie die Datei über HTTP herunter. |
FILE_NAME1 oder FILE_NAME2 |
Der Name der Erweiterungsdatei (1 steht für die Hauptdatei, 2 für die Patchdatei). Sie müssen diese wenn Sie die Datei auf dem Gerät speichern. |
FILE_SIZE1 oder FILE_SIZE2 |
Die Größe der Datei in Byte (1 ist für die Hauptdatei, 2 für die Patchdatei). Hiermit können Sie Downloads unterstützen und dafür sorgen, dass auf dem gemeinsam genutzten Gerät genügend Speicherplatz verfügbar ist, herunterladen. |
Gültigkeitsdauer der Lizenz
Der Google Play-Lizenzierungsserver legt eine Gültigkeitsdauer für alle
heruntergeladenen Anwendungen. Die Periode drückt das Zeitintervall aus, über das ein
sollte der Lizenzstatus der Anwendung nicht geändert werden und
eine Policy
-Lizenzierung in der Anwendung. Der Lizenzierungsserver umfasst die
Gültigkeit in der Antwort auf alle Lizenzprüfungen,
Gültigkeitsende-Zeitstempel als Extraelement unter dem Schlüssel VT
an die Antwort. A
Policy
kann den Wert des VT-Schlüssels extrahieren und damit bedingt Zugriff auf Folgendes gewähren:
den Antrag ohne erneute Überprüfung der Lizenz bis zum Gültigkeitszeitraum bearbeiten.
verfällt.
Die Gültigkeit der Lizenz signalisiert einer Lizenzierung Policy
, wenn diese die
Lizenzierungsstatus mit dem Lizenzierungsserver. Dies soll nicht implizieren,
ob eine Anwendung tatsächlich für die Nutzung lizenziert ist. Das heißt, wenn ein
die Gültigkeit der Lizenz abläuft, bedeutet dies nicht,
Anwendung nicht mehr zur Nutzung lizenziert ist, sondern sie weist nur darauf hin,
Der Policy
muss den Lizenzierungsstatus noch einmal mit dem Server prüfen. Daraus folgt,
Solange die Gültigkeitsdauer der Lizenz noch nicht abgelaufen ist, ist die Lizenz
Policy
, um den anfänglichen Lizenzstatus lokal im Cache zu speichern und die im Cache gespeicherte Lizenz zurückzugeben
statt eine neue Lizenzprüfung an den Server zu senden.
Der Lizenzierungsserver verwaltet die Gültigkeitsdauer, um dem Anwendung die Lizenzierung über den von Google Play für kostenpflichtige Apps Der Gültigkeitszeitraum richtet sich nach ob die Anwendung gekauft wurde und, falls ja, wann. Genauer gesagt: legt der Server den Gültigkeitszeitraum wie folgt fest:
- Bei einer kostenpflichtigen Anwendung legt der Server die anfängliche Gültigkeitsdauer der Lizenz fest.
damit die Lizenzantwort so lange gültig bleibt, wie der Antrag
erstattungsfähig. Eine Lizenzierung
Policy
in der Anwendung kann das Element Ergebnis der ersten Lizenzprüfung und muss die Lizenz nicht noch einmal prüfen bis der Gültigkeitszeitraum abgelaufen ist. - Wenn eine Anwendung nicht mehr erstattungsfähig ist, legt einen längeren Gültigkeitszeitraum fest, der in der Regel mehrere Tage umfasst.
- Bei einer kostenlosen Anwendung legt der Server den Gültigkeitszeitraum sehr hoch fest.
Wert (
long.MAX_VALUE
) Dadurch wird sichergestellt, dass, sofernPolicy
den Gültigkeitszeitstempel lokal im Cache gespeichert hat, Lizenzstatus des Antrags in der Zukunft liegt.
Die ServerManagedPolicy
-Implementierung verwendet den extrahierten Zeitstempel
(mValidityTimestamp
) als primäre Bedingung für die Entscheidung,
den Lizenzstatus noch einmal mit dem Server zu prüfen, bevor Sie dem Nutzer Zugriff auf
der Anwendung.
Wiederholungszeitraum und maximale Anzahl von Wiederholungen
In einigen Fällen können System- oder Netzwerkbedingungen den Lizenzierungsserver nicht erreicht, oder verhindert, die Google Play-Clientanwendung erreicht. Beispiel: Der Parameter Nutzende starten eine App, wenn kein Mobilfunknetz oder keine Daten vorhanden sind. verfügbar ist, zum Beispiel im Flugzeug, Netzwerkverbindung ist instabil oder das Mobilfunksignal ist schwach.
Wenn eine Lizenzüberprüfung durch Netzwerkprobleme verhindert oder unterbrochen wird,
Der Play-Client benachrichtigt die App durch Rückgabe eines RETRY
-Antwortcodes an
Die Methode processServerResponse()
der Policy
. Bei einem System
z. B. wenn die App nicht mit dem
ILicensingService
-Implementierung ruft die LicenseChecker
-Bibliothek selbst den
Methode processServerResponse()
der Richtlinie mit einem RETRY
-Antwortcode.
Im Allgemeinen signalisiert der Antwortcode RETRY
der Anwendung, dass ein
ist ein Fehler aufgetreten, durch den die Lizenzüberprüfung nicht abgeschlossen werden konnte.
Der Google Play-Server unterstützt eine App bei der Verwaltung der Lizenzierung unter
Fehlerbedingungen durch Festlegen eines Kulanzzeitraums für den Wiederholungsversuch und ein empfohlenes Maximum
Anzahl der Wiederholungsversuche. Der Server nimmt diese Werte
in alle Antworten zur Lizenzprüfung auf,
und hängen Sie sie als Extras unter den Schlüsseln GT
und GR
an.
Die Anwendung Policy
kann die Extras GT
und GR
extrahieren und für Folgendes verwenden:
unter bestimmten Bedingungen den Zugriff auf die Anwendung zulassen:
- Für eine Lizenzprüfung, die zu einer
RETRY
-Antwort führt, solltePolicy
speichern Sie denRETRY
-Antwortcode im Cache und erhöhen Sie die Anzahl derRETRY
-Antworten. - Der
Policy
sollte es dem Nutzer ermöglichen, auf die Anwendung zuzugreifen, vorausgesetzt, Entweder ist der Kulanzzeitraum für Wiederholungsversuche noch aktiv oder die maximale Anzahl der Wiederholungen wurde nicht erreicht.
ServerManagedPolicy
verwendet die vom Server bereitgestellten Werte GT
und GR
als
beschrieben. Das folgende Beispiel zeigt die bedingte Verarbeitung der Wiederholungsversuche.
Antworten in der Methode allow()
. Die Anzahl der RETRY
Antworten beträgt
werden in der processServerResponse()
-Methode beibehalten (nicht dargestellt).
Kotlin
fun allowAccess(): Boolean { val ts = System.currentTimeMillis() return when(lastResponse) { LICENSED -> { // Check if the LICENSED response occurred within the validity timeout. ts <= validityTimestamp // Cached LICENSED response is still valid. } RETRY -> { ts < lastResponseTime + MILLIS_PER_MINUTE && // Only allow access if we are within the retry period // or we haven't used up our max retries. (ts <= retryUntil || retryCount <= maxRetries) } else -> false } }
Java
public boolean allowAccess() { long ts = System.currentTimeMillis(); if (lastResponse == LicenseResponse.LICENSED) { // Check if the LICENSED response occurred within the validity timeout. if (ts <= validityTimestamp) { // Cached LICENSED response is still valid. return true; } } else if (lastResponse == LicenseResponse.RETRY && ts < lastResponseTime + MILLIS_PER_MINUTE) { // Only allow access if we are within the retry period // or we haven't used up our max retries. return (ts <= retryUntil || retryCount <= maxRetries); } return false; }