अपने ऐप्लिकेशन में क्लाइंट-साइड लाइसेंस की पुष्टि करने की सुविधा जोड़ना

चेतावनी: जब आपका ऐप्लिकेशन, लाइसेंस की पुष्टि करता है तो संभावित हमलावरों के लिए बदलाव करना या हटाना आसान होता है पुष्टि करने की इस प्रक्रिया से जुड़ा लॉजिक.

इस वजह से, हम खास तौर पर आपको इसके लिए सुझाव देते हैं सर्वर-साइड की परफ़ॉर्मेंस लाइसेंस की पुष्टि करने की ज़रूरत नहीं होगी.

प्रकाशक खाता और डेवलपमेंट एनवायरमेंट (लाइसेंस देने के लिए सेट अप करना देखें) सेट अप करने के बाद, आप इसके लिए लाइसेंस की पुष्टि करने की सुविधा को जोड़ने के लिए तैयार हैं: लाइसेंस वेरिफ़िकेशन लाइब्रेरी (LVL) के साथ आपका ऐप्लिकेशन डाउनलोड करना.

एलवीएल में लाइसेंस की पुष्टि करने की सुविधा जोड़ने पर, ये काम किए जा सकते हैं:

  1. अपने ऐप्लिकेशन के मेनिफ़ेस्ट में, लाइसेंस देने की अनुमति जोड़ना.
  2. नीति लागू करना — एलवीएल में दिए गए सभी तरीकों में से कोई एक चुनें या अपनी ज़रूरत के हिसाब से कोई नीति बनाएं.
  3. obfuscator को लागू करना, अगर आपका Policy किसी भी चीज़ को कैश मेमोरी में सेव करेगा लाइसेंस रिस्पॉन्स डेटा.
  4. अपने ऐप्लिकेशन के मुख्य ऐप्लिकेशन में, लाइसेंस की जांच करने के लिए कोड जोड़ना गतिविधि.
  5. DeviceLimiter लागू करना (ज़रूरी नहीं है. साथ ही, इसके इस्तेमाल का सुझाव नहीं दिया जाता है) ज़्यादातर ऐप्लिकेशन).

इन सेक्शन में इन टास्क के बारे में बताया गया है. काम पूरा हो जाने के बाद: तो आप अपने ऐप्लिकेशन को सफलतापूर्वक कंपाइल कर सकते हैं और टेस्ट शुरू कर सकता है, जैसा कि टेस्ट सेट अप करना एनवायरमेंट.

एलवीएल में शामिल सोर्स फ़ाइलों के पूरे सेट की खास जानकारी के लिए, एलवीएल क्लास की खास जानकारी देखें और इंटरफ़ेस में उपलब्ध हैं.

लाइसेंस देने की अनुमति जोड़ना

Google Play ऐप्लिकेशन का इस्तेमाल करके, सर्वर के लिए, आपके ऐप्लिकेशन को उचित अनुमति का अनुरोध करना होगा, com.android.vending.CHECK_LICENSE. अगर आपका ऐप्लिकेशन लाइसेंस देने की अनुमति के बारे में जानकारी नहीं देता है, लेकिन लाइसेंस की जांच करने की कोशिश करता है, LVL सुरक्षा में एक अपवाद देता है.

अपने ऐप्लिकेशन में लाइसेंस की अनुमति का अनुरोध करने के लिए, <uses-permission> का एलान करें एलिमेंट, <manifest> के चाइल्ड के रूप में इस प्रकार है:

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

उदाहरण के लिए, यहां बताया गया है कि LVL सैंपल ऐप्लिकेशन किस तरह अनुमति का एलान करता है: 

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

ध्यान दें: फ़िलहाल, आप CHECK_LICENSE अनुमति के साथ-साथ, क्योंकि SDK टूल के टूल इसे डिपेंडेंट के मेनिफ़ेस्ट में मर्ज नहीं करेंगे का इस्तेमाल करें. इसके बजाय, आपको हर डिपेंडेंट ऐप्लिकेशन के मेनिफ़ेस्ट में बताया जा सकता है.

नीति लागू करना

Google Play लाइसेंस देने वाली सेवा खुद यह तय नहीं करती कि जिस उपयोगकर्ता को लाइसेंस दिया गया है उसे आपके ऐप्लिकेशन का ऐक्सेस मिलना चाहिए. इसके बजाय, यह ज़िम्मेदारी आपकी ओर से उपलब्ध कराए गए Policy को लागू करने की होती है आपके आवेदन में.

नीति एक ऐसा इंटरफ़ेस है जिसका एलान एलवीएल ने किया है. इसे आपके नतीजे के आधार पर, उपयोगकर्ता को ऐक्सेस देने या न देने के लिए ऐप्लिकेशन का लॉजिक लाइसेंस की जांच की जाती है. LVL का इस्तेमाल करने के लिए, आपके ऐप्लिकेशन को Policy को लागू करना.

Policy इंटरफ़ेस में दो तरीकों का एलान किया गया है: allowAccess() और processServerResponse(), जिसे LicenseChecker कॉल करता है उदाहरण के लिए, जब लाइसेंस सर्वर से रिस्पॉन्स को प्रोसेस किया जाता हो. इसमें यह भी बताया गया है कि LicenseResponse नाम की enum की वैल्यू, जिसमें लाइसेंस के रिस्पॉन्स के बारे में बताया गया है processServerResponse() को कॉल में पास किया गया मान.

  • processServerResponse() की मदद से, रॉ जवाब को पहले से प्रोसेस किया जा सकता है यह तय करने से पहले कि ऐक्सेस दें.

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

    रिस्पॉन्स डेटा को स्थानीय तौर पर सेव करते समय, Policy को यह पक्का करना होगा कि डेटा उलझाने वाला (obfuscator लागू करना, नीचे दिया गया है).

  • allowAccess() तय करता है कि उपयोगकर्ता को इनका ऐक्सेस दिया जाए या नहीं किसी भी उपलब्ध लाइसेंस प्रतिक्रिया डेटा ( लाइसेंस देने वाले सर्वर या कैश मेमोरी से) या ऐप्लिकेशन से जुड़ी अन्य जानकारी शामिल होती है. इसके लिए उदाहरण के लिए, allowAccess() को लागू करने पर खाते के अन्य मानदंड, जैसे कि किसी बैकएंड सर्वर. सभी मामलों में, allowAccess() को लागू करने पर true को केवल तभी लौटाना चाहिए जब उपयोगकर्ता के पास इसका उपयोग करने का लाइसेंस हो आवेदन, जैसा कि लाइसेंस देने वाला सर्वर तय करता है या अगर कोई अस्थायी सेवा उपलब्ध है नेटवर्क या सिस्टम की समस्या, जो लाइसेंस की जांच को पूरा होने से रोकती है. तय सीमा में ऐसे मामलों में, आपके लागू करने पर फिर से कोशिश करने के रिस्पॉन्स की संख्या बरकरार रह सकती है और अस्थायी रूप से ऐक्सेस की अनुमति देंगे. हालांकि, ऐसा तब तक होगा, जब तक लाइसेंस की अगली जांच पूरी नहीं हो जाती.

