১৬ কেবি পৃষ্ঠার সাইজ কাজ করে

ঐতিহাসিকভাবে, অ্যান্ড্রয়েড শুধুমাত্র 4 KB মেমরি পৃষ্ঠার আকার সমর্থন করে, যা অ্যান্ড্রয়েড ডিভাইসে সাধারণত থাকা মোট মেমরির গড় পরিমাণের জন্য সিস্টেম মেমরির কার্যকারিতা অপ্টিমাইজ করেছে। অ্যান্ড্রয়েড 15 দিয়ে শুরু করে, AOSP 16 KB (16 KB ডিভাইস) এর পৃষ্ঠার আকার ব্যবহার করার জন্য কনফিগার করা ডিভাইসগুলিকে সমর্থন করে। যদি আপনার অ্যাপটি SDK-এর মাধ্যমে প্রত্যক্ষ বা পরোক্ষভাবে কোনও NDK লাইব্রেরি ব্যবহার করে, তাহলে এই 16 KB ডিভাইসে কাজ করার জন্য আপনাকে আপনার অ্যাপটি পুনর্নির্মাণ করতে হবে।

যেহেতু ডিভাইস নির্মাতারা বৃহত্তর পরিমাণে ভৌত মেমরি (RAM) সহ ডিভাইসগুলি তৈরি করতে থাকে, এই ডিভাইসগুলির মধ্যে অনেকগুলি ডিভাইসের কার্যকারিতা অপ্টিমাইজ করার জন্য 16 KB (এবং শেষ পর্যন্ত আরও বড়) পৃষ্ঠার আকার গ্রহণ করবে। 16 KB পৃষ্ঠার আকারের ডিভাইসগুলির জন্য সমর্থন যোগ করা আপনার অ্যাপটিকে এই ডিভাইসগুলিতে চালানোর জন্য সক্ষম করে এবং আপনার অ্যাপটিকে সংশ্লিষ্ট কর্মক্ষমতা উন্নতি থেকে উপকৃত হতে সাহায্য করে। পুনরায় কম্পাইল করা ছাড়া, অ্যাপগুলি ভবিষ্যতের Android রিলিজে 16 KB ডিভাইসে কাজ করবে না।

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

Google Play-এর সাথে মানানসই হওয়ার প্রয়োজনীয়তা

Android-এর লেটেস্ট ভার্সনে আপনার অ্যাপ যাতে সঠিকভাবে কাজ করে তা নিশ্চিত করতে, Android 15 (API লেভেল 35) এবং তার পরবর্তী ভার্সনকে টার্গেট করা সব অ্যাপকে Google Play-তে 64-বিট ডিভাইসে 16 কেবি মেমরি পৃষ্ঠা সাইজকে অবশ্যই সাপোর্ট করতে হবে। ১ ফেব্রুয়ারি, ২০২৭ থেকে, আপনার অ্যাপ আপডেট ১৬ কেবি মেমরি পৃষ্ঠা সাইজ সাপোর্ট না করলে, আপনি এইসব আপডেট রিলিজ করতে পারবেন না।

ছবি ১. Google Play Console-এর কম্প্যাটিবিলিটি সংক্রান্ত সতর্কতা।

সুবিধা ও পারফর্ম্যান্সের উন্নতি

16 KB পৃষ্ঠার আকারের সাথে কনফিগার করা ডিভাইসগুলি গড়ে সামান্য বেশি মেমরি ব্যবহার করে, তবে সিস্টেম এবং অ্যাপ উভয়ের জন্য বিভিন্ন কর্মক্ষমতা উন্নতিও লাভ করে:

• সিস্টেম মেমরির চাপে থাকাকালীন অ্যাপ লঞ্চের সময় কম: গড়ে 3.16% কম, কিছু অ্যাপের জন্য আরও উল্লেখযোগ্য উন্নতি (30% পর্যন্ত) যা আমরা পরীক্ষা করেছি
• অ্যাপ লঞ্চের সময় পাওয়ার ড্র কম হয়েছে: গড়ে 4.56% হ্রাস
• দ্রুত ক্যামেরা লঞ্চ: গড়ে 4.48% দ্রুত গরম শুরু হয় এবং গড়ে 6.60% দ্রুত ঠান্ডা শুরু হয়
• উন্নত সিস্টেম বুট সময়: গড়ে 8% (প্রায় 950 মিলিসেকেন্ড) দ্বারা উন্নত

এই উন্নতিগুলি আমাদের প্রাথমিক পরীক্ষার উপর ভিত্তি করে করা হয়েছে এবং প্রকৃত ডিভাইসগুলির ফলাফলগুলি সম্ভবত আলাদা হতে পারে৷ আমরা আমাদের পরীক্ষা চালিয়ে যাওয়ার সাথে সাথে অ্যাপগুলির সম্ভাব্য লাভের অতিরিক্ত বিশ্লেষণ প্রদান করব।

আপনার অ্যাপ প্রভাবিত হয়েছে কিনা তা চেক করুন

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

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

আপনার অ্যাপ কি নেটিভ কোড ব্যবহার করে?

নিম্নলিখিতগুলির মধ্যে কোনওটি প্রযোজ্য হলে, আপনার অ্যাপ নেটিভ কোড ব্যবহার করে:

• আপনার অ্যাপ যেকোনও C/C++ (নেটিভ) কোড ব্যবহার করে। আপনার অ্যাপ যদি Android NDK ব্যবহার করে, তাহলে আপনার অ্যাপ নেটিভ কোড ব্যবহার করে।
• আপনার অ্যাপ কোনও থার্ড-পার্টি নেটিভ লাইব্রেরি বা ডিপেন্ডেন্সির (যেমন SDK) সাথে লিঙ্ক করে যা সেগুলি ব্যবহার করে।
• আপনার অ্যাপটি থার্ড-পার্টি অ্যাপ বিল্ডার দ্বারা তৈরি করা হয়েছে যা ডিভাইসে নেটিভ লাইব্রেরি ব্যবহার করে।

APK Analyzer ব্যবহার করে নেটিভ লাইব্রেরি শনাক্ত করা

APK Analyzer হল এমন একটি টুল যা আপনাকে বিল্ট APK-এর বিভিন্ন দিক মূল্যায়ন করতে দেয়। আপনার অ্যাপ নেটিভ কোড ব্যবহার করে কিনা তা চেক করতে (এটি ১৬ কেবির সাথে মানানসই কিনা তা নির্বিশেষে):

1. Android Studio খুলে ফাইল > খুলুন বিকল্পে ক্লিক করুন এবং যেকোনও প্রোজেক্ট বেছে নিন।

2. মেনু বার থেকে, বিল্ড > APK বিশ্লেষণ করুন... বিকল্পে ক্লিক করুন

   

3. আপনি যে APK বিশ্লেষণ করতে চান সেটি বেছে নিন।

4. lib ফোল্ডারের মধ্যে দেখুন, যেখানে শেয়ার করা অবজেক্ট (.so) ফাইল হোস্ট করা থাকে, যদি কোনও ফাইল উপস্থিত থাকে। কোনও শেয়ার করা অবজেক্ট ফাইল থাকলে, আপনার অ্যাপ নেটিভ কোড ব্যবহার করে। অ্যালাইনমেন্ট কলামে অ্যালাইনমেন্ট সংক্রান্ত সমস্যা আছে এমন ফাইলের জন্য সতর্কতামূলক মেসেজ দেখানো হয়। কোনও শেয়ার করা অবজেক্ট ফাইল না থাকলে বা lib ফোল্ডার না থাকলে, আপনার অ্যাপ নেটিভ কোড ব্যবহার করে না।

   

