64-বিট আর্কিটেকচার সাপোর্ট করে

Google Play-তে প্রকাশিত অ্যাপে ৬৪-বিট আর্কিটেকচার কাজ করতে হবে। আপনার অ্যাপের ৬৪-বিট ভার্সন যোগ করলে পারফর্ম্যান্স উন্নত হয় এবং শুধু ৬৪-বিট হার্ডওয়্যার আছে এমন ডিভাইসের জন্য আপনার অ্যাপ সেট-আপ করে।

আপনার ৩২-বিট অ্যাপ যাতে ৬৪-বিট ডিভাইসে কাজ করে তা নিশ্চিত করতে নিম্নলিখিত ধাপগুলি অনুসরণ করুন।

আপনার অ্যাপ মূল্যায়ন করুন

আপনার অ্যাপ যদি শুধুমাত্র Java প্রোগ্রামিং ল্যাঙ্গুয়েজ বা Kotlin-এ লেখা কোড ব্যবহার করে, যার মধ্যে সব লাইব্রেরি বা SDK অন্তর্ভুক্ত, তাহলে আপনার অ্যাপ 64-বিট ডিভাইসে কাজ করবে। আপনার অ্যাপ কোনও নেটিভ কোড ব্যবহার করলে অথবা আপনি যদি নিশ্চিত না হন যে এটি করে কিনা, তাহলে আপনার অ্যাপ মূল্যায়ন করুন।

স্ট্যাটাস দ্রুত চেক করা

Play Console-এ যান এবং আগে থেকে থাকা রিলিজগুলি নীতি মেনে চলছে কিনা তা দেখুন।

এছাড়াও, ৬৪-বিট সংক্রান্ত কোনও সমস্যা থাকলে, Play Console আপনার ড্রাফ্ট রিলিজের ক্ষেত্রে প্রযোজ্য সতর্কতা দেখায়। নিচের ছবিটি একটি উদাহরণ।

কোনও সতর্কতা দেখানো হলে, আপনার অ্যাপকে ৬৪-বিট ডিভাইসের সাথে মানানসই করতে নিম্নলিখিত ধাপগুলি দেখুন।

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

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

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

আপনার অ্যাপে কি ৬৪-বিট লাইব্রেরি আছে?

আপনার APK ফাইলের গঠন পরীক্ষা করুন। তৈরি করার সময়, অ্যাপের জন্য প্রয়োজনীয় যেকোনও নেটিভ লাইব্রেরির সাথে APK প্যাকেজ করা হয়। ABI-এর উপর ভিত্তি করে বিভিন্ন ফোল্ডারে নেটিভ লাইব্রেরি স্টোর করা হয়। প্রতিটি ৬৪-বিট আর্কিটেকচারকে সাপোর্ট করার প্রয়োজন নেই, তবে আপনার সাপোর্ট করা প্রতিটি নেটিভ ৩২-বিট আর্কিটেকচারের জন্য আপনাকে অবশ্যই সংশ্লিষ্ট ৬৪-বিট আর্কিটেকচার অন্তর্ভুক্ত করতে হবে।

ARM আর্কিটেকচারের জন্য, 32-বিট লাইব্রেরি armeabi-v7a-তে রয়েছে। 64-বিটের সমতুল্য হল arm64-v8a।

x86 আর্কিটেকচারের জন্য, ৩২-বিটের ক্ষেত্রে x86 এবং ৬৪-বিটের ক্ষেত্রে x86_64 খুঁজুন।

এই দুটি ফোল্ডারে নেটিভ লাইব্রেরি আছে কিনা তা নিশ্চিত করুন। সংক্ষেপে:

মনে রাখবেন যে আপনার অ্যাপের উপর নির্ভর করে, প্রতিটি ফোল্ডারে ঠিক একই ধরনের লাইব্রেরি থাকতে পারে বা নাও থাকতে পারে। আপনার অ্যাপ যাতে শুধুমাত্র ৬৪-বিট এনভায়রনমেন্টে সঠিকভাবে কাজ করে তা নিশ্চিত করাই হল এর লক্ষ্য।

সাধারণত, ৩২-বিট ও ৬৪-বিট আর্কিটেকচারের জন্য তৈরি করা APK বা বান্ডেলে দুটি ABI-এর জন্যই ফোল্ডার থাকে, প্রতিটিতে নেটিভ লাইব্রেরির সংশ্লিষ্ট সেট থাকে। ৬৪-বিট কাজ না করলে, আপনি ৩২-বিট ABI ফোল্ডার দেখতে পেতে পারেন কিন্তু ৬৪-বিট ফোল্ডার নয়।

