লাইব্রেরি লেখকদের জন্য অপ্টিমাইজেশন

লাইব্রেরির লেখক হিসেবে, আপনাকে নিশ্চিত করতে হবে যে অ্যাপ ডেভেলপাররা যাতে সহজেই আপনার লাইব্রেরি তাদের অ্যাপে অন্তর্ভুক্ত করতে পারেন এবং একই সাথে গ্রাহকের জন্য খুব ভালো অভিজ্ঞতা বজায় রাখতে পারেন। এর অর্থ হল, আপনার লাইব্রেরিটি অবশ্যই Android অপ্টিমাইজেশনের (R8) সাথে মানানসই হতে হবে, যাতে ডেভেলপারের অতিরিক্ত সেট-আপের প্রয়োজন না হয়—অথবা ডকুমেন্ট করতে হবে যে লাইব্রেরিটি Android-এ ব্যবহারের জন্য অনুপযুক্ত হতে পারে। Android-এ ব্যবহারের জন্য তৈরি করা লাইব্রেরি যাতে গুরুত্বপূর্ণ অ্যাপ অপ্টিমাইজেশনকে বাধা না দেয় এবং অতিরিক্ত অপ্টিমাইজেশন সংক্রান্ত প্রয়োজনীয়তা মেনে চলে, তা নিশ্চিত করা অত্যন্ত গুরুত্বপূর্ণ।

এই ডকুমেন্টেশনটি প্রকাশিত লাইব্রেরির ডেভেলপারদের জন্য তৈরি করা হয়েছে, তবে এটি একটি বড়, মডুলারাইজড অ্যাপে ইন্টার্নাল লাইব্রেরি মডিউলের ডেভেলপারদের জন্যও উপযোগী হতে পারে।

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

রাখার নিয়মের ধরন বোঝা

লাইব্রেরিতে আপনি দুই ধরনের রাখার নিয়ম সেট করতে পারেন:

  • গ্রাহক কীপ সংক্রান্ত নিয়ম অবশ্যই এমন নিয়ম নির্দিষ্ট করবে যা লাইব্রেরিতে যা দেখানো হয় তা রেখে দেয়। কোনও লাইব্রেরি যদি তার কোডে কল করার জন্য রিফ্লেকশন বা JNI ব্যবহার করে অথবা ক্লায়েন্ট অ্যাপের দ্বারা সংজ্ঞায়িত কোড ব্যবহার করে, তাহলে এইসব নিয়মে কোন কোড রাখতে হবে তা বর্ণনা করতে হবে। লাইব্রেরিতে গ্রাহকের ডেটা রাখার নিয়ম প্যাকেজ করা উচিত, যা অ্যাপের ডেটা রাখার নিয়মের মতো একই ফর্ম্যাট ব্যবহার করে। এইসব নিয়ম লাইব্রেরি আর্টিফ্যাক্টে (AAR বা JAR) বান্ডেল করা থাকে এবং লাইব্রেরি ব্যবহার করার সময় Android অ্যাপ অপ্টিমাইজেশনের সময় অটোমেটিক ব্যবহার করা হয়। এইসব নিয়ম আপনার build.gradle.kts (বা build.gradle) ফাইলের consumerProguardFiles প্রপার্টিতে উল্লেখ করা ফাইলে মেনে চলা হয়। আরও জানতে, গ্রাহক রাখার নিয়ম লিখুন দেখুন।
  • আপনার লাইব্রেরি তৈরি করার সময় লাইব্রেরি তৈরি করার নিয়ম প্রয়োগ করা হয়। আপনি যদি বিল্ড টাইমে আপনার লাইব্রেরি আংশিকভাবে অপ্টিমাইজ করার সিদ্ধান্ত নেন, তাহলেই এগুলি প্রয়োজন। লাইব্রেরির পাবলিক API যাতে সরানো না হয় তা তাদের নিশ্চিত করতে হবে, অন্যথায় লাইব্রেরি ডিস্ট্রিবিউশনে পাবলিক API থাকবে না, যার অর্থ হল অ্যাপ ডেভেলপাররা লাইব্রেরি ব্যবহার করতে পারবেন না। এইসব নিয়ম আপনার build.gradle.kts (বা build.gradle) ফাইলের proguardFiles প্রপার্টিতে উল্লেখ করা ফাইলে বজায় রাখা হয়। আরও জানতে, AAR লাইব্রেরি বিল্ড অপ্টিমাইজ করুন দেখুন।

