64-बिट आर्किटेक्चर के साथ काम करता है

Google Play पर पब्लिश किए गए ऐप्लिकेशन के लिए, 64-बिट आर्किटेक्चर के साथ काम करना ज़रूरी है. अपने ऐप्लिकेशन का 64-बिट वर्शन जोड़ने से, उसकी परफ़ॉर्मेंस बेहतर होती है. साथ ही, इससे आपका ऐप्लिकेशन सिर्फ़ 64-बिट हार्डवेयर वाले डिवाइसों पर काम करने के लिए तैयार हो जाता है.

यहां दिए गए तरीके से यह पक्का किया जा सकता है कि आपका 32-बिट ऐप्लिकेशन, 64-बिट वाले डिवाइसों पर काम करे.

अपने ऐप्लिकेशन का आकलन करना

अगर आपका ऐप्लिकेशन सिर्फ़ Java प्रोग्रामिंग लैंग्वेज या Kotlin में लिखे गए कोड का इस्तेमाल करता है, तो वह 64-बिट वाले डिवाइसों पर काम करता है. इसमें सभी लाइब्रेरी या SDK टूल शामिल हैं. अगर आपका ऐप्लिकेशन किसी नेटिव कोड का इस्तेमाल करता है या आपको पक्का नहीं है कि वह ऐसा करता है, तो अपने ऐप्लिकेशन का आकलन करें.

स्टेटस की तुरंत जांच करना

Play Console पर जाएं और मौजूदा रिलीज़ देखें. इससे आपको पता चलेगा कि वे हमारी नीतियों का पालन करती हैं या नहीं.

अगर 64-बिट की ज़रूरी शर्त से जुड़ी कोई समस्या है, तो Play Console आपके ड्राफ़्ट रिलीज़ पर लागू होने वाली चेतावनियां भी दिखाता है. यहां दी गई इमेज एक उदाहरण है.

अगर आपको कोई सूचना दिखती है, तो अपने ऐप्लिकेशन को 64-बिट वाले डिवाइसों के साथ काम करने लायक बनाने के लिए, यहां दिया गया तरीका अपनाएं.

क्या आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है?

आपका ऐप्लिकेशन नेटिव कोड का इस्तेमाल करता है, अगर:

• आपके ऐप्लिकेशन में किसी C/C++ (नेटिव) कोड का इस्तेमाल किया जाता है.
• तीसरे पक्ष की किसी भी नेटिव लाइब्रेरी के साथ लिंक करता है.
• इसे तीसरे पक्ष के ऐप्लिकेशन बिल्डर ने बनाया हो और इसमें नेटिव लाइब्रेरी का इस्तेमाल किया गया हो.

क्या आपके ऐप्लिकेशन में 64-बिट लाइब्रेरी शामिल हैं?

अपनी APK फ़ाइल के स्ट्रक्चर की जांच करें. APK बनाते समय, उसे ऐप्लिकेशन के लिए ज़रूरी नेटिव लाइब्रेरी के साथ पैकेज किया जाता है. नेटिव लाइब्रेरी को एबीआई के आधार पर अलग-अलग फ़ोल्डर में सेव किया जाता है. यह ज़रूरी नहीं है कि आपका ऐप्लिकेशन हर 64-बिट आर्किटेक्चर के साथ काम करे. हालांकि, हर नेटिव 32-बिट आर्किटेक्चर के लिए, आपको उससे जुड़ा 64-बिट आर्किटेक्चर शामिल करना होगा.

ARM आर्किटेक्चर के लिए, 32-बिट वाली लाइब्रेरी armeabi-v7a में मौजूद होती हैं. 64-बिट के बराबर arm64-v8a है.

x86 आर्किटेक्चर के लिए, 32-बिट के लिए x86 और 64-बिट के लिए x86_64 देखें.

पक्का करें कि आपके पास इन दोनों फ़ोल्डर में नेटिव लाइब्रेरी हों. ज़रूरी बातों पर फिर से एक नज़र:

ध्यान दें कि आपके ऐप्लिकेशन के हिसाब से, हर फ़ोल्डर में लाइब्रेरी का एक जैसा सेट हो भी सकता है और नहीं भी. इसका मकसद यह पक्का करना है कि आपका ऐप्लिकेशन, सिर्फ़ 64-बिट वाले एनवायरमेंट में सही तरीके से काम करे.

आम तौर पर, 32-बिट और 64-बिट आर्किटेक्चर, दोनों के लिए बनाए गए APK या बंडल में, दोनों एबीआई के लिए फ़ोल्डर होते हैं. हर फ़ोल्डर में नेटिव लाइब्रेरी का एक सेट होता है. अगर 64-बिट वाले डिवाइसों पर काम करने की सुविधा मौजूद नहीं है, तो आपको 32-बिट वाला एबीआई फ़ोल्डर दिख सकता है, लेकिन 64-बिट वाला फ़ोल्डर नहीं दिखेगा.

APK ऐनालाइज़र का इस्तेमाल करके नेटिव लाइब्रेरी ढूंढना

APK ऐनालाइज़र एक ऐसा टूल है जिसकी मदद से, बनाए गए APK के अलग-अलग पहलुओं का आकलन किया जा सकता है. इसका इस्तेमाल करके, नेटिव लाइब्रेरी ढूंढें और पक्का करें कि 64-बिट वाली लाइब्रेरी मौजूद हों.

1. Android Studio खोलें और कोई प्रोजेक्ट खोलें.

2. मेन्यू में जाकर, Build > Analyze APK… को चुनें

   

3. वह APK चुनें जिसकी आपको जांच करनी है.

4. lib फ़ोल्डर में देखें. इसमें '.so' फ़ाइलें होती हैं. अगर कोई गड़बड़ी नहीं है, तो इसका मतलब है कि आपका ऐप्लिकेशन 64-बिट वाले डिवाइसों पर काम करता है. ऐसे में, आपको कुछ और करने की ज़रूरत नहीं है. अगर आपको armeabi-v7a या x86 दिखता है, तो इसका मतलब है कि आपके पास 32-बिट वाली लाइब्रेरी हैं.

5. देखें कि आपके पास arm64-v8a या x86_64 फ़ोल्डर में, मिलती-जुलती '.so' फ़ाइलें हैं या नहीं.

   

6. अगर आपके पास कोई arm64-v8a या x86_64 लाइब्रेरी नहीं है, तो अपने APK में उन आर्टफ़ैक्ट को बनाने और पैकेज करने के लिए, बिल्ड प्रोसेस को अपडेट करें.

7. अगर आपको पहले से ही दोनों लाइब्रेरी पैकेज की हुई दिखती हैं, तो 64-बिट हार्डवेयर पर अपने ऐप्लिकेशन की जांच करना पर जाएं.

APK को अनज़िप करके नेटिव लाइब्रेरी ढूंढना

APK फ़ाइलें, ZIP फ़ाइलों की तरह स्ट्रक्चर्ड होती हैं. कमांड लाइन या किसी अन्य एक्सट्रैक्शन टूल की मदद से, APK फ़ाइल को एक्सट्रैक्ट करें. फ़ाइल को एक्सट्रैक्ट करने के लिए इस्तेमाल किए जा रहे टूल के हिसाब से, आपको फ़ाइल का नाम बदलकर .zip करना पड़ सकता है.

एक्सट्रैक्ट की गई फ़ाइलों को ब्राउज़ करें. इसके लिए, ऊपर दिए गए दिशा-निर्देशों का पालन करें. इससे आपको यह पता चलेगा कि आपका ऐप्लिकेशन 64-बिट वाले डिवाइसों पर काम करता है या नहीं. कमांड लाइन से, इस तरह का कमांड दिया जा सकता है:

:: 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-बिट वाले आर्किटेक्चर के साथ काम करता है.

64-बिट लाइब्रेरी की मदद से अपना ऐप्लिकेशन बनाना

यहां दिए गए निर्देशों में, 64-बिट लाइब्रेरी बनाने का तरीका बताया गया है. ध्यान दें कि इन चरणों में सिर्फ़ ऐसे कोड और लाइब्रेरी बनाने के बारे में बताया गया है जिन्हें सोर्स से बनाया जा सकता है.