অটোমেটেড চেকের মাধ্যমে অ্যালাইনমেন্ট সংক্রান্ত সমস্যা শনাক্ত করুন

আপনার আগে থেকে তৈরি লাইব্রেরি বা APK ১৬ কেবি-র সাথে মানানসই না হলে, Android Studio আপনাকে আগে থেকেই সতর্ক করে দেয়। কোন লাইব্রেরি আপডেট করতে হবে বা কোনও কোড পরিবর্তন করতে হবে কিনা তা পর্যালোচনা করতে APK Analyzer টুল ব্যবহার করুন।

Android Studio-তে Lint সেইসব নেটিভ লাইব্রেরিও হাইলাইট করে যেগুলি ১৬ কেবি সাইজের সাথে অ্যালাইন করা নেই।

শেয়ার করা লাইব্রেরির জন্য ELF সেগমেন্টের অ্যালাইনমেন্ট চেক করুন

যেকোনও শেয়ার করা লাইব্রেরির ক্ষেত্রে, ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে শেয়ার করা লাইব্রেরির ELF সেগমেন্ট সঠিকভাবে অ্যালাইন করা হয়েছে কিনা তা যাচাই করুন।

APK Analyzer ব্যবহার করুন (সাজেস্ট করা হয়েছে)

আপনার শেয়ার করা লাইব্রেরির অ্যালাইনমেন্ট যাচাই করার সবচেয়ে সহজ উপায় হল Android Studio-তে APK Analyzer ব্যবহার করা। কোনও শেয়ার করা অবজেক্ট ফাইল ১৬ কেবি অ্যালাইন করা না থাকলে, অ্যালাইনমেন্ট কলামে একটি সতর্কতামূলক মেসেজ দেখানো হবে।

check_elf_alignment.sh স্ক্রিপ্ট (Linux বা macOS) ব্যবহার করুন

আপনি যদি Linux বা macOS-এ ডেভেলপ করেন এবং স্ক্রিপ্ট ব্যবহার করতে চান, তাহলে আপনি check_elf_alignment.sh স্ক্রিপ্ট ব্যবহার করতে পারেন:

1. check_elf_alignment.sh স্ক্রিপ্টটি একটি ফাইলে সেভ করুন।

2. আপনার অ্যাপের APK ফাইলে স্ক্রিপ্ট রান করুন:

   check_elf_alignment.sh APK_NAME.apk
   

   স্ক্রিপ্টটি সমস্ত arm64-v8a শেয়ার করা লাইব্রেরির জন্য ALIGNED বা UNALIGNED আউটপুট দেয়।

3. কোনও arm64-v8a বা x86_64 শেয়ার করা লাইব্রেরি UNALIGNED হলে, আপনাকে সেইসব লাইব্রেরির প্যাকেজিং আপডেট করতে হবে, তারপর আপনার অ্যাপ রিকম্পাইল করতে হবে এবং এই বিভাগের ধাপগুলি অনুসরণ করে আবার পরীক্ষা করতে হবে।

সরাসরি কমান্ড-লাইন টুল ব্যবহার করুন

সরাসরি কমান্ড-লাইন টুল ব্যবহার করে ELF সেগমেন্টের অ্যালাইনমেন্ট চেক করতে, এই ধাপগুলি অনুসরণ করুন:

1. Android SDK বিল্ড-টুল ভার্সন 35.0.0 বা তার পরবর্তী ভার্সন এবং Android NDK, উভয়ই Android Studio-তে SDK Manager বা sdkmanager কমান্ড-লাইন টুল ব্যবহার করে ইনস্টল করা হয়েছে কিনা তা নিশ্চিত করুন।

2. আপনার অ্যাপের APK ফাইল এক্সট্র্যাক্ট করুন:

   Linux বা macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. আপনি যে অস্থায়ী ডিরেক্টরিতে APK ফাইল এক্সট্র্যাক্ট করেছেন, সেখানে শেয়ার করা অবজেক্ট (.so) ফাইলের জন্য lib ডিরেক্টরির কন্টেন্ট চেক করুন। APK Analyzer ব্যবহার করে নেটিভ লাইব্রেরি শনাক্ত করার সময় আপনি যে শেয়ার করা অবজেক্ট ফাইলগুলি দেখতে পেতেন, এগুলিও ঠিক একই রকম। প্রতিটি শেয়ার করা অবজেক্ট ফাইলে নিম্নলিখিত কমান্ড রান করুন:

   Linux বা macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   যেখানে SDK_ROOT_LOCATION হল সেই ডিরেক্টরির পাথ যেখানে আপনি Android SDK ইনস্টল করেছেন, SHARED_OBJECT_FILE হল আপনি যে শেয়ার করা অবজেক্ট ফাইলটি চেক করছেন সেটির নাম এবং NDK_VERSION হল আপনার ইনস্টল করা Android NDK-এর ভার্সন (যেমন, 28.0.12433566)। আপনি চেক করছেন এমন প্রতিটি ফাইলের জন্য আউটপুটটি নিম্নলিখিতটির মতো দেখাবে:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. লোড সেগমেন্টের ভ্যালু 2**14-এর কম কিনা তা নিশ্চিত করতে আউটপুট লাইন চেক করুন। কোনও লোড সেগমেন্ট 2**13, 2**12 বা তার থেকে কম মানের হলে, আপনাকে সেইসব লাইব্রেরির প্যাকেজিং আপডেট করতে হবে, তারপর আপনার অ্যাপ রিকম্পাইল করতে হবে এবং এই বিভাগের ধাপগুলি অনুসরণ করে আবার পরীক্ষা করতে হবে।

5. এরপর, আপনার অ্যাপের APK ফাইলে zipalign কমান্ড-লাইন টুল রান করুন:

   Linux বা macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   যেখানে SDK_ROOT_LOCATION হল সেই ডিরেক্টরির পাথ যেখানে আপনি Android SDK ইনস্টল করেছেন এবং APK_NAME হল আপনার অ্যাপের APK ফাইলের নাম। সব শেয়ার করা লাইব্রেরি সঠিকভাবে অ্যালাইন করা থাকলে, আউটপুটের শেষ লাইনে "যাচাইকরণ সম্পূর্ণ হয়েছে" লেখা থাকবে।

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

RELRO নিরাপত্তা ফ্ল্যাগ চেক করুন

নিরাপত্তা সংক্রান্ত এক্সপ্লয়েট কমাতে, আধুনিক লিঙ্কার রিলোকেশন রিড-ওনলি (RELRO) ফ্ল্যাগ ব্যবহার করে যাতে ডায়নামিক রিলোকেশন সম্পূর্ণ হওয়ার পরে শেয়ার করা অবজেক্ট ফাইলের রিলোকেশন টার্গেট সেকশন (যেমন .got এবং .data.rel.ro) রিড-ওনলি করা যায়। আপনার বিল্ডে RELRO ফ্ল্যাগ চালু করুন।