अपने ऐप्लिकेशन में लाइसेंस जोड़ने की प्रोसेस को आसान बनाने के लिए और यह बताएं कि Policy को कैसे डिज़ाइन किया जाना चाहिए. एलवीएल में ये शामिल हैं Policy को लागू करने के दो पूरे तरीके हैं, जिन्हें बिना बदलाव के इस्तेमाल किया जा सकता है या आपकी ज़रूरतों के हिसाब से:

  • ServerManagedPolicy, एक सुविधाजनक Policy जो सर्वर से मिलने वाली सेटिंग और कैश मेमोरी में सेव किए गए रिस्पॉन्स का इस्तेमाल करके, आपके सभी खातों के ऐक्सेस को मैनेज करता है नेटवर्क की अलग-अलग स्थितियां, और
  • StrictPolicy, जो किसी जवाब को कैश मेमोरी में सेव नहीं करता डेटा उपलब्ध कराता है और केवल तब ही ऐक्सेस करने देता है, जब सर्वर लाइसेंस वाला जवाब.

ज़्यादातर ऐप्लिकेशन के लिए, ServerManagedPolicy का बहुत ज़्यादा इस्तेमाल किया जाता है सुझाया गया. Server ManagedPolicy LVL की डिफ़ॉल्ट सेटिंग है और इसके साथ इंटिग्रेट किया गया है LVL सैंपल ऐप्लिकेशन पर भी जा सकते हैं.

पसंद के मुताबिक बनाई गई नीतियों के लिए दिशा-निर्देश

लाइसेंस लागू करते समय, पूरी नीतियों में से किसी एक का इस्तेमाल किया जा सकता है उपलब्ध कराया जाएगा या आप एक कस्टम नीति बनाएं. किसी भी प्रकार की कस्टम नीति के लिए, कई महत्वपूर्ण डिज़ाइन इन बातों को समझना और लागू करने के लिए उन्हें ध्यान में रखना चाहिए.

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

अगर अपने हिसाब से कोई नीति बनाई जा रही है, तो हमारा सुझाव है कि Policy:

  1. सबसे हाल के सफल लाइसेंस रिस्पॉन्स को कैश (और अच्छी तरह से उलझाने वाले) में ज़्यादा स्टोरेज मिलता है.
  2. सभी लाइसेंस की जांच के लिए, कैश मेमोरी में सेव किया गया रिस्पॉन्स भेजता है. ऐसा तब तक के लिए किया जाता है, जब तक कैश मेमोरी में सेव किया गया रिस्पॉन्स मान्य होता है. इससे लाइसेंस देने वाले सर्वर से अनुरोध नहीं किया जाता. सर्वर से मिले VT के हिसाब से रिस्पॉन्स की वैधता सेट करना अतिरिक्त का सुझाव दिया जाता है. सर्वर रिस्पॉन्स एक्स्ट्रा देखें हमारा वीडियो देखें.
  3. अगर किसी नतीजे के लिए फिर से कोशिश की जाती है, तो एक्सपोनेन्शियल बैकऑफ़ पीरियड का इस्तेमाल किया जाता है गड़बड़ियां हैं. ध्यान दें कि Google Play क्लाइंट की अपने-आप दोबारा कोशिश नहीं हो सकी इसलिए, ज़्यादातर मामलों में Policy को फिर से अनुरोध करने की ज़रूरत नहीं होती.
  4. "ग्रेस पीरियड" देता है जिससे उपयोगकर्ता आपकी सीमित समय या इस्तेमाल के लिए आवेदन फ़ॉर्म भरने के दौरान, जब तक लाइसेंस की जाँच की जा रही हो दोबारा कोशिश की. ग्रेस पीरियड की मदद से लोगों को अगले सीज़न तक ऐक्सेस दिया जा सकता है लाइसेंस की जाँच पूरी की जा सकती है. साथ ही, इससे आपको अपने कारोबार के लिए कोई मान्य लाइसेंस प्रतिक्रिया न होने पर आपके आवेदन की पहुंच के लिए हार्ड सीमा उपलब्ध हैं.

अपने Policy को ऊपर दिए गए दिशा-निर्देशों के हिसाब से डिज़ाइन करना बहुत ज़रूरी है, क्योंकि यह आपको उन उपयोगकर्ताओं के लिए सर्वोत्तम अनुभव प्रदान करता है, जो आपके ऐप्लिकेशन पर गड़बड़ी की स्थितियों में भी असरदार कंट्रोल.

ध्यान दें कि कोई भी Policy, लाइसेंस देने वाले सर्वर की सेटिंग का इस्तेमाल इन कामों के लिए कर सकता है वैधता और कैश मेमोरी को मैनेज करने, ग्रेस पीरियड के लिए फिर से कोशिश करने जैसे कई दूसरे काम किए जा सकते हैं. एक्सट्रैक्ट करना सर्वर से मिलने वाली सेटिंग आसान होती हैं और उनका बहुत ज़्यादा इस्तेमाल किया जाता है सुझाया गया. सर्वर मैनेज करने से जुड़ी नीति लागू करने का उदाहरण देखें. यहां आपको पता चलेगा कि में से एक को शामिल करना शुरू करें और उसका इस्तेमाल करें. सर्वर सेटिंग की सूची और उनका उपयोग कैसे करें, सर्वर रिस्पॉन्स देखें अतिरिक्त कॉन्टेंट.

सर्वर प्रबंधित नीति

एलवीएल में, Policy को पूरी तरह से लागू करने का सुझाव दिया जाता है ServerManagePolicy नाम का एक इंटरफ़ेस है. लागू करने की प्रक्रिया LVL क्लास और लाइब्रेरी में डिफ़ॉल्ट Policy के तौर पर काम करती है.

ServerManagedPolicy लाइसेंस के लिए सभी हैंडलिंग उपलब्ध कराता है और फिर से कोशिश करें जवाब. यह सभी रिस्पॉन्स डेटा को स्थानीय तौर पर कैश मेमोरी में सेव करता है SharedPreferences फ़ाइल है, जिसे ऐप्लिकेशन को Obfuscator लागू करना. इससे यह पक्का होता है कि डेटा सुरक्षित रहता है और डिवाइस के पावर साइकल के दौरान बना रहता है. सर्वर प्रबंधित नीति इंटरफ़ेस विधियों को ठोस तौर पर लागू किया जाता है processServerResponse() और allowAccess() के साथ ही इसमें लाइसेंस को मैनेज करने के लिए उपलब्ध तरीकों और टाइप का एक सेट शामिल है जवाब.

