लाइसेंस का रेफ़रंस

LVL क्लास और इंटरफ़ेस

पहली टेबल में, लाइसेंस की पुष्टि से जुड़ी सभी सोर्स फ़ाइलों की सूची दी गई है Android SDK के ज़रिए उपलब्ध लाइब्रेरी (LVL). सभी फ़ाइलें इसका हिस्सा हैं com.android.vending.licensing पैकेज.

टेबल 1. LVL लाइब्रेरी के बारे में खास जानकारी क्लास और इंटरफ़ेस.

सर्वर से जवाब

दूसरी टेबल में, लाइसेंस के रिस्पॉन्स फ़ील्ड के तौर पर लौटाए गए सभी लाइसेंस देने वाला सर्वर.

दूसरी टेबल. लाइसेंस के रिस्पॉन्स फ़ील्ड की खास जानकारी Google Play सर्वर से मिला.

सर्वर रिस्पॉन्स कोड

टेबल 3 में, उन सभी लाइसेंस रिस्पॉन्स कोड की सूची दी गई है जिनका इस्तेमाल लाइसेंस देने वाला सर्वर. आम तौर पर, ऐप्लिकेशन को इन सभी रिस्पॉन्स को हैंडल करना चाहिए कोड. डिफ़ॉल्ट रूप से, LVL की LicenseValidator क्लास डिफ़ॉल्ट रूप से वे सभी सुविधाएं देती है इन रिस्पॉन्स कोड को मैनेज करना ज़रूरी है.

तीसरी टेबल. रिस्पॉन्स कोड के बारे में खास जानकारी Google Play सर्वर से, लाइसेंस रिस्पॉन्स के तौर पर मिला.

ध्यान दें: जैसा कि में बताया गया है टेस्टिंग एनवायरमेंट सेट अप करना, रिस्पॉन्स कोड को मैन्युअल तरीके से सेट अप किया जा सकता है ऐप्लिकेशन डेवलपर और Google Play Console पर जाएं.

ध्यान दें: पहले, ऐप्लिकेशन की जांच के लिए अप्रकाशित "ड्राफ़्ट" अपलोड करना वर्शन है. यह सुविधा अब काम नहीं करती समर्थित; इसके बजाय, आपको इसे ऐल्फ़ा या बीटा डिस्ट्रिब्यूशन पर पब्लिश करना होगा चैनल. ज़्यादा जानकारी के लिए, ड्राफ़्ट ऐप्लिकेशन' देखें अब काम नहीं करते हैं.

सर्वर रिस्पॉन्स अतिरिक्त

ऐप्लिकेशन के रिफ़ंड में, ऐप्लिकेशन का ऐक्सेस मैनेज करने में आपके ऐप्लिकेशन की मदद करने के लिए अवधि और अन्य जानकारी प्रदान करते हैं, तो लाइसेंसिंग सर्वर में में जानकारी शामिल होती है. यह सेवा खास तौर पर, ऐप्लिकेशन के लाइसेंस की वैधता अवधि, फिर से कोशिश करने की मोहलत, फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या, और अन्य सेटिंग. यदि आपका ऐप्लिकेशन APK का उपयोग करता है एक्सपैंशन फ़ाइलें अपलोड करते हैं, तो रिस्पॉन्स में फ़ाइल के नाम, साइज़, और यूआरएल भी शामिल होते हैं. सर्वर जुड़ जाता है लाइसेंस रिस्पॉन्स "अतिरिक्त" में, की-वैल्यू पेयर के तौर पर सेटिंग फ़ील्ड में डालें.

Policy को लागू करने पर, लाइसेंस से अतिरिक्त सेटिंग एक्सट्रैक्ट की जा सकती हैं और उनकी ज़रूरत के हिसाब से उनका इस्तेमाल करें. एलवीएल के डिफ़ॉल्ट Policy लागू करने के तरीके, ServerManagedPolicy का इस्तेमाल लागू करने के बारे में बताया गया है. साथ ही, इस बात की भी जानकारी दी गई है कि सेटिंग.

टेबल 4. इसका सारांश लाइसेंस को मैनेज करने की वे सेटिंग जो Google Play सर्वर से लाइसेंस के लिए मिलती हैं जवाब.

