আপনার অ্যাপে ক্লায়েন্ট-সাইড লাইসেন্স যাচাইকরণ যোগ করা হচ্ছে

সতর্কতা: যখন আপনার অ্যাপটি ক্লায়েন্টের পাশে লাইসেন্স যাচাইকরণ প্রক্রিয়াটি সম্পাদন করে, তখন সম্ভাব্য আক্রমণকারীদের পক্ষে এই যাচাইকরণ প্রক্রিয়ার সাথে যুক্ত যুক্তি সংশোধন করা বা সরানো সহজ।

এই কারণে, আমরা এর পরিবর্তে সার্ভার-সাইড লাইসেন্স যাচাই করার জন্য আপনাকে জোরালোভাবে উত্সাহিত করি৷

আপনি একটি প্রকাশক অ্যাকাউন্ট এবং ডেভেলপমেন্ট এনভায়রনমেন্ট সেট আপ করার পরে ( লাইসেন্সিং এর জন্য সেট আপ দেখুন), আপনি লাইসেন্স যাচাইকরণ লাইব্রেরি (LVL) এর সাথে আপনার অ্যাপে লাইসেন্স যাচাইকরণ যোগ করতে প্রস্তুত।

LVL এর সাথে লাইসেন্স যাচাইকরণ যোগ করা এই কাজগুলিকে অন্তর্ভুক্ত করে:

  1. আপনার আবেদনের ম্যানিফেস্টে লাইসেন্সিং অনুমতি যোগ করা হচ্ছে ।
  2. একটি নীতি প্রয়োগ করা — আপনি LVL-এ প্রদত্ত সম্পূর্ণ বাস্তবায়নের একটি বেছে নিতে পারেন বা নিজের তৈরি করতে পারেন।
  3. একটি Obfuscator বাস্তবায়ন করা , যদি আপনার Policy কোনো লাইসেন্স প্রতিক্রিয়া ডেটা ক্যাশে করে।
  4. আপনার অ্যাপ্লিকেশনের প্রধান কার্যকলাপে লাইসেন্স চেক করতে কোড যোগ করা হচ্ছে ।
  5. একটি ডিভাইস লিমিটার প্রয়োগ করা (ঐচ্ছিক এবং বেশিরভাগ অ্যাপ্লিকেশনের জন্য প্রস্তাবিত নয়)।

নীচের বিভাগগুলি এই কাজগুলি বর্ণনা করে। যখন আপনি ইন্টিগ্রেশন সম্পন্ন করেন, তখন আপনি আপনার অ্যাপ্লিকেশনটি সফলভাবে কম্পাইল করতে সক্ষম হবেন এবং আপনি পরীক্ষা শুরু করতে পারবেন, যেমনটি সেট আপ দ্য টেস্ট এনভায়রনমেন্টে বর্ণিত হয়েছে।

LVL-এ অন্তর্ভুক্ত সোর্স ফাইলগুলির সম্পূর্ণ সেটের একটি ওভারভিউয়ের জন্য, LVL ক্লাস এবং ইন্টারফেসের সারাংশ দেখুন।

লাইসেন্সিং অনুমতি যোগ করা হচ্ছে

সার্ভারে লাইসেন্স চেক পাঠানোর জন্য Google Play অ্যাপ্লিকেশন ব্যবহার করতে, আপনার অ্যাপ্লিকেশনটিকে অবশ্যই যথাযথ অনুমতির অনুরোধ করতে হবে, com.android.vending.CHECK_LICENSE । যদি আপনার আবেদন লাইসেন্সিং অনুমতি ঘোষণা না করে কিন্তু লাইসেন্স চেক শুরু করার চেষ্টা করে, LVL একটি নিরাপত্তা ব্যতিক্রম নিক্ষেপ করে।

আপনার আবেদনে লাইসেন্সিং অনুমতির অনুরোধ করতে, <manifest> এর সন্তান হিসাবে একটি <uses-permission> উপাদান ঘোষণা করুন, নিম্নরূপ:

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

উদাহরণস্বরূপ, এখানে এলভিএল নমুনা অ্যাপ্লিকেশন কীভাবে অনুমতি ঘোষণা করে:

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

দ্রষ্টব্য: বর্তমানে, আপনি LVL লাইব্রেরি প্রকল্পের ম্যানিফেস্টে CHECK_LICENSE অনুমতি ঘোষণা করতে পারবেন না, কারণ SDK টুলগুলি এটিকে নির্ভরশীল অ্যাপ্লিকেশনগুলির ম্যানিফেস্টে একত্রিত করবে না৷ পরিবর্তে, আপনাকে অবশ্যই প্রতিটি নির্ভরশীল অ্যাপ্লিকেশনের ম্যানিফেস্টে অনুমতি ঘোষণা করতে হবে।

একটি নীতি বাস্তবায়ন

Google Play লাইসেন্সিং পরিষেবা নিজেই নির্ধারণ করে না যে প্রদত্ত লাইসেন্স সহ প্রদত্ত ব্যবহারকারীকে আপনার আবেদনে অ্যাক্সেস দেওয়া উচিত কিনা৷ বরং, সেই দায়িত্বটি একটি Policy বাস্তবায়নের উপর ছেড়ে দেওয়া হয় যা আপনি আপনার আবেদনে প্রদান করেন।

নীতি হল LVL দ্বারা ঘোষিত একটি ইন্টারফেস যা লাইসেন্স চেকের ফলাফলের উপর ভিত্তি করে ব্যবহারকারীর অ্যাক্সেসের অনুমতি বা অননুমোদিত করার জন্য আপনার অ্যাপ্লিকেশনের যুক্তি ধরে রাখার জন্য ডিজাইন করা হয়েছে। LVL ব্যবহার করতে, আপনার আবেদনকে অবশ্যই Policy বাস্তবায়ন প্রদান করতে হবে।

Policy ইন্টারফেস দুটি পদ্ধতি ঘোষণা করে, allowAccess() এবং processServerResponse() , যা লাইসেন্স সার্ভার থেকে একটি প্রতিক্রিয়া প্রক্রিয়া করার সময় একটি LicenseChecker উদাহরণ দ্বারা ডাকা হয়। এটি LicenseResponse নামক একটি enumও ঘোষণা করে, যা processServerResponse() এ কলে পাস করা লাইসেন্স প্রতিক্রিয়া মান নির্দিষ্ট করে।

  • processServerResponse() আপনাকে লাইসেন্সিং সার্ভার থেকে প্রাপ্ত কাঁচা প্রতিক্রিয়া ডেটা প্রিপ্রসেস করতে দেয়, অ্যাক্সেস দেওয়া হবে কিনা তা নির্ধারণ করার আগে।

    একটি সাধারণ বাস্তবায়ন লাইসেন্সের প্রতিক্রিয়া থেকে কিছু বা সমস্ত ক্ষেত্র বের করে এবং ডেটা স্থানীয়ভাবে একটি স্থায়ী স্টোরে সংরক্ষণ করে, যেমন SharedPreferences স্টোরেজের মাধ্যমে, নিশ্চিত করতে যে অ্যাপ্লিকেশন আহ্বান এবং ডিভাইস পাওয়ার চক্র জুড়ে ডেটা অ্যাক্সেসযোগ্য। উদাহরণ স্বরূপ, একটি Policy সর্বশেষ সফল লাইসেন্স চেকের টাইমস্ট্যাম্প, পুনঃপ্রচেষ্টার গণনা, লাইসেন্সের বৈধতার সময়কাল এবং একটি স্থায়ী স্টোরে অনুরূপ তথ্য বজায় রাখবে, প্রতিবার অ্যাপ্লিকেশন চালু করার সময় মানগুলি পুনরায় সেট করার পরিবর্তে।

    স্থানীয়ভাবে প্রতিক্রিয়া ডেটা সংরক্ষণ করার সময়, Policy নিশ্চিত করতে হবে যে ডেটা অস্পষ্ট হয়েছে (নীচে একটি অবফুসকেটর বাস্তবায়ন দেখুন)।

  • allowAccess() কোন উপলব্ধ লাইসেন্স প্রতিক্রিয়া ডেটা (লাইসেন্সিং সার্ভার বা ক্যাশে থেকে) বা অন্যান্য অ্যাপ্লিকেশন-নির্দিষ্ট তথ্যের উপর ভিত্তি করে ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনে অ্যাক্সেস দিতে হবে কিনা তা নির্ধারণ করে। উদাহরণ স্বরূপ, আপনার অনুমোদিত allowAccess() প্রয়োগের ক্ষেত্রে অতিরিক্ত মানদণ্ড বিবেচনা করা যেতে পারে, যেমন ব্যবহার বা ব্যাকএন্ড সার্ভার থেকে প্রাপ্ত অন্যান্য ডেটা। সমস্ত ক্ষেত্রে, অনুমতি প্রদানকারী সার্ভার দ্বারা নির্ধারিত ব্যবহারকারীর অ্যাপ্লিকেশনটি ব্যবহারের জন্য লাইসেন্সপ্রাপ্ত হলে, অথবা যদি একটি ক্ষণস্থায়ী নেটওয়ার্ক বা সিস্টেম সমস্যা থাকে যা লাইসেন্স চেক সম্পূর্ণ হতে বাধা দেয় তবেই allowAccess() এর বাস্তবায়ন true হবে। এই ধরনের ক্ষেত্রে, আপনার বাস্তবায়ন পুনরায় চেষ্টার প্রতিক্রিয়াগুলির একটি গণনা বজায় রাখতে পারে এবং পরবর্তী লাইসেন্স চেক সম্পূর্ণ না হওয়া পর্যন্ত অস্থায়ীভাবে অ্যাক্সেসের অনুমতি দিতে পারে।