GNU_RELRO যখন পরবর্তী রাইটেবল ডেটা সহ রাইটেবল LOAD সেগমেন্ট শেয়ার করে (যেমন .data বা .bss), তখন GNU_RELRO সেগমেন্টের শেষ অ্যাড্রেস (VirtAddr + MemSiz) অবশ্যই ১৬ কেবি অ্যালাইন করা (0x4000) হতে হবে। অন্যথায়, Android লিঙ্কার যখন GNU_RELRO-এর শেষ অংশ সহ ১৬ কেবি পৃষ্ঠাকে শুধুমাত্র পাঠযোগ্য হিসেবে চিহ্নিত করে, তখন একই ১৬ কেবি পৃষ্ঠার বাকি অংশে থাকা যেকোনও সংলগ্ন রাইটেবল ডেটাও শুধুমাত্র পাঠযোগ্য হয়ে যায়, যার ফলে সেই ডেটা লেখার সময় রানটাইমে সেগমেন্টেশন ফল্ট (SIGSEGV) সহ অ্যাপ ক্র্যাশ করে। .so ফাইলটি NDK টুলচেন r27 এবং তার নিচের ভার্সন দিয়ে তৈরি করা হলে এবং প্রাসঙ্গিক ফ্ল্যাগ চালু না করা হলে সাধারণত এটি ঘটে।

APK Analyzer ব্যবহার করুন (সাজেস্ট করা হয়েছে)

আপনি Android Studio-তে APK Analyzer ব্যবহার করে সরাসরি আপনার শেয়ার করা অবজেক্ট ফাইলের RELRO অ্যালাইনমেন্ট স্ট্যাটাস চেক করতে পারবেন।

কমান্ড-লাইন টুল ব্যবহার করা

আপনি যদি ম্যানুয়ালি অ্যালাইনমেন্ট চেক করতে চান বা প্রসেসটি অটোমেট করতে চান, তাহলে এইসব ধাপ অনুসরণ করুন:

ধাপ ১: প্রোগ্রাম হেডার পরীক্ষা করা

প্রতিটি শেয়ার করা অবজেক্ট ফাইলে নিম্নলিখিত কমান্ড রান করুন (Linux-এ, darwin-x86_64-এর পরিবর্তে linux-x86_64 লিখুন):

Linux বা macOS

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'LOAD\|RELRO\|Type'

Windows (PowerShell)

SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-readelf.exe -Wl SHARED_OBJECT_FILE.so | Select-String -Pattern 'LOAD|RELRO|Type'

RELRO সেগমেন্ট থাকলে GNU_RELRO স্ট্রিং প্রিন্ট করা হয়।

ধাপ ২: RELRO-এর জন্য ১৬ কেবি কমপ্লায়েন্স যাচাই করা

একটি শেয়ার করা অবজেক্ট ফাইল RELRO-এর ক্ষেত্রে ১৬ কেবি-র সাথে মানানসই হয় যদি নিম্নলিখিত শর্তগুলির মধ্যে যেকোনও একটি পূরণ করা হয়:

1. প্রোগ্রাম হেডারে কোনও GNU_RELRO সেগমেন্ট নেই।
2. GNU_RELRO-এর শেষ ঠিকানা ১৬ কেবি অ্যালাইন করা: এটির ভার্চুয়াল অ্যাড্রেস (VirtAddr) ও মেমরি সাইজের (MemSiz) যোগফলকে ১৬ কেবি (0x4000) দিয়ে ভাগ করলে ভাগশেষ (মডিউলো) শূন্য হয়: (VirtAddr + MemSiz) % 0x4000 == 0.
3. একই LOAD সেগমেন্টে GNU_RELRO-এর পরে কোনও রাইটেবল ডেটা নেই: GNU_RELRO তার LOAD সেগমেন্টের বাকি পুরো অংশ দখল করে (যার অর্থ LOAD.VirtAddr + LOAD.MemSiz == RELRO.VirtAddr + RELRO.MemSiz), তাই কোনও রাইটেবল .data বা .bss বিভাগ ট্রেলিং পৃষ্ঠা শেয়ার করে না।

---

উদাহরণ

নিম্নলিখিত উদাহরণগুলি দেখায় যে কীভাবে বিভিন্ন GNU_RELRO কনফিগারেশনের জন্য llvm-readelf আউটপুট মূল্যায়ন করতে হয়।

উদাহরণ ১: সারিবদ্ধ নয় এমন .so ফাইল (নীতি মেনে চলে না)

এই উদাহরণে, GNU_RELRO পরবর্তী লেখার যোগ্য ডেটার সাথে RW LOAD সেগমেন্ট শেয়ার করে এবং এর শেষ অ্যাড্রেস 0x4000-এর গুণিতক নয়:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0cfaf0 0x0cfaf0 R E 0x4000
LOAD           0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x02510 0x04510 RW  0x4000
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

• ফর্মুলা: (VirtAddr + MemSiz) % 0x4000 == 0
• ফলাফল: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

যেহেতু 0x1000 শূন্য নয় এবং LOAD সেগমেন্ট 0xE1000-এর পরেও (0xdfaf0 + 0x04510 = 0xE4000-এ শেষ হচ্ছে) চলছে, তাই এই .so ফাইল ১৬ কেবি কমপ্লায়েন্ট নয়। ১৬ কেবি ডিভাইসে, লিঙ্কার RELRO সুরক্ষা রেঞ্জকে ১৬ কেবি পেজ বাউন্ডারিতে রাউন্ড করে, 0xDC000 (আগের পেজ ব্রেক) থেকে 0xE4000 পর্যন্ত শুধু-পড়ার-জন্য হিসেবে চিহ্নিত করে। তবে, .so ফাইলের রাইটেবল .data এবং .bss বিভাগ 0xE1000 থেকে 0xE4000-এর সাব-রেঞ্জে থাকে, যার ফলে রানটাইমে পরিবর্তন করা হলে সেগমেন্টেশন ফল্ট হয়। ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে আপনার অ্যাপ কম্পাইল করুন বিভাগে যেমন বর্ণনা করা হয়েছে সেই অনুযায়ী এই .so ফাইল আবার তৈরি করুন।

উদাহরণ ২: RELRO সেগমেন্টের সাথে অ্যালাইন করা .so ফাইল (মানানসই)

এই উদাহরণে, GNU_RELRO সেগমেন্টের শেষ অংশ ১৬ কেবি পৃষ্ঠার সীমানায় পড়ে:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0cfaf0 0x0cfaf0 R E 0x4000
LOAD           0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x03510 RW  0x4000
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x00510 0x00510 R   0x1

• ফর্মুলা: (VirtAddr + MemSiz) % 0x4000 == 0
• ফলাফল: (0xdfaf0 + 0x00510) % 0x4000 = 0xE0000 % 0x4000 == 0

যেহেতু অবশিষ্ট হল 0, তাই RELRO সুরক্ষা 0xE0000 পৃষ্ঠার সীমানায় পরিষ্কারভাবে শেষ হয়, 0xE0000 থেকে শুরু হওয়া যেকোনও লেখার যোগ্য ডেটা প্রভাবিত হয় না।

উদাহরণ ৩: RELRO সেগমেন্ট ছাড়া .so ফাইল (মানানসই)

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000680 0x000680 R E 0x4000
LOAD           0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x0001d8 RW  0x4000