लाइसेंस के मान्य रहने की अवधि

Google Play लाइसेंस देने वाला सर्वर सभी के लिए लाइसेंस की वैधता अवधि सेट करता है ऐप्लिकेशन को डाउनलोड करने के लिए किया जा सकता है. यह समयावधि उस समय के अंतराल को दिखाती है जिसमें आवेदन के लाइसेंस की स्थिति को ऐप्लिकेशन में, लाइसेंसिंग Policy. लाइसेंस देने वाले सर्वर में सभी लाइसेंस जांचों के जवाब में वैध रहने की अवधि के साथ-साथ, VT कुंजी के नीचे, जवाब के खत्म होने की पुष्टि का टाइमस्टैंप, अतिरिक्त के तौर पर. ऐप्लिकेशन Policy, वीटी कुंजी की वैल्यू को एक्सट्रैक्ट कर सकता है. साथ ही, इसका इस्तेमाल कुछ शर्तों के साथ लाइसेंस की फिर से जांच किए बिना ऐप्लिकेशन, जब तक कि समयसीमा खत्म नहीं हो जाती समय-सीमा खत्म.

लाइसेंस की वैधता Policy को तब भेजी जाती है, जब उसे दोबारा जांच करनी होती है लाइसेंस देने की स्थिति के बारे में भी बताएंगे. इसका मकसद यह नहीं बताना है कि कि ऐप्लिकेशन इस्तेमाल करने का लाइसेंस वाकई में है या नहीं. इसका मतलब है कि जब ऐप्लिकेशन की लाइसेंस की समयसीमा खत्म हो जाती है, इसका यह मतलब नहीं कि ऐप्लिकेशन अब उपयोग के लिए लाइसेंसीकृत नहीं है — बल्कि, यह केवल यह बताता है कि Policy को सर्वर पर लाइसेंस की स्थिति की फिर से जांच करनी होगी. इसके तहत, अगर लाइसेंस की वैधता की अवधि खत्म नहीं हुई है, तो स्थानीय तौर पर लाइसेंस की शुरुआती स्थिति को कैश मेमोरी में सेव करने और कैश मेमोरी में सेव किए गए लाइसेंस को लौटाने के लिए Policy स्टेटस का इस्तेमाल करें.

लाइसेंस देने वाला सर्वर, समयसीमा की अवधि को ऐप्लिकेशन के ज़रिए ऑफ़र की गई रिफ़ंड अवधि के दौरान लाइसेंसिंग की प्रक्रिया सही तरह से लागू हो पैसे चुकाकर डाउनलोड किए जाने वाले ऐप्लिकेशन के लिए Google Play. यह इन बातों के आधार पर पुष्टि की अवधि सेट करता है ऐप्लिकेशन खरीदा गया था या नहीं और अगर हां, तो कितनी देर पहले खरीदा था. खास तौर पर, सर्वर, मान्य रहने की अवधि को इस तरह सेट करता है:

• पैसे देकर इस्तेमाल किए जाने वाले ऐप्लिकेशन के लिए, सर्वर, लाइसेंस की शुरुआती समयसीमा सेट करता है ताकि लाइसेंस रिस्पॉन्स तब तक मान्य रहे, जब तक आवेदन रिफ़ंड किया जा सकता है. ऐप्लिकेशन में Policy का लाइसेंस देने से, लाइसेंस की जांच के नतीजे दिखते हैं. इस वजह से, लाइसेंस की दोबारा जांच करने की ज़रूरत नहीं पड़ती जब तक कि इसकी समयसीमा खत्म न हो जाए.
• जब किसी ऐप्लिकेशन को वापस नहीं किया जा सकता, तो सर्वर लंबी वैधता अवधि सेट करता है. आम तौर पर, यह अवधि कुछ दिनों की होती है.
• मुफ़्त ऐप्लिकेशन के लिए, सर्वर वैधता अवधि को बहुत ज़्यादा पर सेट करता है मान (long.MAX_VALUE). इससे यह पक्का होता है कि, बशर्ते Policy के पास मान्यता के टाइमस्टैंप को स्थानीय तौर पर कैश मेमोरी में सेव किया जाता है, तो इसे लाइसेंस की स्थिति.