सर्वर प्रबंधन नीति की एक मुख्य सुविधा यह है कि पूरे संगठन में लाइसेंस को मैनेज करने के आधार के रूप में, सर्वर से मिलने वाली सेटिंग और अलग-अलग नेटवर्क और गड़बड़ी की शर्तों के हिसाब से हो. जब कोई ऐप्लिकेशन लाइसेंस की जांच के लिए Google Play सर्वर से संपर्क करता है, तो सर्वर कुछ सेटिंग के कुछ के अतिरिक्त फ़ील्ड में की-वैल्यू पेयर के तौर पर कई सेटिंग जोड़ता है लाइसेंस रिस्पॉन्स टाइप. उदाहरण के लिए, सर्वर ऐप्लिकेशन के लाइसेंस की मान्यता की अवधि, फिर से कोशिश करें और अनुमति की ज़्यादा से ज़्यादा अवधि अन्य विकल्पों के अलावा, फिर से कोशिश करने की संख्या. ServerManagedPolicy से मान एक्सट्रैक्ट करता है इसके processServerResponse() तरीके और जांच में लाइसेंस रिस्पॉन्स उन्हें अपनी allowAccess() तरीके से जोड़ सकते हैं. सर्वर से मिलने वाली सूची की सूची के लिए ServerManagedPolicy में इस्तेमाल की गई सेटिंग के लिए, सर्वर रिस्पॉन्स देखें अतिरिक्त कॉन्टेंट.

सुविधा, सबसे अच्छी परफ़ॉर्मेंस, और लाइसेंस की सेटिंग इस्तेमाल करने से मिलने वाले फ़ायदों के लिए Google Play सर्वर से, ServerManagedPolicy का इस्तेमाल करके हमारा सुझाव है कि Policy का लाइसेंस दें.

यदि आप लाइसेंस प्रतिक्रिया डेटा की सुरक्षा के बारे में चिंतित हैं SharedPreferences में लोकल स्टोरेज में सेव किया गया है, तो कोड को और भी ज़्यादा या ऐसा ज़्यादा सख्त Policy डिज़ाइन कर सकते हैं जिसमें लाइसेंस का डेटा सेव नहीं होता. द एलवीएल इस तरह के Policy का उदाहरण शामिल है — ज़्यादा जानकारी के लिए StrictPolicy पर जाएं.

ServerManagePolicy का इस्तेमाल करने के लिए, बस इसे अपनी गतिविधि में इंपोर्ट करें. इसके बाद, और अपनी LicenseChecker. देखें लाइसेंस-चेकर झटपट तैयार करें और ज़्यादा जानकारी के लिए, LicenseCheckerCallback.

सख्त नीति

LVL में Policy इंटरफ़ेस को पूरी तरह से लागू करने का एक वैकल्पिक तरीका शामिल है जिसे StrictPolicy कहा जाता है. StrongPolicy को लागू करने पर, ज़्यादा पाबंदी लगाई जाती है Server ManagedPolicy की नीति के तहत की गई नीति, जिसमें उपयोगकर्ता को ऐक्सेस करने की अनुमति नहीं है तब तक आवेदन फ़ॉर्म, जब तक कि ऐक्सेस का समय बताता है कि उपयोगकर्ता के पास लाइसेंस है.

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

  • लाइसेंस देने वाले सर्वर से, लाइसेंस रिस्पॉन्स लिया जाता है और
  • लाइसेंस रिस्पॉन्स से पता चलता है कि उपयोगकर्ता के पास का इस्तेमाल करें.

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

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

कुल मिलाकर, यह नीति उपयोगकर्ता को मिलने वाली सुविधा का कुछ हिस्सा दिखाती है के लिए, पूरी सुरक्षा और ऐक्सेस पर कंट्रोल किया जा सकता है. कीमत में बदलाव करने के बारे में सोच-समझकर फ़ैसला लें इस Policy का इस्तेमाल करने से पहले.

StrictPolicy का इस्तेमाल करने के लिए, बस इसे अपनी गतिविधि में इंपोर्ट करें, एक इंस्टेंस बनाएं, और अपना LicenseChecker बनाते समय इसका एक रेफ़रंस पास करें. यहां जाएं: लाइसेंस-चेकर और LicenseCheckerCallback झटपट करना हमारा वीडियो देखें.

आम तौर पर, Policy लागू करने पर, लाइसेंस रिस्पॉन्स डेटा सेव करना पड़ता है स्थायी स्टोर के लिए एक ऐप्लिकेशन, ताकि इसे सभी प्लैटफ़ॉर्म पर ऐक्सेस किया जा सके ऐप्लिकेशन को शुरू करने और डिवाइस के पावर साइकल पर निर्भर करता है. उदाहरण के लिए, Policy आखिरी बार सफल लाइसेंस की जांच का टाइमस्टैंप, फिर से कोशिश की संख्या बनाए रखें, लाइसेंस की वैधता की अवधि और ऐसी ही अन्य जानकारी किसी स्थायी स्टोर में मौजूद होती है, का उपयोग करें. कॉन्टेंट बनाने डिफ़ॉल्ट Policy, LVL, ServerManagedPolicy में शामिल है, लाइसेंस के रिस्पॉन्स को सेव करता है SharedPreferences इंस्टेंस में डेटा इकट्ठा करता है, ताकि यह पक्का किया जा सके कि डेटा स्थायी बना रहता है.

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

LVL, ऐप्लिकेशन के लाइसेंस रिस्पॉन्स डेटा को और हमेशा सुरक्षित रखा जाए. सबसे पहले, यह Obfuscator इंटरफ़ेस जो आपके ऐप्लिकेशन को उसके अस्पष्ट बनाने वाला एल्गोरिदम सेव किए गए डेटा के लिए विकल्प. इसी आधार पर एलवीएल, हेल्पर क्लास को उपलब्ध कराता है PreferenceObfuscator, जो ऐप्लिकेशन की Obfuscator क्लास और उलझाने वाले डेटा को SharedPreferences इंस्टेंस.

LVL, Obfuscator को लागू करने की पूरी प्रोसेस उपलब्ध कराता है. ऐसा AESObfuscator, जो डेटा को अस्पष्ट बनाने के लिए AES एन्क्रिप्शन का इस्तेमाल करता है. आप अपने ऐप्लिकेशन में बिना बदलाव के AESObfuscator का इस्तेमाल करें या फिर इसे आपकी ज़रूरतों के हिसाब से बदल सकते हैं. अगर आप Policy (जैसे ServerManagedPolicy) तय करना, जो AESObfuscator का इस्तेमाल आपको Obfuscator को लागू करने का आधार चुनने का सुझाव दिया जाता है. ज़्यादा जानकारी के लिए, अगला सेक्शन देखें.

एईएसओबीफ़ुस्केटर

