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

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

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

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

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

स्थिति की तुरंत जाँच

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. मेन्यू से, बिल्ड > 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 फ़ाइलों को ज़िप फ़ाइलों की तरह बनाया जाता है. कमांड-लाइन या किसी दूसरे ऐप्लिकेशन से, 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 का इस्तेमाल करके बनाया गया है, तो '-DANDROID_ABI' पैरामीटर में arm64-v8a डालकर, 64-बिट एबीआई के लिए ऐप्लिकेशन बनाया जा सकता है:

:: 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-बिट सिस्टम के लिए बनाया गया है, तो आपको मुख्य समस्या हल करनी होगी. यह समस्या यह है कि पॉइंटर अब int जैसे 32-बिट इंटिजर टाइप में फ़िट नहीं होते.

ऐसा कोड अपडेट करें जो int, unsigned या uint32_t जैसे पॉइंटर सेव करता हो. यूनिक्स सिस्टम पर, long पॉइंटर के साइज़ से मेल खाता है. हालांकि, यह विंडो पर लागू नहीं होता. इसके बजाय, मकसद बताने वाले 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 खोजें और पक्का करें कि आप 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

अगर आपके पास इनलाइन असेंबलर है, तो उसे फिर से लिखें या सी/सी++ के सामान्य वर्शन का इस्तेमाल करें.

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

अगर आपको 64-बिट से 32-बिट के लिए, कुछ शर्तों के साथ अलग कोड कंपाइल करना है, तो 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 का इस्तेमाल करना पड़ सकता है. 1 सिर्फ़ 32 बिट का होता है.

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

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

गेम डेवलपर

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

• Unreal 2015 से
• Cocos2d का इस्तेमाल 2015 से किया जा रहा है
• Unity का इस्तेमाल 2018 से किया जा रहा है

Unity डेवलपर

काम करने वाले वर्शन पर अपग्रेड करना

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

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

यहां एक चार्ट दिया गया है, जिसमें Unity के अलग-अलग वर्शन और आपको क्या करना चाहिए, इसकी जानकारी दी गई है:

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

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

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

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

   

3. प्लेयर सेटिंग पैनल > Android के लिए सेटिंग > अन्य सेटिंग > कॉन्फ़िगरेशन पर जाएं

4. स्क्रिप्टिंग बैकएंड को IL2CPP पर सेट करें.

5. टारगेट आर्किटेक्चर > ARM64 चेकबॉक्स चुनें.

   

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

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

मल्टी-एपीके और 64-बिट वाले वर्शन के लिए ज़रूरी शर्तें

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

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

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 बिट वाली इमेज पाएं

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

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

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

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

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

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

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

  • 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 वर्चुअल डिवाइस (AVD) बनाएं.

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

अगर आपके पास इनमें से कोई डिवाइस नहीं है या Android एमुलेटर का इस्तेमाल नहीं किया जा सकता, तो आपके पास 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

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

देखें कि डिवाइस के साथ काम करने से जुड़ी कौनसी समस्याएं हैं

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

SoLoader

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

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

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

OpenSSL

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

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

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

BTI

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

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

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

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