আপনার আবেদনে লাইসেন্স যোগ করার প্রক্রিয়াটিকে সহজ করার জন্য এবং একটি Policy কীভাবে ডিজাইন করা উচিত তার একটি উদাহরণ প্রদান করার জন্য, LVL-এ দুটি সম্পূর্ণ Policy বাস্তবায়ন অন্তর্ভুক্ত রয়েছে যা আপনি পরিবর্তন ছাড়াই ব্যবহার করতে পারেন বা আপনার প্রয়োজনের সাথে খাপ খাইয়ে নিতে পারেন:

  • ServerManagedPolicy , একটি নমনীয় Policy যা বিভিন্ন নেটওয়ার্ক অবস্থার মধ্যে অ্যাক্সেস পরিচালনা করতে সার্ভার-প্রদত্ত সেটিংস এবং ক্যাশে করা প্রতিক্রিয়া ব্যবহার করে, এবং
  • StrictPolicy , যা কোনো প্রতিক্রিয়া ডেটা ক্যাশে করে না এবং সার্ভার লাইসেন্সকৃত প্রতিক্রিয়া প্রদান করলেই অ্যাক্সেসের অনুমতি দেয়।

বেশিরভাগ অ্যাপ্লিকেশনের জন্য, ServerManagedPolicy ব্যবহার করার জন্য অত্যন্ত সুপারিশ করা হয়। ServerManagedPolicy হল LVL ডিফল্ট এবং LVL নমুনা অ্যাপ্লিকেশনের সাথে একত্রিত।

কাস্টম নীতির জন্য নির্দেশিকা

আপনার লাইসেন্সিং বাস্তবায়নে, আপনি LVL (ServerManagedPolicy বা StrictPolicy) এ প্রদত্ত সম্পূর্ণ নীতিগুলির একটি ব্যবহার করতে পারেন অথবা আপনি একটি কাস্টম নীতি তৈরি করতে পারেন৷ যেকোনো ধরনের কাস্টম নীতির জন্য, আপনার বাস্তবায়নে বুঝতে এবং অ্যাকাউন্ট করার জন্য বেশ কিছু গুরুত্বপূর্ণ ডিজাইন পয়েন্ট রয়েছে।

লাইসেন্সিং সার্ভার সম্পদের অত্যধিক ব্যবহার থেকে রক্ষা করার জন্য সাধারণ অনুরোধের সীমা প্রয়োগ করে যা পরিষেবা অস্বীকার করতে পারে। যখন একটি অ্যাপ্লিকেশন অনুরোধের সীমা অতিক্রম করে, লাইসেন্সিং সার্ভার একটি 503 প্রতিক্রিয়া প্রদান করে, যা একটি সাধারণ সার্ভার ত্রুটি হিসাবে আপনার অ্যাপ্লিকেশনের মাধ্যমে পাস হয়। এর মানে হল যে সীমা রিসেট না হওয়া পর্যন্ত ব্যবহারকারীর কাছে কোনো লাইসেন্স প্রতিক্রিয়া পাওয়া যাবে না, যা ব্যবহারকারীকে একটি অনির্দিষ্ট সময়ের জন্য প্রভাবিত করতে পারে।

আপনি যদি একটি কাস্টম নীতি ডিজাইন করেন, আমরা সুপারিশ করি যে Policy :

  1. স্থানীয় স্থায়ী সঞ্চয়স্থানে সবচেয়ে সাম্প্রতিক সফল লাইসেন্স প্রতিক্রিয়া ক্যাশে (এবং সঠিকভাবে অস্পষ্ট করে)।
  2. লাইসেন্সিং সার্ভারের কাছে অনুরোধ না করে যতক্ষণ পর্যন্ত ক্যাশ করা প্রতিক্রিয়া বৈধ থাকে ততক্ষণ পর্যন্ত সমস্ত লাইসেন্স চেকের জন্য ক্যাশ করা প্রতিক্রিয়া প্রদান করে৷ সার্ভার-প্রদত্ত VT অতিরিক্ত অনুযায়ী প্রতিক্রিয়া বৈধতা সেট করা অত্যন্ত সুপারিশ করা হয়। আরো তথ্যের জন্য সার্ভার প্রতিক্রিয়া অতিরিক্ত দেখুন.
  3. একটি সূচকীয় ব্যাকঅফ সময়কাল ব্যবহার করে, যদি পুনরায় চেষ্টা করার ফলে ত্রুটি দেখা দেয়। মনে রাখবেন যে Google Play ক্লায়েন্ট স্বয়ংক্রিয়ভাবে ব্যর্থ অনুরোধগুলি পুনরায় চেষ্টা করে, তাই বেশিরভাগ ক্ষেত্রে তাদের পুনরায় চেষ্টা করার জন্য আপনার Policy প্রয়োজন নেই৷
  4. একটি "গ্রেস পিরিয়ড" প্রদান করে যা ব্যবহারকারীকে সীমিত সময় বা সংখ্যক ব্যবহারের জন্য আপনার অ্যাপ্লিকেশন অ্যাক্সেস করতে দেয়, যখন লাইসেন্স চেক পুনরায় চেষ্টা করা হচ্ছে। পরবর্তী লাইসেন্স চেক সফলভাবে সম্পন্ন না হওয়া পর্যন্ত গ্রেস পিরিয়ড অ্যাক্সেসের অনুমতি দিয়ে ব্যবহারকারীকে উপকৃত করে এবং যখন কোন বৈধ লাইসেন্স প্রতিক্রিয়া উপলব্ধ না থাকে তখন আপনার আবেদনে অ্যাক্সেসের উপর একটি হার্ড সীমা স্থাপন করে এটি আপনাকে উপকৃত করে।

উপরে তালিকাভুক্ত নির্দেশিকা অনুসারে আপনার Policy ডিজাইন করা গুরুত্বপূর্ণ, কারণ এটি ব্যবহারকারীদের জন্য সর্বোত্তম সম্ভাব্য অভিজ্ঞতা নিশ্চিত করে এবং ত্রুটির পরিস্থিতিতেও আপনাকে আপনার অ্যাপ্লিকেশনের উপর কার্যকর নিয়ন্ত্রণ দেয়।

নোট করুন যে কোনও Policy বৈধতা এবং ক্যাশিং পরিচালনা করতে, গ্রেস পিরিয়ড এবং আরও অনেক কিছুর জন্য পুনরায় চেষ্টা করতে লাইসেন্সিং সার্ভার দ্বারা প্রদত্ত সেটিংস ব্যবহার করতে পারে। সার্ভার-প্রদত্ত সেটিংস এক্সট্র্যাক্ট করা সহজ এবং সেগুলি ব্যবহার করা অত্যন্ত সুপারিশ করা হয়৷ কিভাবে এক্সট্রাক্ট এবং ব্যবহার করতে হয় তার উদাহরণের জন্য সার্ভারম্যানেজড পলিসি বাস্তবায়ন দেখুন। সার্ভার সেটিংসের একটি তালিকা এবং সেগুলি কীভাবে ব্যবহার করবেন সে সম্পর্কে তথ্যের জন্য, সার্ভার প্রতিক্রিয়া অতিরিক্ত দেখুন।

সার্ভার-ম্যানেজড পলিসি

LVL-এ সার্ভারম্যানেজড পলিসি নামক Policy ইন্টারফেসের একটি সম্পূর্ণ এবং প্রস্তাবিত বাস্তবায়ন অন্তর্ভুক্ত রয়েছে। বাস্তবায়ন LVL ক্লাসের সাথে একীভূত এবং লাইব্রেরিতে ডিফল্ট Policy হিসাবে কাজ করে।

ServerManagedPolicy লাইসেন্সের জন্য সমস্ত হ্যান্ডলিং এবং পুনরায় চেষ্টা করার প্রতিক্রিয়া প্রদান করে। এটি একটি SharedPreferences ফাইলে স্থানীয়ভাবে সমস্ত প্রতিক্রিয়া ডেটা ক্যাশ করে, এটিকে অ্যাপ্লিকেশনের Obfuscator বাস্তবায়নের সাথে অস্পষ্ট করে। এটি নিশ্চিত করে যে লাইসেন্স প্রতিক্রিয়া ডেটা সুরক্ষিত এবং ডিভাইস পাওয়ার চক্র জুড়ে টিকে থাকে। ServerManagedPolicy ইন্টারফেস পদ্ধতির processServerResponse() এবং allowAccess() এর সুনির্দিষ্ট বাস্তবায়ন প্রদান করে এবং লাইসেন্স প্রতিক্রিয়া পরিচালনার জন্য সহায়ক পদ্ধতি এবং প্রকারের একটি সেটও অন্তর্ভুক্ত করে।