অপ্টিমাইজেশন সংক্রান্ত প্রয়োজনীয়তা ও নির্দেশিকা

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

অপ্টিমাইজেশন সংক্রান্ত প্রয়োজনীয়তা মেনে চলুন

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

  • কোনও বিস্তৃত বা প্যাকেজ-ব্যাপী 'কিপ' নিয়ম নেই: আপনার লাইব্রেরিতে এমন কোনও বিস্তৃত 'কিপ' নিয়ম থাকা চলবে না যা আপনার লাইব্রেরি বা অন্য কোনও লাইব্রেরির বেশিরভাগ কোডকে রেখে দেয়। ব্রড কিপ নিয়ম স্বল্পমেয়াদে ক্র্যাশ হওয়ার সমস্যা সমাধান করতে পারে, কিন্তু এটি আপনার লাইব্রেরি ব্যবহার করে এমন সব অ্যাপের সাইজ বাড়িয়ে দেয়।

    আপনার লাইব্রেরি বা অন্যান্য রেফারেন্স করা লাইব্রেরিতে প্যাকেজের জন্য প্যাকেজ-ওয়াইড কিপ রুল (যেমন -keep class com.mylibrary.** {*; }) অন্তর্ভুক্ত করবেন না। এই ধরনের নিয়ম আপনার লাইব্রেরি ব্যবহার করে এমন সব অ্যাপ জুড়ে এইসব প্যাকেজের জন্য অপ্টিমাইজেশন সীমিত করে।

  • কোনও অনুপযুক্ত গ্লোবাল নিয়ম নেই: গ্লোবাল বিকল্প যেমন -dontobfuscate বা -allowaccessmodification কখনই ব্যবহার করবেন না।

  • সম্ভব হলে রিফ্লেকশনের পরিবর্তে কোডজেন ব্যবহার করা: সম্ভব হলে, রিফ্লেকশনের পরিবর্তে কোড জেনারেশন (codegen) ব্যবহার করুন। প্রোগ্রামিং করার সময় বয়লারপ্লেট কোড এড়ানোর জন্য কোডজেন ও রিফ্লেকশন, দুটিই সাধারণ পদ্ধতি হলেও, কোডজেন R8-এর মতো অ্যাপ অপ্টিমাইজারের সাথে আরও বেশি মানানসই।

    codegen-এর মাধ্যমে, বিল্ড প্রসেস চলাকালীন কোড বিশ্লেষণ ও পরিবর্তন করা হয়। কম্পাইল করার পরে কোনও বড় ধরনের পরিবর্তন করা হয় না বলে, অপ্টিমাইজার জানে যে কোন কোডটি শেষ পর্যন্ত প্রয়োজন এবং কোনটি নিরাপদে সরিয়ে দেওয়া যায়।

    রিফ্লেকশনের মাধ্যমে, রানটাইমে কোড বিশ্লেষণ ও ম্যানিপুলেট করা হয়। যেহেতু কোডটি এক্সিকিউট না হওয়া পর্যন্ত সত্যিই চূড়ান্ত হয় না, তাই অপ্টিমাইজার জানে না কোন কোড নিরাপদে সরানো যেতে পারে। এটি সম্ভবত রানটাইমের সময় রিফ্লেকশনের মাধ্যমে ডাইনামিকভাবে ব্যবহৃত কোড সরিয়ে দেয়, যার ফলে ব্যবহারকারীদের জন্য অ্যাপ ক্র্যাশ হয়।

    অনেক আধুনিক লাইব্রেরি রিফ্লেকশনের পরিবর্তে কোডজেন ব্যবহার করে। Room, Hilt এবং আরও অনেক কিছুর দ্বারা ব্যবহৃত সাধারণ এন্ট্রি পয়েন্টের জন্য KSP দেখুন।

  • R8 ফুল মোড সাপোর্ট করা: R8 ফুল মোড চালু করা থাকলে আপনার লাইব্রেরি ক্র্যাশ করা উচিত নয়। R8 ব্যবহার করার জন্য R8-এর সম্পূর্ণ মোড সাজেস্ট করা হয় এবং এটি AGP 8.0 থেকে ডিফল্ট হিসেবে আছে, যা ২০২৩ সালে স্থিতিশীল করা হয়েছে। R8-এর অধীনে আপনার লাইব্রেরি ক্র্যাশ করলে, এর সমাধান হল নির্দিষ্ট রিফ্লেকশন বা JNI এন্ট্রি পয়েন্ট শনাক্ত করা এবং টার্গেট করা নিয়ম যোগ করা, পুরো প্যাকেজটি রেখে দেওয়া নয়।