Android Studio या Gradle की मदद से ऐप्लिकेशन बनाना

ज़्यादातर Android Studio प्रोजेक्ट, Gradle को बिल्ड सिस्टम के तौर पर इस्तेमाल करते हैं. इसलिए, यह सेक्शन दोनों मामलों पर लागू होता है. अपने नेटिव कोड के लिए बिल्ड चालू करने के लिए, अपने ऐप्लिकेशन की 'build.gradle' फ़ाइल में ndk.abiFilters सेटिंग में arm64-v8a और/या 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 '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 का इस्तेमाल करके बनाया गया है, तो 64-बिट वाले एबीआई के लिए ऐप्लिकेशन बनाया जा सकता है. इसके लिए, '-DANDROID_ABI' पैरामीटर में arm64-v8a पास करें:

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

ndk-build की मदद से बिल्ड करना

अगर आपका ऐप्लिकेशन ndk-build की मदद से बनाया गया है, तो APP_ABI वैरिएबल का इस्तेमाल करके, 'Application.mk' फ़ाइल में बदलाव करके, 64-बिट एबीआई के लिए ऐप्लिकेशन बनाया जा सकता है:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

32-बिट कोड को 64-बिट में पोर्ट करना

अगर आपका कोड पहले से ही डेस्कटॉप या iOS पर काम करता है, तो आपको Android के लिए कुछ और करने की ज़रूरत नहीं है. अगर आपका कोड पहली बार 64-बिट सिस्टम के लिए बनाया गया है, तो आपको सबसे पहले इस समस्या को हल करना होगा कि पॉइंटर अब 32-बिट के पूर्णांक टाइप, जैसे कि 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 क्लास में भी यही समस्या होती है. अपने जेएनआई सोर्स में jint खोजें. साथ ही, पक्का करें कि आपने Java साइड पर long और C++ साइड पर jlong पर स्विच किया हो.

इंप्लिसिट फ़ंक्शन डिक्लेरेशन, 64-बिट कोड के लिए ज़्यादा खतरनाक होते हैं. 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++ का इस्तेमाल करें.

अगर आपने टाइप के साइज़ को हार्ड कोड किया गया है (उदाहरण के लिए, 8 या 16 बाइट), तो उन्हें sizeof(T) एक्सप्रेशन से बदलें, जैसे कि sizeof(void*).

अगर आपको 32-बिट के लिए, 64-बिट से अलग कोड को शर्त के साथ कंपाइल करना है, तो 32/64 के सामान्य अंतर के लिए #if defined(__LP64__) का इस्तेमाल किया जा सकता है. इसके अलावा, Android पर काम करने वाले खास आर्किटेक्चर के लिए, __arm__, __aarch64__ (arm64), __i386__ (x86), और __x86_64__ का इस्तेमाल किया जा सकता है.

printf या scanf जैसे फ़ंक्शन के लिए, फ़ॉर्मैट स्ट्रिंग में बदलाव करें. ऐसा इसलिए, क्योंकि फ़ॉर्मैट के लिए इस्तेमाल होने वाले पारंपरिक स्पेसिफ़ायर, 64-बिट टाइप को इस तरह से तय करने की अनुमति नहीं देते हैं जो 32-बिट और 64-बिट, दोनों डिवाइसों के लिए सही हो. <inttypes.h> में मौजूद PRI और SCN मैक्रो इस समस्या को हल करते हैं. साथ ही, हेक्स पॉइंटर को लिखने और पढ़ने के लिए PRIxPTR और SCNxPTR का इस्तेमाल किया जाता है. इसके अलावा, 64-बिट वैल्यू को पोर्टेबल तरीके से लिखने और पढ़ने के लिए PRId64 और SCNd64 का इस्तेमाल किया जाता है.

शिफ़्ट करते समय, आपको 1 के बजाय 1ULL का इस्तेमाल करना पड़ सकता है, ताकि शिफ़्ट करने के लिए 64-बिट का कॉन्सटैंट मिल सके. सिर्फ़ 32 बिट का होता है.

Android ऐप्लिकेशन बंडल की मदद से, ऐप्लिकेशन के साइज़ को बढ़ने से रोकना