एलवीएल में, Obfuscator को पूरी तरह से लागू करने का सुझाव दिया जाता है AESObfuscator नाम का इंटरफ़ेस लागू करने की प्रक्रिया LVL सैंपल ऐप्लिकेशन का इस्तेमाल करता है और लाइब्रेरी में डिफ़ॉल्ट Obfuscator के तौर पर काम करता है.

AESObfuscator, एईएस का इस्तेमाल करके, डेटा को सुरक्षित तरीके से अस्पष्ट बनाने के लिए डेटा को वैसे ही एन्क्रिप्ट और डिक्रिप्ट कर सकता है जैसा कि उसे स्टोरेज में लिखा गया है या पढ़ा गया है. Obfuscator, दिए गए तीन डेटा फ़ील्ड का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करता है ऐप्लिकेशन के हिसाब से:

  1. सॉल्ट — हर डेटा को अस्पष्ट बनाने के लिए, रैंडम बाइट का कलेक्शन.
  2. ऐप्लिकेशन आइडेंटिफ़ायर स्ट्रिंग, आम तौर पर ऐप्लिकेशन के पैकेज का नाम.
  3. डिवाइस आइडेंटिफ़ायर स्ट्रिंग, जो डिवाइस के हिसाब से अलग-अलग सोर्स से मिलती है ताकि उसे खास बनाया जा सके.

AESObfuscator का इस्तेमाल करने के लिए, पहले इसे अपनी गतिविधि में इंपोर्ट करें. निजी तौर पर सेट करें स्टैटिक फ़ाइनल अरे, सॉल्ट बाइट होल्ड करने और रैंडम तरीके से 20 से शुरू करने के लिए जनरेट किए गए बाइट.

Kotlin

// 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
)

Java

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

इसके बाद, डिवाइस आइडेंटिफ़ायर को होल्ड करने और किया जा सकता है. उदाहरण के लिए, LVL में शामिल सैंपल ऐप्लिकेशन इस विकल्प के लिए सिस्टम सेटिंग से क्वेरी करता है android.Settings.Secure.ANDROID_ID, जो हर डिवाइस के लिए अलग होता है.

ध्यान दें कि आपके इस्तेमाल किए जा रहे एपीआई के आधार पर, आपके ऐप्लिकेशन को डिवाइस से जुड़ी खास जानकारी पाने के लिए अतिरिक्त अनुमतियों का अनुरोध कर सकते हैं. उदाहरण के लिए, वैल्यू पाने के लिए TelephonyManager से क्वेरी करने के लिए या उससे जुड़े डेटा की ज़रूरत नहीं है, तो ऐप्लिकेशन को मेनिफ़ेस्ट में android.permission.READ_PHONE_STATE अनुमति है.

ऐक्सेस पाने के सिर्फ़ एक मकसद के लिए, नई अनुमतियों का अनुरोध करने से पहले आपके Obfuscator में उपयोग करने के लिए डिवाइस-विशिष्ट जानकारी, ऐसा करने से आपके ऐप्लिकेशन या Google Play पर उसे फ़िल्टर करने की सुविधा पर क्या असर पड़ेगा (क्योंकि कुछ अनुमतियों की वजह से SDK टूल के बिल्ड टूल संबंधित <uses-feature>).

आखिर में, AESObfuscator का इंस्टेंस बनाएं, जिसमें सॉल्ट को पास करना, ऐप्लिकेशन आइडेंटिफ़ायर और डिवाइस आइडेंटिफ़ायर. आपके पास इंस्टेंस बनाने का विकल्प है सीधे, अपने Policy और LicenseChecker को बनाते समय. उदाहरण के लिए:

Kotlin

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

Java

    ...
    // 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.
        );
    ...

एक पूरे उदाहरण के लिए, एलवीएल सैंपल ऐप्लिकेशन में MainActivity देखें.

किसी गतिविधि में मौजूद लाइसेंस की जांच करना

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

लाइसेंस की जांच जोड़ने और रिस्पॉन्स को मैनेज करने के लिए, आपको ये काम करने होंगे:

  1. इंपोर्ट जोड़ना
  2. निजी इनर क्लास के तौर पर, LicenseCheckerCallback लागू करना
  3. लाइसेंस-चेकरकॉलबैक से यूज़र इंटरफ़ेस (यूआई) थ्रेड पर पोस्ट करने के लिए, हैंडलर बनाएं
  4. Instantiate LicenseChecker और LicenseCheckerCallback
  5. लाइसेंस की जांच शुरू करने के लिए, checkAccess() को कॉल करें
  6. लाइसेंस देने के लिए अपनी सार्वजनिक कुंजी एम्बेड करें
  7. आईपीसी कनेक्शन बंद करने के लिए, अपने LicenseChecker के onDestroy() तरीके को कॉल करें.

इन सेक्शन में इन टास्क के बारे में बताया गया है.

लाइसेंस की जांच और रिस्पॉन्स की खास जानकारी

ज़्यादातर मामलों में, आपको अपने आवेदन के मुख्य हिस्से में लाइसेंस की जांच करने की सुविधा जोड़नी चाहिए onCreate() तरीके में Activity. यह पक्का करता है कि जब उपयोगकर्ता सीधे आपका ऐप्लिकेशन लॉन्च करे, तो लाइसेंस की जांच को तुरंत लागू कर दिया जाएगा. कुछ मामलों में, आप अन्य जगहें भी. उदाहरण के लिए, अगर आपके ऐप्लिकेशन में एक से ज़्यादा ऐक्टिविटी शामिल हैं कॉम्पोनेंट, जिन्हें अन्य ऐप्लिकेशन Intent से चालू कर सकते हैं, तो उन गतिविधियों में लाइसेंस की जांच जोड़ी जा सकती है.

लाइसेंस की जांच में दो मुख्य कार्रवाइयां होती हैं:

  • लाइसेंस की जांच शुरू करने के तरीके का इस्तेमाल करना — एलवीएल में यह LicenseChecker ऑब्जेक्ट के checkAccess() तरीके को किया गया कॉल जिसे खुद बनाना है.
  • एक कॉलबैक जो लाइसेंस की जांच का नतीजा दिखाता है. एलवीएल में यह LicenseCheckerCallback इंटरफ़ेस, जिसे आपने लागू किया है. कॉन्टेंट बनाने इंटरफ़ेस दो मेथड का एलान करता है, allow() और dontAllow(), जिनका इस्तेमाल लाइब्रेरी में लाइसेंस जांच का नतीजा. इन दोनों तरीकों को किसी भी लॉजिक से लागू किया जाता है आपके पास यह विकल्प होगा कि आप उपयोगकर्ता को अपने ऐप्लिकेशन का ऐक्सेस दें या अनुमति न दें. ध्यान दें कि इन तरीकों से यह तय नहीं किया जाता कि ऐक्सेस की अनुमति देनी है — यानी Policy को लागू करने की ज़िम्मेदारी आपकी होगी. इसके बजाय, इन के तरीकों में ऐप्लिकेशन के व्यवहार के बारे में बताया जाता है. इससे पता चलता है कि ऐप्लिकेशन में कैसे और को ऐक्सेस करने की अनुमति नहीं देनी चाहिए और ऐप्लिकेशन से जुड़ी गड़बड़ियों को ठीक करना चाहिए.

    allow() और dontAllow() वाले तरीकों में "वजह" दिखता है उनके जवाब के लिए कर सकते हैं, जो Policy मानों, LICENSED में से एक हो सकता है, NOT_LICENSED या RETRY. खास तौर पर, आपको ऐसे मामले तरीके को dontAllow() के लिए RETRY रिस्पॉन्स मिलता है और उपयोगकर्ता को यह "फिर से कोशिश करें" बटन पर क्लिक किया होगा, जो शायद इसलिए हुआ होगा क्योंकि अनुरोध.