APK Analyzer ব্যবহার করে নেটিভ লাইব্রেরি খোঁজা

APK Analyzer হল এমন একটি টুল যা আপনাকে বিল্ট APK-এর বিভিন্ন দিক মূল্যায়ন করতে দেয়। কোনও নেটিভ লাইব্রেরি খুঁজতে এটি ব্যবহার করুন এবং ৬৪-বিট লাইব্রেরি উপস্থিত আছে কিনা তা নিশ্চিত করুন।

1. Android Studio খুলুন এবং যেকোনও প্রোজেক্ট খুলুন।

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

   

3. আপনি যে APK মূল্যায়ন করতে চান সেটি বেছে নিন।

4. lib ফোল্ডারের মধ্যে দেখুন, যেখানে '.so' ফাইল হোস্ট করা থাকে। যদি কোনওটিই না থাকে, তাহলে আপনার অ্যাপ 64-বিট ডিভাইসে কাজ করে এবং আর কোনও অ্যাকশন নেওয়ার প্রয়োজন নেই। আপনি armeabi-v7a বা x86 দেখতে পেলে, আপনার কাছে ৩২-বিট লাইব্রেরি আছে।

5. arm64-v8a বা x86_64 ফোল্ডারে একই ধরনের '.so' ফাইল আছে কিনা তা চেক করুন।

   

6. আপনার কাছে কোনও arm64-v8a বা x86_64 লাইব্রেরি না থাকলে, আপনার APK-তে এইসব আর্টিফ্যাক্ট তৈরি ও প্যাকেজ করা শুরু করতে বিল্ড প্রসেস আপডেট করুন।

7. আপনি যদি আগে থেকেই দুটি লাইব্রেরি প্যাকেজ করা অবস্থায় দেখতে পান, তাহলে আপনি সরাসরি ৬৪-বিট হার্ডওয়্যারে আপনার অ্যাপ পরীক্ষা করা ধাপে চলে যেতে পারেন।

APK আনজিপ করে নেটিভ লাইব্রেরি খুঁজুন

APK ফাইল জিপ ফাইলের মতো স্ট্রাকচার করা হয়। কমান্ড লাইন বা অন্য কোনও এক্সট্র্যাকশন টুলের সাহায্যে APK ফাইল এক্সট্র্যাক্ট করুন। আপনার এক্সট্র্যাকশন টুলের উপর নির্ভর করে, আপনাকে ফাইলের নাম পরিবর্তন করে .zip করতে হতে পারে।

আপনার অ্যাপ ৬৪-বিট ডিভাইস সাপোর্ট করে কিনা তা নির্ধারণ করতে উপরের নির্দেশিকা অনুসরণ করে এক্সট্র্যাক্ট করা ফাইলগুলি ব্রাউজ করুন। আপনি কমান্ড লাইন থেকে নিম্নলিখিত কমান্ডের উদাহরণ রান করতে পারেন:

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

এই উদাহরণে armeabi-v7a এবং arm64-v8a লাইব্রেরির উপস্থিতি লক্ষ্য করুন, যার অর্থ হল অ্যাপটি 64-বিট আর্কিটেকচার সাপোর্ট করে।

৬৪-বিট লাইব্রেরি সহ আপনার অ্যাপ তৈরি করুন

৬৪-বিট লাইব্রেরি কীভাবে তৈরি করতে হয় তা নিম্নলিখিত নির্দেশাবলীতে উল্লেখ করা আছে। মনে রাখবেন যে এইসব ধাপ শুধুমাত্র বিল্ডিং কোড এবং লাইব্রেরি কভার করে যা আপনি সোর্স থেকে তৈরি করতে পারবেন।

Android Studio বা Gradle-এর সাহায্যে তৈরি করুন

বেশিরভাগ Android Studio প্রোজেক্টে অন্তর্নিহিত বিল্ড সিস্টেম হিসেবে Gradle ব্যবহার করা হয়, তাই এই বিভাগ দুটি ক্ষেত্রেই প্রযোজ্য। আপনার নেটিভ কোডের জন্য বিল্ড চালু করতে, আপনি যে আর্কিটেকচারকে সাপোর্ট করতে চান তার উপর নির্ভর করে, arm64-v8a এবং/অথবা x86_64 যোগ করুন, আপনার অ্যাপের 'build.gradle' ফাইলের ndk.abiFilters সেটিংসে:

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

CMake-এর সাহায্যে তৈরি করুন