अपने ऐप्लिकेशन में 64-बिट वाले आर्किटेक्चर के साथ काम करने की सुविधा जोड़ने से, आपके APK का साइज़ बढ़ सकता है. हमारा सुझाव है कि आप Android ऐप्लिकेशन बंडल सुविधा का इस्तेमाल करें. इससे, एक ही APK में 32-बिट और 64-बिट, दोनों नेटिव कोड शामिल करने पर, APK के साइज़ पर पड़ने वाले असर को कम किया जा सकता है.

गेम डेवलपर

सबसे ज़्यादा इस्तेमाल किए जाने वाले ये तीन इंजन, 64-बिट वाले डिवाइसों पर काम करते हैं:

• 2015 से Unreal
• Cocos2d, 2015 से
• साल 2018 से Unity

Unity डेवलपर

ज़रूरी वर्शन पर अपग्रेड करना

Unity, 2018.2 और 2017.4.16 वर्शन के साथ 64-बिट की सुविधा देता है.

अगर आपके पास Unity का ऐसा वर्शन है जो 64-बिट के साथ काम नहीं करता, तो तय करें कि आपको किस वर्शन पर अपग्रेड करना है. इसके बाद, Unity की गाइड में दिए गए निर्देशों का पालन करके, अपने एनवायरमेंट को माइग्रेट करें. इससे यह पक्का किया जा सकेगा कि आपका ऐप्लिकेशन, 64-बिट लाइब्रेरी बनाने वाले वर्शन पर अपग्रेड हो गया है. Unity का सुझाव है कि आप एडिटर के सबसे नए एलटीएस वर्शन पर अपग्रेड करें, ताकि आपको नई सुविधाओं और अपडेट का ऐक्सेस मिल सके.

यहां एक चार्ट दिया गया है, जिसमें Unity के अलग-अलग वर्शन और उनके लिए ज़रूरी कार्रवाइयों के बारे में बताया गया है:

64-बिट लाइब्रेरी आउटपुट करने के लिए, बिल्ड सेटिंग बदलें

अगर Unity के ऐसे वर्शन का इस्तेमाल किया जा रहा है जो 64-बिट वाली Android लाइब्रेरी के साथ काम करता है, तो बिल्ड की सेटिंग में बदलाव करके, अपने ऐप्लिकेशन का 64-बिट वाला वर्शन जनरेट किया जा सकता है. स्क्रिप्टिंग बैकएंड के तौर पर, IL2CPP बैकएंड का इस्तेमाल करें. 64-बिट आर्किटेक्चर बनाने के लिए, अपने Unity प्रोजेक्ट को सेट अप करने के लिए, यह तरीका अपनाएं:

1. Build Settings पर जाएं और पक्का करें कि आपने Android के लिए बिल्ड किया है. इसके लिए, पुष्टि करें कि Platform में Android के बगल में Unity का सिंबल मौजूद है. 1. अगर Android प्लैटफ़ॉर्म के बगल में Unity का सिंबल नहीं है, तो Android को चुनें और Switch Platform पर क्लिक करें.

2. प्लेयर की सेटिंग पर क्लिक करें.

   

3. Player Settings Panel > Settings for Android > Other settings > Configuration पर जाएं

4. Scripting Backend को IL2CPP पर सेट करें.

5. Target Architecture > ARM64 चेकबॉक्स को चुनें.

   

6. सामान्य तरीके से बनाएं!

ध्यान दें कि ARM64 के लिए ऐप्लिकेशन बनाने के लिए, यह ज़रूरी है कि आपकी सभी ऐसेट खास तौर पर उस प्लैटफ़ॉर्म के लिए बनाई गई हों. APK का साइज़ कम करने के लिए, Unity के दिशा-निर्देशों का पालन करें. साथ ही, साइज़ में होने वाली इस बढ़ोतरी को कम करने के लिए, Android ऐप्लिकेशन बंडल सुविधा का फ़ायदा लें.

एक से ज़्यादा APK और 64-बिट के साथ काम करने की सुविधा