গুরুত্বপূর্ণভাবে, ServerManagedPolicy-এর একটি মূল বৈশিষ্ট্য হল সার্ভার-প্রদত্ত সেটিংসের ব্যবহার একটি অ্যাপ্লিকেশনের রিফান্ডের সময়কাল এবং বিভিন্ন নেটওয়ার্ক এবং ত্রুটির শর্তগুলির মাধ্যমে লাইসেন্সিং পরিচালনার ভিত্তি হিসাবে। যখন একটি অ্যাপ্লিকেশন লাইসেন্স চেকের জন্য Google Play সার্ভারের সাথে যোগাযোগ করে, সার্ভারটি নির্দিষ্ট লাইসেন্স প্রতিক্রিয়া প্রকারের অতিরিক্ত ক্ষেত্রে কী-মান জোড়া হিসাবে বেশ কয়েকটি সেটিংস যুক্ত করে। উদাহরণ স্বরূপ, সার্ভারটি অন্যদের মধ্যে অ্যাপ্লিকেশনের লাইসেন্সের মেয়াদকাল, পুনরায় চেষ্টা করার গ্রেস পিরিয়ড এবং সর্বাধিক অনুমোদিত পুনরায় চেষ্টা গণনার জন্য প্রস্তাবিত মান প্রদান করে। ServerManagedPolicy তার processServerResponse() পদ্ধতিতে লাইসেন্সের প্রতিক্রিয়া থেকে মানগুলি বের করে এবং তাদের allowAccess() পদ্ধতিতে পরীক্ষা করে। ServerManagedPolicy দ্বারা ব্যবহৃত সার্ভার-প্রদত্ত সেটিংসের একটি তালিকার জন্য, সার্ভার প্রতিক্রিয়া অতিরিক্ত দেখুন।

সুবিধার জন্য, সেরা পারফরম্যান্স এবং Google Play সার্ভার থেকে লাইসেন্স সেটিংস ব্যবহার করার সুবিধার জন্য, আপনার লাইসেন্সিং Policy হিসাবে ServerManagedPolicy ব্যবহার করার জন্য দৃঢ়ভাবে সুপারিশ করা হয় ৷

আপনি যদি SharedPreferences এ স্থানীয়ভাবে সংরক্ষিত লাইসেন্স প্রতিক্রিয়া ডেটার নিরাপত্তা নিয়ে উদ্বিগ্ন হন, তাহলে আপনি একটি শক্তিশালী অস্পষ্টকরণ অ্যালগরিদম ব্যবহার করতে পারেন বা লাইসেন্স ডেটা সংরক্ষণ করে না এমন একটি কঠোর Policy ডিজাইন করতে পারেন৷ LVL-এ এই ধরনের একটি Policy উদাহরণ রয়েছে — আরও তথ্যের জন্য StrictPolicy দেখুন।

ServerManagedPolicy ব্যবহার করতে, এটিকে আপনার ক্রিয়াকলাপে আমদানি করুন, একটি উদাহরণ তৈরি করুন এবং আপনার LicenseChecker তৈরি করার সময় উদাহরণের একটি রেফারেন্স পাস করুন। আরও তথ্যের জন্য ইনস্ট্যান্টিয়েট লাইসেন্স চেকার এবং লাইসেন্স চেকার কলব্যাক দেখুন।

কঠোর নীতি

LVL-এর মধ্যে রয়েছে StrictPolicy নামক Policy ইন্টারফেসের একটি বিকল্প পূর্ণ বাস্তবায়ন। StrictPolicy বাস্তবায়ন সার্ভারম্যানেজড পলিসির চেয়ে আরও বেশি সীমাবদ্ধ নীতি প্রদান করে, যাতে এটি ব্যবহারকারীকে অ্যাপ্লিকেশানটি অ্যাক্সেস করার অনুমতি দেয় না যদি না অ্যাক্সেসের সময় সার্ভার থেকে একটি লাইসেন্স প্রতিক্রিয়া পাওয়া যায় যা নির্দেশ করে যে ব্যবহারকারী লাইসেন্সপ্রাপ্ত।

StrictPolicy-এর প্রধান বৈশিষ্ট্য হল এটি একটি স্থায়ী দোকানে স্থানীয়ভাবে লাইসেন্সের কোনো প্রতিক্রিয়া ডেটা সংরক্ষণ করে না। যেহেতু কোনও ডেটা সংরক্ষণ করা হয় না, আবার চেষ্টা করার অনুরোধগুলি ট্র্যাক করা হয় না এবং ক্যাশে করা প্রতিক্রিয়াগুলি লাইসেন্স চেকগুলি পূরণ করতে ব্যবহার করা যায় না৷ Policy শুধুমাত্র যদি অ্যাক্সেসের অনুমতি দেয়:

  • লাইসেন্সের প্রতিক্রিয়া লাইসেন্সিং সার্ভার থেকে প্রাপ্ত হয়, এবং
  • লাইসেন্স প্রতিক্রিয়া নির্দেশ করে যে ব্যবহারকারী অ্যাপ্লিকেশন অ্যাক্সেস করার লাইসেন্সপ্রাপ্ত।

StrictPolicy ব্যবহার করা উপযুক্ত যদি আপনার প্রাথমিক উদ্বেগ নিশ্চিত করা হয় যে, সমস্ত সম্ভাব্য ক্ষেত্রে, ব্যবহারকারীর ব্যবহারের সময় লাইসেন্সপ্রাপ্ত হওয়ার বিষয়টি নিশ্চিত না হওয়া পর্যন্ত কোনো ব্যবহারকারীকে অ্যাপ্লিকেশনটি অ্যাক্সেস করার অনুমতি দেওয়া হবে না। অতিরিক্তভাবে, নীতিটি ServerManagedPolicy-এর চেয়ে কিছুটা বেশি নিরাপত্তা প্রদান করে — যেহেতু স্থানীয়ভাবে কোনো ডেটা ক্যাশ করা নেই, তাই এমন কোনও উপায় নেই যে কোনও ক্ষতিকারক ব্যবহারকারী ক্যাশে করা ডেটার সাথে হস্তক্ষেপ করতে পারে এবং অ্যাপ্লিকেশনটিতে অ্যাক্সেস পেতে পারে।

একই সময়ে, এই Policy সাধারণ ব্যবহারকারীদের জন্য একটি চ্যালেঞ্জ উপস্থাপন করে, কারণ এর মানে হল যে কোনো নেটওয়ার্ক (সেল বা Wi-Fi) সংযোগ উপলব্ধ না থাকলে তারা অ্যাপ্লিকেশনটি অ্যাক্সেস করতে সক্ষম হবে না। আরেকটি পার্শ্ব-প্রতিক্রিয়া হল যে আপনার অ্যাপ্লিকেশন সার্ভারে আরও লাইসেন্স চেক অনুরোধ পাঠাবে, যেহেতু একটি ক্যাশড প্রতিক্রিয়া ব্যবহার করা সম্ভব নয়।

সামগ্রিকভাবে, এই নীতিটি সম্পূর্ণ নিরাপত্তা এবং অ্যাক্সেসের উপর নিয়ন্ত্রণের জন্য ব্যবহারকারীর সুবিধার কিছু মাত্রার ট্রেডঅফ উপস্থাপন করে। এই Policy ব্যবহার করার আগে ট্রেডঅফটি সাবধানে বিবেচনা করুন৷

StrictPolicy ব্যবহার করতে, এটিকে আপনার কার্যকলাপে আমদানি করুন, একটি উদাহরণ তৈরি করুন এবং আপনার LicenseChecker তৈরি করার সময় এটির একটি রেফারেন্স পাস করুন। আরও তথ্যের জন্য ইনস্ট্যান্টিয়েট লাইসেন্স চেকার এবং লাইসেন্স চেকার কলব্যাক দেখুন।

একটি সাধারণ Policy বাস্তবায়নের জন্য একটি অ্যাপ্লিকেশনের লাইসেন্স প্রতিক্রিয়া ডেটা একটি স্থায়ী স্টোরে সংরক্ষণ করতে হবে, যাতে এটি অ্যাপ্লিকেশন আহ্বান এবং ডিভাইস পাওয়ার চক্র জুড়ে অ্যাক্সেসযোগ্য হয়। উদাহরণ স্বরূপ, একটি Policy সর্বশেষ সফল লাইসেন্স চেকের টাইমস্ট্যাম্প, পুনঃপ্রচেষ্টার গণনা, লাইসেন্সের বৈধতার সময়কাল এবং একটি স্থায়ী স্টোরে অনুরূপ তথ্য বজায় রাখবে, প্রতিবার অ্যাপ্লিকেশন চালু করার সময় মানগুলি পুনরায় সেট করার পরিবর্তে। LVL, ServerManagedPolicy-এ অন্তর্ভুক্ত ডিফল্ট Policy , একটি SharedPreferences উদাহরণে লাইসেন্স প্রতিক্রিয়া ডেটা সঞ্চয় করে, যাতে ডেটা স্থায়ী হয় তা নিশ্চিত করা যায়।