এই .so ফাইলে কোনও GNU_RELRO সেগমেন্ট নেই, তাই RELRO পৃষ্ঠা-সীমানা সংক্রান্ত সমস্যা প্রযোজ্য নয় (যদিও নিরাপত্তার জন্য RELRO চালু করার সাজেশন এখনও দেওয়া হয়)।

উদাহরণ ৪: GNU_RELRO তার নিজস্ব LOAD সেগমেন্টে (নীতি মেনে চলে)

এই উদাহরণে, GNU_RELRO ১৬ কেবি সীমানায় শেষ হয় না, তবে এটি এখনও মানানসই কারণ একই LOAD সেগমেন্টে কোনও লেখার যোগ্য ডেটা এটিকে অনুসরণ করে না:

Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x000680 0x000680 R E 0x4000
LOAD           0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 RW  0x4000
GNU_RELRO      0x000680 0x0000000000004680 0x0000000000004680 0x0001d8 0x000980 R   0x1

• ফর্মুলা: (VirtAddr + MemSiz) % 0x4000 == 0
• ফলাফল: (0x4680 + 0x0980) % 0x4000 = 0x5000 % 0x4000 == 0x1000

0x1000 শূন্য না হলেও, এই .so ফাইলটি এখনও ১৬ কেবি কমপ্লায়েন্ট। GNU_RELRO-এর সাথে এর মধ্যে থাকা LOAD সেগমেন্ট (দ্বিতীয় LOAD এন্ট্রি) তুলনা করে দেখা গেছে যে দুটিই VirtAddr 0x4680-এ শুরু হয় এবং ঠিক একই ঠিকানায় (0x4680 + 0x0980 = 0x5000) শেষ হয়।

যেহেতু সম্পূর্ণ LOAD সেগমেন্টে শুধুমাত্র RELRO ডেটা আছে, তাই 0x5000 থেকে 0x8000 পর্যন্ত সাব-রেঞ্জে কোনও রাইটেবল .data বা .bss ডেটা নেই (হয় লাইব্রেরিতে কোনও নন-RELRO রাইটেবল ডেটা নেই অথবা পরবর্তী কোনও রাইটেবল LOAD সেগমেন্ট 0x8000 বা তার পরে আলাদা ১৬ কেবি পৃষ্ঠা সীমানায় শুরু হয়)। লিঙ্কারের রিড-অনলি সুরক্ষা কোনও রাইটেবল ডেটার সাথে ওভারল্যাপ করবে না, তাই কোনও সেগমেন্টেশন ফল্ট হবে না।

১৬ কেবি ডিভাইসের জন্য সাপোর্ট সহ আপনার অ্যাপ তৈরি করুন

আপনার অ্যাপ নেটিভ কোড ব্যবহার করলে, আপনার অ্যাপ ১৬ কেবি ডিভাইস সাপোর্ট করে কিনা তা নিশ্চিত করতে নিম্নলিখিত বিভাগে উল্লেখ করা ধাপগুলি সম্পূর্ণ করুন:

1. আপনার শেয়ার করা লাইব্রেরির প্যাকেজিং আপডেট করুন
2. ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে আপনার অ্যাপ কম্পাইল করুন
3. কোড ঠিক করা এবং রানটাইম সংক্রান্ত সমস্যার সমাধান করা
4. কাস্টম মেমরি অ্যালোকেটর অপ্টিমাইজ করুন (প্রযোজ্য হলে)
5. ১৬ কেবি সাপোর্টের জন্য SDK চেক করুন

পরামর্শ: আপনি যদি টুলগুলি লেটেস্ট ভার্সনে (AGP ভার্সন 8.5.1 বা তার পরবর্তী এবং NDK ভার্সন r28 বা তার পরবর্তী) আপডেট করেন এবং ১৬ কেবি-র সাথে মানানসই প্রি-বিল্ট ডিপেন্ডেন্সি ব্যবহার করেন, তাহলে আপনার অ্যাপ ডিফল্ট হিসেবে ১৬ কেবি-র সাথে মানানসই হবে এবং আপনি কোড ঠিক করা এবং রানটাইম সংক্রান্ত সমস্যার সমাধান করা সংক্রান্ত ধাপটি এড়িয়ে যেতে পারবেন।

আপনার শেয়ার করা লাইব্রেরির প্যাকেজিং আপডেট করুন

AGP ভার্সন 8.5.1 বা তার পরবর্তী ভার্সনে আপগ্রেড করুন এবং কম্প্রেস করা নয় এমন শেয়ার করা লাইব্রেরি ব্যবহার করুন।

জিপ অ্যালাইনমেন্ট যাচাই করতে bundletool ব্যবহার করুন

আপনার বান্ডেলের অ্যালাইনমেন্ট দেখতে, এটি ব্যবহার করুন:

bundletool dump config --bundle=<my .aab>  | grep alignment

আপনি PAGE_ALIGNMENT_16K দেখতে পেলে, আপনার বান্ডেল ১৬ কেবি জিপ অ্যালাইনমেন্টের অনুরোধ করে। আপনি PAGE_ALIGNMENT_4K দেখতে পেলে, এটি এই AAB থেকে তৈরি করা APK-কে জিপ ফাইলে .so ফাইল ৪ কেবি অ্যালাইন করার নির্দেশ দেয়।

AGP ভার্সন 8.5.1 বা তার পরবর্তী যেকোনও ভার্সন

১৬ কেবি ডিভাইসে এমন অ্যাপের প্রয়োজন হয় যা আনকমপ্রেসড শেয়ার করা লাইব্রেরির সাথে আসে যাতে সেগুলিকে ১৬ কেবি জিপ-অ্যালাইনড বাউন্ডারিতে অ্যালাইন করা যায়। এটি করতে, আপনাকে Android Gradle Plugin (AGP) ভার্সন 8.5.1 বা তার পরবর্তী যেকোনও ভার্সনে আপগ্রেড করতে হবে। আপগ্রেড করার প্রসেস সম্পর্কে বিস্তারিত জানতে Android Gradle প্লাগ-ইন আপগ্রেড অ্যাসিস্ট্যান্ট বিভাগ দেখুন।

AGP ভার্সন 8.5 বা তার আগের যেকোনও ভার্সন

মনে রাখবেন: AGP ভার্সন ৮.৩ থেকে ৮.৫-এ, অ্যাপ ডিফল্ট হিসেবে ১৬ কেবি অ্যালাইন করা থাকে। তবে, bundletool ডিফল্ট হিসেবে APK-কে zipalign করে না। তাই, অ্যাপটি কাজ করছে বলে মনে হতে পারে, কিন্তু Play-তে বান্ডেল থেকে তৈরি করা হলে, এটি ইনস্টল হবে না।

আপনি যদি AGP-কে 8.5.1 বা তার পরবর্তী ভার্সনে আপগ্রেড করতে না পারেন, তাহলে বিকল্প হিসেবে কম্প্রেস করা শেয়ার্ড লাইব্রেরি ব্যবহার করতে পারেন। আপনার অ্যাপ প্যাকেজ করার সময়, শেয়ার করা লাইব্রেরি যাতে Gradle কম্প্রেস করে, তার জন্য আপনার Gradle কনফিগারেশন আপডেট করুন। এর ফলে, শেয়ার করা লাইব্রেরি অ্যালাইন না হওয়ার কারণে অ্যাপ ইনস্টল করার সময় হওয়া সমস্যা এড়ানো যাবে।