अगर आपने ऐप्लिकेशन पब्लिश करने के लिए, Google Play की एक से ज़्यादा APK के साथ काम करने की सुविधा का इस्तेमाल किया है, तो ध्यान दें कि 64-बिट की ज़रूरी शर्त का पालन करने की जांच, रिलीज़ लेवल पर की जाती है. हालांकि, 64-बिट की ज़रूरी शर्त उन APKs या ऐप्लिकेशन बंडल पर लागू नहीं होती जो Android 9 Pie या इसके बाद के वर्शन वाले डिवाइसों पर उपलब्ध नहीं हैं.

अगर आपके किसी APK को नीति का पालन न करने वाले के तौर पर मार्क किया गया है, लेकिन वह पुराना वर्शन है और उसे नीति के मुताबिक बनाना मुमकिन नहीं है, तो एक तरीका यह है कि उस APK के मेनिफ़ेस्ट में uses-sdk एलिमेंट में maxSdkVersion="27" एट्रिब्यूट जोड़ें. यह APK, Android 9 Pie या इसके बाद के वर्शन वाले डिवाइसों पर डिलीवर नहीं किया जाता. साथ ही, यह अब नीति का पालन करने से नहीं रोकता.

RenderScript और 64-बिट आर्किटेक्चर के साथ काम करने की सुविधा

अगर आपका ऐप्लिकेशन RenderScript का इस्तेमाल करता है और उसे Android टूल के पुराने वर्शन की मदद से बनाया गया है, तो आपको ऐप्लिकेशन के लिए 64-बिट के साथ काम करने से जुड़ी समस्याएं दिख सकती हैं. 21.0.0 से पहले के बिल्ड टूल की मदद से, कंपाइलर किसी बाहरी .bc फ़ाइल में बिटकोड जनरेट कर सकता है. ये लेगसी .bc फ़ाइलें, अब 64-बिट आर्किटेक्चर के साथ काम नहीं करती हैं. इसलिए, आपके APK में फ़ाइल की मौजूदगी की वजह से, नीति के पालन से जुड़ी समस्या होती है.

इस समस्या को ठीक करने के लिए, अपने प्रोजेक्ट से सभी.bc फ़ाइलें हटाएं. साथ ही, अपने एनवायरमेंट को build-tools-21.0.0 या इसके बाद के वर्शन पर अपग्रेड करें. इसके बाद, Android Studio में renderscriptTargetApi को 21+ पर सेट करें, ताकि कंपाइलर को .bc फ़ाइलें न भेजने के लिए कहा जा सके. इसके बाद, अपना ऐप्लिकेशन फिर से बनाएं, .bc फ़ाइलों की जांच करें, और Play Console पर अपलोड करें.

64-बिट हार्डवेयर पर अपने ऐप्लिकेशन की जांच करना

आपके ऐप्लिकेशन के 64-बिट वर्शन में, 32-बिट वर्शन जैसी ही क्वालिटी और सुविधाएं होनी चाहिए. अपने ऐप्लिकेशन की जांच करें, ताकि यह पक्का किया जा सके कि 64-बिट वाले नए डिवाइसों पर उपयोगकर्ताओं को आपके ऐप्लिकेशन का बेहतरीन अनुभव मिले.

सिर्फ़ 64-बिट वाले डिवाइस

हमारा सुझाव है कि जब भी संभव हो, अपने ऐप्लिकेशन को सिर्फ़ 64-बिट वाले एनवायरमेंट में टेस्ट करें. इसके लिए, इनमें से किसी एक विकल्प का इस्तेमाल करें:

• सिर्फ़ 64-बिट सिस्टम इमेज वाला Google Pixel
• Android Emulator

सिर्फ़ 64-बिट वाली सिस्टम इमेज वाला Google Pixel

ऐप्लिकेशन डेवलपमेंट और टेस्टिंग को आसान बनाने के लिए, हमने कुछ Pixel डिवाइसों के लिए खास सिस्टम इमेज उपलब्ध कराई हैं. इनमें सिर्फ़ 64-बिट वाला एनवायरमेंट होता है. सिर्फ़ 64-बिट वाली ये इमेज, Android 13 और 14 के रिलीज़ होने से पहले झलक देखने के लिए बनाए गए वर्शन के लिए, स्टैंडर्ड फ़ैक्ट्री सिस्टम इमेज के साथ उपलब्ध कराई गई थीं. हालांकि, 64-बिट के साथ काम करने वाले ऐप्लिकेशन की जांच करने के लिए, इनका इस्तेमाल जारी रखा जा सकता है.