যেহেতু Policy অ্যাপ্লিকেশানে অ্যাক্সেসের অনুমতি বা অননুমোদিত কিনা তা নির্ধারণ করতে সঞ্চিত লাইসেন্স প্রতিক্রিয়া ডেটা ব্যবহার করবে, এটি নিশ্চিত করতে হবে যে কোনও সঞ্চিত ডেটা সুরক্ষিত এবং কোনও ডিভাইসে কোনও রুট ব্যবহারকারী দ্বারা পুনরায় ব্যবহার বা ম্যানিপুলেট করা যাবে না। বিশেষভাবে, Policy অবশ্যই সবসময় ডেটা সংরক্ষণ করার আগে অস্পষ্ট করে, একটি কী ব্যবহার করে যা অ্যাপ্লিকেশন এবং ডিভাইসের জন্য অনন্য। অ্যাপ্লিকেশন-নির্দিষ্ট এবং ডিভাইস-নির্দিষ্ট উভয়ই একটি কী ব্যবহার করে অস্পষ্ট করা গুরুত্বপূর্ণ, কারণ এটি অস্পষ্ট ডেটাকে অ্যাপ্লিকেশন এবং ডিভাইসগুলির মধ্যে ভাগ করা থেকে বাধা দেয়৷

LVL অ্যাপ্লিকেশানটিকে তার লাইসেন্স প্রতিক্রিয়া ডেটা একটি নিরাপদ, অবিরাম পদ্ধতিতে সংরক্ষণ করতে সহায়তা করে। প্রথমত, এটি একটি Obfuscator ইন্টারফেস প্রদান করে যা আপনার অ্যাপ্লিকেশনটিকে সঞ্চিত ডেটার জন্য তার পছন্দের অস্পষ্টকরণ অ্যালগরিদম সরবরাহ করতে দেয়। এর উপর ভিত্তি করে, LVL সাহায্যকারী শ্রেণী PreferenceObfuscator প্রদান করে, যা অ্যাপ্লিকেশনের Obfuscator ক্লাসে কল করার এবং SharedPreferences উদাহরণে অস্পষ্ট ডেটা পড়া এবং লেখার বেশিরভাগ কাজ পরিচালনা করে।

LVL AESObfuscator নামে একটি সম্পূর্ণ Obfuscator বাস্তবায়ন প্রদান করে যা ডেটা অস্পষ্ট করতে AES এনক্রিপশন ব্যবহার করে। আপনি পরিবর্তন ছাড়াই আপনার অ্যাপ্লিকেশনে AESObfuscator ব্যবহার করতে পারেন বা আপনি এটিকে আপনার প্রয়োজনে মানিয়ে নিতে পারেন। আপনি যদি এমন একটি Policy (যেমন সার্ভারম্যানেজড পলিসি) ব্যবহার করেন যা লাইসেন্সের প্রতিক্রিয়া ডেটা ক্যাশ করে, তাহলে আপনার Obfuscator বাস্তবায়নের ভিত্তি হিসাবে AESObfuscator ব্যবহার করার সুপারিশ করা হয়। আরও তথ্যের জন্য, পরবর্তী বিভাগটি দেখুন।

AESObfuscator

LVL এ AESObfuscator নামক Obfuscator ইন্টারফেসের একটি সম্পূর্ণ এবং প্রস্তাবিত বাস্তবায়ন অন্তর্ভুক্ত করে। বাস্তবায়ন LVL নমুনা অ্যাপ্লিকেশনের সাথে একত্রিত করা হয়েছে এবং লাইব্রেরিতে ডিফল্ট Obfuscator হিসাবে কাজ করে।

AESObfuscator ডেটা এনক্রিপ্ট এবং ডিক্রিপ্ট করার জন্য AES ব্যবহার করে ডেটার সুরক্ষিত অস্পষ্টতা প্রদান করে যেমন এটি স্টোরেজে লেখা বা পড়া হয়। Obfuscator অ্যাপ্লিকেশন দ্বারা প্রদত্ত তিনটি ডেটা ক্ষেত্র ব্যবহার করে এনক্রিপশন বীজ করে:

  1. একটি লবণ - প্রতিটি (আন) অস্পষ্টতার জন্য ব্যবহার করার জন্য এলোমেলো বাইটের একটি অ্যারে।
  2. একটি অ্যাপ্লিকেশন শনাক্তকারী স্ট্রিং, সাধারণত অ্যাপ্লিকেশনটির প্যাকেজ নাম।
  3. একটি ডিভাইস শনাক্তকারী স্ট্রিং, যতটা সম্ভব ডিভাইস-নির্দিষ্ট উত্স থেকে প্রাপ্ত, যাতে এটিকে অনন্য করে তোলা যায়।

AESObfuscator ব্যবহার করতে, প্রথমে এটি আপনার কার্যকলাপে আমদানি করুন। লবণ বাইট ধরে রাখতে একটি ব্যক্তিগত স্ট্যাটিক চূড়ান্ত অ্যারে ঘোষণা করুন এবং এটিকে 20 এলোমেলোভাবে জেনারেট করা বাইটে শুরু করুন।

কোটলিন 

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

এরপরে, একটি ডিভাইস শনাক্তকারীকে ধরে রাখার জন্য একটি ভেরিয়েবল ঘোষণা করুন এবং যে কোনো উপায়ে এটির জন্য একটি মান তৈরি করুন। উদাহরণস্বরূপ, LVL-এ অন্তর্ভুক্ত নমুনা অ্যাপ্লিকেশনটি android.Settings.Secure.ANDROID_ID এর জন্য সিস্টেম সেটিংস জিজ্ঞাসা করে, যা প্রতিটি ডিভাইসের জন্য অনন্য।

মনে রাখবেন, আপনি যে APIগুলি ব্যবহার করেন তার উপর নির্ভর করে, ডিভাইস-নির্দিষ্ট তথ্য অর্জন করার জন্য আপনার অ্যাপ্লিকেশনটিকে অতিরিক্ত অনুমতির অনুরোধ করতে হতে পারে। উদাহরণস্বরূপ, ডিভাইসের IMEI বা সম্পর্কিত ডেটা পেতে TelephonyManager জিজ্ঞাসা করতে, অ্যাপ্লিকেশনটিকে তার ম্যানিফেস্টে android.permission.READ_PHONE_STATE অনুমতির অনুরোধ করতে হবে।

আপনার Obfuscator এ ব্যবহারের জন্য ডিভাইস-নির্দিষ্ট তথ্য অর্জনের একমাত্র উদ্দেশ্যের জন্য নতুন অনুমতির অনুরোধ করার আগে, এটি কীভাবে আপনার অ্যাপ্লিকেশন বা Google Play-তে এর ফিল্টারিংকে প্রভাবিত করতে পারে তা বিবেচনা করুন (যেহেতু কিছু অনুমতি SDK বিল্ড টুলগুলিকে যুক্ত করতে পারে <uses-feature> )।

অবশেষে, AESObfuscator-এর একটি উদাহরণ তৈরি করুন, লবণ, অ্যাপ্লিকেশন শনাক্তকারী এবং ডিভাইস শনাক্তকারীকে পাস করে। আপনার Policy এবং LicenseChecker তৈরি করার সময় আপনি সরাসরি উদাহরণটি তৈরি করতে পারেন। যেমন:

কোটলিন 

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

একটি সম্পূর্ণ উদাহরণের জন্য, LVL নমুনা অ্যাপ্লিকেশনে MainActivity দেখুন।

একটি কার্যকলাপ থেকে লাইসেন্স চেক করা হচ্ছে

একবার আপনি আপনার অ্যাপ্লিকেশানে অ্যাক্সেস পরিচালনার জন্য একটি Policy প্রয়োগ করার পরে, পরবর্তী পদক্ষেপটি হল আপনার অ্যাপ্লিকেশনটিতে একটি লাইসেন্স চেক যুক্ত করা, যা প্রয়োজন হলে লাইসেন্সিং সার্ভারে একটি প্রশ্ন শুরু করে এবং লাইসেন্স প্রতিক্রিয়ার উপর ভিত্তি করে অ্যাপ্লিকেশনটিতে অ্যাক্সেস পরিচালনা করে। লাইসেন্স চেক যোগ করার এবং প্রতিক্রিয়া পরিচালনা করার সমস্ত কাজ আপনার প্রধান Activity সোর্স ফাইলে সঞ্চালিত হয়।

লাইসেন্স চেক যোগ করতে এবং প্রতিক্রিয়া পরিচালনা করতে, আপনাকে অবশ্যই:

  1. আমদানি যোগ করুন
  2. একটি ব্যক্তিগত অভ্যন্তরীণ শ্রেণী হিসাবে LicenseCheckerCallback প্রয়োগ করুন
  3. LicenseCheckerCallback থেকে UI থ্রেডে পোস্ট করার জন্য একটি হ্যান্ডলার তৈরি করুন
  4. তাত্ক্ষণিক লাইসেন্স চেকার এবং লাইসেন্স চেকার কলব্যাক
  5. লাইসেন্স চেক শুরু করতে checkAccess() কে কল করুন
  6. লাইসেন্সের জন্য আপনার সর্বজনীন কী এম্বেড করুন
  7. IPC সংযোগ বন্ধ করতে আপনার LicenseChecker-এর onDestroy() পদ্ধতিতে কল করুন ।

নীচের বিভাগগুলি এই কাজগুলি বর্ণনা করে।

লাইসেন্স চেক এবং প্রতিক্রিয়া ওভারভিউ