গ্ৰুভি

আপনার build.gradle ফাইলে, নিম্নলিখিত বিকল্প যোগ করুন:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

Kotlin

আপনার build.gradle.kts ফাইলে, নিম্নলিখিত বিকল্প যোগ করুন:

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

AGP ভার্সন 8.0 বা তার আগের যেকোনও ভার্সন

আপনি যদি 8.0 বা তার আগের কোনও AGP ভার্সন ব্যবহার করেন, তাহলে আপনাকে আপনার gradle.properties ফাইলে অ্যাপ বান্ডেলের জন্য আনকমপ্রেসড নেটিভ লাইব্রেরি বিকল্পটি বন্ধ করতে হবে:

android.bundle.enableUncompressedNativeLibs=false

সতর্কতা: আপনি কম্প্রেস করা শেয়ার্ড লাইব্রেরি ব্যবহার করলে, আপনার অ্যাপ ইনস্টল করার সময় আরও বেশি জায়গা নেয়, কারণ লাইব্রেরি APK থেকে এক্সট্র্যাক্ট করে ডিস্কে কপি করা হয়। আপনার অ্যাপ ইনস্টল করার সময় আরও ঘনঘন সমস্যা হতে পারে কারণ ডিস্কের ব্যবহার বেড়ে যাওয়ার অর্থ হল ডিভাইসে কম জায়গা থাকা। এটি এড়াতে, AGP ভার্সন 8.5.1 বা তার পরবর্তী যেকোনও ভার্সনে আপগ্রেড করুন।

১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে আপনার অ্যাপ কম্পাইল করুন

১৬ কেবি ডিভাইসে আপনার অ্যাপ চালানোর জন্য ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে শেয়ার করা লাইব্রেরির ELF সেগমেন্ট সঠিকভাবে অ্যালাইন করতে হবে।

গেম ডেভেলপারদের জন্য, আপনার গেম যদি Unity গেম ইঞ্জিনের উপরে চলে, তাহলে Unity গাইড দেখুন। আপনার গেম Unreal গেম ইঞ্জিন-এর উপরে রান করলে, Unreal গাইড দেখুন। নেটিভ গেম ইঞ্জিনের জন্য, এই গাইডটি অনুসরণ করা চালিয়ে যান।

মনে রাখবেন: আপনার অ্যাপ ফাইল সিস্টেমে নেটিভ লাইব্রেরি এক্সট্র্যাক্ট না করলে (extractNativeLibs false-এ সেট করা), ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে কম্পাইল করার পরে আপনার অ্যাপের বাইনারি সাইজ সামান্য বৃদ্ধি পেতে পারে। Android 15-এ প্যাকেজ ম্যানেজারের অপ্টিমাইজেশন এই বৃদ্ধির ফলে হওয়া রানটাইম খরচকে বাতিল করে দেয়।

১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে আপনার অ্যাপ কম্পাইল করতে, আপনি Android NDK-এর যে ভার্সন ব্যবহার করছেন তার উপর নির্ভর করে নিম্নলিখিত বিভাগগুলির মধ্যে একটির ধাপগুলি সম্পূর্ণ করুন।

গুরুত্বপূর্ণ: আপনার অ্যাপ কোনও আগে থেকে তৈরি করা শেয়ার করা লাইব্রেরি ব্যবহার করলে, আপনাকেও একইভাবে সেগুলি রিকম্পাইল করতে হবে এবং আপনার অ্যাপে ১৬ কেবি-অ্যালাইন করা লাইব্রেরি আবার ইমপোর্ট করতে হবে।

Android NDK r28 এবং তার পরবর্তী যেকোনও ভার্সন

NDK ভার্সন r28 এবং তার পরবর্তী ভার্সন ডিফল্ট হিসেবে ১৬ কেবি-অ্যালাইনড কম্পাইল করে।

Android NDK r27 ও এর আগের যেকোনও ভার্সন

Android NDK ভার্সন r27 বা তার আগের ভার্সনের সাথে ১৬ কেবি-অ্যালাইন করা শেয়ার করা লাইব্রেরি কম্পাইল করার জন্য, নিম্নলিখিত লিঙ্কার ফ্ল্যাগ ব্যবহার করুন:

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

আপনার বিল্ড সিস্টেম কনফিগারেশন ফাইল কীভাবে আপডেট করবেন তা এখানে দেওয়া হল:

ndk-build

আপনি ndk-build ব্যবহার করলে, ১৬ কেবি ELF অ্যালাইনমেন্ট চালু করতে আপনার Android.mk আপডেট করুন:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

CMake

আপনি CMake ব্যবহার করলে, ১৬ কেবি ELF চালু করতে আপনার CMakeLists.txt আপডেট করুন

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

মনে রাখবেন: আপনার অ্যাপ NDKs r26 এবং তার নিচের ভার্সন থেকে C++ স্ট্যান্ডার্ড লাইব্রেরির (libc++_shared.so) সাথে ডায়নামিকভাবে লিঙ্ক করা থাকলেও, যার মধ্যে কয়েকটিতে ১৬ কেবি অ্যালাইন করা libc++_shared.so নেই, তবুও আপনাকে এখানে অন্যান্য সব লাইব্রেরির অ্যালাইনমেন্ট আপডেট করতে হবে এবং PAGE_SIZE-এর উপর নির্ভরতা এড়াতে আপনার কোড আপডেট করতে হবে। ১৬ কেবি ডিভাইসে NDK-এর পুরনো ভার্সনে টেস্ট করার জন্য, LTS NDK ভার্সন r23 এবং r25-এর ক্যানারি রিলিজ ১৬ কেবি অ্যালাইন করা libc++_shared.so লাইব্রেরি সহ Android CI-তে উপলভ্য।

মনে রাখবেন: আপনি নতুন Android NDK-তে যেতে না পারলে, আপনার শেয়ার করা লাইব্রেরিতে C++ স্ট্যান্ডার্ড লাইব্রেরি স্ট্যাটিক্যালি কম্পাইল করার জন্য আপনার অ্যাপ আপডেট করতে পারবেন। C++ স্ট্যান্ডার্ড লাইব্রেরির সাথে স্ট্যাটিক্যালি লিঙ্ক করার বিষয়ে বিস্তারিত জানতে C++ লাইব্রেরি সহায়তা বিভাগটি দেখুন এবং গুরুত্বপূর্ণ বিবেচ্য বিষয় বিভাগটি পড়তে ভুলবেন না।

কোড ঠিক করুন এবং রানটাইম সংক্রান্ত সমস্যার সমাধান করুন

আপনার অ্যাপ ১৬ কেবি-অ্যালাইনড হলেও, আপনার কোডের কোনও জায়গায় যদি ধরে নেওয়া হয় যে ডিভাইসটি নির্দিষ্ট পেজ সাইজ ব্যবহার করছে, তাহলে আপনার অ্যাপে সমস্যা হতে পারে। এটি এড়াতে, নিম্নলিখিত ধাপগুলি সম্পূর্ণ করুন:

1. PAGE_SIZE কনস্ট্যান্ট বা আপনার কোড লজিকের ইনস্ট্যান্সকে রেফারেন্স করে এমন যেকোনও হার্ড-কোডেড ডিপেন্ডেন্সি সরিয়ে দিন, যা ধরে নেয় যে ডিভাইসের পৃষ্ঠা সাইজ হল ৪ কেবি (4096)।

   পরিবর্তে getpagesize() বা sysconf(_SC_PAGESIZE) ব্যবহার করুন।