सिर्फ़ 64-बिट वाली इमेज पाना

फ़ैक्ट्री सिस्टम इमेज की तरह ही, अपने डिवाइस पर सिर्फ़ 64-बिट वाली इमेज को फ़्लैश किया जा सकता है. इसके लिए, Android Flash Tool का इस्तेमाल करें या अपने डिवाइस को मैन्युअल तरीके से फ़्लैश करें. इसके बारे में यहां बताया गया है.

Android Flash Tool का इस्तेमाल करके, अपने डिवाइस को फ़्लैश करना

Android Flash Tool की मदद से, Pixel डिवाइस पर सिस्टम इमेज को सुरक्षित तरीके से फ़्लैश किया जा सकता है. Android Flash Tool, WebUSB की सुविधा वाले किसी भी वेब ब्राउज़र पर काम करता है. जैसे, Chrome या Edge 79+.

Android Flash Tool, आपके डिवाइस को फ़्लैश करने की प्रोसेस के बारे में सिलसिलेवार तरीके से बताता है. इसके लिए, आपको टूल इंस्टॉल करने की ज़रूरत नहीं है. हालांकि, आपको अपना डिवाइस अनलॉक करना होगा और डेवलपर के लिए सेटिंग और टूल में जाकर, यूएसबी के ज़रिए डीबग करने की सुविधा चालू करनी होगी. पूरे निर्देश देखने के लिए, Android Flash Tool का दस्तावेज़ देखें.

अपने डिवाइस को यूएसबी से कनेक्ट करें. इसके बाद, आपको जिस तरह की सिस्टम इमेज को फ़्लैश करना है उसके आधार पर, इनमें से किसी एक लिंक का इस्तेमाल करके Android Flash Tool पर जाएं और स्क्रीन पर दिए गए निर्देशों का पालन करें:

• Android 14 (बीटा 5.2) की सिर्फ़ 64-बिट वाली सिस्टम इमेज

  वह डिवाइस चुनें जिसे आपको फ़्लैश करना है:

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

• Android 13 (QPR3 Beta 3.2) की सिर्फ़ 64-बिट वाली सिस्टम इमेज

  वह डिवाइस चुनें जिसे आपको फ़्लैश करना है:

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

अपने डिवाइस को मैन्युअल तरीके से फ़्लैश करना

आपके पास, सिस्टम इमेज का नया वर्शन डाउनलोड करने और उसे अपने डिवाइस पर मैन्युअल तरीके से फ़्लैश करने का विकल्प भी है. अपने टेस्ट डिवाइस के लिए सिस्टम इमेज डाउनलोड करने के लिए, यहां दी गई टेबल देखें. अगर आपको टेस्ट एनवायरमेंट पर सटीक कंट्रोल चाहिए या आपको बार-बार फिर से इंस्टॉल करना है, तो डिवाइस को मैन्युअल तरीके से फ़्लैश करना फ़ायदेमंद होता है. जैसे, ऑटोमेटेड टेस्टिंग करते समय.

अपने डिवाइस के डेटा का बैक अप लेने और उससे मैच होने वाली सिस्टम इमेज डाउनलोड करने के बाद, इमेज को अपने डिवाइस पर फ़्लैश किया जा सकता है.

आपके पास किसी भी समय सार्वजनिक तौर पर उपलब्ध सबसे नए बिल्ड पर वापस जाने का विकल्प होता है.

Android 14 (बीटा 5.3) के लिए, सिर्फ़ 64-बिट वाली फ़ैक्ट्री इमेज

ये इमेज, 64-बिट वाले ऐप्लिकेशन के साथ काम करने की सुविधा की जांच करने के लिए, सिर्फ़ 64-बिट वाला एनवायरमेंट उपलब्ध कराती हैं. सिर्फ़ 64-बिट वाले ये कॉन्फ़िगरेशन, डेवलपर के इस्तेमाल के लिए हैं.