আপনার অ্যাপ CMake ব্যবহার করে তৈরি করা হলে, আপনি '-DANDROID_ABI' প্যারামিটারে arm64-v8a পাস করে ৬৪-বিট ABI-এর জন্য তৈরি করতে পারবেন:

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

ndk-build-এর সাহায্যে তৈরি করুন

আপনার অ্যাপ ndk-build দিয়ে তৈরি করা হলে, APP_ABI ভেরিয়েবল ব্যবহার করে 'Application.mk' ফাইল পরিবর্তন করার মাধ্যমে ৬৪-বিট ABI-এর জন্য তৈরি করতে পারবেন:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

৩২-বিট কোডকে ৬৪-বিটে পোর্ট করুন

আপনার কোড যদি আগে থেকেই ডেস্কটপ বা iOS-এ রান করে, তাহলে Android-এর জন্য আপনাকে কোনও অতিরিক্ত কাজ করতে হবে না। আপনার কোড যদি প্রথমবার ৬৪-বিট সিস্টেমের জন্য তৈরি করা হয়, তাহলে আপনাকে যে প্রধান সমস্যাটি সমাধান করতে হবে তা হল, পয়েন্টার আর int-এর মতো ৩২-বিট ইন্টিজার টাইপে ফিট করে না।

int, unsigned বা uint32_t-এর মতো টাইপে পয়েন্টার স্টোর করে এমন কোড আপডেট করুন। Unix সিস্টেমে, long পয়েন্টারের সাইজের সাথে মেলে, কিন্তু Windows-এ এটি মেলে না। পরিবর্তে, ইনটেনশন-রিভিলিং টাইপ uintptr_t বা intptr_t ব্যবহার করুন। দুটি পয়েন্টারের মধ্যে পার্থক্য স্টোর করতে, ptrdiff_t টাইপ ব্যবহার করুন।

<stdint.h>-এ নির্দিষ্ট করা নির্দিষ্ট, ফিক্সড-প্রস্থের পূর্ণসংখ্যা টাইপ ব্যবহার করা সবসময়ই ভালো, int বা long-এর মতো নন-ফিক্সড-প্রস্থের টাইপ ব্যবহার না করে, এমনকি নন-পয়েন্টারের ক্ষেত্রেও।

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

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

C/C++ অবজেক্টের পয়েন্টার হোল্ড করে এমন int ফিল্ড সহ Java ক্লাসের ক্ষেত্রেও একই সমস্যা হয়। আপনার JNI সোর্সে jint সার্চ করুন এবং নিশ্চিত করুন যে আপনি জাভা সাইডে long এবং C++ সাইডে jlong-এ সুইচ করেছেন।

৬৪-বিট কোডের ক্ষেত্রে ইমপ্লিসিট ফাংশন ডিক্লারেশন অনেক বেশি বিপজ্জনক। C/C++ ধরে নেয় যে ইমপ্লিসিটভাবে ঘোষিত ফাংশনের (অর্থাৎ, এমন একটি ফাংশন যার জন্য কম্পাইলার কোনও ঘোষণা দেখেনি) রিটার্ন টাইপ হল int। আপনার ফাংশনের প্রকৃত রিটার্ন টাইপ যদি একটি পয়েন্টার হয়, তাহলে এটি একটি 32-বিট সিস্টেমে ভাল কাজ করে যেখানে আপনার পয়েন্টারটি একটি int-এ ফিট করে। তবে, একটি 64-বিট সিস্টেমে, কম্পাইলার আপনার পয়েন্টারের উপরের অর্ধেকটি ড্রপ করে। যেমন:

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

নিম্নলিখিত কম্পাইলার ফ্ল্যাগ ইমপ্লিসিট ফাংশন ডিক্লারেশন সংক্রান্ত সতর্কতাগুলিকে ত্রুটিতে পরিণত করে যাতে আপনি এই সমস্যাটি আরও সহজে খুঁজে পেতে এবং সমাধান করতে পারেন:

-Werror=implicit-function-declaration

আপনার ইনলাইন অ্যাসেম্বলার থাকলে, এটি আবার লিখুন বা সাধারণ C/C++ ইমপ্লিমেন্টেশন ব্যবহার করুন।

আপনার কাছে হার্ড-কোডেড সাইজের ধরন (যেমন, ৮ বা ১৬ বাইট) থাকলে, সেগুলিকে সমতুল্য sizeof(T) এক্সপ্রেশন, যেমন sizeof(void*) দিয়ে পরিবর্তন করুন।