2. mmap() এবং অন্যান্য API-এর ব্যবহার খুঁজুন যেগুলির জন্য পৃষ্ঠা-সারিবদ্ধ আর্গুমেন্ট প্রয়োজন এবং যেখানে প্রয়োজন সেখানে বিকল্প দিয়ে প্রতিস্থাপন করুন।

কিছু ক্ষেত্রে, আপনার অ্যাপ যদি PAGE_SIZE-কে এমন একটি সুবিধাজনক ভ্যালু হিসেবে ব্যবহার করে যা অন্তর্নিহিত পৃষ্ঠার সাইজের সাথে যুক্ত নয়, তাহলে ১৬ কেবি মোডে ব্যবহার করার সময় এটি আপনার অ্যাপকে ব্রেক করবে না। তবে, এই ভ্যালু কার্নেলে mmap-এর সাথে MAP_FIXED ছাড়া পাস করা হলে, কার্নেল এখনও পুরো পৃষ্ঠা ব্যবহার করে, যা কিছু মেমরি নষ্ট করে। এইসব কারণে, NDK r27 এবং তার পরবর্তী যেকোনও ভার্সনে ১৬ কেবি মোড চালু করা থাকলে, PAGE_SIZE সংজ্ঞায়িত করা হয় না।

আপনার অ্যাপ যদি এইভাবে PAGE_SIZE ব্যবহার করে এবং এই ভ্যালু সরাসরি কার্নেলে পাস না করে, তাহলে PAGE_SIZE ব্যবহার করার পরিবর্তে, নতুন নাম দিয়ে একটি নতুন ভেরিয়েবল তৈরি করুন যাতে বোঝা যায় যে এটি অন্য উদ্দেশ্যে ব্যবহার করা হয়েছে এবং আসল মেমরি পৃষ্ঠা দেখায় না।

কাস্টম মেমরি অ্যালোকেটর অপ্টিমাইজ করা

মনে রাখবেন: এই বিভাগটি শুধুমাত্র তখনই প্রযোজ্য হবে যদি আপনার অ্যাপ, গেম ইঞ্জিন বা নেটিভ লাইব্রেরি কাস্টম মেমরি ম্যানেজার, হিপ বা স্ল্যাব অ্যালোকেটর (যেমন কাস্টম গেম ইঞ্জিন, এম্বেড করা ডেটাবেস বা রানটাইম এম্বেডিং jemalloc বা mimalloc) প্রয়োগ করে। আপনার অ্যাপ স্ট্যান্ডার্ড Android মেমরি অ্যালোকেটর (scudo) ব্যবহার করলে, আপনি এই বিভাগটি এড়িয়ে যেতে পারেন।

১৬ কেবি সিস্টেমে, অপারেটিং সিস্টেমের বরাদ্দ করা ফিজিক্যাল মেমরির সবচেয়ে ছোট ইউনিট ৪ কেবি সিস্টেমের চেয়ে চার গুণ বড়। যদি কোনও কাস্টম অ্যালোকেটর ৪ কেবি অনুমানের উপর ভিত্তি করে ডিজাইন করা হয়, তাহলে এটি একাধিক ১৬ কেবি পৃষ্ঠা জুড়ে ছোট অবজেক্ট ছড়িয়ে দিতে পারে এবং অপ্রয়োজনীয়ভাবে খালি মেমরি ধরে রাখতে পারে। এটি ফিজিক্যাল মেমরির ব্যবহার (RSS) উল্লেখযোগ্যভাবে বাড়াতে পারে এবং কম্প্রেস করা সোয়াপ (ZRAM) কার্যকারিতা হ্রাস করতে পারে।

আপনার কোড যদি নিজস্ব মেমরি পুল ম্যানেজ করে, তাহলে এইসব সাজেশন অনুসরণ করুন:

১. মেমরি খালি করার জন্য হার্ড-কোডেড বাইট থ্রেশহোল্ড এড়িয়ে চলুন

অনেক অ্যালোকেটর madvise(MADV_DONTNEED) ব্যবহার করে OS-এ কখন মেমরি রিলিজ করতে হবে তা নির্ধারণ করতে নির্দিষ্ট বাইট সীমা ব্যবহার করে (যেমন, শুধুমাত্র মেমরি রিলিজ করুন যদি অ্যাক্টিভ অবজেক্ট ৮ কেবি-এর কম জায়গা নেয়)।

১৬ কেবি সিস্টেমে, এমনকি একটি ১৬-বাইট লাইভ অবজেক্টও সম্পূর্ণ ১৬ কেবি পৃষ্ঠা (যা ৮ কেবির থেকে বেশি) পিন করে। এর ফলে, রিলিজ থ্রেশহোল্ড কখনও পূরণ হয় না এবং অ্যালোকেটর কখনও কার্নেলে আশেপাশের অব্যবহৃত মেমরি ফেরত দেয় না।

কী করতে হবে: পৃষ্ঠা-রিলিজ হিউরিস্টিকের জন্য হার্ড-কোডেড বাইট কনস্ট্যান্ট কখনও ব্যবহার করবেন না। sysconf(_SC_PAGESIZE) ব্যবহার করে পৃষ্ঠার আসল সাইজের উপর ভিত্তি করে রানটাইমে রিলিজ থ্রেশহোল্ড ডাইনামিকভাবে স্কেল করুন।

২. আগে থেকে ব্যবহার করা পৃষ্ঠাগুলি প্রথমে পূরণ করুন (ঘন-প্রথম বরাদ্দ)

অ্যালোকেটর যদি ফার্স্ট-ইন-ফার্স্ট-আউট (FIFO) বা রাউন্ড-রবিন অর্ডারে মেমরি হ্যান্ড আউট করে, তাহলে নতুন অ্যালোকেশনগুলি আংশিকভাবে ভর্তি অনেক ১৬ কেবি পৃষ্ঠা জুড়ে ছড়িয়ে পড়ে। কোনও পৃষ্ঠার একটি অবজেক্ট ফিজিক্যাল RAM-এ ১৬ কেবি রেসিডেন্ট রাখে।

কী করতে হবে: খালি বা কম ব্যবহৃত পৃষ্ঠা স্পর্শ করার আগে সর্বদা সবচেয়ে পূর্ণ (ঘন) পৃষ্ঠা বা স্ল্যাব থেকে নতুন অবজেক্ট বরাদ্দ করুন। আগে থেকেই ডার্টি পেজে নতুন অ্যালোকেশন কনসেনট্রেট করলে, হালকাভাবে ব্যবহার করা পেজ স্বাভাবিকভাবেই শূন্য অ্যাক্টিভ অবজেক্টে ড্রেন হয়ে যায়, তাই সম্পূর্ণ ১৬ কেবি পেজ OS-এ রিলিজ করা যেতে পারে।

৩. মেমরি পুল ১৬ কেবিতে অ্যালাইন করুন এবং পুলের সাইজ মাঝারি রাখুন