অতিরিক্ত সাজেশন

অপ্টিমাইজেশন সংক্রান্ত প্রয়োজনীয়তা ছাড়াও, নিচে উল্লেখ করা বিষয়গুলি অতিরিক্ত পরামর্শ।

  • আপনার লাইব্রেরির গ্রাহক রাখার নিয়মের ফাইলে -repackageclasses ব্যবহার করবেন না। তবে, আপনার লাইব্রেরি বিল্ড অপ্টিমাইজ করতে, আপনি ইন্টার্নাল প্যাকেজের নামের সাথে -repackageclasses ব্যবহার করতে পারেন, যেমন <your.library.package>.internal, আপনার লাইব্রেরির বিল্ড কিপ রুলস ফাইলে। এটি অপ্টিমাইজ না করা অ্যাপে আপনার লাইব্রেরির দক্ষতা উন্নত করতে পারে। তবে, সাধারণত এটি করার প্রয়োজন হয় না, কারণ অ্যাপও অপ্টিমাইজ করা উচিত।
  • আপনার লাইব্রেরির ফাংশনের জন্য প্রয়োজনীয় যেকোনও অ্যাট্রিবিউট আপনার লাইব্রেরির কিপ রুল ফাইলে ঘোষণা করুন, এমনকি proguard-android-optimize.txt-এ সংজ্ঞায়িত অ্যাট্রিবিউটের সাথে ওভারল্যাপ থাকলেও।
  • আপনার লাইব্রেরি ডিস্ট্রিবিউশনে নিম্নলিখিত অ্যাট্রিবিউট প্রয়োজন হলে, সেগুলি আপনার লাইব্রেরির বিল্ড কিপ রুল ফাইলে বজায় রাখুন, আপনার লাইব্রেরির কনজিউমার কিপ রুল ফাইলে নয়:
    • AnnotationDefault
    • EnclosingMethod
    • Exceptions
    • InnerClasses
    • RuntimeInvisibleAnnotations
    • RuntimeInvisibleParameterAnnotations
    • RuntimeInvisibleTypeAnnotations
    • RuntimeVisibleAnnotations
    • RuntimeVisibleParameterAnnotations
    • RuntimeVisibleTypeAnnotations
    • Signature
  • রানটাইমে অ্যানোটেশন ব্যবহার করা হলে, লাইব্রেরি লেখকদের উচিত তাদের কনজিউমার কিপ নিয়মে RuntimeVisibleAnnotations অ্যাট্রিবিউট রাখা।
  • লাইব্রেরি লেখকদের তাদের কনজিউমার কিপ নিয়মে নিম্নলিখিত গ্লোবাল বিকল্প ব্যবহার করা উচিত নয়:
    • -include
    • -basedirectory
    • -injars
    • -outjars
    • -libraryjars
    • -repackageclasses
    • -flattenpackagehierarchy
    • -allowaccessmodification
    • -renamesourcefileattribute
    • -ignorewarnings
    • -addconfigurationdebugging
    • -printconfiguration
    • -printmapping
    • -printusage
    • -printseeds
    • -applymapping
    • -obfuscationdictionary
    • -classobfuscationdictionary
    • -packageobfuscationdictionary