আপনাকে যদি ৩২-বিট ও ৬৪-বিটের জন্য আলাদা কোড কম্পাইল করতে হয়, তাহলে আপনি সাধারণ ৩২/৬৪-বিট পার্থক্যের জন্য #if defined(__LP64__) অথবা Android-এর দ্বারা সমর্থিত নির্দিষ্ট আর্কিটেকচারের জন্য __arm__, __aarch64__ (arm64), __i386__ (x86) এবং __x86_64__ ব্যবহার করতে পারেন।

printf বা scanf-এর মতো ফাংশনের জন্য ফর্ম্যাট স্ট্রিং অ্যাডজাস্ট করুন, কারণ প্রথাগত ফর্ম্যাট স্পেসিফায়ার আপনাকে এমনভাবে ৬৪-বিট টাইপ নির্দিষ্ট করার অনুমতি দেয় না যা ৩২-বিট এবং ৬৪-বিট উভয় ডিভাইসের জন্যই সঠিক। PRI এবং SCN ম্যাক্রো <inttypes.h>-এ এই সমস্যার সমাধান করে, PRIxPTR এবং SCNxPTR হেক্স পয়েন্টার লেখা ও পড়ার জন্য; এবং PRId64 এবং SCNd64 ৬৪-বিট ভ্যালু পোর্টেবলভাবে লেখা ও পড়ার জন্য।

শিফ্ট করার সময়, শিফ্ট করার জন্য 64-বিট কনস্ট্যান্ট পেতে আপনাকে 1ULL ব্যবহার করতে হতে পারে 1 ব্যবহার করার পরিবর্তে, যা মাত্র 32 বিট।

Android App Bundle-এর মাধ্যমে সাইজ বৃদ্ধি কমানো

আপনার অ্যাপে ৬৪-বিট আর্কিটেকচার সাপোর্ট যোগ করলে, আপনার APK-এর সাইজ বেড়ে যেতে পারে। আমরা বিশেষভাবে সাজেস্ট করি যে আপনি Android App Bundle ফিচারের সুবিধা নিন যাতে একই APK-তে ৩২ ও ৬৪-বিট নেটিভ কোড অন্তর্ভুক্ত করার ফলে সাইজের উপর যে প্রভাব পড়ে তা কমানো যায়।

গেম ডেভেলপার

সবচেয়ে বেশি ব্যবহৃত তিনটি ইঞ্জিন 64-বিট সাপোর্ট করে:

• ২০১৫ সাল থেকে অবাস্তব
• ২০১৫ থেকে Cocos2d
• ২০১৮ থেকে Unity

Unity ডেভেলপার

উপযুক্ত ভার্সনে আপগ্রেড করুন

Unity 2018.2 এবং 2017.4.16 ভার্সনের সাথে ৬৪-বিট সাপোর্ট প্রদান করে।

আপনি যদি Unity-র এমন কোনও ভার্সন ব্যবহার করেন যা ৬৪-বিট সাপোর্ট করে না, তাহলে আপনি যে ভার্সনে আপগ্রেড করতে চান সেটি নির্ধারণ করুন এবং আপনার এনভায়রনমেন্ট মাইগ্রেট করার জন্য Unity-র দেওয়া গাইড অনুসরণ করুন, যাতে আপনার অ্যাপটি এমন একটি ভার্সনে আপগ্রেড করা হয় যা ৬৪-বিট লাইব্রেরি তৈরি করতে পারে। Unity সাজেস্ট করে যে আপনি যেন এডিটরের লেটেস্ট LTS ভার্সনে আপগ্রেড করার মাধ্যমে লেটেস্ট ফিচার ও আপডেট অ্যাক্সেস করেন।

এখানে একটি চার্ট দেওয়া হল যাতে Unity-র বিভিন্ন ভার্সন এবং আপনার কী করা উচিত তা উল্লেখ করা আছে:

৬৪-বিট লাইব্রেরি আউটপুট করতে বিল্ড সেটিংস পরিবর্তন করুন

আপনি যদি Unity-র এমন কোনও ভার্সন ব্যবহার করেন যা ৬৪-বিট Android লাইব্রেরি সাপোর্ট করে, তাহলে বিল্ড সেটিংস অ্যাডজাস্ট করে আপনার অ্যাপের ৬৪-বিট ভার্সন জেনারেট করতে পারবেন। আপনার স্ক্রিপ্টিং ব্যাকএন্ড হিসেবে IL2CPP ব্যাকএন্ড ব্যবহার করুন। ৬৪-বিট আর্কিটেকচার তৈরি করার জন্য আপনার Unity প্রোজেক্ট সেট-আপ করতে, নিম্নলিখিত ধাপগুলি অনুসরণ করুন:

1. বিল্ড সেটিংস-এ যান এবং প্ল্যাটফর্ম-এর অধীনে Android-এর পাশে Unity চিহ্ন আছে কিনা তা যাচাই করে নিশ্চিত করুন যে আপনি Android-এর জন্য বিল্ড করছেন। ১. Android প্ল্যাটফর্মের পাশে Unity চিহ্ন না থাকলে, Android বেছে নিয়ে প্ল্যাটফর্ম পাল্টান বিকল্পে ক্লিক করুন।

2. প্লেয়ার সেটিংস বিকল্পে ক্লিক করুন।

   

3. প্লেয়ার সেটিংস প্যানেল > Android-এর জন্য সেটিংস > অন্যান্য সেটিংস > কনফিগারেশন বিকল্পে যান

4. স্ক্রিপ্টিং ব্যাকএন্ড IL2CPP-এ সেট করুন।

5. টার্গেট আর্কিটেকচার > ARM64 চেকবক্স বেছে নিন।

   

6. স্বাভাবিকভাবে তৈরি করুন!

মনে রাখবেন, ARM64-এর জন্য তৈরি করতে হলে আপনার সব অ্যাসেট বিশেষভাবে সেই প্ল্যাটফর্মের জন্য তৈরি করতে হবে। APK-এর সাইজ কমাতে Unity-এর নির্দেশিকা অনুসরণ করুন এবং সাইজ বৃদ্ধির এই সমস্যা কমাতে Android App Bundle ফিচারের সুবিধা নেওয়ার কথা বিবেচনা করুন।

মাল্টি-APK এবং ৬৪-বিট সংক্রান্ত সম্মতি

আপনি যদি অ্যাপ প্রকাশ করার জন্য Google Play-এর একাধিক-APK সংক্রান্ত সহায়তা ব্যবহার করেন, তাহলে মনে রাখবেন যে ৬৪-বিট সংক্রান্ত প্রয়োজনীয়তা মেনে চলার বিষয়টি রিলিজ লেভেলে মূল্যায়ন করা হয়। তবে, Android 9 Pie বা তার পরবর্তী ভার্সনে চলে এমন ডিভাইসে ডিস্ট্রিবিউট করা হয় না এমন APK বা অ্যাপ বান্ডেলের ক্ষেত্রে ৬৪-বিট সংক্রান্ত প্রয়োজনীয়তা প্রযোজ্য নয়।

আপনার কোনও APK যদি নীতি মেনে চলছে না বলে চিহ্নিত করা হয়, কিন্তু সেটি আগের ভার্সন হয় এবং সেটি নীতি মেনে চলার মতো করে তোলা সম্ভব না হয়, তাহলে একটি কৌশল হল সেই APK-এর ম্যানিফেস্টে uses-sdk এলিমেন্টে maxSdkVersion="27" অ্যাট্রিবিউট যোগ করা। Android 9 Pie বা তার পরবর্তী ভার্সন চলছে এমন ডিভাইসে এই APK ডেলিভার করা হয় না এবং এটি আর কমপ্লায়েন্স ব্লক করে না।

RenderScript এবং ৬৪-বিট সংক্রান্ত নিয়ম মেনে চলা

আপনার অ্যাপ RenderScript ব্যবহার করলে এবং Android টুলের পুরনো ভার্সন দিয়ে তৈরি হলে, অ্যাপের জন্য ৬৪-বিট কমপ্লায়েন্স সংক্রান্ত সমস্যা দেখতে পেতে পারেন। ২১.০.০-এর আগের বিল্ড টুল দিয়ে, কম্পাইলার এক্সটার্নাল .bc ফাইলে বিটকোড তৈরি করতে পারে। এইসব পুরনো .bc ফাইল ৬৪-বিট আর্কিটেকচারের জন্য আর কাজ করে না, তাই আপনার APK-তে ফাইলটি থাকলে তা নীতি মেনে চলার ক্ষেত্রে সমস্যা সৃষ্টি করে।

সমস্যার সমাধান করতে, আপনার প্রোজেক্ট থেকে যেকোনও.bc ফাইল সরিয়ে দিন, আপনার এনভায়রনমেন্ট build-tools-21.0.0 বা তার পরবর্তী ভার্সনে আপগ্রেড করুন এবং Android Studio-তে renderscriptTargetApi ২১+ হিসেবে সেট করুন, যাতে কম্পাইলারকে .bc ফাইল এমিট না করার নির্দেশ দেওয়া যায়। তারপর, আপনার অ্যাপ আবার তৈরি করুন, .bc ফাইলের জন্য পরীক্ষা করুন এবং Play Console-এ আপলোড করুন।