Android 13 (QPR3 बीटा 3.2) के लिए, सिर्फ़ 64-बिट वाली फ़ैक्ट्री इमेज

ये इमेज, 64-बिट वाले ऐप्लिकेशन के साथ काम करने की सुविधा की जांच करने के लिए, सिर्फ़ 64-बिट वाला एनवायरमेंट उपलब्ध कराती हैं. सिर्फ़ 64-बिट वाले ये कॉन्फ़िगरेशन, डेवलपर के इस्तेमाल के लिए हैं.

सार्वजनिक बिल्ड पर वापस जाना

Android Flash Tool का इस्तेमाल करके, फ़ैक्ट्री इमेज को फ़्लैश किया जा सकता है. इसके अलावा, Nexus और Pixel डिवाइसों के लिए फ़ैक्ट्री इमेज पेज से फ़ैक्ट्री स्पेसिफ़िकेशन वाली सिस्टम इमेज हासिल की जा सकती है. इसके बाद, इसे डिवाइस पर मैन्युअल तरीके से फ़्लैश किया जा सकता है.

Android Emulator

Android 12 (एपीआई लेवल 31) से, Android Emulator की सिस्टम इमेज सिर्फ़ 64-बिट की होती हैं. ऐप्लिकेशन की टेस्टिंग के लिए, सिर्फ़ 64-बिट वाला एनवायरमेंट पाने के लिए, Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन वाली सिस्टम इमेज का इस्तेमाल करके, Android वर्चुअल डिवाइस (एवीडी) बनाएं.

डिवाइस के अन्य विकल्प

अगर आपके पास इनमें से कोई डिवाइस नहीं है या Android Emulator का इस्तेमाल नहीं किया जा सकता, तो आपके लिए अगला सबसे अच्छा विकल्प 64-बिट वाला डिवाइस इस्तेमाल करना है. जैसे, Google Pixel या डिवाइस बनाने वाली अन्य कंपनियों के हाल ही के फ़्लैगशिप डिवाइस.

अपना ऐप्लिकेशन इंस्टॉल करना और उसकी जांच करना

अपने APK की जांच करने का सबसे आसान तरीका है कि Android डीबग ब्रिज (adb) का इस्तेमाल करके ऐप्लिकेशन इंस्टॉल करें. ज़्यादातर मामलों में, --abi को पैरामीटर के तौर पर दिया जा सकता है, ताकि यह बताया जा सके कि डिवाइस पर कौनसी लाइब्रेरी इंस्टॉल करनी हैं. इससे डिवाइस पर, सिर्फ़ 64-बिट लाइब्रेरी वाला ऐप्लिकेशन इंस्टॉल होता है.

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

ऐप्लिकेशन इंस्टॉल होने के बाद, उसकी जांच करें. इससे यह पक्का किया जा सकेगा कि 64-बिट वाले वर्शन की क्वालिटी, 32-बिट वाले वर्शन जैसी ही है.

साथ काम करने से जुड़ी समस्याओं का पता लगाना

टेस्टिंग के दौरान, अपने ऐप्लिकेशन में इन समस्याओं की जांच करें. ये समस्याएं, 64-बिट वाले डिवाइसों पर ऐप्लिकेशन चलाने के दौरान आती हैं. ऐसा हो सकता है कि आपका ऐप्लिकेशन, सीधे तौर पर उन लाइब्रेरी पर निर्भर न हो जिन पर असर पड़ा है. हालांकि, आपके ऐप्लिकेशन में मौजूद, तीसरे पक्ष की लाइब्रेरी और एसडीके में से किसी एक के भी इस पर निर्भर होने की वजह से, यह समस्या आ सकती है.

SoLoader

अगर नेटिव कोड लोडर एसडीके SoLoader का इस्तेमाल किया जा रहा है, तो इसे v0.10.4 या इसके बाद के वर्शन पर अपडेट करें. अगर आपका ऐप्लिकेशन ऐसे SDK टूल इस्तेमाल करता है जो SoLoader पर निर्भर हैं, तो पक्का करें कि आपने उन SDK टूल को भी नए स्टेबल वर्शन पर अपडेट किया हो जिन पर असर पड़ा है.

