इस पेज का अनुवाद Cloud Translation API से किया गया है.

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 देखें.

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

प्लैटफ़ॉर्म	32-बिट लाइब्रेरी फ़ोल्डर	64-बिट लाइब्रेरी फ़ोल्डर
सेट करें	`lib/armeabi-v7a`	`lib/arm64-v8a`
x86	`lib/x86`	`lib/x86_64`

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

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

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

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

Android Studio खोलें और कोई भी प्रोजेक्ट खोलें.
मेन्यू में जाकर, बिल्ड > APK का विश्लेषण करें… चुनें
वह APK चुनें जिसका आकलन करना है.
lib फ़ोल्डर में देखें. अगर कोई '.so' फ़ाइल मौजूद है, तो वह इसी फ़ोल्डर में होगी. अगर कोई भी डिवाइस नहीं है, तो इसका मतलब है कि आपका ऐप्लिकेशन 64-बिट डिवाइसों के साथ काम करता है. ऐसे में, आपको कोई कार्रवाई करने की ज़रूरत नहीं है. अगर आपको armeabi-v7a या x86 दिखता है, तो इसका मतलब है कि आपके पास 32-बिट लाइब्रेरी हैं.
देखें कि क्या आपके पास arm64-v8a या x86_64 फ़ोल्डर में एक जैसी '.so' फ़ाइलें हैं.
अगर आपके पास arm64-v8a या x86_64 लाइब्रेरी नहीं हैं, तो अपनी बिल्ड प्रोसेस को अपडेट करें, ताकि अपने APK में उन आर्टफ़ैक्ट को बिल्ड और पैकेज किया जा सके.
अगर आपको पहले से ही दोनों लाइब्रेरी पैकेज की जा रही हैं, तो 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-बिट लाइब्रेरी बनाने का तरीका बताया गया है. ध्यान दें कि इन चरणों में, सिर्फ़ ऐसे कोड और लाइब्रेरी बनाने का तरीका बताया गया है जिन्हें सोर्स से बनाया जा सकता है.

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

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

ज़्यादातर Android Studio प्रोजेक्ट, Gradle को बुनियादी बिल्ड सिस्टम के तौर पर इस्तेमाल करते हैं. इसलिए, यह सेक्शन दोनों मामलों पर लागू होता है. अपने नेटिव कोड के लिए बिल्ड चालू करने के लिए, अपने ऐप्लिकेशन की 'build.gradle' फ़ाइल में मौजूद ndk.abiFilters सेटिंग में, arm64-v8a और/या x86_64 जोड़ें. यह इस बात पर निर्भर करता है कि आपको किन आर्किटेक्चर के साथ काम करना है:

Groovy

// 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'
// ...

Kotlin

// 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-बिट ABI के लिए ऐप्लिकेशन बनाया जा सकता है:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

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

अगर आपका कोड पहले से ही डेस्कटॉप या iOS पर काम करता है, तो आपको Android के लिए कोई अतिरिक्त काम करने की ज़रूरत नहीं है. अगर आपका कोड पहली बार 64-बिट सिस्टम के लिए बनाया गया है, तो आपको इस मुख्य समस्या को ठीक करना होगा कि पॉइंटर अब 32-बिट पूर्णांक टाइप में फ़िट नहीं होते, जैसे कि int.

ऐसे कोड को अपडेट करें जो int, unsigned या uint32_t जैसे टाइप में पॉइंटर सेव करता है. यूनिक्स सिस्टम पर, 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

int फ़ील्ड वाली Java क्लास में भी यही समस्या होती है. ये फ़ील्ड, C/C++ ऑब्जेक्ट के पॉइंटर रखते हैं. अपने 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

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

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

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

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

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

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

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

गेम डेवलपर

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

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

Unity डेवलपर

बेहतर वर्शन पर अपग्रेड करना

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

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

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

Unity का वर्शन	क्या यह वर्शन 64-बिट वाले डिवाइसों पर काम करता है?	सुझाई गई कार्रवाई
2020.x	✔️	पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2019.x	✔️	पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2018.4 (एलटीएस)	✔️	पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2018.3	✔️	पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2018.2	✔️	पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2018.1	➖	इसमें 64-बिट वाले डिवाइसों पर काम करने की सुविधा, एक्सपेरिमेंट के तौर पर उपलब्ध है.
2017.4 (एलटीएस)	✔️	16.4.2017 से काम करता है. पक्का करें कि आपकी बिल्ड सेटिंग, 64-बिट लाइब्रेरी आउटपुट करती हों.
2017.3	✖️	ऐसे वर्शन पर अपग्रेड करें जो 64-बिट को सपोर्ट करता हो.
2017.2	✖️	ऐसे वर्शन पर अपग्रेड करें जो 64-बिट को सपोर्ट करता हो.
2017.1	✖️	ऐसे वर्शन पर अपग्रेड करें जो 64-बिट को सपोर्ट करता हो.
<=5.6	✖️	ऐसे वर्शन पर अपग्रेड करें जो 64-बिट को सपोर्ट करता हो.

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

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