৬৪-বিট হার্ডওয়্যারে আপনার অ্যাপ পরীক্ষা করুন

আপনার অ্যাপের ৬৪-বিট ভার্সনে ৩২-বিট ভার্সনের মতোই একই কোয়ালিটি ও ফিচার সেট অফার করতে হবে। লেটেস্ট ৬৪-বিট ডিভাইস ব্যবহারকারীরা যাতে আপনার অ্যাপে দারুণ অভিজ্ঞতা পান তা নিশ্চিত করতে আপনার অ্যাপ পরীক্ষা করুন।

শুধুমাত্র ৬৪-বিট ডিভাইস

সম্ভব হলে, নিম্নলিখিত বিকল্পগুলির মধ্যে একটি ব্যবহার করে আপনার অ্যাপটি কঠোরভাবে ৬৪-বিট-অনলি পরিবেশে পরীক্ষা করার সাজেশন দিই:

• শুধুমাত্র ৬৪-বিট সিস্টেম ইমেজ সহ Google Pixel
• Android Emulator

শুধুমাত্র ৬৪-বিট সিস্টেম ইমেজ সহ Google Pixel

অ্যাপ ডেভেলপমেন্ট ও টেস্টিংয়ের সুবিধা দিতে, আমরা কিছু Pixel ডিভাইসের জন্য শুধুমাত্র ৬৪-বিট এনভায়রনমেন্ট সহ বিশেষ সিস্টেম ইমেজ প্রদান করেছি। এইসব শুধুমাত্র ৬৪-বিট ইমেজ মূলত Android 13 ও 14 প্রিভিউ রিলিজের জন্য স্ট্যান্ডার্ড ফ্যাক্টরি সিস্টেম ইমেজের সাথে একই সময়ে প্রদান করা হয়েছিল, তবে আপনি ৬৪-বিট কম্প্যাটিবিলিটির জন্য আপনার অ্যাপ পরীক্ষা করার সময় এগুলি ব্যবহার করা চালিয়ে যেতে পারবেন।

শুধুমাত্র ৬৪-বিট ইমেজ পান

ফ্যাক্টরি সিস্টেম ইমেজের মতো, আপনি Android Flash Tool ব্যবহার করে অথবা ম্যানুয়ালি আপনার ডিভাইস ফ্ল্যাশ করে, আপনার ডিভাইসে শুধুমাত্র ৬৪-বিট ইমেজ ফ্ল্যাশ করতে পারবেন, যেমনটি নিম্নলিখিত বিভাগে বর্ণনা করা হয়েছে।

Android Flash Tool ব্যবহার করে আপনার ডিভাইস ফ্ল্যাশ করুন

Android Flash Tool আপনাকে কাজ করে এমন Pixel ডিভাইসে নিরাপদে সিস্টেম ইমেজ ফ্ল্যাশ করতে দেয়। Android Flash Tool এমন যেকোনও ওয়েব ব্রাউজারের সাথে কাজ করে যা WebUSB-কে সাপোর্ট করে, যেমন Chrome বা Edge 79+।

Android Flash Tool আপনার ডিভাইস ফ্ল্যাশ করার প্রসেস ধাপে ধাপে দেখায়—কোনও টুল ইনস্টল করার প্রয়োজন নেই—তবে আপনাকে ডিভাইস আনলক করতে হবে এবং ডেভেলপার বিকল্পে USB ডিবাগিং চালু করতে হবে। সম্পূর্ণ নির্দেশাবলীর জন্য, Android Flash Tool ডকুমেন্টেশন দেখুন।

USB-র মাধ্যমে আপনার ডিভাইস কানেক্ট করুন, তারপর আপনি যে ধরনের সিস্টেম ইমেজ ফ্ল্যাশ করতে চান তার উপর নির্ভর করে, নিম্নলিখিত লিঙ্কগুলির মধ্যে একটি ব্যবহার করে Android Flash Tool-এ নেভিগেট করুন এবং অনস্ক্রিন নির্দেশিকা অনুসরণ করুন:

• Android 14 (Beta 5.2) শুধুমাত্র ৬৪-বিট সিস্টেম ইমেজ

  আপনি যে ডিভাইস ফ্ল্যাশ করার চেষ্টা করছেন সেটি বেছে নিন:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• Android 13 (QPR3 Beta 3.2) শুধুমাত্র ৬৪-বিট সিস্টেম ইমেজ

  আপনি যে ডিভাইস ফ্ল্যাশ করার চেষ্টা করছেন সেটি বেছে নিন:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

আপনার ডিভাইস ম্যানুয়ালি ফ্ল্যাশ করুন

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

আপনার ডিভাইসের ডেটা ব্যাক-আপ নেওয়া এবং ম্যাচিং সিস্টেম ইমেজ ডাউনলোড করার পরে, আপনি আপনার ডিভাইসে ইমেজ ফ্ল্যাশ করতে পারবেন।

আপনি যেকোনও সময় লেটেস্ট পাবলিক বিল্ডে ফিরে যেতে পারবেন।

Android 14 (বিটা 5.3)-এর জন্য শুধুমাত্র 64-বিট ফ্যাক্টরি ইমেজ

এইসব ছবি ৬৪-বিট অ্যাপের মানানসই হওয়ার বিষয়টি পরীক্ষা করার জন্য কঠোরভাবে শুধুমাত্র ৬৪-বিট এনভায়রনমেন্ট প্রদান করে। এইসব শুধুমাত্র ৬৪-বিট কনফিগারেশন শুধু ডেভেলপারদের ব্যবহারের জন্য।

Android 13-এর জন্য শুধুমাত্র ৬৪-বিট ফ্যাক্টরি ইমেজ (QPR3 বিটা ৩.২)

এইসব ছবি ৬৪-বিট অ্যাপের মানানসই হওয়ার বিষয়টি পরীক্ষা করার জন্য কঠোরভাবে শুধুমাত্র ৬৪-বিট এনভায়রনমেন্ট প্রদান করে। এইসব শুধুমাত্র ৬৪-বিট কনফিগারেশন শুধু ডেভেলপারদের ব্যবহারের জন্য।

সর্বজনীন বিল্ডে ফিরে যান

আপনি Android Flash Tool ব্যবহার করে ফ্যাক্টরি ইমেজ ফ্ল্যাশ করতে পারেন অথবা Nexus ও Pixel ডিভাইসের জন্য ফ্যাক্টরি ইমেজ পৃষ্ঠা থেকে ফ্যাক্টরি স্পেক সিস্টেম ইমেজ পেতে পারেন এবং তারপর ডিভাইসে ম্যানুয়ালি ফ্ল্যাশ করতে পারেন।

Android Emulator

Android 12 (API লেভেল ৩১) থেকে শুরু করে, Android Emulator সিস্টেম ইমেজ শুধুমাত্র ৬৪-বিট হয়। অ্যাপ টেস্টিংয়ের জন্য কঠোরভাবে শুধুমাত্র ৬৪-বিট এনভায়রনমেন্ট পেতে, Android 12 (API লেভেল 31) বা তার পরবর্তী ভার্সনের সিস্টেম ইমেজ ব্যবহার করে Android ভার্চুয়াল ডিভাইস (AVD) তৈরি করুন।

অন্যান্য ডিভাইসের বিকল্প

আপনার কাছে এইসব ডিভাইসের কোনওটি না থাকলে অথবা Android Emulator ব্যবহার করতে না পারলে, আপনার পরবর্তী সেরা বিকল্প হল এমন ডিভাইস ব্যবহার করা যা ৬৪-বিট প্রসেসর চালাতে পারে, যেমন Google Pixel বা অন্যান্য ডিভাইস প্রস্তুতকারকের সাম্প্রতিক ফ্ল্যাগশিপ ডিভাইস।

আপনার অ্যাপ ইনস্টল ও টেস্ট করুন

আপনার APK পরীক্ষা করার সবচেয়ে সহজ উপায় হল Android ডিবাগ ব্রিজ (adb) ব্যবহার করে অ্যাপ ইনস্টল করা। অধিকাংশ ক্ষেত্রে, ডিভাইসে কোন লাইব্রেরি ইনস্টল করতে হবে তা নির্দেশ করতে আপনি প্যারামিটার হিসেবে --abi প্রদান করতে পারেন। এটি ডিভাইসে শুধুমাত্র ৬৪-বিট লাইব্রেরি সহ অ্যাপ ইনস্টল করে।

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

ইনস্টল করা হয়ে গেলে, ৩২-বিট ভার্সনের মতো কোয়ালিটি বজায় আছে কিনা তা নিশ্চিত করতে, আপনার অ্যাপটি স্বাভাবিকভাবে পরীক্ষা করুন।