पहला डायग्राम. खास जानकारी लाइसेंस की जांच से जुड़ा सामान्य इंटरैक्शन.

ऊपर दिया गया डायग्राम दिखाता है कि आम तौर पर, लाइसेंस की जांच कैसे की जाती है:

  1. ऐप्लिकेशन की मुख्य गतिविधि में मौजूद कोड, LicenseCheckerCallback को इंस्टैंशिएट करता है और LicenseChecker ऑब्जेक्ट हैं. LicenseChecker को बनाते समय, कोड Context, इस्तेमाल करने के लिए Policy, और पैरामीटर के रूप में लाइसेंस देने के लिए प्रकाशक खाते की सार्वजनिक कुंजी का उपयोग करें.
  2. इसके बाद कोड checkAccess() पद्धति को LicenseChecker ऑब्जेक्ट. लागू करने का तरीका, Policy को कॉल करके यह तय करता है कि क्या स्थानीय तौर पर कैश मेमोरी में सेव किया गया मान्य लाइसेंस रिस्पॉन्स मौजूद है SharedPreferences.
    • अगर ऐसा है, तो checkAccess() लागू करने पर allow().
    • ऐसा न करने पर, LicenseChecker भेजा गया लाइसेंस की जांच करने का अनुरोध शुरू कर देता है सीमित करने का विकल्प देता है.

    ध्यान दें: लाइसेंस देने वाला सर्वर हमेशा LICENSED को तब ट्रांसफ़र किया जाता है, जब ड्राफ़्ट किए गए आवेदन के लिए लाइसेंस की जांच की जाती है.

  3. जब कोई जवाब मिलता है, तो LicenseChecker एक LicenseValidator बनाता है जो हस्ताक्षर किए गए लाइसेंस के डेटा की पुष्टि करता है और रिस्पॉन्स के फ़ील्ड को एक्सट्रैक्ट करता है. इसके बाद इन्हें आपके Policy को भेज देता है, ताकि आगे की जांच की जा सके.
    • लाइसेंस मान्य होने पर, Policy रिस्पॉन्स को कैश मेमोरी में सेव कर देता है SharedPreferences और पुष्टि करने वाले को इसकी सूचना देता है. इसके बाद, LicenseCheckerCallback ऑब्जेक्ट पर allow() तरीका.
    • अगर लाइसेंस मान्य नहीं है, तो Policy, पुष्टि करने वाले को इसकी सूचना देता है, जो LicenseCheckerCallback को dontAllow() तरीका.
  4. लोकल या सर्वर की गड़बड़ी ठीक हो जाने की स्थिति में, जैसे कि नेटवर्क अनुरोध भेजने के लिए उपलब्ध नहीं है, LicenseChecker ने RETRY जवाब पास किया है आपके Policy ऑब्जेक्ट का processServerResponse() तरीका.

    साथ ही, allow() और dontAllow(), दोनों कॉलबैक तरीकों को reason आर्ग्युमेंट. allow() तरीके की वजह आम तौर पर Policy.LICENSED या Policy.RETRY होती है और dontAllow() की वजह आम तौर पर Policy.NOT_LICENSED या Policy.RETRY होती है. रिस्पॉन्स की ये वैल्यू काम की होती हैं, ताकि आप उपयोगकर्ता को सही जवाब मिले. जैसे, "फिर से कोशिश करें" लिखकर dontAllow() के Policy.RETRY के साथ जवाब देने पर बटन. ऐसा शायद इसलिए था, क्योंकि सेवा उपलब्ध नहीं हैं.

  5. ऐप्लिकेशन में कोई गड़बड़ी होने की स्थिति में, जैसे कि जब ऐप्लिकेशन किसी अमान्य पैकेज नाम के लाइसेंस की जाँच करें, LicenseChecker कोई गड़बड़ी देता है लाइसेंस-चेकरकॉलबैक के applicationError() का जवाब तरीका.

ध्यान दें कि, लाइसेंस की जांच शुरू करने और जिसके बारे में नीचे दिए गए सेक्शन में बताया गया है, तो आपके ऐप्लिकेशन को नीति लागू करने की सलाह दी जाती है और अगर Policy रिस्पॉन्स डेटा (जैसे कि ServerManagedPolicy) को सेव करता है. यह एक Obfuscator लागू है.

इंपोर्ट जोड़ें

सबसे पहले, ऐप्लिकेशन की मुख्य गतिविधि की क्लास फ़ाइल खोलें और इंपोर्ट करें LVL पैकेज से LicenseChecker और LicenseCheckerCallback.

Kotlin

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

Java

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

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

Kotlin

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

Java

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

लाइसेंस-चेकर कॉलबैक को निजी इनर क्लास के तौर पर लागू करें

LicenseCheckerCallback एक ऐसा इंटरफ़ेस है जिसे एलवीएल ने हैंडल करने के लिए दिया है लाइसेंस जांच के नतीजे के तौर पर स्वीकार किया जाता है. LVL का इस्तेमाल करके लाइसेंस लेने की सुविधा देने के लिए, आपको यह करना होगा LicenseCheckerCallback लागू करें और ऐप्लिकेशन तक ऐक्सेस की अनुमति देने या न देने की इसकी विधियां.

लाइसेंस की जांच के नतीजे के तौर पर, हमेशा जवाब की पुष्टि के आधार पर बनाया गया LicenseCheckerCallback तरीका पेलोड, सर्वर रिस्पॉन्स कोड, और दी गई कोई भी अतिरिक्त प्रोसेसिंग आपके Policy से. आपका ऐप्लिकेशन किसी भी ज़रूरी तरीके को लागू कर सकता है. तय सीमा में सामान्य, तरीकों को आसान रखते हुए यूआई को मैनेज करने तक सीमित रखना सबसे अच्छा है राज्य और ऐप्लिकेशन ऐक्सेस. अगर आपको लाइसेंस की अन्य प्रोसेस को जोड़ना है रिस्पॉन्स, जैसे कि बैकएंड सर्वर से संपर्क करना या कस्टम कंस्ट्रेंट लागू करके, तो आपको वह कोड अपने Policy में शामिल करने पर विचार करना चाहिए इसे LicenseCheckerCallback तरीकों में डालना होगा.