প্রতিফলন ঠিক থাকলে

আপনাকে যদি রিফ্লেকশন ব্যবহার করতেই হয়, তাহলে নিম্নলিখিতগুলির মধ্যে যেকোনও একটিতে রিফ্লেক্ট করতে হবে:

  • টার্গেট করা নির্দিষ্ট ধরন (নির্দিষ্ট ইন্টারফেস ইমপ্লিমেন্টার বা সাবক্লাস)
  • নির্দিষ্ট রানটাইম অ্যানোটেশন ব্যবহার করে কোড

এইভাবে রিফ্লেকশন ব্যবহার করলে রানটাইম খরচ সীমিত হয় এবং টার্গেট করা গ্রাহকদের ধরে রাখার নিয়ম লেখা যায়।

এই নির্দিষ্ট ও টার্গেট করা রিফ্লেকশন হল এমন একটি প্যাটার্ন যা আপনি Android ফ্রেমওয়ার্ক (যেমন, অ্যাক্টিভিটি, ভিউ ও ড্রয়েবল ইনফ্লেট করার সময়) এবং AndroidX লাইব্রেরি (যেমন, WorkManager ListenableWorkers বা RoomDatabases কনস্ট্রাক্ট করার সময়) জুড়ে দেখতে পাবেন। এর বিপরীতে, Gson-এর ওপেন এন্ডেড রিফ্লেকশন Android অ্যাপে ব্যবহারের জন্য উপযুক্ত নয়।

সাধারণ ভুল ধারণা

কিছু সাধারণ ভুল ধারণা আপনাকে R8 ভুলভাবে কনফিগার করতে বাধ্য করতে পারে। এর মধ্যে এগুলি অন্তর্ভুক্ত:

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

  • অফস্কেট করা লাইব্রেরির অপ্টিমাইজেশন বাইপাস করা: একটি সাধারণ সমস্যা হল, অপ্টিমাইজেশন থেকে কোনও লাইব্রেরিকে বাদ দেওয়া, কারণ লাইব্রেরিটি AAR (Android Archive) বা JAR (Java Archive)-এ কম্পাইল করার সময় অপ্টিমাইজ বা অফস্কেট করা হয়েছিল। লাইব্রেরি তৈরি করার সময় অপ্টিমাইজেশন সীমিত থাকে এবং আপনার অ্যাপকে কোনও কীপ নিয়মে অন্তর্ভুক্ত করে লাইব্রেরির অপ্টিমাইজেশন বন্ধ করা উচিত নয়। আরও তথ্যের জন্য, AAR লাইব্রেরি বিল্ড অপ্টিমাইজ করা দেখুন।

  • -keep বিকল্পের ভুল ব্যাখ্যা -keep নিয়মটি R8-কে তার কোনও অপ্টিমাইজেশন পাস রান করা থেকে আটকায়। আরও তথ্যের জন্য, সঠিক রাখার বিকল্প বেছে নিন দেখুন।

গ্রাহক সংক্রান্ত ডেটা কতদিন রাখা যাবে সেই সংক্রান্ত নিয়মের কোয়ালিটি যাচাই করা

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

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

নিয়ম প্যাকেজিং কনফিগার করুন

আপনার কনজিউমার কিপ রুল সঠিকভাবে প্রয়োগ করা হয়েছে কিনা তা নিশ্চিত করতে, আপনার লাইব্রেরি ফর্ম্যাটের উপর নির্ভর করে আপনাকে সেগুলি যথাযথভাবে প্যাকেজ করতে হবে।

