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

ঐতিহাসিকভাবে, অ্যান্ড্রয়েড শুধুমাত্র 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 কেবি মেমরি পৃষ্ঠা সাইজকে অবশ্যই সাপোর্ট করতে হবে। ১ ফেব্রুয়ারি, ২০২৭ থেকে, আপনার অ্যাপ আপডেট ১৬ কেবি মেমরি পৃষ্ঠা সাইজ সাপোর্ট না করলে, আপনি এইসব আপডেট রিলিজ করতে পারবেন না।

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

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 অ্যালাইনমেন্ট ব্যবহার করে সঠিকভাবে অ্যালাইন করা হয়েছে কিনা তা যাচাই করুন। আপনি যদি Linux বা macOS-এর মধ্যে কোনও একটিতে ডেভেলপ করেন, তাহলে নিচের বিভাগে যেভাবে বর্ণনা করা হয়েছে সেইভাবে check_elf_alignment.sh স্ক্রিপ্ট ব্যবহার করতে পারবেন। এছাড়াও, আপনি সরাসরি কমান্ড-লাইন টুল ব্যবহার করতে পারবেন।

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

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

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) ফ্ল্যাগ ব্যবহার করে যাতে লোড করার পরে শেয়ার করা অবজেক্ট ফাইলের রিলোকেশন বিভাগ রিড-ওনলি করা যায়। আপনার বিল্ডে RELRO ফ্ল্যাগ চালু করুন।

স্টার্ট অ্যাড্রেস প্লাস সেগমেন্ট সাইজ (MemSize) সহ RELRO বিভাগ যা ১৬ কেবি অ্যালাইন করা নয়, তা রানটাইমে সেগমেন্টেশন ফল্টের মাধ্যমে অ্যাপ ক্র্যাশ করে। .so ফাইলটি যদি NDK টুল চেইন r27 ও তার আগের যেকোনও ভার্সন দিয়ে তৈরি করা হয় এবং প্রাসঙ্গিক ফ্ল্যাগ চালু না করা থাকে, তাহলে এটি হয়।

প্রতিটি শেয়ার করা অবজেক্ট ফাইলে (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 'RELRO\|Type'

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

এরপর, RELRO সেগমেন্টের ভার্চুয়াল অফসেট অ্যাড্রেস (VirtAddr) এবং সেগমেন্ট মেমরির সাইজ (MemSiz) যোগ করে এবং ১৬ কেবি (0x4000) দিয়ে ভাগ করে RELRO সেগমেন্ট অ্যালাইনমেন্ট চেক করুন। ভাগশেষ (মডিউলো) শূন্য হলে, RELRO সেগমেন্ট ১৬ কেবি অ্যালাইন করা আছে।

এখানে একটি নন-অ্যালাইনড .so ফাইলের উদাহরণ দেওয়া হল:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

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

ফলাফল: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

যেহেতু 0x1000 শূন্য নয়, তাই এই .so ফাইলটি ১৬ কেবি কমপ্লায়েন্ট নয়। DC000 (আগের পৃষ্ঠা ব্রেক) থেকে E4000 পর্যন্ত RELRO সুরক্ষা রেঞ্জ হল রিড-অনলি, কিন্তু Android Linker-এর প্রত্যাশা হল E1000 থেকে E4000 পর্যন্ত সাব-রেঞ্জ যেন রাইটেবল হয়, এর ফলে সেগমেন্টেশন ফল্ট হয়। এই ক্ষেত্রে, ১৬ কেবি ELF অ্যালাইনমেন্ট ব্যবহার করে আপনার অ্যাপ কম্পাইল করুন বিভাগে বর্ণনা করা অনুযায়ী .so ফাইলটি আবার তৈরি করুন।

এখানে RELRO সেগমেন্ট সহ অ্যালাইন করা .so ফাইলের একটি উদাহরণ দেওয়া হল:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

RELRO সেগমেন্ট ছাড়া .so ফাইলের একটি উদাহরণ এখানে দেওয়া হল:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align

এটি হল কোনও RELRO সেগমেন্ট ছাড়াই ১৬ কেবি কমপ্লায়েন্ট .so ফাইল।

এখানে একটি অ্যালাইন করা .so ফাইলের উদাহরণ দেওয়া হল যেখানে 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 পরবর্তী রাইটেবল ডেটার (যেমন .data বা .bss) সাথে LOAD সেগমেন্ট শেয়ার করে।

GNU_RELRO তার নিজস্ব LOAD সেগমেন্টে আছে কিনা তা চেক করতে, llvm-readelf -Wl রান করে এবং grep 'LOAD\|RELRO\|Type' দিয়ে ফিল্টার করে প্রোগ্রাম হেডারগুলি পরীক্ষা করুন। কন্টেনিং LOAD সেগমেন্টের সাথে GNU_RELRO-এর VirtAddr ও MemSiz তুলনা করুন। এই উদাহরণে, দুটিতেই VirtAddr 0x4680 এবং MemSiz 0x0980 আছে।

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

১৬ কেবি ডিভাইসের জন্য কাজ করে এমন অ্যাপ তৈরি করুন

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

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

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

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-কে 8.5.1 বা তার পরের যেকোনও ভার্সনে আপগ্রেড করতে না পারলে, বিকল্প হিসেবে কম্প্রেস করা শেয়ার করা লাইব্রেরি ব্যবহার করতে পারেন। আপনার Gradle কনফিগারেশন আপডেট করুন যাতে আপনার অ্যাপ প্যাকেজ করার সময় Gradle আপনার শেয়ার করা লাইব্রেরিগুলিকে কম্প্রেস করে যাতে অ্যালাইন না করা শেয়ার করা লাইব্রেরিগুলির সাথে অ্যাপ ইনস্টলেশন সমস্যা এড়ানো যায়।

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

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

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

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

android.bundle.enableUncompressedNativeLibs=false

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

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

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

১৬ কেবি 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

কী করতে হবে:

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

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

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

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

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

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

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

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

সাজেশনের সারসংক্ষেপ

১৬ কেবি সাইজের জন্য SDK কাজ করে কিনা তা চেক করুন

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

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

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

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

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

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

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

   adb shell getconf PAGE_SIZE
   

   কমান্ডটি 16384-এর একটি মান ফেরত দেবে।

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

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

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

১৬-KB-ভিত্তিক সিস্টেম ইমেজ সহ Android এমুলেটর সেট-আপ করা

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

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

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

   • Google APIs Experimental ১৬ কেবি পৃষ্ঠা সাইজ ARM 64 v8a সিস্টেম ইমেজ
   • Google APIs Experimental 16 KB Page Size Intel x86_64 Atom System Image

   

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-এ, আপনি প্রতিটি অ্যাপের জন্য ১৬ KB ব্যাককম্প্যাট বন্ধ করতে বাধ্য করতে পারেন এবং কোনও ইনকম্প্যাটিবল বাইনারি অবিলম্বে বাতিল করতে পারেন:

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

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