SoLoader v0.9.0 और इससे पहले के वर्शन यह मान लेते हैं कि सिस्टम लाइब्रेरी, /vendor/lib:/system/lib में मौजूद हैं. यह गड़बड़ी, Pixel 7 जैसे उन डिवाइसों में नहीं दिखती जिनमें पाथ मौजूद होता है. हालांकि, इस अनुमान की वजह से उन डिवाइसों में क्रैश होते हैं जिनमें सिर्फ़ /vendor/lib64:/system/lib64 में सिस्टम लाइब्रेरी होती हैं.

इस समस्या और SoLoader की वजह से होने वाली अन्य समस्याओं को ठीक करने के बारे में ज़्यादा जानने के लिए, Google के सहायता केंद्र पर इससे जुड़ा जवाब देखें.

OpenSSL

अगर OpenSSL लाइब्रेरी का इस्तेमाल किया जा रहा है, तो OpenSSL 1.1.1i या इसके बाद वाले वर्शन पर अपडेट करें. अगर आपका ऐप्लिकेशन, एचटीटीपीएस का इस्तेमाल करके कम्यूनिकेशन की सुविधा देने वाले SDK टूल या OpenSSL पर निर्भर रहने वाले अन्य SDK टूल का इस्तेमाल करता है, तो SDK टूल के नए वर्शन पर भी अपडेट करना न भूलें. यह वर्शन, OpenSSL के नए वर्शन का इस्तेमाल करता है. अगर ऐसा कोई वर्शन उपलब्ध नहीं है, तो एसडीके बनाने वाली कंपनी से संपर्क करें.

ARMv8.3 PAC, हार्डवेयर के साथ मिलकर कंट्रोल फ़्लो में बदलाव होने से रोकने वाले फ़ंक्शन को चालू करता है. इसके लिए, रनटाइम के दौरान पॉइंटर की पुष्टि की जाती है. OpenSSL के पुराने वर्शन, इन सुविधाओं का गलत तरीके से इस्तेमाल करते हैं. इस वजह से, ARMv8.3a और इसके बाद के वर्शन पर आधारित प्रोसेसर वाले सभी डिवाइसों में रनटाइम के दौरान ऐप्लिकेशन क्रैश हो जाते हैं.

इस समस्या और OpenSSL की वजह से होने वाली अन्य समस्याओं को ठीक करने के बारे में ज़्यादा जानने के लिए, Google सहायता केंद्र में इससे जुड़ा जवाब देखें.

BTI

ARMv8.5 और इसके बाद के वर्शन, जेओपी हमलों से सुरक्षा के लिए, ब्रांच टारगेट इंस्ट्रक्शन (बीटीआई) का इस्तेमाल करते हैं. ऑब्फ़स्केशन एसडीके के पुराने वर्शन, बीटीआई की मदद से बनाई गई लाइब्रेरी के रैंडम ऑफ़सेट में ब्रांच हो जाते हैं. इससे ऐप्लिकेशन क्रैश हो सकते हैं. निर्देशों को HINT के तौर पर एन्कोड किया जाता है. इसलिए, यह गड़बड़ी उन डिवाइसों में नहीं दिखती जिनमें बीटीआई की सुविधा काम नहीं करती.

प्रकाशित करें

जब आपको लगे कि आपका ऐप्लिकेशन तैयार है, तो उसे सामान्य तरीके से पब्लिश करें. हमेशा की तरह, अपने ऐप्लिकेशन को डिप्लॉय करने के लिए सबसे सही तरीके अपनाएं. हमारा सुझाव है कि आप क्लोज़्ड टेस्टिंग ट्रैक का इस्तेमाल करें, ताकि सीमित संख्या में उपयोगकर्ताओं के लिए ऐप्लिकेशन को रोल आउट किया जा सके. इससे यह पक्का किया जा सकेगा कि आपके ऐप्लिकेशन की क्वालिटी एक जैसी बनी रहे.

कोई खास अपडेट रोल आउट करते समय, पक्का करें कि आपने ज़्यादा लोगों के लिए पब्लिश करने से पहले, 64-बिट वाले डिवाइसों पर अच्छी तरह से टेस्ट कर लिया हो.