ज़्यादातर मामलों में, आपको आपके ऐप्लिकेशन के मुख्य सेक्शन में, LicenseCheckerCallback को निजी क्लास के तौर पर गतिविधि की क्लास.

allow() और dontAllow() तरीकों को इस तरह लागू करें की ज़रूरत नहीं है. सबसे पहले, नतीजों को मैनेज करने के आसान तरीकों का इस्तेमाल किया जा सकता है: तरीकों का इस्तेमाल कर सकते हैं, जैसे कि एक डायलॉग में लाइसेंस का नतीजा दिखाने का तरीका. इससे आपको यह पाने में मदद मिलती है आपका ऐप्लिकेशन तेज़ी से चलता है और डीबग करने में आपकी सहायता कर सकता है. बाद में, आपके बाद ने वही व्यवहार तय किए हैं जो आपको चाहिए, तो हैंडलिंग के तरीके को ज़्यादा जटिल बनाया जा सकता है.

बिना लाइसेंस वाले जवाबों को मैनेज करने के लिए, कुछ सुझाव dontAllow() में शामिल हैं:

  • "फिर से कोशिश करें" दिखाएं उपयोगकर्ता के लिए एक डायलॉग बॉक्स, नई लाइसेंस जांच करें कि दिया गया reason Policy.RETRY है या नहीं.
  • "यह ऐप्लिकेशन खरीदें" दिखाएं दिखाई देता है, जिसमें एक बटन होता है. उपयोगकर्ता को Google Play पर ऐप्लिकेशन के ज़्यादा जानकारी वाले पेज पर डीप-लिंक करता है, जहां से का उपयोग करके एप्लिकेशन खरीद सकते हैं. Google Analytics 4 प्रॉपर्टी को सेट अप करने के तरीके के बारे में लिंक के तौर पर, अपने प्रॉडक्ट से लिंक करना देखें.
  • टोस्ट सूचना दिखाएं, जो दिखाती हो कि आवेदन सीमित है, क्योंकि इसके पास लाइसेंस नहीं है.

नीचे दिए गए उदाहरण में दिखाया गया है कि एलवीएल सैंपल ऐप्लिकेशन कैसे लागू होता है LicenseCheckerCallback में, लाइसेंस की जांच का नतीजा डायलॉग.

Kotlin

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

Java

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

इसके अलावा, आपको applicationError() को लागू करना चाहिए तरीका है, जिसे LVL आपके ऐप्लिकेशन को ऐसी गड़बड़ियों को हैंडल करने के लिए कॉल करता है जो फिर से कोशिश की जा सकती है. ऐसी गड़बड़ियों की सूची देखने के लिए, सर्वर लाइसेंसिंग संदर्भ में रिस्पॉन्स कोड. इन्हें लागू किया जा सकता है किसी भी तरह से बदल सकते हैं. ज़्यादातर मामलों में, का तरीका गड़बड़ी का कोड लॉग करेगा और dontAllow() को कॉल करेगा.

LicenseCheckerCallback से पोस्ट करने के लिए एक हैंडलर बनाएं यूज़र इंटरफ़ेस (यूआई) थ्रेड में

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

LicenseChecker क्लास, आपके ऐप्लिकेशन के आईपीसी कम्यूनिकेशन को इनके साथ मैनेज करती है Google Play ऐप्लिकेशन, जिसमें अनुरोध भेजने वाला कॉल और यह एक कॉलबैक है, जिसे जवाब मिलता है. LicenseChecker ओपन लाइसेंस को भी ट्रैक करता है अनुरोध करता है और उनके टाइम आउट को मैनेज करता है.

इससे टाइम आउट को सही तरीके से मैनेज किया जा सकेगा और मिलने वाले जवाबों को भी प्रोसेस किया जा सकेगा आपके ऐप् लिकेशन के UI थ्रेड को प्रभावित किए बिना, LicenseChecker एक इंस्टैंशिएट करने पर बैकग्राउंड थ्रेड. थ्रेड में यह हर तरह की प्रोसेसिंग लाइसेंस की जांच के नतीजे देख सकते हैं कि यह नतीजा सर्वर से मिला जवाब है या नहीं या टाइम आउट की गड़बड़ी दिखेगी. प्रोसेस पूरी हो जाने पर, एलवीएल आपके बैकग्राउंड थ्रेड से LicenseCheckerCallback तरीके.

आपके ऐप्लिकेशन में इसका मतलब है कि:

  1. कई मामलों में, किसीLicenseCheckerCallback बैकग्राउंड थ्रेड.
  2. उन तरीकों से स्थिति अपडेट नहीं होगी या यूज़र इंटरफ़ेस (यूआई) थ्रेड, जब तक कि यूज़र इंटरफ़ेस (यूआई) थ्रेड में हैंडलर न बनाया जाए और आपको कॉलबैक न मिले तरीके, हैंडलर पर पोस्ट किए जाते हैं.

अगर आपको LicenseCheckerCallback के तरीकों से यूज़र इंटरफ़ेस (यूआई) थ्रेड को अपडेट करना है, तो मुख्य ऐक्टिविटी में, Handler को इंस्टैंशिएट करें onCreate() तरीका, जैसा कि नीचे दिखाया गया है. इस उदाहरण में, LVL सैंपल ऐप्लिकेशन का LicenseCheckerCallback तरीके (ऊपर देखें) displayResult() को इस पर कॉल करें हैंडलर के ज़रिए यूज़र इंटरफ़ेस (यूआई) थ्रेड को अपडेट करें post() तरीका.

Kotlin

    private lateinit var handler: Handler

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

Java

    private Handler handler;

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

इसके बाद, LicenseCheckerCallback वाले तरीकों में हैंडलर के तरीकों का इस्तेमाल करके ये काम किए जा सकते हैं चलाने योग्य या हैंडलर को संदेश ऑब्जेक्ट पोस्ट करने के लिए. यह रहा सैंपल LVL में शामिल ऐप्लिकेशन, यूज़र इंटरफ़ेस (यूआई) थ्रेड में किसी हैंडलर को रन किया जा सकने वाला फ़ॉर्मैट पोस्ट करता है डालें.

Kotlin

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

Java

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

लाइसेंस-चेकर और लाइसेंस-चेकरकॉलबैक को इंस्टैंशिएट करें

मुख्य ऐक्टिविटी onCreate() तरीका, LicenseCheckerCallback और LicenseChecker के निजी इंस्टेंस बनाएं. आपको ऐसा ज़रूर करना चाहिए पहले LicenseCheckerCallback को इंस्टैंशिएट करें, क्योंकि आपको कोई रेफ़रंस पास करना होगा उस इंस्टेंस पर तब लागू होगा, जब आप LicenseChecker के लिए कंस्ट्रक्टर को कॉल करेंगे.

