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

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

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

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

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

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

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

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

अगर कोई सूचना दिखती है, तो अपने ऐप्लिकेशन को 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 विश्लेषक एक ऐसा टूल है जिसकी मदद से, बने हुए 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-बिट हार्डवेयर पर अपने ऐप्लिकेशन की जांच करने के लिए आगे बढ़ें.

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

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*).

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

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

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

गेम डेवलपर

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

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

Unity डेवलपर

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

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

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

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

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

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

1. बिल्ड सेटिंग पर जाएं और पक्का करें कि आपने Android के लिए ऐप्लिकेशन बनाया है. इसके लिए, प्लैटफ़ॉर्म में जाकर देखें कि Android के बगल में Unity का सिंबल मौजूद है या नहीं. 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 या इसके बाद के वर्शन वाले डिवाइसों पर डिलीवर नहीं किया जाता. साथ ही, अब यह नीति का पालन करने से नहीं रोकता.

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 Tool का इस्तेमाल करके, अपने डिवाइस को फ़्लैश करना

Android Flash Tool की मदद से, Pixel डिवाइस पर सिस्टम इमेज को सुरक्षित तरीके से फ़्लैश किया जा सकता है. Android Flash Tool, वेबयूएसबी के साथ काम करने वाले किसी भी वेब ब्राउज़र के साथ काम करता है. जैसे, 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 Beta 3.2) के लिए, सिर्फ़ 64-बिट फ़ैक्ट्री इमेज

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

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

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

Android Emulator

Android 12 (एपीआई लेवल 31) से, Android एमुलेटर की सिस्टम इमेज सिर्फ़ 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 का इस्तेमाल किया जा रहा है, तो इसे 0.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 टूल या OpenSSL पर निर्भर अन्य SDK टूल का इस्तेमाल करता है, तो पक्का करें कि आपने SDK टूल के उस नए वर्शन पर भी अपडेट कर लिया हो जो OpenSSL के नए वर्शन का इस्तेमाल करता है. अगर कोई SDK टूल उपलब्ध नहीं है, तो SDK टूल की सेवा देने वाली कंपनी से संपर्क करें.

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

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

BTI

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

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

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

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