Dokumentacja dotycząca licencjonowania

Klasy i interfejsy LVL

Tabela 1 zawiera wszystkie pliki źródłowe objęte weryfikacją licencji Biblioteka (LVL) dostępna w pakiecie SDK na Androida. Wszystkie pliki są częścią pakiet com.android.vending.licensing.

Tabela 1. Podsumowanie biblioteki LVL za pomocą klas i interfejsów.

Odpowiedź serwera

Tabela 2 zawiera listę wszystkich pól odpowiedzi dotyczących licencji zwróconych przez serwera licencjonowania.

Tabela 2. Podsumowanie pól odpowiedzi na temat licencji zwracane przez serwer Google Play.

Kody odpowiedzi serwera

Tabela 3 zawiera listę wszystkich kodów odpowiedzi dotyczących licencji obsługiwanych przez serwera licencjonowania. Ogólnie rzecz biorąc, aplikacja powinna obsługiwać wszystkie te odpowiedzi kodami. Domyślnie klasa LicenseValidator w LVL zawiera wszystkie obsługi tych kodów odpowiedzi.

Tabela 3. Podsumowanie kodów odpowiedzi zwracane przez serwer Google Play w odpowiedzi licencji.

Uwaga: jak opisano w Skonfigurowanie środowiska testowego – kod odpowiedzi można dodać ręcznie dla dewelopera aplikacji oraz wszystkich zarejestrowanych użytkowników testowych Konsola Google Play.

Uwaga: wcześniej można było testować aplikację przez przesłanie nieopublikowanej wersji roboczej, wersji. Ta funkcja nie jest już dostępna obsługiwany; musisz go opublikować w wersji alfa lub beta kanał. Więcej informacji znajdziesz w artykule Wersje robocze aplikacji nie są już obsługiwane.

Dodatki do odpowiedzi serwera

Pomoc w zarządzaniu dostępem do aplikacji w ramach zwrotu środków i dostarczanie innych informacji. Serwer licencji zawiera kilka i informacjami w odpowiedziach dotyczących licencji. W szczególności usługa podaje zalecane wartości dla atrybutu okres ważności licencji aplikacji, okres prolongaty ponawiania próby, maksymalna dozwolona liczba ponownych prób i inne ustawieniach. Jeśli aplikacja używa pliku APK rozszerzeń odpowiedź zawiera też nazwy, rozmiary i adresy URL plików. Serwer dołącza ustawienia jako pary klucz-wartość w odpowiedzi licencji „extras” .

Każda implementacja Policy może wyodrębnić ustawienia dodatków z licencji. i używać ich w razie potrzeby. Domyślna implementacja LVL Policy, ServerManagedPolicy, służy jako działająca oraz ilustrację tego, jak uzyskać, przechowywać i wykorzystywać ustawieniach.

Tabela 4. Podsumowanie ustawienia zarządzania licencjami określone przez serwer Google Play w licencji. .

Okres ważności licencji

Serwer licencjonowania Google Play ustawia okres ważności licencji dla wszystkich pobrane aplikacje. Okres określa przedział czasu, w którym stan licencji aplikacji należy uznać za niezmienny i umożliwiający jej buforowanie przez licencja Policy w aplikacji. Serwer licencjonowania zawiera okresu ważności w odpowiedzi na wszystkie kontrole licencji, z dołączonym atrybutem sygnatury czasowej końca ważności odpowiedzi, jako dodatku w kluczu VT. O Policy może wyodrębnić wartość klucza VT i użyć jej do warunkowego dostępu do aplikacji bez ponownego sprawdzania licencji, aż do okresu ich ważności wygasa.