৪ কেবি সিস্টেমের জন্য ডিজাইন করা মাল্টি-পেজ স্প্যান ১৬ কেবি কার্নেলে অতিরিক্ত রিলিজ না করা মেমরি স্ল্যাক ধরে রাখতে পারে। এছাড়াও, ১৬ কেবিতে সমানভাবে ভাগ করা যায় না এমন সাইজ ক্লাস প্রতিটি পৃষ্ঠার শেষে ফ্র্যাগমেন্টেশন তৈরি করে।

কী করতে হবে:

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

৪. ক্যাশে করা বড় বাফারের জন্য ফিজিক্যাল মেমরি অবিলম্বে খালি করুন

কাস্টম অ্যালোকেটর প্রায়ই ইন-মেমরি পুলে বড় বাফার (> ৬৪ কেবি) ক্যাশে করে যাতে mmap বা munmap সিস্টেম কলের ওভারহেড ছাড়াই সেগুলি আবার ব্যবহার করা যায়। তবে, মেমরিতে এই ডার্টি বাফার ধরে রাখলে, ইভিকশন টাইমারের জন্য অপেক্ষা করার সময় ফিজিক্যাল RAM-এর মেগাবাইট নষ্ট হয়।

কী করতে হবে: দ্রুত আবার ব্যবহার করার জন্য ভার্চুয়াল মেমরি অ্যাড্রেস রেঞ্জ রিজার্ভ করে রাখুন, তবে ক্যাশেতে বাফার ফিরিয়ে দেওয়ার সময় অবিলম্বে madvise(..., MADV_DONTNEED) বা madvise(..., MADV_FREE) কল করুন। অপারেটিং সিস্টেম ফিজিক্যাল RAM সাথে সাথে রিক্লেম করে নেয়, তবে আপনার অ্যাপ এখনও ভার্চুয়াল অ্যাড্রেস সাথে সাথে আবার ব্যবহার করতে পারে, এর জন্য নতুন করে বরাদ্দ করার প্রয়োজন হয় না।

৫. ZRAM কম্প্রেশনের জন্য অ্যালোকেশনের পরিবর্তে ফ্রি মেমরি জিরো আউট করুন

ব্যাকগ্রাউন্ড অ্যাপ মেমরিতে রাখতে Android কম্প্রেসড সোয়াপ (ZRAM) ব্যবহার করে। ১৬ কেবি ডিভাইসে, কোনও পৃষ্ঠায় একটি লাইভ অবজেক্ট থাকলেও, সম্পূর্ণ ১৬ কেবি পৃষ্ঠা রেসিডেন্ট থাকে বা ZRAM-এ সোয়্যাপ হয়ে যায়। সেই পৃষ্ঠার আগে খালি করা অংশে অবশিষ্ট গার্বেজ ডেটা (যেমন, বাসি পয়েন্টার এবং স্ট্রিং) খারাপভাবে কম্প্রেস করে।

আপনার অ্যালোকেটর মেমরি জিরো করলে (যেমন নিরাপত্তা বা জিরো-ইনিশিয়ালাইজড অ্যালোকেশনের জন্য), অ্যালোকেশনের পরিবর্তে ডিলিট করার (free()) সময় জিরো করার কথা বিবেচনা করুন:

• পিন করা পৃষ্ঠার জন্য কম খরচ হয়: আংশিকভাবে ভর্তি ১৬ কেবি পৃষ্ঠায় অব্যবহৃত মেমরি ZRAM-এ প্রায় কিছুই থাকে না, তাই পিন করা পৃষ্ঠা ফিজিক্যাল সোয়াপ স্পেস নষ্ট করে না।
• ন্যূনতম ক্যাশে ওভারহেড: free() কল করার সময়, সিপিইউ ক্যাশেতে মেমরি আগে থেকেই হট থাকে, ফলে পরে অতিরিক্ত ক্যাশে মিস এড়ানো যায়।

সাজেশনের সারাংশ

ক্ষেত্রফল	সাজেশন	প্রত্যাশিত প্রভাব
পার্জ থ্রেশহোল্ড	sysconf(_SC_PAGESIZE) ব্যবহার করে ডায়নামিকভাবে রিলিজ থ্রেশহোল্ড স্কেল করুন।	রিলিজ লজিককে স্থায়ীভাবে ডেডলক হওয়া থেকে আটকায়।
অ্যালোকেশন অর্ডার	সবচেয়ে ঘন (প্রায় ভর্তি) পৃষ্ঠা বা স্ল্যাব থেকে প্রথমে বরাদ্দ করুন।	অ্যাক্টিভ অবজেক্ট একসাথে প্যাক করে রেসিডেন্ট মেমরি (RSS) কমায়।
স্প্যান সাইজিং	সাইজ ক্লাসকে ১৬ কেবি মাল্টিপলে অ্যালাইন করুন এবং অতিরিক্ত সাইজের স্ল্যাব এড়িয়ে চলুন।	টেল-পেজ ফ্র্যাগমেন্টেশন দূর করে এবং মেমরি স্ল্যাক কমায়।
বাফার ক্যাশে	বড় বাফার ক্যাশে করার সময় অবিলম্বে madvise(MADV_DONTNEED) কল করুন।	দ্রুত ভার্চুয়াল রিইউজ বজায় রেখে অব্যবহৃত RAM-এর ব্লট দূর করে।
Swap / ZRAM	অ্যালোকেশনের পরিবর্তে free()-এ মেমরি জিরো আউট করুন।	ZRAM কম্প্রেশন অনুপাত উন্নত করে যাতে পিন করা পৃষ্ঠাগুলি কম খরচ করে।

১৬ কেবি সাপোর্ট করে কিনা তা জানতে SDK চেক করুন

অনেক SDK ১৬ কেবি সাইজের পৃষ্ঠার সাথে মানানসই, বিশেষ করে আপনি যদি সেগুলি নিজে তৈরি করেন অথবা সাম্প্রতিক প্রি-বিল্ট পান। তবে, কিছু SDK প্রি-বিল্ট বা SDK ভার্সন ১৬ কেবি-র সাথে মানানসই নয়, তাই ১৬ কেবি-র সাথে কোন ভার্সন ব্যবহার করবেন তা নির্ধারণ করতে, প্রতিটি SDK প্রোভাইডারের ওয়েবসাইট চেক করা উচিত।

১৬ কেবি এনভায়রনমেন্টে আপনার অ্যাপ পরীক্ষা করুন

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

1. Android 15 SDK বা তার পরবর্তী ভার্সন সেট-আপ করুন।

2. নিম্নলিখিত টেস্টিং এনভায়রনমেন্টের মধ্যে যেকোনও একটি সেট-আপ করুন:

   • ১৬ কেবি-ভিত্তিক, Android 15 সিস্টেম ইমেজের সাথে Android এমুলেটর সেট-আপ করা
   • ARM64-এ ১৬ কেবি সাইজের পৃষ্ঠা সহ Cuttlefish ব্যবহার করা
   • x86-64-এ ১৬ কেবি সাইজের পৃষ্ঠা সহ Cuttlefish সিমুলেট করুন
   • ডেভেলপার বিকল্প ব্যবহার করে ডিভাইসে ১৬ কেবি মোড চালু করা
   • ১৬ কেবি কাজ করে এমন ডিভাইসে Samsung Remote Test Lab ব্যবহার করুন