আপনার লাইব্রেরির রিফ্লেকশন ও JNI ব্যবহার ঘোষণা করার জন্য Jetpack Keep ব্যবহার করলে, এর Gradle প্লাগ-ইন আপনার জন্য কনজিউমার কিপ রুল হিসেবে জেনারেট করা নিয়ম প্যাকেজ করতে পারে।

AAR লাইব্রেরি

AAR লাইব্রেরির জন্য গ্রাহক নিয়ম যোগ করতে, Android লাইব্রেরি মডিউলের বিল্ড স্ক্রিপ্টে consumerProguardFiles বিকল্প ব্যবহার করুন। আরও তথ্যের জন্য, আমাদের লাইব্রেরি মডিউল তৈরি করার নির্দেশিকা দেখুন।

Kotlin

android {
    defaultConfig {
        consumerProguardFiles("consumer-proguard-rules.pro")
    }
    ...
}

গ্ৰুভি

android {
    defaultConfig {
        consumerProguardFiles 'consumer-proguard-rules.pro'
    }
    ...
}

JAR লাইব্রেরি

JAR হিসেবে শিপ করা Kotlin বা Java লাইব্রেরির সাথে নিয়ম বান্ডেল করতে, আপনার নিয়মের ফাইলটি ফাইনাল JAR-এর META-INF/proguard/ ডিরেক্টরিতে যেকোনও ফাইলের নাম দিয়ে রাখুন। যেমন, আপনার কোড <libraryroot>/src/main/kotlin-এ থাকলে, একটি কনজিউমার নিয়ম ফাইল <libraryroot>/src/main/resources/META-INF/proguard/consumer-proguard-rules.pro-এ রাখুন এবং আপনার আউটপুট JAR-এ সঠিক লোকেশনে নিয়মগুলি বান্ডেল করা হবে।

ফাইনাল JAR বান্ডেল সংক্রান্ত নিয়ম সঠিকভাবে যাচাই করতে, নিয়মগুলি META-INF/proguard ডিরেক্টরিতে আছে কিনা তা চেক করুন।

AAR লাইব্রেরি বিল্ড অপ্টিমাইজ করুন (উন্নত)

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

আপনি যদি এখনও বিল্ড করার সময় আপনার লাইব্রেরি অপ্টিমাইজ করতে চান, তাহলে এটি Android Gradle প্লাগ-ইন দ্বারা সমর্থিত।

Kotlin

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        configureEach {
            consumerProguardFiles("consumer-rules.pro")
        }
    }
}

গ্ৰুভি

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles
                getDefaultProguardFile('proguard-android-optimize.txt'),
                'proguard-rules.pro'
        }
        configureEach {
            consumerProguardFiles "consumer-rules.pro"
        }
    }
}

মনে রাখবেন যে proguardFiles-এর আচরণ consumerProguardFiles-এর থেকে খুব আলাদা:

  • proguardFiles বিল্ড করার সময় ব্যবহার করা হয়, প্রায়ই getDefaultProguardFile("proguard-android-optimize.txt")-এর সাথে, যাতে লাইব্রেরি বিল্ড করার সময় আপনার লাইব্রেরির কোন অংশ রাখা উচিত তা নির্ধারণ করা যায়। At a minimum, this is your public API.
  • consumerProguardFiles-এর বিপরীতে লাইব্রেরিতে প্যাকেজ করা হয়, যাতে পরে অপ্টিমাইজেশন করা যায়। এটি এমন অ্যাপ তৈরির সময় করা হয় যা আপনার লাইব্রেরি ব্যবহার করে।

যেমন, আপনার লাইব্রেরি যদি ইন্টার্নাল ক্লাস তৈরি করার জন্য রিফ্লেকশন ব্যবহার করে, তাহলে আপনাকে proguardFiles এবং consumerProguardFiles, দুটিতেই 'রাখুন' সংক্রান্ত নিয়ম নির্ধারণ করতে হতে পারে।

