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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android Studio या Gradle के साथ बनाएं

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

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

ndk-build के साथ बनाएं

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

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

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

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

ऐसा कोड अपडेट करें जो 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

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

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

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

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

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

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

गेम डेवलपर

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

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

Unity डेवलपर

बेहतर सुविधाओं वाले वर्शन पर अपग्रेड करें

Unity 2018.2 के वर्शन और 16.4.2017.

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

यहां एक चार्ट दिया गया है, जिसमें 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-बिट लाइब्रेरी आउटपुट करती हों.
3.2017.	✖️	64-बिट वाले वर्शन पर अपग्रेड करें.
2017.2	न करें	64-बिट वाले वर्शन पर अपग्रेड करें.
2017.1	न करें	64-बिट वाले वर्शन पर अपग्रेड करें.
5.6 से कम या इसके बराबर	न करें	64-बिट वाले वर्शन पर अपग्रेड करें.

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

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

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

ध्यान दें कि ARM64 के लिए बिल्डिंग बनाने के लिए, यह ज़रूरी है कि आपकी सभी ऐसेट खास तौर पर बनाई जाएं उस प्लैटफ़ॉर्म के लिए. APK के साइज़ को कम करने के लिए, 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 या उसके बाद के लेवल पर सेट करें और renderscriptTargetApi की मदद से Android Studio में 21 साल के बाद के वर्शन पर काम करें कंपाइलर से .bc फ़ाइलें उत्सर्जन न करें. इसके बाद, अपना ऐप्लिकेशन फिर से बनाएं और .bc की जांच करें फ़ाइलों और Play Console पर अपलोड किया जा सकता है.

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

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

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

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

सिर्फ़ 64-बिट वाले सिस्टम इमेज के साथ Google Pixel
Android एम्युलेटर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android 14 (बीटा 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-बिट फ़ैक्ट्री इमेज

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

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

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

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

Android Emulator

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

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

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

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

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

BTI

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

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

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

किसी बड़े अपडेट को रोल आउट करते समय, पक्का करें कि आपने ज़्यादा लोगों के लिए पब्लिश करने से पहले, 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.