बिल्ड सेटिंग पर जाएं और पक्का करें कि Android के लिए बिल्ड किया जा रहा हो. इसके लिए, यह पुष्टि करें कि प्लैटफ़ॉर्म में जाकर, Android के बगल में Unity का सिंबल मौजूद हो. 1. अगर Android प्लैटफ़ॉर्म के बगल में Unity का निशान नहीं है, तो Android को चुनें और प्लैटफ़ॉर्म बदलें पर क्लिक करें.
प्लेयर की सेटिंग पर क्लिक करें.
Player Settings Panel > Settings for Android > Other settings > Configuration पर जाएं
स्क्रिप्टिंग बैकएंड को IL2CPP पर सेट करें.
टारगेट आर्किटेक्चर > ARM64 चेकबॉक्स चुनें.
इसे सामान्य तरीके से बनाएं!

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

एक से ज़्यादा APK और 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-बिट वाले एनवायरमेंट में टेस्ट करें. इसके लिए, इनमें से किसी एक विकल्प का इस्तेमाल करें:

Google Pixel, जिसमें सिर्फ़ 64-बिट सिस्टम इमेज हो
Android Emulator

Google Pixel, जिसमें सिर्फ़ 64-बिट सिस्टम इमेज हो

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

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

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

ध्यान दें: Pixel 7 और Pixel 7 Pro, 64-बिट वाले ऐप्लिकेशन के साथ लॉन्च होने वाले पहले Android फ़ोन थे. हालांकि, ये डिवाइस Android 13 की सिस्टम इमेज के साथ लॉन्च हुए थे. इनमें 32-बिट फ़ाइल सिस्टम और 32-बिट सिस्टम लाइब्रेरी शामिल हैं, ताकि कंपैटिबिलिटी से जुड़ी समस्याओं को हल किया जा सके. इसलिए, अगर आपके पास Pixel 7 या Pixel 7 Pro के साथ-साथ, 64-बिट सिस्टम इमेज वाला Pixel डिवाइस भी है, तो 64-बिट सिस्टम इमेज वाले डिवाइस का इस्तेमाल करें. इससे, 64-बिट के साथ काम करने की सुविधा की टेस्टिंग के लिए, बेहतर कंट्रोल वाला एनवायरमेंट बनाया जा सकेगा.

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-बिट वाली सिस्टम इमेज

वह डिवाइस चुनें जिसे आपको फ़्लैश करना है:
Android 13 (QPR3 Beta 3.2) की सिर्फ़ 64-बिट वाली सिस्टम इमेज

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

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

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

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

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

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

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

डिवाइस	डाउनलोड करने का लिंक	SHA-256 चेकसम
Pixel 4a (5G)		`7e6731fab811ae389f5ff882d5c5a2b8b942b8363b22bbcc038b39d7c539e60a`
Pixel 5		`c4da6a19086a02f2cd2fa7a4054e870916954b8e5a61e9a07ee942c537e4b45a`
Pixel 6		`98943384284cbc7323b8867d84c36151757f67ae7633012fb69cb5d6bec2b554`
Pixel 6 Pro		`67ec40be5bd05a40fa5dabc1ce6795aae75d1904193d52e2da00425ed7cb895b`

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

डिवाइस	डाउनलोड करने का लिंक	SHA-256 चेकसम
Pixel 4a (5G)		`b4be40924f62c3c2b3ed20a9f7fa4303aa9c39649d778eb96f86c867fe3ae59a`
Pixel 5		`6e5e027a4f64f9f786db9bb69d50d1a551c3f6aad893ae450e1f8279ea1b761a`
Pixel 6		`becb9b81a5bddad67a4ac32d30a50dcb372b9d083cb7c046e5180510e479a0b8`
Pixel 6 Pro		`b0ef544ed2312ac44dc827f24999281b147c11d76356c2d06b2c57a191c60480`

सार्वजनिक तौर पर उपलब्ध बिल्ड पर वापस जाना

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

Android Emulator

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

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

अगर आपके पास इनमें से कोई डिवाइस नहीं है या 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

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

देखें कि इस ऐप्लिकेशन के साथ काम करने से जुड़ी कोई समस्या तो नहीं है

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

SoLoader

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

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

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

OpenSSL

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

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

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

बीटीआई

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

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

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

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

डाउनलोड करें Android 14 factory system image (64-bit-only)

डाउनलोड करने से पहले, आपको नीचे दी गई शर्तों को स्वीकार करना होगा.

नियम और शर्तें

By clicking to accept, you hereby agree to the following:

All use of this development version SDK will be governed by the Android Software Development Kit License Agreement (available at https://developer.android.com/studio/terms and such URL may be updated or changed by Google from time to time), which will terminate when Google issues a final release version.

Your testing and feedback are important part of the development process and by using the SDK, you acknowledge that (i) implementation of some features are still under development, (ii) you should not rely on the SDK having the full functionality of a stable release; (iii) you agree not to publicly distribute or ship any application using this SDK as this SDK will no longer be supported after the official Android SDK is released; and (iv) you agree that Google may deliver elements of the SDK to your devices via auto-update (OTA or otherwise, in each case as determined by Google).

WITHOUT LIMITING SECTION 10 OF THE ANDROID SOFTWARE DEVELOPMENT KIT LICENSE AGREEMENT, YOU UNDERSTAND THAT A DEVELOPMENT VERSION OF A SDK IS NOT A STABLE RELEASE AND MAY CONTAIN ERRORS, DEFECTS AND SECURITY VULNERABILITIES THAT CAN RESULT IN SIGNIFICANT DAMAGE, INCLUDING THE COMPLETE, IRRECOVERABLE LOSS OF USE OF YOUR COMPUTER SYSTEM OR OTHER DEVICE.