ডকুমেন্টে সামঞ্জস্যের ক্ষেত্রে কোনও সমস্যা আছে কিনা তা চেক করুন

পরীক্ষা করার সময়, আপনার অ্যাপে নিম্নলিখিত সমস্যাগুলি আছে কিনা তা চেক করুন, যেগুলি ৬৪-বিট ডিভাইসে অ্যাপ চালানোর সময় প্রভাব ফেলে। আপনার অ্যাপ সরাসরি প্রভাবিত লাইব্রেরির উপর নির্ভর না করলেও, আপনার অ্যাপের ডিপেন্ডেন্সিতে থাকা থার্ড-পার্টি লাইব্রেরি এবং SDK করতে পারে।

SoLoader

আপনি নেটিভ কোড লোডার SDK SoLoader ব্যবহার করলে, v0.10.4 বা তার পরবর্তী ভার্সনে আপডেট করুন। আপনার অ্যাপ যদি SoLoader-এর উপর নির্ভর করে এমন SDK ব্যবহার করে, তাহলে প্রভাবিত SDK-এর লেটেস্ট স্টেবল ভার্সনেও আপডেট করতে ভুলবেন না।

SoLoader v0.9.0 এবং তার আগের ভার্সন ধরে নেয় যে সিস্টেম লাইব্রেরি /vendor/lib:/system/lib-এ আছে। Pixel 7-এর মতো ডিভাইসে এই সমস্যা দেখা যায় না, কারণ সেখানে পাথ আছে। তবে, এই অনুমানের কারণে সেইসব ডিভাইসে ক্র্যাশ হয়, যেগুলিতে শুধু /vendor/lib64:/system/lib64-এ সিস্টেম লাইব্রেরি আছে।

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

OpenSSL

আপনি OpenSSL লাইব্রেরি ব্যবহার করলে, OpenSSL 1.1.1i বা তার পরবর্তী ভার্সনে আপডেট করুন। আপনার অ্যাপ যদি এমন SDK ব্যবহার করে যা HTTPS ব্যবহার করে যোগাযোগ করে অথবা OpenSSL-এর উপর নির্ভর করে এমন অন্য SDK ব্যবহার করে, তাহলে SDK-এর লেটেস্ট ভার্সনে আপডেট করতে ভুলবেন না যা নতুন OpenSSL ভার্সন ব্যবহার করে। কোনও SDK উপলভ্য না থাকলে SDK প্রোভাইডারের সাথে যোগাযোগ করুন।

ARMv8.3 PAC রানটাইমে পয়েন্টার যাচাই করার মাধ্যমে হার্ডওয়্যার-অ্যাসিস্টেড কন্ট্রোল ফ্লো ইন্টিগ্রিটি চালু করে। OpenSSL-এর আগের ভার্সনগুলি এইসব ক্ষমতা ভুলভাবে ব্যবহার করে, যার ফলে ARMv8.3a এবং তার পরবর্তী ভার্সনের প্রসেসর সহ সব ডিভাইসে রানটাইম ক্র্যাশ হয়।

OpenSSL-এর কারণে হওয়া এই এবং অন্যান্য সমস্যা সমাধানের ব্যাপারে আরও তথ্য পেতে, Google সহায়তা কেন্দ্রে সংশ্লিষ্ট উত্তর দেখুন।

BTI

ARMv8.5 এবং তার পরবর্তী ভার্সনগুলি JOP অ্যাটাক থেকে রক্ষা করতে সাহায্য করার জন্য ব্রাঞ্চ টার্গেট ইন্সট্রাকশন (BTI) ব্যবহার করে। অবফাসকেশন SDK-এর আগের ভার্সন যা BTI-এর মাধ্যমে তৈরি লাইব্রেরির র‍্যান্ডম অফসেটে ব্রাঞ্চ করে, তা অ্যাপ ক্র্যাশ হওয়ার কারণ হতে পারে। যেহেতু নির্দেশাবলী HINTs হিসেবে এনকোড করা হয়েছে, তাই BTI কাজ করে না এমন ডিভাইসে এই সমস্যা দেখা যায় না।

প্রকাশ করুন

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

কোনও বড় আপডেট প্রকাশ করার সময়, আরও বেশি দর্শকের কাছে প্রকাশ করার আগে ৬৪-বিট-সক্ষম ডিভাইসে ভালভাবে পরীক্ষা করে নিয়েছেন কিনা তা নিশ্চিত করুন।