বেশীরভাগ ক্ষেত্রেই, onCreate() পদ্ধতিতে আপনার অ্যাপ্লিকেশনের প্রধান Activity লাইসেন্স চেক যোগ করা উচিত। এটি নিশ্চিত করে যে ব্যবহারকারী যখন সরাসরি আপনার অ্যাপ্লিকেশন চালু করেন, তখন লাইসেন্স চেক অবিলম্বে আহ্বান করা হবে। কিছু ক্ষেত্রে, আপনি অন্যান্য অবস্থানেও লাইসেন্স চেক যোগ করতে পারেন। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশানে একাধিক অ্যাক্টিভিটি উপাদান অন্তর্ভুক্ত থাকে যা অন্যান্য অ্যাপ্লিকেশানগুলি Intent দ্বারা শুরু করতে পারে, আপনি সেই অ্যাক্টিভিটিগুলিতে লাইসেন্স চেক যোগ করতে পারেন৷

একটি লাইসেন্স চেক দুটি প্রধান কর্ম নিয়ে গঠিত:

  • লাইসেন্স চেক শুরু করার জন্য একটি পদ্ধতির জন্য একটি কল — LVL-এ, এটি আপনার তৈরি করা একটি LicenseChecker অবজেক্টের checkAccess() পদ্ধতিতে একটি কল।
  • একটি কলব্যাক যা লাইসেন্স চেকের ফলাফল প্রদান করে। LVL-এ, এটি একটি LicenseCheckerCallback ইন্টারফেস যা আপনি প্রয়োগ করেন। ইন্টারফেস দুটি পদ্ধতি ঘোষণা করে, allow() এবং dontAllow() , যা লাইসেন্স চেকের ফলাফলের উপর ভিত্তি করে লাইব্রেরি দ্বারা আহ্বান করা হয়। আপনি আপনার অ্যাপ্লিকেশনে ব্যবহারকারীর অ্যাক্সেসের অনুমতি দিতে বা অননুমোদিত করার জন্য আপনার যা প্রয়োজন যুক্তি দিয়ে এই দুটি পদ্ধতি প্রয়োগ করুন। মনে রাখবেন যে এই পদ্ধতিগুলি অ্যাক্সেসের অনুমতি দেবে কিনা তা নির্ধারণ করে না — সেই সংকল্পটি আপনার Policy বাস্তবায়নের দায়িত্ব৷ বরং, এই পদ্ধতিগুলি কেবল কীভাবে অ্যাক্সেসের অনুমতি এবং অস্বীকৃতি (এবং অ্যাপ্লিকেশন ত্রুটিগুলি পরিচালনা) করার জন্য অ্যাপ্লিকেশন আচরণ প্রদান করে।

    allow() এবং dontAllow() পদ্ধতিগুলি তাদের প্রতিক্রিয়ার জন্য একটি "কারণ" প্রদান করে, যা Policy মানগুলির মধ্যে একটি হতে পারে, LICENSED , NOT_LICENSED , বা RETRY ৷ বিশেষ করে, আপনার সেই ক্ষেত্রে পরিচালনা করা উচিত যেখানে পদ্ধতিটি dontAllow() এর জন্য RETRY প্রতিক্রিয়া পায় এবং ব্যবহারকারীকে একটি "পুনরায় চেষ্টা করুন" বোতাম প্রদান করে, যা অনুরোধের সময় পরিষেবাটি অনুপলব্ধ হওয়ার কারণে ঘটে থাকতে পারে।

চিত্র 1. একটি সাধারণ লাইসেন্স চেক ইন্টারঅ্যাকশনের ওভারভিউ।

উপরের চিত্রটি ব্যাখ্যা করে যে কীভাবে একটি সাধারণ লাইসেন্স চেক হয়:

  1. অ্যাপ্লিকেশানের প্রধান ক্রিয়াকলাপের কোডটি LicenseCheckerCallback এবং LicenseChecker অবজেক্টগুলিকে ইনস্ট্যান্টিয়েট করে৷ LicenseChecker নির্মাণ করার সময়, কোডটি Context , ব্যবহার করার জন্য একটি Policy বাস্তবায়ন, এবং প্যারামিটার হিসাবে লাইসেন্সের জন্য প্রকাশক অ্যাকাউন্টের সর্বজনীন কী পাস করে৷
  2. কোডটি তারপর LicenseChecker অবজেক্টে checkAccess() পদ্ধতিতে কল করে। SharedPreferences এ স্থানীয়ভাবে ক্যাশ করা বৈধ লাইসেন্স প্রতিক্রিয়া আছে কিনা তা নির্ধারণ করতে পদ্ধতি বাস্তবায়ন Policy কল করে।
    • যদি তাই হয়, checkAccess() বাস্তবায়ন কল allow() ।
    • অন্যথায়, LicenseChecker একটি লাইসেন্স চেক অনুরোধ শুরু করে যা লাইসেন্সিং সার্ভারে পাঠানো হয়।

    দ্রষ্টব্য: যখন আপনি একটি খসড়া আবেদনের লাইসেন্স পরীক্ষা করেন তখন লাইসেন্সিং সার্ভার সর্বদা LICENSED প্রদান করে।

  3. যখন একটি প্রতিক্রিয়া পাওয়া যায়, LicenseChecker একটি LicenseValidator তৈরি করে যা স্বাক্ষরিত লাইসেন্স ডেটা যাচাই করে এবং প্রতিক্রিয়ার ক্ষেত্রগুলি বের করে, তারপরে আরও মূল্যায়নের জন্য সেগুলিকে আপনার Policy পাঠায়৷
    • লাইসেন্সটি বৈধ হলে, Policy SharedPreferences প্রতিক্রিয়া ক্যাশ করে এবং যাচাইকারীকে অবহিত করে, যা LicenseCheckerCallback অবজেক্টে allow() পদ্ধতিকে কল করে।
    • লাইসেন্সটি বৈধ না হলে, Policy যাচাইকারীকে অবহিত করে, যা LicenseCheckerCallback এ dontAllow() পদ্ধতিকে কল করে।
  4. একটি পুনরুদ্ধারযোগ্য স্থানীয় বা সার্ভার ত্রুটির ক্ষেত্রে, যেমন অনুরোধ পাঠানোর জন্য নেটওয়ার্ক উপলব্ধ না হলে, LicenseChecker আপনার Policy অবজেক্টের processServerResponse() পদ্ধতিতে একটি RETRY প্রতিক্রিয়া পাস করে৷

    এছাড়াও, উভয় allow() এবং dontAllow() কলব্যাক পদ্ধতি একটি reason যুক্তি পায়। allow() পদ্ধতির কারণ হল সাধারণত Policy.LICENSED বা Policy.RETRY এবং dontAllow() কারণ হল সাধারণত Policy.NOT_LICENSED বা Policy.RETRY । এই প্রতিক্রিয়া মানগুলি দরকারী যাতে আপনি ব্যবহারকারীর জন্য একটি উপযুক্ত প্রতিক্রিয়া দেখাতে পারেন, যেমন একটি "পুনরায় চেষ্টা করুন" বোতাম প্রদান করে যখন dontAllow() Policy.RETRY এর সাথে প্রতিক্রিয়া জানায়, যা পরিষেবাটি অনুপলব্ধ হওয়ার কারণে হতে পারে৷

  5. একটি অ্যাপ্লিকেশন ত্রুটির ক্ষেত্রে, যেমন অ্যাপ্লিকেশনটি একটি অবৈধ প্যাকেজ নামের লাইসেন্স চেক করার চেষ্টা করলে, LicenseChecker চেকারকলব্যাকের applicationError() পদ্ধতিতে একটি ত্রুটি প্রতিক্রিয়া পাস করে।

নোট করুন যে, লাইসেন্স চেক শুরু করা এবং ফলাফল পরিচালনা করার পাশাপাশি, যা নীচের বিভাগে বর্ণিত হয়েছে, আপনার আবেদনকে একটি নীতি বাস্তবায়ন প্রদান করতে হবে এবং, যদি Policy প্রতিক্রিয়া ডেটা (যেমন সার্ভারম্যানেজড পলিসি) সঞ্চয় করে, একটি অবফুসকেটর বাস্তবায়ন।

আমদানি যোগ করুন

প্রথমে, অ্যাপ্লিকেশনটির প্রধান কার্যকলাপের ক্লাস ফাইলটি খুলুন এবং LVL প্যাকেজ থেকে LicenseChecker এবং LicenseCheckerCallback আমদানি করুন।

কোটলিন 

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;

আপনি যদি LVL, ServerManagedPolicy-এর সাথে প্রদত্ত ডিফল্ট Policy বাস্তবায়ন ব্যবহার করেন, তাহলে AESObfuscator এর সাথে এটিও আমদানি করুন। আপনি যদি একটি কাস্টম Policy বা Obfuscator ব্যবহার করেন, তবে পরিবর্তে সেগুলি আমদানি করুন৷

কোটলিন 

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 প্রয়োগ করুন

LicenseCheckerCallback হল একটি লাইসেন্স চেকের ফলাফল পরিচালনার জন্য LVL দ্বারা প্রদত্ত একটি ইন্টারফেস। LVL ব্যবহার করে লাইসেন্সিং সমর্থন করার জন্য, আপনাকে অবশ্যই LicenseCheckerCallback এবং এর পদ্ধতিগুলি প্রয়োগ করতে হবে যাতে অ্যাপ্লিকেশানে অ্যাক্সেসের অনুমতি দেওয়া বা না দেওয়া যায়৷