ServerManagedPolicy को लागू करने के लिए, एक्सट्रैक्ट किए गए टाइमस्टैंप का इस्तेमाल किया जाता है (mValidityTimestamp) यह तय करने के लिए पहली शर्त के रूप में उपयोगकर्ता को ऐप्लिकेशन खोलें.

फिर से कोशिश करने की अवधि और फिर से कोशिश करने की ज़्यादा से ज़्यादा संख्या

कुछ मामलों में, सिस्टम या नेटवर्क की शर्तें ऐप्लिकेशन की लाइसेंस की जांच को लाइसेंस देने वाले सर्वर तक पहुंचने से रोक सकते हैं, या Google Play क्लाइंट ऐप्लिकेशन तक पहुंचने से मिला जवाब. उदाहरण के लिए, सेल नेटवर्क या डेटा न होने पर, उपयोगकर्ता किसी ऐप्लिकेशन को लॉन्च कर सकता है कनेक्शन उपलब्ध हो—जैसे जब हवाई जहाज़ में हो—या जब इंटरनेट ठीक से काम नहीं कर रहा है या सेल सिग्नल कमज़ोर है.

जब नेटवर्क समस्याएं लाइसेंस की जांच को रोकती हैं या उसमें रुकावट डालती हैं, तो Google Play क्लाइंट, इस नंबर पर RETRY रिस्पॉन्स कोड लौटाकर ऐप्लिकेशन को इसकी सूचना देता है Policy का processServerResponse() तरीका. सिस्टम के मामले में समस्याएं, जैसे जब ऐप्लिकेशन Google Play के ILicensingService लागू करने पर, LicenseChecker लाइब्रेरी RETRY रिस्पॉन्स कोड के साथ नीति से जुड़ा processServerResponse() तरीका.

आम तौर पर, RETRY रिस्पॉन्स कोड ऐप्लिकेशन को यह सिग्नल देता है कि गड़बड़ी हुई है, जिसकी वजह से लाइसेंस की जाँच पूरी नहीं हो पाई.

Google Play सर्वर, ऐप्लिकेशन को इसके तहत लाइसेंस मैनेज करने में मदद करता है "ग्रेस पीरियड" को फिर से सेट करने की कोशिश करें और एक सुझाई गई सीमा एक से ज़्यादा बार कितनी बार कोशिश की गई. सर्वर इन वैल्यू को, लाइसेंस की जांच के सभी रिस्पॉन्स में शामिल करता है, उन्हें GT और GR कुंजियों में अतिरिक्त के तौर पर जोड़कर.

Policy ऐप्लिकेशन, GT और GR अतिरिक्त चीज़ों को एक्सट्रैक्ट कर सकता है और उनका इस्तेमाल इन कामों के लिए कर सकता है कुछ शर्तों के साथ ऐप्लिकेशन को ऐक्सेस करने की अनुमति देने के लिए, यहां दिया गया तरीका अपनाएं:

• लाइसेंस की जांच के नतीजे के तौर पर RETRY से जवाब मिलता है. इस जांच के लिए, Policy को यह करना चाहिए RETRY रिस्पॉन्स कोड को कैश मेमोरी में सेव करें और RETRY रिस्पॉन्स की संख्या बढ़ाएं.
• Policy से उपयोगकर्ता को ऐप्लिकेशन ऐक्सेस करने की अनुमति मिलनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि या तो फिर से कोशिश करने की मोहलत अब भी चालू है या फिर से बार-बार कोशिश करने की ज़्यादा से ज़्यादा संख्या है अभी तक नहीं पहुंचा है.

ServerManagedPolicy, सर्वर से मिली GT और GR वैल्यू का इस्तेमाल इस तरह करता है ऊपर बताया गया है. नीचे दिए गए उदाहरण में, शर्तों के साथ फिर से कोशिश करने के तरीके को दिखाया गया है allow() तरीके में रिस्पॉन्स. RETRY जवाबों की संख्या है processServerResponse() विधि में बनाए रखा गया है, नहीं दिखाया गया है.

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