Ważność licencji jest sygnalizowana firmie Policy licencyjnej, gdy musi ponownie sprawdzić z serwerem licencjonowania. Nie służy do sugerowania czy aplikacja rzeczywiście jest licencjonowana do użytku. Oznacza to, że gdy ważność licencji na aplikację wygasa, nie oznacza to, że aplikacji nie ma już licencji do użytku – wskazuje tylko, że Policy musi ponownie sprawdzić stan licencji na serwerze. Z tego wynika, (o ile okres ważności licencji jeszcze nie upłynął, można Policy, aby zapisać początkowy stan licencji lokalnie i zwrócić licencję w pamięci podręcznej. zamiast wysyłać do serwera nowe sprawdzenie licencji.

Serwer licencjonowania zarządza okresem ważności, pomagając prawidłowe egzekwowanie licencji przez okres zwrotu środków oferowany przez Google Play dla płatnych aplikacji. Ustawia okres ważności na podstawie czy aplikacja została kupiona, a jeśli tak, to ile lat temu; Konkretnie: serwer ustawia taki okres ważności:

• W przypadku płatnej aplikacji serwer ustawia początkowy okres ważności licencji. aby odpowiedź dotycząca licencji była ważna tak długo, jak aplikacja podlega zwrotowi. Licencjonowany zasób Policy w aplikacji może buforować nie trzeba ponownie sprawdzać licencji. aż do upłynięcia okresu ważności.
• Gdy aplikacja nie podlega już zwrotowi środków, serwer ustawia dłuższy okres ważności – zwykle kilka dni.
• Dla bezpłatnej aplikacji serwer ustawia bardzo wysoki okres ważności (long.MAX_VALUE). Dzięki temu, jeśli Policy ma lokalnej sygnatury czasowej poprawności, nie trzeba jej ponownie sprawdzać stanu licencji aplikacji w przyszłości.

Implementacja ServerManagedPolicy używa wyodrębnionej sygnatury czasowej (mValidityTimestamp) jako głównego warunku określającego, czy , aby ponownie sprawdzić stan licencji na serwerze przed zezwoleniem użytkownikowi na dostęp do aplikacji.

Okres ponawiania i maksymalna liczba ponownych prób

W niektórych przypadkach warunki systemu lub sieci mogą uniemożliwić aplikacji przed uzyskaniem dostępu do serwera licencjonowania lub uniemożliwienie odpowiedź przed dotarciem do aplikacji klienckiej Google Play. Na przykład parametr użytkownik może uruchomić aplikację, gdy nie ma sieci komórkowej lub transmisji danych np. w samolocie lub gdy połączenie sieciowe jest niestabilne lub sygnał komórkowy jest słaby.

Jeśli problemy z siecią uniemożliwiają lub przerywają sprawdzanie licencji, Google Klient Play powiadamia aplikację, zwracając kod odpowiedzi RETRY do metody processServerResponse() operatora Policy. W przypadku systemu na przykład wtedy, gdy aplikacja nie jest w stanie powiązać z implementacji ILicensingService, biblioteka LicenseChecker wywołuje funkcję Metoda processServerResponse() z kodem odpowiedzi RETRY.

Ogólnie kod odpowiedzi RETRY informuje aplikację, że wystąpił błąd uniemożliwiający ukończenie sprawdzania licencji.

Serwer Google Play pomaga aplikacji w zarządzaniu licencjami warunki błędu przez ustawienie „okresu prolongaty” ponowienia próby i zalecaną maksymalną ponownych prób. serwer uwzględnia te wartości we wszystkich odpowiedziach na sprawdzanie licencji, Dołączam je jako dodatki w kluczach GT i GR.

Aplikacja Policy może wyodrębnić dodatki GT oraz GR i użyć ich do warunkowo zezwól na dostęp do aplikacji w ten sposób:

• W przypadku sprawdzenia licencji, które skutkuje odpowiedzią RETRY, Policy powinien zapisywać w pamięci podręcznej kod odpowiedzi RETRY i zwiększać liczbę odpowiedzi do RETRY.
• Obiekt Policy powinien zezwalać użytkownikowi na dostęp do aplikacji, pod warunkiem że: okres prolongaty ponawiania prób jest nadal aktywny albo została osiągnięta maksymalna liczba ponownych prób nie skontaktowaliśmy się z.

ServerManagedPolicy wykorzystuje dostarczone przez serwer wartości GT i GR jako opisane powyżej. Przykład poniżej pokazuje obsługę warunkową ponawiania w metodzie allow(). Liczba odpowiedzi RETRY to są przechowywane w metodzie processServerResponse(), a nie wyświetlane.

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
    }
}

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;
}