লাইসেন্স চেকের ফলাফল হল সর্বদা LicenseCheckerCallback পদ্ধতিগুলির একটিতে একটি কল যা প্রতিক্রিয়া পেলোড, সার্ভার প্রতিক্রিয়া কোড নিজেই এবং আপনার Policy দ্বারা প্রদত্ত যেকোন অতিরিক্ত প্রক্রিয়াকরণের ভিত্তিতে তৈরি করা হয়। আপনার অ্যাপ্লিকেশন প্রয়োজনীয় যে কোনো উপায়ে পদ্ধতি বাস্তবায়ন করতে পারে. সাধারণভাবে, পদ্ধতিগুলিকে সহজ রাখা ভাল, সেগুলিকে UI অবস্থা এবং অ্যাপ্লিকেশন অ্যাক্সেস পরিচালনা করার জন্য সীমাবদ্ধ করে। আপনি যদি লাইসেন্স প্রতিক্রিয়াগুলির আরও প্রক্রিয়াকরণ যোগ করতে চান, যেমন একটি ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করে বা কাস্টম সীমাবদ্ধতা প্রয়োগ করে, আপনার সেই কোডটিকে LicenseCheckerCallback পদ্ধতিতে রাখার পরিবর্তে আপনার Policy অন্তর্ভুক্ত করার বিষয়ে বিবেচনা করা উচিত।

বেশিরভাগ ক্ষেত্রে, আপনার অ্যাপ্লিকেশনের প্রধান অ্যাক্টিভিটি ক্লাসের মধ্যে একটি ব্যক্তিগত ক্লাস হিসাবে আপনার LicenseCheckerCallback বাস্তবায়ন ঘোষণা করা উচিত।

প্রয়োজন অনুযায়ী allow() এবং dontAllow() পদ্ধতি প্রয়োগ করুন। শুরু করার জন্য, আপনি পদ্ধতিতে সহজ ফলাফল-হ্যান্ডলিং আচরণ ব্যবহার করতে পারেন, যেমন একটি ডায়ালগে লাইসেন্স ফলাফল প্রদর্শন করা। এটি আপনাকে আপনার অ্যাপ্লিকেশনটি শীঘ্রই চালু করতে সহায়তা করে এবং ডিবাগিংয়ে সহায়তা করতে পারে। পরে, আপনি যে সঠিক আচরণগুলি চান তা নির্ধারণ করার পরে, আপনি আরও জটিল হ্যান্ডলিং যোগ করতে পারেন।

dontAllow() -এ লাইসেন্সবিহীন প্রতিক্রিয়াগুলি পরিচালনা করার জন্য কিছু পরামর্শ অন্তর্ভুক্ত:

  • ব্যবহারকারীর কাছে একটি "আবার চেষ্টা করুন" ডায়ালগ প্রদর্শন করুন, একটি নতুন লাইসেন্স চেক করার জন্য একটি বোতাম সহ, সরবরাহ করা reason Policy.RETRY । পুনরায় চেষ্টা করুন।
  • একটি "এই অ্যাপ্লিকেশনটি কিনুন" ডায়ালগ প্রদর্শন করুন, একটি বোতাম সহ যা ব্যবহারকারীকে Google Play-তে অ্যাপ্লিকেশনটির বিশদ পৃষ্ঠাতে গভীর-লিঙ্ক করে, যেখান থেকে ব্যবহারকারী অ্যাপ্লিকেশনটি কিনতে পারে৷ এই ধরনের লিঙ্কগুলি কীভাবে সেট আপ করবেন সে সম্পর্কে আরও তথ্যের জন্য, আপনার পণ্যগুলির সাথে লিঙ্ক করা দেখুন।
  • একটি টোস্ট বিজ্ঞপ্তি প্রদর্শন করুন যা নির্দেশ করে যে অ্যাপ্লিকেশনটির বৈশিষ্ট্যগুলি সীমিত কারণ এটি লাইসেন্সপ্রাপ্ত নয়৷

নীচের উদাহরণটি দেখায় কিভাবে LVL নমুনা অ্যাপ্লিকেশনটি LicenseCheckerCallback প্রয়োগ করে, এমন পদ্ধতিগুলির সাথে যা একটি ডায়ালগে লাইসেন্স চেক ফলাফল প্রদর্শন করে।

কোটলিন 

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

অতিরিক্তভাবে, আপনাকে applicationError() পদ্ধতিটি প্রয়োগ করতে হবে, যা LVL আপনার অ্যাপ্লিকেশনটিকে পুনরায় চেষ্টা করা যায় না এমন ত্রুটিগুলি পরিচালনা করতে দেয়। এই ধরনের ত্রুটির তালিকার জন্য, লাইসেন্সিং রেফারেন্সে সার্ভার প্রতিক্রিয়া কোডগুলি দেখুন। আপনি যে কোনও উপায়ে প্রয়োজনীয় পদ্ধতিটি বাস্তবায়ন করতে পারেন। বেশিরভাগ ক্ষেত্রে, পদ্ধতির ত্রুটি কোড লগ করা উচিত এবং dontAllow() কল করা উচিত।

LicenseCheckerCallback থেকে UI থ্রেডে পোস্ট করার জন্য একটি হ্যান্ডলার তৈরি করুন

লাইসেন্স চেক করার সময়, LVL Google Play অ্যাপ্লিকেশনের কাছে অনুরোধটি পাস করে, যা লাইসেন্সিং সার্ভারের সাথে যোগাযোগ পরিচালনা করে। এলভিএল অ্যাসিঙ্ক্রোনাস আইপিসি ( Binder ব্যবহার করে) অনুরোধটি পাস করে যাতে প্রকৃত প্রক্রিয়াকরণ এবং নেটওয়ার্ক যোগাযোগ আপনার অ্যাপ্লিকেশন দ্বারা পরিচালিত থ্রেডে সঞ্চালিত হয় না। একইভাবে, যখন Google Play অ্যাপ্লিকেশনটি ফলাফল পায়, তখন এটি IPC-এর উপর একটি কলব্যাক পদ্ধতি চালু করে, যা আপনার অ্যাপ্লিকেশনের প্রক্রিয়ায় একটি IPC থ্রেড পুলে কার্যকর করে।

LicenseChecker ক্লাস Google Play অ্যাপ্লিকেশানের সাথে আপনার অ্যাপ্লিকেশনের IPC যোগাযোগ পরিচালনা করে, যার মধ্যে যে কলটি অনুরোধ পাঠানো হয় এবং যে কলব্যাকটি প্রতিক্রিয়া পায়। LicenseChecker খোলা লাইসেন্সের অনুরোধগুলিও ট্র্যাক করে এবং তাদের সময়সীমা পরিচালনা করে।

যাতে এটি সঠিকভাবে টাইমআউট পরিচালনা করতে পারে এবং আপনার অ্যাপ্লিকেশনের UI থ্রেডকে প্রভাবিত না করে ইনকামিং প্রতিক্রিয়াগুলি প্রক্রিয়া করতে পারে, LicenseChecker ইনস্ট্যান্টেশনে একটি পটভূমি থ্রেড তৈরি করে। থ্রেডে এটি লাইসেন্স চেক ফলাফলের সমস্ত প্রক্রিয়াকরণ করে, ফলাফলটি সার্ভার থেকে প্রাপ্ত প্রতিক্রিয়া বা টাইমআউট ত্রুটি কিনা। প্রক্রিয়াকরণের উপসংহারে, LVL ব্যাকগ্রাউন্ড থ্রেড থেকে আপনার LicenseCheckerCallback পদ্ধতিগুলিকে কল করে।

আপনার আবেদনের জন্য, এর মানে হল:

  1. আপনার LicenseCheckerCallback পদ্ধতিগুলি, অনেক ক্ষেত্রে, একটি ব্যাকগ্রাউন্ড থ্রেড থেকে আহ্বান করা হবে।
  2. আপনি UI থ্রেডে একটি হ্যান্ডলার তৈরি না করলে এবং হ্যান্ডলারের কাছে আপনার কলব্যাক পদ্ধতিগুলি পোস্ট না করা পর্যন্ত এই পদ্ধতিগুলি স্টেট আপডেট করতে বা UI থ্রেডে কোনও প্রক্রিয়াকরণ করতে সক্ষম হবে না।

আপনি যদি আপনার LicenseCheckerCallback পদ্ধতিগুলিকে UI থ্রেড আপডেট করতে চান, তাহলে নীচে দেখানো হিসাবে, প্রধান কার্যকলাপের onCreate() পদ্ধতিতে একটি Handler ইনস্ট্যান্টিয়েট করুন৷ এই উদাহরণে, LVL নমুনা অ্যাপ্লিকেশনের LicenseCheckerCallback পদ্ধতিগুলি (উপরে দেখুন) কল displayResult() হ্যান্ডলারের post() পদ্ধতির মাধ্যমে UI থ্রেড আপডেট করতে।

কোটলিন 

    private lateinit var handler: Handler

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

জাভা 

    private Handler handler;

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

তারপর, আপনার LicenseCheckerCallback পদ্ধতিতে, আপনি হ্যান্ডলারের কাছে রানযোগ্য বা বার্তা অবজেক্ট পোস্ট করতে হ্যান্ডলার পদ্ধতি ব্যবহার করতে পারেন। LVL-এ অন্তর্ভুক্ত নমুনা অ্যাপ্লিকেশনটি লাইসেন্সের স্থিতি প্রদর্শনের জন্য UI থ্রেডে একটি হ্যান্ডলারের কাছে রানযোগ্য পোস্ট করে।