LicenseChecker को इंस्टैंशिएट करने पर, आपको इन पैरामीटर को पास करना होगा:

  • Context ऐप्लिकेशन
  • लाइसेंस की जांच में इस्तेमाल करने के लिए, Policy को लागू करने का रेफ़रंस. तय सीमा में ज़्यादातर मामलों में, एलवीएल से मिले डिफ़ॉल्ट Policy का इस्तेमाल किया जाएगा, ServerManagedPolicy.
  • स्ट्रिंग वैरिएबल लाइसेंसिंग सिस्टम.

अगर आप ServerManagedPolicy का इस्तेमाल कर रहे हैं, तो आपको क्लास को ऐक्सेस करने की ज़रूरत नहीं होगी ताकि आप इसे LicenseChecker कंस्ट्रक्टर में इंस्टैंशिएट कर सकें, जैसा कि नीचे उदाहरण में दिखाया गया है. ध्यान दें कि आपको एक नए जब आप ServerManagedPolicy बनाते हैं, तो ऑब्फ़स्केटर इंस्टेंस.

नीचे दिया गया उदाहरण LicenseChecker और किसी गतिविधि के onCreate() तरीके में से LicenseCheckerCallback क्लास.

Kotlin

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

Java

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, यूज़र इंटरफ़ेस (यूआई) से LicenseCheckerCallback के तरीकों को कॉल करता है थ्रेड सिर्फ़ तब ही मान्य होगा, जब स्थानीय तौर पर मान्य लाइसेंस रिस्पॉन्स को कैश मेमोरी में सेव किया गया हो. अगर लाइसेंस की जांच सर्वर को भेजी जाती है, कॉलबैक हमेशा बैकग्राउंड थ्रेड, यहां तक कि नेटवर्क की गड़बड़ियों के लिए भी.

लाइसेंस की जांच शुरू करने के लिए, checkAccess() को कॉल करें

अपनी मुख्य गतिविधि में, इसके checkAccess() तरीके में कोई कॉल जोड़ें LicenseChecker इंस्टेंस. कॉल के दौरान, अपने पैरामीटर के तौर पर LicenseCheckerCallback इंस्टेंस. अगर आपको अपने समाचार संगठन के लिए, खास यूज़र इंटरफ़ेस (यूआई) इफ़ेक्ट या स्टेट मैनेजमेंट की सुविधा सेट अप करना, आपको यह काम का लग सकता है किसी रैपर तरीके से checkAccess() को कॉल करने के लिए. उदाहरण के लिए, LVL सैंपल ऐप्लिकेशन कॉल checkAccess() doCheck() रैपर तरीका:

Kotlin

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

Java

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

लाइसेंस देने के लिए अपनी सार्वजनिक कुंजी जोड़ें

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

Google Play Console, किसी भी व्यक्ति को लाइसेंस देने के लिए सार्वजनिक पासकोड उपलब्ध कराता है डेवलपर ने Play Console में साइन इन किया है, लेकिन यह निजी पासकोड को बनाए रखता है सभी लोगों को नहीं दिखेगा. जब कोई ऐप्लिकेशन किसी आपके खाते में प्रकाशित किसी ऐप्लिकेशन, लाइसेंसिंग सर्वर, आपके ऐप्लिकेशन के कुंजी के जोड़े की निजी कुंजी का इस्तेमाल करके लाइसेंस रिस्पॉन्स पर हस्ताक्षर करता है. जब LVL को जवाब मिलता है, तो वह उस सार्वजनिक पासकोड का इस्तेमाल करता है जो लाइसेंस के रिस्पॉन्स के हस्ताक्षर की पुष्टि करने के लिए आवेदन.

किसी ऐप्लिकेशन में लाइसेंस जोड़ने के लिए, आपको अपने आवेदन की सार्वजनिक पासकोड का इस्तेमाल करके, उसे अपने ऐप्लिकेशन में कॉपी कर सकता है. यहाँ बताया गया है कि लाइसेंस देने के लिए आपके ऐप्लिकेशन की सार्वजनिक कुंजी:

  1. Google Play Console पर जाएं और साइन इन करें. पक्का करें कि आप उसी खाते में साइन इन करें जिससे आप ऐप्लिकेशन का इस्तेमाल कर रहे हैं. लाइसेंसिंग की जानकारी पब्लिश हो गई है या पब्लिश कर दी जाएगी.
  2. ऐप्लिकेशन की जानकारी वाले पेज पर, सेवाएं और एपीआई और उस पर क्लिक करें.
  3. सेवाएं और APIs पेज पर, लाइसेंस देना और इन-ऐप बिलिंग सेक्शन. इसके लिए आपकी सार्वजनिक कुंजी लाइसेंस देने के लिए, इस ऐप्लिकेशन के लिए आपकी लाइसेंस कुंजी फ़ील्ड.

अपने ऐप्लिकेशन में सार्वजनिक कुंजी जोड़ने के लिए, बस कुंजी स्ट्रिंग को कॉपी करें/चिपकाएं फ़ील्ड से अपने ऐप्लिकेशन में स्ट्रिंग वैरिएबल के मान के रूप में BASE64_PUBLIC_KEY. कॉपी करते समय ध्यान रखें कि किसी भी वर्ण को छोड़े बिना, पूरी कुंजी स्ट्रिंग को चुना गया हो.

यहां LVL सैंपल ऐप्लिकेशन का एक उदाहरण दिया गया है:

Kotlin

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

Java

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

अपने LicenseChecker के onDestroy() तरीके को कॉल करें आईपीसी कनेक्शन बंद करने के लिए

आखिर में, आवेदन से पहले एलवीएल को स्टोरेज खाली करने के लिए Context बदलाव किया गया, LicenseChecker की आपकी ऐक्टिविटी के onDestroy() तरीके onDestroy() लागू किया गया. कॉल की वजह से Google Play से किसी भी खुले आईपीसी कनेक्शन को सही तरीके से बंद करने के लिए LicenseChecker ऐप्लिकेशन की IलाइसेंसService से मेल खाती है और सेवा के सभी स्थानीय संदर्भ हटा देती है और हैंडलर.

LicenseChecker के onDestroy() तरीके को कॉल नहीं किया जा सका इससे आपके ऐप्लिकेशन की लाइफ़साइकल में समस्याएं आ सकती हैं. उदाहरण के लिए, अगर ऐप्लिकेशन में लाइसेंस की जांच के दौरान, उपयोगकर्ता स्क्रीन ओरिएंटेशन बदलता है Context को खत्म कर दिया गया है. अगर आपका ऐप्लिकेशन LicenseChecker के IPC कनेक्शन को ठीक से बंद कर दें, आपका ऐप्लिकेशन क्रैश हो जाएगा का जवाब दें. इसी तरह, अगर उपयोगकर्ता आपके ऐप्लिकेशन से बाहर निकल जाता है जब लाइसेंस की जाँच की जा रही हो, तो आपका ऐप्लिकेशन तब क्रैश हो जाएगा, जब जवाब मिल चुका है, जब तक कि उसमें ठीक से LicenseChecker की onDestroy() का तरीका.