আপনার লাইব্রেরির বিল্ডে -repackageclasses ব্যবহার করলে, আপনার লাইব্রেরির প্যাকেজের মধ্যে সাব-প্যাকেজে ক্লাস রিপ্যাকেজ করুন। যেমন, -repackageclasses 'internal'-এর পরিবর্তে -repackageclasses 'com.example.mylibrary.internal' ব্যবহার করুন।

বিভিন্ন R8 ভার্সন সাপোর্ট করে (উন্নত)

R8-এর নির্দিষ্ট ভার্সনকে টার্গেট করার জন্য আপনি নিয়ম তৈরি করতে পারেন। এটি আপনার লাইব্রেরিকে নতুন R8 ভার্সন ব্যবহার করা প্রোজেক্টে সর্বোত্তমভাবে কাজ করতে সক্ষম করে, পাশাপাশি পুরনো R8 ভার্সন ব্যবহার করা প্রোজেক্টে বিদ্যমান নিয়মগুলি ব্যবহার করা চালিয়ে যাওয়ার অনুমতি দেয়।

টার্গেট করা R8 নিয়ম নির্দিষ্ট করতে, আপনাকে সেগুলি AAR-এর classes.jar-এর মধ্যে META-INF/com.android.tools ডিরেক্টরিতে অথবা JAR-এর META-INF/com.android.tools ডিরেক্টরিতে অন্তর্ভুক্ত করতে হবে।

In an AAR library:
    proguard.txt (legacy location, the file name must be "proguard.txt")
    classes.jar
    └── META-INF
        └── com.android.tools (location of targeted R8 rules)
            ├── r8-from-<X>-upto-<Y>/<R8-rule-files>
            └── ... (more directories with the same name format)

In a JAR library:
    META-INF
    ├── proguard/<ProGuard-rule-files> (legacy location)
    └── com.android.tools (location of targeted R8 rules)
        ├── r8-from-<X>-upto-<Y>/<R8-rule-files>
        └── ... (more directories with the same name format)

META-INF/com.android.tools ডিরেক্টরিতে, r8-from-<X>-upto-<Y>-এর মতো নামের একাধিক সাবডিরেক্টরি থাকতে পারে, যা থেকে বোঝা যায় যে কোন R8 ভার্সনের জন্য নিয়ম লেখা হয়েছে। প্রতিটি সাবডিরেক্টরিতে R8 নিয়ম সহ এক বা একাধিক ফাইল থাকতে পারে, যার যেকোনও ফাইলের নাম ও এক্সটেনশন থাকতে পারে।

মনে রাখবেন যে -from-<X> এবং -upto-<Y> অংশগুলি ঐচ্ছিক, <Y> ভার্সনটি এক্সক্লুসিভ এবং ভার্সনের রেঞ্জ সাধারণত একটানা হয়, তবে ওভারল্যাপও করতে পারে।

যেমন, r8, r8-upto-8.0.0, r8-from-8.0.0-upto-8.2.0 এবং r8-from-8.2.0 হল ডিরেক্টরির নাম যা টার্গেট করা R8 নিয়মের সেটকে দেখায়। r8 ডিরেক্টরির অধীনে থাকা নিয়মগুলি যেকোনও R8 ভার্সন ব্যবহার করতে পারে। r8-from-8.0.0-upto-8.2.0 ডিরেক্টরির নিয়মগুলি R8-এর 8.0.0 থেকে 8.2.0 ভার্সন পর্যন্ত ব্যবহার করা যাবে, তবে 8.2.0 ভার্সন অন্তর্ভুক্ত নয়।

Android Gradle প্লাগ-ইন সেই তথ্য ব্যবহার করে এমন সব নিয়ম বেছে নেয় যা বর্তমান R8 ভার্সন ব্যবহার করতে পারে। কোনও লাইব্রেরি টার্গেট করা R8 নিয়ম নির্দিষ্ট না করলে, Android Gradle প্লাগ-ইন পুরনো লোকেশন থেকে নিয়ম বেছে নেবে (proguard.txt AAR-এর জন্য অথবা META-INF/proguard/<ProGuard-rule-files> JAR-এর জন্য)।