কোটলিন 

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

তাত্ক্ষণিক লাইসেন্স চেকার এবং লাইসেন্স চেকার কলব্যাক

প্রধান কার্যকলাপের onCreate() পদ্ধতিতে, LicenseCheckerCallback এবং LicenseChecker এর ব্যক্তিগত উদাহরণ তৈরি করুন। আপনাকে প্রথমে LicenseCheckerCallback ইনস্ট্যান্টিয়েট করতে হবে, কারণ যখন আপনি LicenseChecker এর জন্য কনস্ট্রাক্টরকে কল করবেন তখন আপনাকে সেই উদাহরণের একটি রেফারেন্স পাস করতে হবে।

যখন আপনি LicenseChecker instantiate করেন, তখন আপনাকে এই পরামিতিগুলিতে পাস করতে হবে:

  • আবেদনের Context
  • লাইসেন্স চেকের জন্য ব্যবহার করার জন্য Policy বাস্তবায়নের একটি রেফারেন্স। বেশিরভাগ ক্ষেত্রে, আপনি LVL, ServerManagedPolicy দ্বারা প্রদত্ত ডিফল্ট Policy বাস্তবায়ন ব্যবহার করবেন।
  • স্ট্রিং ভেরিয়েবল লাইসেন্স করার জন্য আপনার প্রকাশক অ্যাকাউন্টের সর্বজনীন কী ধারণ করে।

আপনি যদি ServerManagedPolicy ব্যবহার করেন, তাহলে আপনাকে সরাসরি ক্লাসে প্রবেশ করতে হবে না, তাই আপনি এটিকে LicenseChecker কনস্ট্রাক্টরে ইনস্ট্যান্টিয়েট করতে পারেন, যেমনটি নীচের উদাহরণে দেখানো হয়েছে। মনে রাখবেন যে আপনি যখন ServerManagedPolicy তৈরি করেন তখন আপনাকে একটি নতুন Obfuscator উদাহরণে একটি রেফারেন্স পাস করতে হবে।

নিচের উদাহরণটি একটি অ্যাক্টিভিটি ক্লাসের onCreate() পদ্ধতি থেকে LicenseChecker এবং LicenseCheckerCallback এর ইনস্ট্যান্টেশন দেখায়।

কোটলিন 

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 UI থ্রেড থেকে LicenseCheckerCallback পদ্ধতিগুলিকে কল করে৷ লাইসেন্স চেক সার্ভারে পাঠানো হলে, কলব্যাকগুলি সর্বদা ব্যাকগ্রাউন্ড থ্রেড থেকে উদ্ভূত হয়, এমনকি নেটওয়ার্ক ত্রুটির জন্যও।

লাইসেন্স চেক শুরু করতে checkAccess() কে কল করুন

আপনার প্রধান কার্যকলাপে, LicenseChecker উদাহরণের checkAccess() পদ্ধতিতে একটি কল যোগ করুন। কলে, একটি প্যারামিটার হিসাবে আপনার LicenseCheckerCallback উদাহরণের একটি রেফারেন্স পাস করুন৷ কল করার আগে আপনার যদি কোনো বিশেষ UI ইফেক্ট বা স্টেট ম্যানেজমেন্ট পরিচালনা করতে হয়, তাহলে আপনি একটি র্যাপার পদ্ধতি থেকে checkAccess() কল করা দরকারী বলে মনে করতে পারেন। উদাহরণস্বরূপ, LVL নমুনা অ্যাপ্লিকেশনটি একটি doCheck() মোড়ক পদ্ধতি থেকে checkAccess() কল করে:

কোটলিন 

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

লাইসেন্সের জন্য আপনার সর্বজনীন কী এম্বেড করুন

প্রতিটি অ্যাপ্লিকেশনের জন্য, Google Play পরিষেবা স্বয়ংক্রিয়ভাবে একটি 2048-বিট RSA পাবলিক/প্রাইভেট কী জোড়া তৈরি করে যা লাইসেন্সিং এবং ইন-অ্যাপ বিলিং এর জন্য ব্যবহৃত হয়। কী জোড়া অনন্যভাবে অ্যাপ্লিকেশনের সাথে যুক্ত। যদিও অ্যাপ্লিকেশানের সাথে যুক্ত, কী জোড়াটি আপনার অ্যাপ্লিকেশানগুলিতে স্বাক্ষর করার জন্য যে কী ব্যবহার করেন তার মতো নয় (বা এটি থেকে উদ্ভূত)৷

Google Play Console, Play Console-এ সাইন ইন করা যেকোনো বিকাশকারীকে লাইসেন্স দেওয়ার জন্য সর্বজনীন কী প্রকাশ করে, কিন্তু এটি একটি নিরাপদ স্থানে সমস্ত ব্যবহারকারীর কাছ থেকে ব্যক্তিগত কী লুকিয়ে রাখে। যখন একটি অ্যাপ্লিকেশন আপনার অ্যাকাউন্টে প্রকাশিত একটি অ্যাপ্লিকেশনের জন্য লাইসেন্স চেকের অনুরোধ করে, তখন লাইসেন্সিং সার্ভার আপনার অ্যাপ্লিকেশনের কী জোড়ার ব্যক্তিগত কী ব্যবহার করে লাইসেন্স প্রতিক্রিয়াতে স্বাক্ষর করে। যখন LVL প্রতিক্রিয়া পায়, তখন এটি লাইসেন্স প্রতিক্রিয়ার স্বাক্ষর যাচাই করতে অ্যাপ্লিকেশন দ্বারা প্রদত্ত সর্বজনীন কী ব্যবহার করে।

একটি অ্যাপ্লিকেশনে লাইসেন্স যোগ করতে, আপনাকে অবশ্যই লাইসেন্সের জন্য আপনার অ্যাপ্লিকেশনের সর্বজনীন কী পেতে হবে এবং এটি আপনার অ্যাপ্লিকেশনে অনুলিপি করতে হবে। লাইসেন্সের জন্য আপনার অ্যাপ্লিকেশনের সর্বজনীন কী কীভাবে খুঁজে পাবেন তা এখানে:

  1. Google Play Console- এ যান এবং সাইন ইন করুন। নিশ্চিত করুন যে আপনি যে অ্যাকাউন্ট থেকে লাইসেন্স করছেন সেই অ্যাকাউন্টে সাইন ইন করেছেন (বা প্রকাশিত হবে)।
  2. অ্যাপ্লিকেশন বিশদ পৃষ্ঠায়, পরিষেবা এবং API লিঙ্কটি সনাক্ত করুন এবং এটিতে ক্লিক করুন৷
  3. পরিষেবা এবং API পৃষ্ঠায়, লাইসেন্সিং এবং ইন-অ্যাপ বিলিং বিভাগটি সন্ধান করুন৷ লাইসেন্সের জন্য আপনার সর্বজনীন কী এই অ্যাপ্লিকেশন ক্ষেত্রের জন্য আপনার লাইসেন্স কীটিতে দেওয়া আছে।

আপনার অ্যাপ্লিকেশনে সর্বজনীন কী যোগ করতে, স্ট্রিং ভেরিয়েবল BASE64_PUBLIC_KEY এর মান হিসাবে আপনার অ্যাপ্লিকেশনে ক্ষেত্র থেকে কী স্ট্রিংটি কেবল অনুলিপি/পেস্ট করুন। আপনি যখন অনুলিপি করছেন, নিশ্চিত করুন যে আপনি কোনও অক্ষর বাদ না দিয়ে সম্পূর্ণ কী স্ট্রিংটি নির্বাচন করেছেন।

এখানে LVL নমুনা অ্যাপ্লিকেশন থেকে একটি উদাহরণ:

কোটলিন 

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

IPC সংযোগ বন্ধ করতে আপনার LicenseChecker-এর onDestroy() পদ্ধতিতে কল করুন

অবশেষে, আপনার অ্যাপ্লিকেশানের Context পরিবর্তনের আগে LVL পরিষ্কার করতে দিতে, আপনার কার্যকলাপের onDestroy() বাস্তবায়ন থেকে LicenseChecker এর onDestroy() পদ্ধতিতে একটি কল যোগ করুন। এই কলের কারণে LicenseChecker Google Play অ্যাপ্লিকেশনের ILicensingService-এর সাথে যেকোনও খোলা IPC সংযোগ সঠিকভাবে বন্ধ করে দেয় এবং পরিষেবা এবং হ্যান্ডলারের স্থানীয় রেফারেন্সগুলি সরিয়ে দেয়৷