यहां LVL में शामिल सैंपल ऐप्लिकेशन का एक उदाहरण दिया गया है, जहां mChecker, LicenseChecker इंस्टेंस है:

Kotlin

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

Java

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

अगर आप LicenseChecker का विस्तार या बदलाव कर रहे हैं, तो आपको कॉल करना पड़ सकता है LicenseChecker का finishCheck() तरीका, किसी भी ओपन आईपीसी को हटाने का तरीका कनेक्शन.

Devicelimiter लागू करना

कुछ मामलों में, हो सकता है कि आप अपने Policy को ऐसे डिवाइस जिन्हें सिर्फ़ एक लाइसेंस का इस्तेमाल करने की अनुमति है. ऐसा करने पर, उपयोगकर्ता को लाइसेंस वाले ऐप्लिकेशन को कई डिवाइस पर ले जाने और ऐप्लिकेशन पर एक ही खाता आईडी से ऐक्सेस किया जा सकता है. इससे, "शेयर किया जा रहा है" से उपयोगकर्ता खाता जानकारी उपलब्ध कराकर ऐप्लिकेशन अन्य व्यक्तियों के लाइसेंस से जुड़े हों, जो बाद में उस खाते में साइन इन कर सकें खाते और ऐप्लिकेशन का लाइसेंस ऐक्सेस कर सकते हैं.

LVL, हर डिवाइस के हिसाब से लाइसेंस देता है. इसके लिए, DeviceLimiter इंटरफ़ेस, जो किसी एक तरीके के बारे में जानकारी देता है, allowDeviceAccess(). जब LicenseValidator किसी रिस्पॉन्स को हैंडल कर रहा हो लाइसेंस देने वाले सर्वर से डाउनलोड करता है, तो यह allowDeviceAccess() को कॉल करता है, जो रिस्पॉन्स से यूज़र आईडी वाली स्ट्रिंग निकाली गई.

अगर आपको डिवाइस की सीमा को तय नहीं करना है, तो आपको ज़रूरी है — LicenseChecker क्लास अपने-आप डिफ़ॉल्ट सेटिंग का इस्तेमाल करती है लागू करने के लिए, NullDeviceLimiter. जैसा कि इसके नाम से ही पता चलता है, NullDeviceLimiter "नो-ऑप" है वह क्लास जिसकी allowDeviceAccess() तरीका बस दिखाता है सभी उपयोगकर्ताओं और डिवाइसों के लिए LICENSED जवाब मिलेगा.

चेतावनी: इन डिवाइसों के लिए, हर डिवाइस के लाइसेंस का सुझाव नहीं दिया जाता है ज़्यादातर ऐप्लिकेशन इस्तेमाल करते हैं, क्योंकि:

  • उपयोगकर्ताओं और डिवाइसों को मैनेज करने के लिए, आपको बैकएंड सर्वर उपलब्ध कराना होगा मैपिंग और
  • इससे अनजाने में उपयोगकर्ता को किसी दूसरे डिवाइस पर कानूनी रूप से खरीदा गया ऐप्लिकेशन हो.

अपने कोड को अस्पष्ट बनाना

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

Android ऐप्लिकेशन के लिए कई obfuscator प्रोग्राम उपलब्ध हैं. इनमें ये शामिल हैं ProGuard, कोड-ऑप्टिमाइज़ेशन की सुविधाएं. उलझाने के लिए ProGuard या इससे मिलते-जुलते प्रोग्राम का इस्तेमाल करना Google का इस्तेमाल करने वाले सभी ऐप्लिकेशन के लिए, आपके कोड का सुझाव दिया जाता है Play की लाइसेंस देने वाली सेवा.

लाइसेंस वाला ऐप्लिकेशन पब्लिश करना

अपने लाइसेंस के लागू होने की जांच पूरी करने के बाद, ऐप्लिकेशन को Google Play पर प्रकाशित करना होगा. ऐप्लिकेशन तैयार करने, हस्ताक्षर करने, और फिर ऐप्लिकेशन पब्लिश करने के लिए, सामान्य तरीके का पालन करें.

सहायता यहां मिलेगी

अगर लागू या डिप्लॉय करते समय कोई समस्या आती है, तो पब्लिश करने के लिए, कृपया नीचे दी गई टेबल में देखें. अपनी क्वेरी को सही फ़ोरम पर भेजकर, सहायता की ज़रूरत है.

दूसरी टेबल. डेवलपर के लिए सहायता संसाधन Google Play लाइसेंसिंग सेवा के लिए.

सहायता का टाइप संसाधन विषयों की रेंज
विकास तथा परीक्षण संबंधी समस्याएं Google समूह: android-developers LVL डाउनलोड और इंटिग्रेशन, लाइब्रेरी प्रोजेक्ट, Policy सवाल, उपयोगकर्ता अनुभव से जुड़े आइडिया, जवाबों को मैनेज करना, Obfuscator, आईपीसी, टेस्ट एनवायरमेंट सेटअप
स्टैक ओवरफ़्लो: http://stackoverflow.com/questions/टैग किया गया/android
खाते, पब्लिश करने, और डिप्लॉयमेंट से जुड़ी समस्याएं Google Play सहायता फ़ोरम पब्लिशर खाते, लाइसेंस देने के लिए कुंजी का जोड़ा, टेस्ट खाते, सर्वर रिस्पॉन्स, टेस्ट रिस्पॉन्स, ऐप्लिकेशन डिप्लॉयमेंट, और नतीजे
बाज़ार लाइसेंस देने से जुड़ी सहायता के बारे में अक्सर पूछे जाने वाले सवाल
एलवीएल से जुड़ी समस्या को ट्रैक करने वाला टूल मार्केट लाइसेंसिंग प्रोजेक्ट से जुड़ी समस्याओं को ट्रैक करने वाला टूल खास तौर पर LVL सोर्स कोड क्लास से जुड़ी गड़बड़ी और समस्या की रिपोर्ट और इंटरफ़ेस को लागू करना

ऊपर दिए गए ग्रुप में पोस्ट करने के तरीके से जुड़ी सामान्य जानकारी के लिए, कम्यूनिटी संसाधन सेक्शन देखें पर जाएं.

अतिरिक्त संसाधन

LVL के साथ शामिल सैंपल ऐप्लिकेशन में, इन बातों का पूरा उदाहरण दिया गया है: लाइसेंस की जांच शुरू करने और नतीजे को मैनेज करने के लिए, MainActivity क्लास.