3. আপনার টেস্ট ডিভাইস চালু করুন, তারপর এটি ১৬ কেবি এনভায়রনমেন্ট ব্যবহার করছে কিনা তা যাচাই করতে নিম্নলিখিত কমান্ড রান করুন:

   adb shell getconf PAGE_SIZE
   

   কমান্ডের ভ্যালু 16384 হতে হবে।

4. আপনার অ্যাপ ১৬ কেবি-অ্যালাইনড কিনা তা যাচাই করতে নিম্নলিখিত zipalign কমান্ড রান করুন, যেখানে APK_NAME হল আপনার অ্যাপের APK ফাইলের নাম:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. আপনার অ্যাপটি পুঙ্খানুপুঙ্খভাবে পরীক্ষা করুন, বিশেষ করে সেইসব জায়গায় ফোকাস করুন যা নির্দিষ্ট পৃষ্ঠার সাইজ রেফারেন্স করে এমন কোড ইনস্ট্যান্স পরিবর্তন করার ফলে প্রভাবিত হতে পারে।

১৬-কেবি-ভিত্তিক সিস্টেম ইমেজের মাধ্যমে Android Emulator সেট-আপ করা

Android Emulator ব্যবহার করে ১৬ কেবি এনভায়রনমেন্ট সেট-আপ করতে, এইসব ধাপ অনুসরণ করুন:

1. Android Studio-তে, টুল > SDK ম্যানেজার বিকল্পে ক্লিক করুন।

2. SDK প্ল্যাটফর্ম ট্যাবে, প্যাকেজের বিবরণ দেখুন বিকল্প বেছে নিন, তারপর Android VanillaIceCream বা তার পরবর্তী ভার্সনের বিভাগটি বড় করে দেখুন এবং আপনি যে ভার্চুয়াল ডিভাইস তৈরি করতে চান তার উপর নির্ভর করে নিম্নলিখিত এমুলেটর সিস্টেম ইমেজের মধ্যে থেকে একটি বা দুটিই বেছে নিন:

   • Google APIs পরীক্ষামূলক ১৬ কেবি পৃষ্ঠা সাইজ ARM 64 v8a সিস্টেম ইমেজ
   • Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image
   মনে রাখবেন: আপনি যদি কাজ করে এমন Google Pixel ডিভাইস এমুলেট করার পরিকল্পনা করেন, তাহলে আপনার শুধু ARM 64 v8a সিস্টেম ইমেজ প্রয়োজন হবে।

   

3. আপনি যে সিস্টেম ইমেজ বেছে নিয়েছেন সেটি ডাউনলোড করতে প্রয়োগ করুন > ঠিক আছে বিকল্পে ক্লিক করুন।

4. Android 15-এর জন্য ভার্চুয়াল ডিভাইস সেট-আপ করতে ধাপগুলি অনুসরণ করুন এবং সিস্টেম ইমেজ বেছে নেওয়ার জন্য প্রম্পট করা হলে, আপনার ডাউনলোড করা ১৬ কেবি সিস্টেম ইমেজ বেছে নিন। এটি অটোমেটিক সাজেস্ট করা না হলে, আপনি অন্যান্য ছবি ট্যাবে ১৬ কেবি সিস্টেম ইমেজ খুঁজে পাবেন।

   

ইমুলেটর লঞ্চ করা

Android এমুলেটর ও ভার্চুয়াল ডিভাইস সেট-আপ করা হয়ে গেলে, টার্গেট ডিভাইস মেনু থেকে অথবা কমান্ড লাইন থেকে এমুলেটর লঞ্চ করুন।

ডেভেলপার অপশন ব্যবহার করে একটি ডিভাইসে ১৬ কেবি মোড সক্ষম করুন

১৬ কেবি মোডে একটি ডিভাইস বুট করতে ১৬ কেবি পৃষ্ঠা আকারের ডেভেলপার বিকল্পটি টগল করুন।

অ্যান্ড্রয়েড ১৫ এর QPR সংস্করণগুলিতে, আপনি নির্দিষ্ট ডিভাইসে উপলব্ধ ডেভেলপার বিকল্পটি ব্যবহার করে ডিভাইসটিকে ১৬ KB মোডে বুট করতে এবং অন-ডিভাইস পরীক্ষা করতে পারেন। ডেভেলপার বিকল্পটি ব্যবহার করার আগে, সেটিংস > সিস্টেম > সফ্টওয়্যার আপডেটে যান এবং উপলব্ধ যেকোনো আপডেট প্রয়োগ করুন।

এই ডেভেলপার বিকল্পটি নিম্নলিখিত ডিভাইসগুলিতে উপলব্ধ:

• Pixel 8 এবং 8 Pro (Android 15 QPR1 বা তার উচ্চতর ভার্সন সহ)

• Pixel 8a (Android 15 QPR1 বা তার উচ্চতর ভার্সন সহ)

• Pixel 9, 9 Pro, এবং 9 Pro XL (Android 15 QPR2 বা তার উচ্চতর ভার্সন সহ)

• Pixel 9a (Android 16 বা তার উচ্চতর ভার্সন সহ)

১৬ কেবি ব্যাককম্প্যাট মোড

পেজ সাইজ কম্প্যাটিবিলিটি মোডে সতর্কতা

১৬ কেবি ব্যাককম্প্যাট বিকল্পটি উপলভ্য হয় যখন কোনও ডিভাইস ১৬ কেবি কার্নেলের সাথে রান করে। নিম্নলিখিত শর্ত পূরণ হলে, প্যাকেজ ম্যানেজার ১৬ কেবি ব্যাককম্প্যাট মোডে অ্যাপ চালায়:

• অ্যাপে যদি ৪ কেবি LOAD সেগমেন্ট অ্যালাইনমেন্ট সহ ELF ফাইল (.so এক্সটেনশন সহ) থাকে।
• জিপ করা APK-তে আনকমপ্রেসড ELF ফাইল থাকলে, যা ৪ কেবি ZIP অ্যালাইন করা।

কোনও অ্যাপের জন্য প্যাকেজ ম্যানেজার ১৬ কেবি ব্যাককম্প্যাট মোড চালু করলে, অ্যাপটি প্রথমবার চালু করার সময় একটি সতর্কতা দেখায় যে এটি ১৬ কেবি ব্যাককম্প্যাট মোডে চলছে।

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

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

পেজ সাইজ কম্প্যাটিবিলিটি মোড সেটিং

ডিভাইসের প্রতিটি অ্যাপের জন্য ১৬ কেবি ব্যাককম্প্যাট চালু করতে বাধ্য করতে:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

ডিভাইসের প্রতিটি অ্যাপের জন্য ১৬ কেবি ব্যাককম্প্যাট বন্ধ করতে বাধ্য করতে:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

Android 17-এ, আপনি প্রতিটি অ্যাপের জন্য ১৬ কেবি ব্যাককম্প্যাট বন্ধ করতে পারবেন এবং যেকোনও বেমানান বাইনারি অবিলম্বে বাতিল করতে পারবেন:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

android:pageSizeCompat প্রপার্টি চালু বা বন্ধ হিসেবে সেট করুন যাতে নির্দিষ্ট অ্যাপের AndroidManifest.xml-এ ব্যাককম্প্যাট মোড চালু বা বন্ধ করা যায়। এই প্রপার্টি সেট করা থাকলে, অ্যাপ লঞ্চ করার সময় ব্যাককম্প্যাট মোড সংক্রান্ত সতর্কতা দেখাবে না।