LicenseChecker এর onDestroy() পদ্ধতিতে কল করতে ব্যর্থ হলে আপনার আবেদনের জীবনচক্রে সমস্যা হতে পারে। উদাহরণ স্বরূপ, লাইসেন্স চেক সক্রিয় থাকাকালীন ব্যবহারকারী যদি স্ক্রীনের অভিযোজন পরিবর্তন করে, তাহলে অ্যাপ্লিকেশন Context ধ্বংস হয়ে যায়। যদি আপনার আবেদনটি সঠিকভাবে LicenseChecker এর IPC সংযোগ বন্ধ না করে, তাহলে প্রতিক্রিয়া প্রাপ্ত হলে আপনার আবেদনটি ক্র্যাশ হয়ে যাবে। একইভাবে, লাইসেন্স চেক চলাকালীন ব্যবহারকারী আপনার আবেদন থেকে প্রস্থান করলে, প্রতিক্রিয়া প্রাপ্ত হলে আপনার অ্যাপ্লিকেশনটি ক্র্যাশ হয়ে যাবে, যদি না এটি পরিষেবা থেকে সংযোগ বিচ্ছিন্ন করার জন্য LicenseChecker onDestroy() পদ্ধতিটিকে সঠিকভাবে কল না করে।

এখানে LVL-এ অন্তর্ভুক্ত নমুনা অ্যাপ্লিকেশন থেকে একটি উদাহরণ দেওয়া হল, যেখানে mChecker হল LicenseChecker উদাহরণ:

কোটলিন 

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

জাভা 

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

আপনি যদি LicenseChecker প্রসারিত বা পরিবর্তন করছেন, তাহলে যেকোনও খোলা IPC সংযোগ পরিষ্কার করতে আপনাকে LicenseChecker 's finishCheck() পদ্ধতিতে কল করতে হতে পারে।

একটি ডিভাইস লিমিটার প্রয়োগ করা হচ্ছে

কিছু ক্ষেত্রে, আপনি আপনার Policy একটি লাইসেন্স ব্যবহার করার জন্য অনুমোদিত প্রকৃত ডিভাইসের সংখ্যা সীমিত করতে চাইতে পারেন। এটি একটি ব্যবহারকারীকে একটি লাইসেন্সকৃত অ্যাপ্লিকেশনকে একাধিক ডিভাইসে সরাতে এবং একই অ্যাকাউন্ট আইডির অধীনে সেই ডিভাইসগুলিতে অ্যাপ্লিকেশন ব্যবহার করতে বাধা দেবে৷ এটি একটি ব্যবহারকারীকে লাইসেন্সের সাথে সম্পর্কিত অ্যাকাউন্টের তথ্য প্রদান করে অ্যাপ্লিকেশনটিকে "ভাগ" করতে বাধা দেবে, যারা তারপরে তাদের ডিভাইসে সেই অ্যাকাউন্টে সাইন ইন করতে এবং অ্যাপ্লিকেশনটিতে লাইসেন্স অ্যাক্সেস করতে পারে।

LVL একটি DeviceLimiter ইন্টারফেস প্রদান করে প্রতি-ডিভাইস লাইসেন্সিং সমর্থন করে, যা একটি একক পদ্ধতি, allowDeviceAccess() ঘোষণা করে। যখন একটি LicenseValidator লাইসেন্সিং সার্ভার থেকে একটি প্রতিক্রিয়া পরিচালনা করে, তখন এটি allowDeviceAccess() কল করে, প্রতিক্রিয়া থেকে বের করা একটি ব্যবহারকারী আইডি স্ট্রিং পাস করে।

আপনি যদি ডিভাইসের সীমাবদ্ধতা সমর্থন করতে না চান, কোন কাজের প্রয়োজন নেই — LicenseChecker ক্লাস স্বয়ংক্রিয়ভাবে NullDeviceLimiter নামক একটি ডিফল্ট বাস্তবায়ন ব্যবহার করে। নাম অনুসারে, NullDeviceLimiter হল একটি "নো-অপ" শ্রেণী যার allowDeviceAccess() পদ্ধতিটি সমস্ত ব্যবহারকারী এবং ডিভাইসের জন্য একটি LICENSED প্রতিক্রিয়া প্রদান করে৷

সতর্কতা: বেশিরভাগ অ্যাপ্লিকেশনের জন্য প্রতি-ডিভাইস লাইসেন্সিং সুপারিশ করা হয় না কারণ:

  • ব্যবহারকারী এবং ডিভাইস ম্যাপিং পরিচালনা করার জন্য আপনাকে একটি ব্যাকএন্ড সার্ভার প্রদান করতে হবে এবং
  • এটি অসাবধানতাবশত একজন ব্যবহারকারীকে একটি অ্যাপ্লিকেশন অ্যাক্সেস করতে অস্বীকার করতে পারে যা তারা বৈধভাবে অন্য ডিভাইসে কিনেছে।

আপনার কোড অস্পষ্ট

আপনার আবেদনের নিরাপত্তা নিশ্চিত করতে, বিশেষ করে একটি অর্থপ্রদানের অ্যাপ্লিকেশনের জন্য যা লাইসেন্সিং এবং/অথবা কাস্টম সীমাবদ্ধতা এবং সুরক্ষা ব্যবহার করে, আপনার অ্যাপ্লিকেশন কোডটি অস্পষ্ট করা খুবই গুরুত্বপূর্ণ৷ আপনার কোডকে সঠিকভাবে অস্পষ্ট করা একটি দূষিত ব্যবহারকারীর জন্য অ্যাপ্লিকেশনটির বাইটকোড ডিকম্পাইল করা, এটি সংশোধন করা - যেমন লাইসেন্স চেক সরিয়ে ফেলার মাধ্যমে - এবং তারপরে এটি পুনরায় কম্পাইল করা আরও কঠিন করে তোলে।

ProGuard সহ Android অ্যাপ্লিকেশনগুলির জন্য বেশ কয়েকটি অবফুসকেটর প্রোগ্রাম উপলব্ধ, যা কোড-অপ্টিমাইজেশন বৈশিষ্ট্যগুলিও অফার করে। Google Play লাইসেন্সিং ব্যবহার করে এমন সমস্ত অ্যাপ্লিকেশনের জন্য আপনার কোডকে অস্পষ্ট করতে ProGuard বা অনুরূপ প্রোগ্রামের ব্যবহার দৃঢ়ভাবে সুপারিশ করা হয়।

একটি লাইসেন্সকৃত আবেদন প্রকাশ করা

আপনি যখন আপনার লাইসেন্স বাস্তবায়নের পরীক্ষা শেষ করেন, আপনি Google Play-এ অ্যাপ্লিকেশনটি প্রকাশ করতে প্রস্তুত। অ্যাপ্লিকেশনটি প্রস্তুত করতে , স্বাক্ষর করতে এবং তারপর প্রকাশ করার জন্য সাধারণ পদক্ষেপগুলি অনুসরণ করুন।

কোথায় সাপোর্ট পাবেন

আপনার অ্যাপ্লিকেশনগুলিতে প্রকাশনা বাস্তবায়ন বা স্থাপন করার সময় আপনার যদি প্রশ্ন থাকে বা সমস্যাগুলির সম্মুখীন হন, তাহলে অনুগ্রহ করে নীচের সারণীতে তালিকাভুক্ত সমর্থন সংস্থানগুলি ব্যবহার করুন৷ সঠিক ফোরামে আপনার প্রশ্নগুলি নির্দেশ করে, আপনি আরও দ্রুত আপনার প্রয়োজনীয় সমর্থন পেতে পারেন৷

সারণি 2. Google Play লাইসেন্সিং পরিষেবার জন্য বিকাশকারী সমর্থন সংস্থান৷

সমর্থন প্রকার সম্পদ বিষয়ের পরিসর
উন্নয়ন এবং পরীক্ষার সমস্যা Google Groups: android-developers এলভিএল ডাউনলোড এবং ইন্টিগ্রেশন, লাইব্রেরি প্রকল্প, Policy প্রশ্ন, ব্যবহারকারীর অভিজ্ঞতার ধারণা, প্রতিক্রিয়া পরিচালনা, Obfuscator , আইপিসি, পরীক্ষার পরিবেশ সেটআপ
স্ট্যাক ওভারফ্লো: http://stackoverflow.com/questions/tagged/android
অ্যাকাউন্ট, প্রকাশনা, এবং স্থাপনার সমস্যা Google Play সহায়তা ফোরাম প্রকাশক অ্যাকাউন্ট, লাইসেন্সিং কী জোড়া, পরীক্ষার অ্যাকাউন্ট, সার্ভার প্রতিক্রিয়া, পরীক্ষার প্রতিক্রিয়া, অ্যাপ্লিকেশন স্থাপনা এবং ফলাফল
মার্কেট লাইসেন্সিং সমর্থন FAQ
LVL সমস্যা ট্র্যাকার মার্কেট লাইসেন্সিং প্রজেক্ট ইস্যু ট্র্যাকার LVL সোর্স কোড ক্লাস এবং ইন্টারফেস বাস্তবায়নের সাথে বিশেষভাবে সম্পর্কিত বাগ এবং সমস্যা রিপোর্ট

উপরে তালিকাভুক্ত গোষ্ঠীগুলিতে কীভাবে পোস্ট করবেন সে সম্পর্কে সাধারণ তথ্যের জন্য, বিকাশকারী সমর্থন সংস্থান পৃষ্ঠায় সম্প্রদায় সংস্থান বিভাগটি দেখুন।

অতিরিক্ত সম্পদ

LVL-এর সাথে অন্তর্ভুক্ত নমুনা অ্যাপ্লিকেশনটি MainActivity ক্লাসে কীভাবে লাইসেন্স চেক শুরু করতে হয় এবং ফলাফল পরিচালনা করতে হয় তার একটি সম্পূর্ণ উদাহরণ প্রদান করে।