मोबाइल SDK के अर्थ और तकनीकी विकास प्रोटोकॉल को समझना

मोबाइल डेवलपमेंट में SDK का क्या अर्थ है? मोबाइल इंजीनियरिंग में, SDK का अर्थ—जो सॉफ्टवेयर डेवलपमेंट किट (Software Development Kit) के लिए है—लाइब्रेरी, API, टूल और डॉक्यूमेंटेशन के एक ऐसे संग्रह को संदर्भित करता है जो डेवलपर्स को एप्लिकेशन बनाने या उनका विस्तार करने में मदद करता है। इसे आमतौर पर Android AAR या iOS XCFramework जैसी संकलित बाइनरी आर्काइव के रूप में वितरित किया जाता है। जब मोबाइल आर्किटेक्ट तृतीय-पक्ष विकास और एट्रिब्यूशन टूल का मूल्यांकन करते हैं, तो बाइनरी और बिल्ड-इंटीग्रेशन स्तर पर SDK के अर्थ को समझना पैकेज के आकार को बढ़ने से रोकने, ट्रांजिटिव डिपेंडेंसी टकराव से बचने और कोल्ड-स्टार्ट स्थिरता बनाए रखने के लिए आवश्यक है। OpoInstall, एक मोबाइल एट्रिब्यूशन और डीप लिंकिंग प्लेटफॉर्म है, जो एंड्रॉइड और आईओएस बिल्ड टूलचेन के लिए डिज़ाइन की गई नेटिव क्लाइंट लाइब्रेरीज़ में क्रॉस-सैंडबॉक्स रूटिंग, चैनल ट्रैकिंग और पैरामीटर रिस्टोरेशन मैकेनिज्म को पैक करता है।

मोबाइल सिस्टम आर्किटेक्चर में, एक SDK केवल कॉल करने योग्य एप्लिकेशन प्रोग्रामिंग इंटरफेस (API) का एक सेट नहीं है। यह एक वितरण योग्य बिल्ड आर्टिफैक्ट है जो कंपाइल-टाइम लिंकिंग के दौरान अपने संकलित बाइटकोड या मशीन-कोड स्लाइस, रिसोर्स टेबल और मेनिफेस्ट घोषणाओं को होस्ट एप्लिकेशन के निष्पादन योग्य पैकेज में एकीकृत करता है।

शब्द (Term)	परिभाषा (Definition)	संबंधित एंटिटी (Related Entity)	खोज आशय भूमिका (Search Intent Role)
SDK Meaning (SDK का अर्थ)	एक होस्ट एप्लिकेशन से जुड़ी लाइब्रेरी, API और टूल पैकेज के रूप में सॉफ्टवेयर डेवलपमेंट किट की वास्तुकला परिभाषा।	होस्ट ऐप बाइनरी	सूचनात्मक (Informational)
Android Archive (`.aar`)	संकलित बाइटकोड, संसाधनों और मेनिफेस्ट नियमों वाली एंड्रॉइड लाइब्रेरीज़ के लिए बाइनरी वितरण प्रारूप।	ग्रैडल बिल्ड सिस्टम	तकनीकी / सूचनात्मक
XCFramework (`.xcframework`)	iOS, macOS और Catalyst के लिए डिवाइस और सिम्युलेटर वेरिएंट को पैकेज करने वाला ऐप्पल का मल्टी-प्लेटफॉर्म बाइनरी बंडल प्रारूप।	एक्सकोड लिंकार	तकनीकी / सूचनात्मक
Technical Growth Protocols (तकनीकी विकास प्रोटोकॉल)	एट्रिब्यूशन SDK द्वारा कार्यान्वित नेटिव रूटिंग, इंस्टॉल-रेफरर, पैरामीटर-रिस्टोरेशन और इवेंट-रिपोर्टिंग तंत्र का संग्रह।	ऐप पैरामीटर इंस्टॉलेशन	वाणिज्यिक / तकनीकी

नेटिव मोबाइल बाइनरी कंपाइलेशन में SDK का अर्थ क्या है

संक्षिप्त नाम से परे: जब आप किसी सॉफ्टवेयर डेवलपमेंट किट को मोबाइल ऐप से लिंक करते हैं तो क्या होता है

शुरुआती स्तर पर, SDK संक्षिप्त नाम सॉफ्टवेयर डेवलपमेंट किट (Software Development Kit) को दर्शाता है - एक सामान्य शब्द जो सोर्स-कोड लाइब्रेरी, कमांड-लाइन कंपाइलर, हार्डवेयर डिबगर और कोड सैंपल को शामिल कर सकता है। हालाँकि, मोबाइल सिस्टम आर्किटेक्ट्स और रिलीज़ इंजीनियरों के लिए, व्यावहारिक SDK अर्थ इस बात से परिभाषित होता है कि कैसे एक तृतीय-पक्ष लाइब्रेरी संकलन (कंपाइलेशन) के दौरान होस्ट एप्लिकेशन को भौतिक रूप से बदल देती है। SDK की व्यापक परिभाषा और स्टेटलेस वेब API से उनके परिचालन अंतर के लिए, हमारी मूलभूत मार्गदर्शिका देखें, How Software Development Kits Power Mobile Attribution and Growth।

एक रिमोट वेब API के विपरीत—जिसे सर्वर-साइड बुनियादी ढांचे के माध्यम से प्रदर्शित किया जाता है और नेटवर्क पर तब呼び (call) किया जाता है जब क्लाइंट अनुरोधों का निर्माण करता है और प्रतिक्रियाओं को संभालता है—एक मोबाइल SDK को सीधे होस्ट प्रोजेक्ट की बिल्ड प्रणाली (एंड्रॉइड पर Gradle या iOS पर Xcode, CocoaPods और Swift Package Manager) द्वारा ग्रहण किया जाता है। एक बार लिंक हो जाने के बाद, SDK का कोड एक अलग बाहरी सेवा के रूप में मौजूद नहीं रहता है; इसकी कक्षाएं, प्रतीक और कॉन्फ़िगरेशन नियम अंत उपयोगकर्ताओं को वितरित एप्लिकेशन बाइनरी का हिस्सा बन जाते हैं, जो होस्ट ऐप की प्रक्रिया मेमोरी, अनुमतियों और ऐप स्टोर या Google Play अनुपालन जिम्मेदारी को साझा करते हैं।

कंपाइलेशन, बाइटकोड DEX पैकेजिंग, और नेटिव लिंकिंग मॉडल

चूँकि एंड्रॉइड और आईओएस अलग-अलग रनटाइम आर्किटेक्चर का उपयोग करते हैं, इसलिए बिल्ड टूलचेन तीन अलग-अलग कंपाइलेशन और लिंकिंग पथों के माध्यम से मोबाइल SDK बाइनरी को एकीकृत करते हैं:

Android Managed Bytecode Compilation (Java/Kotlin to DEX): एंड्रॉइड पर, SDK के भीतर जावा और कोटलिन सोर्स कोड को पहले JVM बाइटकोड (.class फ़ाइलों) में संकलित किया जाता है। जब होस्ट एप्लिकेशन बनता है, तो एंड्रॉइड के D8 और R8 कंपाइलर होस्ट ऐप और सभी लिंक्ड SDK दोनों से .class बाइटकोड को Dalvik Executable (.dex) फ़ाइलों में परिवर्तित करते हैं, जबकि R8 अप्रयुक्त विधियों (methods) को हटाने के लिए कोड श्रिंकिंग, ऑप्टिमाइज़ेशन और ऑबफकेशन करता है।
iOS Native Static Linking (Static Archives .a to Mach-O): iOS पर, जब किसी SDK को स्टैटिक लाइब्रेरी (.a) या स्टैटिक फ्रेमवर्क के रूप में वितरित किया जाता है, तो नेटिव लिंकार (ld) संकलित मशीन-कोड ऑब्जेक्ट फ़ाइलों (.o) को निकालता है और उन्हें सीधे होस्ट एप्लिकेशन के मुख्य Mach-O निष्पादन योग्य बाइनरी में मिला देता है। स्टैटिक लिंकिंग कोल्ड ऐप स्टार्टअप के दौरान रनटाइम डायनेमिक-लोडर ओवरहेड को समाप्त करती है, जबकि डेड-कोड स्ट्रिपिंग लिंक के समय बिना संदर्भ वाले प्रतीकों को हटा देती है।
डाइनैमिक फ्रेमवर्क और शेयरड नेटिव लाइब्रेरीज़ (.framework / .dylib और JNI .so): iOS पर, एक डाइनैमिक फ्रेमवर्क के रूप में पैक किए गए SDK को एप्लिकेशन आर्काइव की Frameworks/ निर्देशिका के भीतर बंडल किया जाता है और जब ऐप लॉन्च होता है तो ऐप्पल के डाइनैमिक लिंकार (dyld) द्वारा मेमोरी में लोड किया जाता है। एंड्रॉइड पर, SDK के अंदर पूर्व-संकलित C या C++ नेटिव कोड को शेयरड ऑब्जेक्ट (.so) लाइब्रेरीज़ के रूप में पैक किया जाता है जिन्हें जावा नेटिव इंटरफेस (System.loadLibrary) के माध्यम से लोड किया जाता है। जबकि डाइनैमिक फ्रेमवर्क iOS ऐप एक्सटेंशन में कोड शेयरिंग की अनुमति देते हैं, स्टार्टअप पर कई डाइनैमिक फ्रेमवर्क लोड करने से main() से पहले dyld रीबेस और बाइंडिंग ओवरहेड बढ़ जाता है।

बिल्ड सिस्टम SDK कोड, संसाधनों, मेनिफेस्ट और होस्ट-ऐप क्षमताओं को कैसे एकीकृत करते हैं

Android and iOS build pipelines integrate SDK binaries into their respective application packages.

बिल्ड पाइपलाइन के दौरान, होस्ट टूलचेन होस्ट प्रोजेक्ट के सुरक्षा कॉन्फ़िगरेशन के साथ-साथ SDK के पैक किए गए मेटाडेटा को संसाधित करता है:

एंड्रॉइड मेनिफेस्ट मर्जिंग: प्रत्येक एंड्रॉइड .aar लाइब्रेरी में SDK द्वारा आवश्यक अनुमतियों या घटकों को घोषित करने वाला एक AndroidManifest.xml होता है। ग्रैडल कंपाइलेशन के दौरान, एंड्रॉइड मेनिफेस्ट मर्जर SDK के मेनिफेस्ट नोड्स को होस्ट एप्लिकेशन के मेनिफेस्ट के साथ जोड़ता है। यदि कोई SDK अपने बंडल किए गए मेनिफेस्ट में अनावश्यक अनुमतियां घोषित करता है, तो tools:node="remove" का उपयोग करके स्पष्ट रूप से हटाए जाने तक वे अनुमतियां अंतिम मर्ज किए गए मेनिफेस्ट द्वारा विरासत में मिल जाती हैं।
iOS होस्ट क्षमताएं और एंटाइटेलमेंट: एंड्रॉइड मेनिफेस्ट के विपरीत, iOS सिस्टम एंटाइटेलमेंट (जैसे यूनिवर्सल लिंक्स के लिए com.apple.developer.associated-domains) को तीसरे पक्ष के XCFramework से होस्ट ऐप में स्वचालित रूप से मर्ज नहीं किया जाता है। इसके बजाय, डेवलपर को एक्सकोड में होस्ट एप्लिकेशन टारगेट पर आवश्यक क्षमता को स्पष्ट रूप से सक्षम करना होगा और ऐप्पल डेवलपर पोर्टल द्वारा अधिकृत प्रोविजनिंग प्रोफ़ाइल के साथ ऐप बाइनरी पर हस्ताक्षर करना होगा।
रिलीज़ आर्टिफैक्ट पैकेजिंग: एंड्रॉइड पर, जब होस्ट एप्लिकेशन को स्टोर रिलीज़ के लिए बनाया जाता है, तो एंड्रॉइड ऐप बंडल (.aab) सीधे इंस्टॉल करने योग्य एप्लिकेशन पैकेज के बजाय एक पब्लिशिंग आर्टिफैक्ट के रूप में कार्य करता है; Google Play App Bundle Delivery .aab को उपयोगकर्ताओं को वितरित किए जाने वाले डिवाइस-विशिष्ट .apk पैकेजों में संसाधित करता है। iOS पर, एक्सकोड ऐप स्टोर वितरण के लिए निष्पादन योग्य और एम्बेडेड फ्रेमवर्क को .ipa आर्काइव में संकलित और हस्ताक्षर करता है।

Exploded Android AAR and Apple XCFramework packages reveal distinct mobile SDK binary structures.

मोबाइल SDK आर्टिफ़ैक्ट्स की संरचना: Android AAR और iOS XCFramework पैकेजों के अंदर

Android AAR आर्काइव के अंदर: बाइटकोड, मेनिफेस्ट, संसाधन और नेटिव लाइब्रेरीज़

Google Android Developers Guide on Android Archive (AAR) Anatomy के अनुसार, AndroidManifest.xml एक .aar आर्काइव में एकमात्र अनिवार्य प्रविष्टि है; अन्य प्रविष्टियाँ—जिनमें classes.jar, R.txt, res/, नेटिव .so लाइब्रेरीज़ और proguard.txt शामिल हैं—वैकल्पिक हैं और लाइब्रेरी के कार्यान्वयन पर निर्भर करती हैं:

/AndroidManifest.xml (अनिवार्य): लाइब्रेरी के पैकेज नेमस्पेस, न्यूनतम समर्थित SDK संस्करण (minSdk), और किसी भी आवश्यक सिस्टम अनुमति या घटक घोषणाओं को घोषित करता है।
/classes.jar (वैकल्पिक): SDK की सार्वजनिक API कक्षाओं और आंतरिक कार्यान्वयन तर्क को उजागर करने वाले संकलित जावा और कोटलिन बाइटकोड (.class फ़ाइलें) शामिल हैं।
/res/ और /R.txt (वैकल्पिक): उनके प्रतीक आईडी मैपिंग के साथ बंडल किए गए UI लेआउट, ड्रॉएबल एसेट्स या स्ट्रिंग टेबल शामिल हैं। गैर-दृश्य बुनियादी ढांचा SDKs (जैसे मोबाइल एट्रिब्यूशन और डीप-लिंकिंग लाइब्रेरीज़) के लिए, UI संसाधनों को छोड़ने से अनावश्यक संसाधन तालिका का फूलना रुक जाता है।
/jni/[abi]/lib*.so (वैकल्पिक): विशिष्ट CPU एप्लिकेशन बाइनरी इंटरफेस (arm64-v8a, armeabi-v7a, x86_64) को लक्षित करने वाली पूर्व-संकलित C या C++ नेटिव लाइब्रेरीज़।
/proguard.txt (वैकल्पिक): उपभोक्ता ProGuard या R8 नियम जो होस्ट ऐप के मिनिफ़ायर को निर्देश देते हैं कि रिलीज़ श्रिंकिंग के दौरान किन SDK कक्षाओं या कॉलबैक इंटरफ़ेस को संरक्षित किया जाना चाहिए।

iOS XCFramework बंडल के अंदर: Info.plist, प्लेटफ़ॉर्म वैरिएंट स्लाइस, हेडर और मॉड्यूल

ऐप्पल प्लेटफॉर्म पर, एक बाइनरी SDK वितरित करने के लिए भौतिक iOS उपकरणों (ARM64) और iOS सिम्युलेटर (ARM64 Apple Silicon और x86_64 Intel) चलाने वाली macOS विकास मशीनों दोनों के समर्थन की आवश्यकता होती है। फैट-बाइनरी टकराव के बिना मल्टी-आर्किटेक्चर वितरण का समर्थन करने के लिए, ऐप्पल ने Apple XCFramework (.xcframework) विनिर्देश पेश किया। एक मानक .framework बिल्ड आमतौर पर एक विशिष्ट प्लेटफ़ॉर्म वैरिएंट को लक्षित करता है और इसमें एक या अधिक समर्थित CPU आर्किटेक्चर हो सकते हैं, जबकि एक .xcframework बंडल कई प्लेटफ़ॉर्म और आर्किटेक्चर वेरिएंट—जैसे कि भौतिक ARM64 iOS डिवाइस स्लाइस के साथ-साथ iOS सिम्युलेटर स्लाइस—को एक ही वितरित करने योग्य निर्देशिका में पैक करता है:

Info.plist (रूट मेनिफेस्ट): प्रत्येक उपलब्ध लाइब्रेरी वैरिएंट (AvailableLibraries) को सूचीबद्ध करता है, इसके SupportedPlatform (ios), SupportedPlatformVariant (डिवाइस बनाम simulator), और SupportedArchitectures (arm64, x86_64) को निर्दिष्ट करता है।
ios-arm64/ और ios-arm64_x86_64-simulator/: उस लक्ष्य के लिए .framework या स्टैटिक .a बाइनरी वाले प्लेटफ़ॉर्म-विशिष्ट सबफ़ोल्डर। आर्काइव बिल्ड के दौरान, एक्सकोड केवल भौतिक डिवाइस स्लाइस का चयन करता है और अंतिम .ipa से सिम्युलेटर स्लाइस को बाहर करता है।
Headers/ और Modules/: सार्वजनिक Objective-C .h हेडर फ़ाइलें (जैसे OpoInstallSDK.h) और Clang module.modulemap फ़ाइलें जो Objective-C और Swift कंपाइलर के लिए टाइप परिभाषाओं को उजागर करती हैं।

# दृष्टांत बाइनरी निर्देशिका तुलना: Android .aar बनाम iOS .xcframework
# नोट: .aar में केवल AndroidManifest.xml अनिवार्य है; आंतरिक XCFramework पथ विक्रेता निर्माण के अनुसार भिन्न होते हैं।

opoinstall-android-sdk.aar                 libOpoInstallSDK.xcframework/
├── AndroidManifest.xml (Mandatory)        ├── Info.plist
├── classes.jar (Optional)                 ├── ios-arm64/
│   └── com/opoinstall/api/                │   ├── Headers/
│       ├── OpoInstall.class               │   │   └── OpoInstallSDK.h
│       ├── OpoData.class                  │   └── libOpoInstallSDK.a
│       ├── OpoError.class                 └── ios-arm64_x86_64-simulator/
│       └── ResultCallBack.class               ├── Headers/
└── proguard.txt (Optional)                    │   └── OpoInstallSDK.h
                                               └── libOpoInstallSDK.a

[Third-Party Mobile SDK Artifact]
       |
       +---> Android (.aar) ---> [AndroidManifest.xml + Optional classes.jar / proguard.txt]
       |                                  |
       |                                  v (Gradle Manifest Merger & D8/R8 DEX Compiler)
       |                         [Host App .aab Publishing Artifact -> Google Play .apk]
       |
       +---> iOS (.xcframework) -> [ios-arm64 Device Slice + ios-simulator Slice]
                                          |
                                          v (Xcode Linker Strips Simulator Slice)
                                 [Host App .ipa Device Executable]

एट्रिब्यूशन SDK के भीतर समाहित तकनीकी विकास प्रोटोकॉल

इस लेख में, "तकनीकी विकास प्रोटोकॉल" एकल औपचारिक मानक के बजाय मोबाइल एट्रिब्यूशन SDK द्वारा सामान्य रूप से कार्यान्वित नेटिव रूटिंग, इंस्टॉल-रेफरर, पैरामीटर-रिस्टोरेशन और इवेंट-रिपोर्टिंग तंत्र के संग्रह को संदर्भित करता है। इन तंत्रों की जाँच करने से यह स्पष्ट होता है कि विकास टीमें वेब ट्रैकिंग स्क्रिप्ट पर पूरी तरह से निर्भर रहने के बजाय अपने बाइनरी में एक क्लाइंट SDK क्यों लिंक करती हैं।

Native mobile SDKs coordinate app links, supported installation context, and asynchronous attribution telemetry.

प्रोटोकॉल 1: URI स्कीम और यूनिवर्सल लिंक या ऐप लिंक रूटिंग इंटरसेप्शन

जब कोई उपयोगकर्ता H5 वेब पेज (https://links.example.com/offer?room_id=402) पर किसी प्रचार लिंक पर टैप करता है, तो एक मोबाइल विकास SDK उन उपयोगकर्ताओं के लिए सीधे इन-ऐप रूटिंग का समन्वय करता है जिनके पास ऐप पहले से स्थापित है:

सिस्टम सत्यापन हैंडशेक: iOS 9+ पर, Apple Universal Links होस्ट ऐप के applinks: एंटाइटेलमेंट से जुड़ी HTTPS-होस्टेड apple-app-site-association (AASA) JSON फ़ाइल के माध्यम से डोमेन स्वामित्व को सत्यापित करते हैं। एंड्रॉइड पर, सत्यापित Android App Links लक्ष्य android:host के साथ http और https दोनों योजनाओं को घोषित करने वाले <intent-filter> पर android:autoVerify="true" का उपयोग करते हैं, जो ऐप के पैकेज नाम और SHA-256 हस्ताक्षर प्रमाणपत्र फ़िंगरप्रिंट वाली होस्ट की गई /.well-known/assetlinks.json डिजिटल एसेट लिंक फ़ाइल के विरुद्ध सत्यापित होता है।
लाइफसाइकिल इंटरसेप्शन: जब OS किसी एप्लिकेशन को किसी सत्यापित लिंक या फ़ॉलबैक कस्टम URI स्कीम (scheme://) के माध्यम से IETF RFC 3986 के अनुसार जागृत करता है, तो नेटिव SDK आने वाले Intent (एंड्रॉइड पर onCreate या onNewIntent के माध्यम से) या NSUserActivity / UIOpenURLContext (आधुनिक सीन-आधारित iOS ऐप्स में UISceneDelegate के माध्यम से, या पुराने UIApplicationDelegate URL-हैन्डलिंग तरीकों, जिन्हें ऐप्पल ने सीन-सक्षम ऐप्स के लिए अप्रचलित चिह्नित किया है) को इंटरसेप्ट करता है, क्वेरी पेलोड को पार्स करता है, और होस्ट ऐप को रूटिंग पैरामीटर वितरित करता है।

प्रोटोकॉल 2: मार्केटप्लेस इंस्टॉल रेफरर IPC बाइंडिंग

जब एप्लिकेशन अभी तक इंस्टॉल नहीं हुआ है और उपयोगकर्ता इसे Google Play Store से डाउनलोड करता है, तो ब्राउज़र कुकीज़ एंड्रॉइड OS सैंडबॉक्स को पार करके नए इंस्टॉल किए गए ऐप में नहीं जा सकती हैं। एंड्रॉइड पर इस अंतर को निश्चित रूप से पाटने के लिए, क्लाइंट SDK आधिकारिक Google Play Install Referrer API का उपयोग करके एक इंटर-प्रोसेस कम्युनिकेशन (IPC) तंत्र को लागू करता है।

पहले लॉन्च पर, SDK एंड्रॉइड के Binder IPC इंटरफेस के माध्यम से Google Play Store सेवा से जुड़ता है और क्लिक और इंस्टॉल-शुरू टाइमस्टैम्प के साथ install_referrer स्ट्रिंग को पढ़ता है। चूँकि Google Play Install Referrer API विशेष रूप से योग्य Google Play Store इंस्टॉलेशन प्रवाहों पर लागू होता है, इसलिए Google Play के बाहर एंड्रॉइड वितरण सर्वर-साइड H5 पैरामीटर मिलान या निर्यातित एंड्रॉइड चैनल पैकेजों (एम्बेडेड channelCode मेटाडेटा ले जाने वाली APK फ़ाइलें) का उपयोग करते हैं।

प्रोटोकॉल 3: एसिंक्रोनस पैरामीटर रिस्टोरेशन और सेशन रिकंसिलिएशन हैंडशेक

क्रॉस-प्लेटफॉर्म वेब-टू-ऐप यात्राओं के लिए (iOS ऐप स्टोर इंस्टॉलेशन सहित, जहाँ ऐप्पल Google Play के इंस्टॉल रेफरर के बराबर सामान्य URL क्वेरी-पैरामीटर पासथ्रू प्रदान नहीं करता है), क्लाइंट SDK IETF RFC 9110 के अनुसार HTTPS पर एक एसिंक्रोनस पैरामीटर रिस्टोरेशन हैंडशेक निष्पादित करता है:

प्री-इंस्टॉल वेब संदर्भ अपलोड: जब उपयोगकर्ता H5 शेयरिंग पेज पर जाता है, तो एकीकृत वेब JS SDK URL में जोड़े गए कस्टम पैरामीटर (जैसे कि इनवाइटर आईडी या channelCode) को पार्स करता है और प्री-इंस्टॉल सेशन रिकॉर्ड को एट्रिब्यूशन सर्वर पर अपलोड करता है।
पोस्ट-इंस्टॉल क्लाइंट हैंडशेक: जब उपयोगकर्ता नए इंस्टॉल किए गए ऐप को खोलता है, तो क्लाइंट SDK अपने टेनेंट AppKey के माध्यम से पंजीकृत एप्लिकेशन की पहचान करते हुए और विक्रेता द्वारा आवश्यक किसी भी अतिरिक्त सत्र-सत्यापन या प्रमाणीकरण तंत्र का उपयोग करते हुए, HTTPS पर एट्रिब्यूशन सर्वर के साथ आरंभ और संवाद करता है। इसके बाद सर्वर कैश्ड कस्टम पैरामीटर (data) और चैनल पहचानकर्ता (channelCode) को पुनर्स्थापित करने का प्रयास करता है। एम्बेडेड AppKey को एक स्टैंडअलोन प्रमाणीकरण रहस्य के रूप में नहीं माना जाना चाहिए।
विक्रेता तंत्र बनाम प्लेटफ़ॉर्म गोपनीयता सीमाएँ: OpoInstall का सार्वजनिक उत्पाद दस्तावेज़ एक H5 चैनल और पैरामीटर इंस्टॉलेशन कार्यप्रवाह का वर्णन करता है जहाँ वेब SDK H5 पेज पर डिवाइस फ़िंगरप्रिंट और चैनल आईडी एकत्र करता है, और नेटिव Android/iOS SDK इंस्टॉलेशन स्रोत का मिलान करने के लिए पहले लॉन्च पर डिवाइस फ़िंगरप्रिंट को पुनः एकत्र करता है। Apple’s User Privacy and Data Use Guidelines के तहत, ऐप्पल स्पष्ट रूप से किसी उपयोगकर्ता या डिवाइस (फ़िंगरप्रिंटिंग) की विशिष्ट रूप से पहचान करने के लिए किसी डिवाइस से डेटा प्राप्त करने पर रोक लगाता है, और प्रतिबंधित फ़िंगरप्रिंटिंग में संलग्न तृतीय-पक्ष SDK का संदर्भ देने वाले ऐप्स को ऐप स्टोर अस्वीकृति का जोखिम होता है। अलग से, जब तृतीय-पक्ष डीप-लिंकिंग या डिफ़र्ड डीप-लिंकिंग सेवाएँ विज्ञापन लक्ष्यीकरण, विज्ञापन माप, या डेटा-ब्रोकर शेयरिंग के लिए विभिन्न कंपनियों के ऐप्स में अद्वितीय पहचानकर्ता पास करती हैं या साझा उपयोगकर्ता पहचान बनाती हैं, तो ऐप ट्रैकिंग ट्रांसपेरेंसी (ATT) प्राधिकरण की आवश्यकता होती है—और ATT सहमति प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग को अनुमति योग्य नहीं बनाती है। यदि कोई विक्रेता यह प्रदर्शित नहीं कर सकता है कि उसका iOS मिलान तंत्र प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग से बचाता है, तो डेवलपर्स को स्वतंत्र रूप से एक अनुपालन विकल्प सत्यापित होने तक iOS पर उस एट्रिब्यूशन तंत्र को तैनात नहीं करना चाहिए।

प्रोटोकॉल 4: डिडुप्लिकेटेड चैनल और कन्वर्जन इवेंट टेलीमेट्री

एक बार इंस्टॉलेशन स्रोत हल हो जाने के बाद, SDK एक एसिंक्रोनस इवेंट-रिपोर्टिंग इंटरफ़ेस प्रदान करता है। ऐप पक्ष पर इंस्टॉलेशन और पंजीकरण रिपोर्ट को डिडुप्लिकेट करके और डेवलपर्स को कस्टम कन्वर्जन "इफेक्ट पॉइंट" (saveEvent / reportEffectPoint) या वायरल शेयरिंग क्रियाओं (shareCode के साथ reportShare) की रिपोर्ट करने की अनुमति देकर, SDK कस्टम पुनः प्रयास कतारों (retry queues) की आवश्यकता के बिना चैनल प्रदर्शन विश्लेषण का समर्थन करता है। विस्तृत विनिर्देश और API परिभाषाएँ OpoInstall technical documentation में उपलब्ध हैं।

SDK बाइनरी फ़ुटप्रिंट और ट्रांजिटिव डिपेंडेंसी का ऑडिट करना

मोबाइल इंजीनियरिंग और यूजर अधिग्रहण के लिए SDK फूलाव (Bloat) क्यों मायने रखता है

Apple के Reducing Your App’s Size (App Thinning) मार्गदर्शन में बताए अनुसार, बड़े एप्लिकेशन पैकेज डाउनलोड समय और स्टोरेज आवश्यकताओं को बढ़ा सकते हैं, जो संभावित रूप से सीमित नेटवर्क या डिवाइस वातावरण में इंस्टॉलेशन पूर्णता दरों को प्रभावित कर सकते हैं। किसी भी तृतीय-पक्ष SDK के प्रभाव को पैकेज के आकार से मानने के बजाय अनुभवजन्य बिल्ड-आकार माप और देखे गए फ़नल मेट्रिक्स के माध्यम से मात्रा निर्धारित किया जाना चाहिए।

ट्रांजिटिव डिपेंडेंसी की छिपी हुई लागत: मेथड रेफरेंस सीमाएं और लाइब्रेरी टकराव

SDK के फूलने और बिल्ड की अस्थिरता का प्राथमिक कारण शायद ही कभी SDK का मुख्य एट्रिब्यूशन तर्क होता है; बल्कि, यह ट्रांजिटिव डिपेंडेंसी हैं—बाहरी ओपन-सोर्स लाइब्रेरीज़ जिन्हें एक SDK ग्रैडल या CocoaPods के माध्यम से स्वचालित रूप से होस्ट प्रोजेक्ट में खींच लेता है:

डिपेंडेंसी संस्करण टकराव: यदि कोई तृतीय-पक्ष SDK किसी सामान्य नेटवर्किंग या सीरियलाइज़ेशन लाइब्रेरी (जैसे OkHttp, Gson, Retrofit, या Protobuf) के विशिष्ट संस्करण पर ट्रांजिटिव डिपेंडेंसी घोषित करता है, और होस्ट एप्लिकेशन उसी लाइब्रेरी के असंगत प्रमुख संस्करण का उपयोग करता है, तो बिल्ड डुप्लिकेट क्लास त्रुटियों के साथ विफल हो सकता है या रनटाइम पर NoSuchMethodError अपवादों के साथ क्रैश हो सकता है।
DEX मेथड रेफरेंस ओवरहेड: एंड्रॉइड पर, Android Multidex Technical Guide के अनुसार प्रत्येक व्यक्तिगत .dex फ़ाइल 65,536 मेथड रेफ़रेंसेस तक सीमित है। यह एक सार्वभौमिक संपूर्ण-एप्लिकेशन मेथड सीमा के बजाय प्रति-DEX-फ़ाइल संदर्भ सीमा है; multidex अनुप्रयोगों को कई DEX फ़ाइलों में संदर्भों को पैकेज करने की अनुमति देता है, हालांकि बड़े ट्रांजिटिव डिपेंडेंसी पेड़ों को खींचने से अभी भी DEX फ़ाइल काउंट, R8 संकलन समय और अंतिम APK आकार बढ़ जाता है।
सप्लाई-चेन सुरक्षा सतह: OWASP Mobile Application Security Project मानकों के अनुसार, किसी SDK द्वारा खींची गई प्रत्येक ट्रांजिटिव लाइब्रेरी एप्लिकेशन के सॉफ्टवेयर सप्लाई-चेन आक्रमण सतह का विस्तार करती है और इसके लिए निरंतर कमज़ोरी निगरानी की आवश्यकता होती है।

परिणामस्वरूप, एक न्यूनतम एट्रिब्यूशन SDK को अनावश्यक बाहरी ट्रांजिटिव डिपेंडेंसी से बचना चाहिए, इसके बजाय मोबाइल ऑपरेटिंग सिस्टम की अंतर्निहित नेटवर्किंग (HttpURLConnection / NSURLSession) और नेटिव JSON पार्सर्स (org.json / NSJSONSerialization) पर भरोसा करना चाहिए।

Android Studio APK Analyzer और Xcode App Thinning रिपोर्ट का उपयोग करके वास्तविक बाइनरी प्रभाव का निरीक्षण करना

इंजीनियरिंग टीमों को कभी भी किसी SDK के फ़ुटप्रिंट का मूल्यांकन करते समय अप्रमाणित आकार के दावों या डाउनलोड की गई .zip आर्काइव के कच्चे संपीड़ित आकार पर भरोसा नहीं करना चाहिए। जबकि OpoInstall का mobile SDK download center नेटिव एंड्रॉइड और iOS SDK पैकेजों को वितरित करता है (वर्तमान में v2.1.0, 2026-09-20 को जारी किया गया), वास्तविक संकलित बाइट डेल्टा, ट्रांजिटिव डिपेंडेंसी काउंट और DEX मेथड संदर्भ वृद्धि को आपके अपने प्रोजेक्ट पर एक बेसलाइन बिल्ड की SDK-एकीकृत बिल्ड से तुलना करके अनुभवजन्य रूप से मापा जाना चाहिए:

Android डिपेंडेंसी ट्री और APK एनालाइज़र: यह सत्यापित करने के लिए कि क्या SDK अवांछित ट्रांजिटिव लाइब्रेरीज़ को खींचता है, Gradle के डिपेंडेंसी टास्क को चलाएं, और फ़ाइल आकार अंतर के लिए apk compare चलाने के लिए आधिकारिक Google Android Developers Guide on APK Analyzer (apkanalyzer CLI या Android Studio GUI) का उपयोग करें, मेथड संदर्भों की तुलना करने के लिए दोनों बिल्ड पर dex references चलाएं, और डाउनलोड-आकार के प्रभाव का अनुमान लगाने के लिए apk download-size चलाएं।
App Thinning साइज़ रिपोर्ट के माध्यम से iOS बेसलाइन तुलना: चूँकि एक .xcframework आर्काइव में भौतिक डिवाइस और सिम्युलेटर दोनों स्लाइस होते हैं, इसलिए डिस्क पर इसका कच्चा फ़ोल्डर आकार इस बात के बराबर नहीं होता है कि अंतिम उपयोगकर्ता क्या डाउनलोड करते हैं। समान रिलीज़ सेटिंग्स का उपयोग करके बेसलाइन बिल्ड (SDK के बिना) और SDK-एकीकृत बिल्ड दोनों के लिए Xcode Organizer में App Thinning साइज़ रिपोर्ट निर्यात करें। SDK के वृद्धिशील फ़ुटप्रिंट का अनुमान लगाने के लिए समान डिवाइस वैरिएंट के लिए संपीड़ित और असंपीडित आकारों की तुलना करें ( $\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$ ), और App Store Connect में अंतिम वितरण आकारों को सत्यापित करें।

निम्नलिखित CLI कमांड यह दर्शाते हैं कि ट्रांजिटिव डिपेंडेंसी, APK आकार डेल्टा और XCFramework स्लाइस का ऑडिट कैसे किया जाए (ध्यान दें कि नीचे दिया गया xcrun lipo पथ उदाहरणात्मक है; lipo कमांड का निर्माण करने से पहले हमेशा .xcframework के भीतर वास्तविक Info.plist और चयनित लाइब्रेरी वैरिएंट का निरीक्षण करें):

Baseline and SDK-integrated release builds reveal binary size, dependency, and method-reference differences.

# 1. Android: अवांछित ट्रांजिटिव लाइब्रेरीज़ को सत्यापित करने के लिए रिलीज़ रनटाइम डिपेंडेंसी का निरीक्षण करें
./gradlew :app:dependencies --configuration releaseRuntimeClasspath

# 2. Android: बेसलाइन और SDK-एकीकृत APKs में DEX मेथड संदर्भ काउंट का निरीक्षण करें
apkanalyzer dex references baseline-release.apk
apkanalyzer dex references with-sdk-release.apk

# 3. Android: कच्चे APK फ़ाइल आकार और अनुमानित ओवर-द-एयर डाउनलोड आकार का निरीक्षण करें
apkanalyzer apk file-size with-sdk-release.apk
apkanalyzer apk download-size with-sdk-release.apk

# 4. Android: बेसलाइन APK (SDK के बिना) की तुलना SDK एकीकृत APK से करें
apkanalyzer apk compare baseline-release.apk with-sdk-release.apk

# 5. iOS: XCFramework रूट plist में समर्थित प्लेटफ़ॉर्म और आर्किटेक्चर वेरिएंट का निरीक्षण करें
plutil -p libOpoInstallSDK.xcframework/Info.plist

# 6. iOS: Info.plist का निरीक्षण करने के बाद किसी विशिष्ट डिवाइस बाइनरी स्लाइस पर उदाहरणात्मक lipo जाँच
xcrun lipo -info libOpoInstallSDK.xcframework/ios-arm64/libOpoInstallSDK.a

मोबाइल SDK बाइनरी फ़ुटप्रिंट और आर्किटेक्चर मूल्यांकन मैट्रिक्स

भारी मोनोलिथिक SDKs की तुलना न्यूनतम एट्रिब्यूशन SDKs से करना

तृतीय-पक्ष मोबाइल SDKs की वास्तुकला संबंधी समीक्षा करते समय, इंजीनियरिंग लीड निम्नलिखित पांच संरचनात्मक आयामों में उम्मीदवारों का मूल्यांकन कर सकते हैं:

मूल्यांकन मानदंड (Evaluation Criterion)	भारी मोनोलिथिक SDK	न्यूनतम एट्रिब्यूशन SDK	होस्ट ऐप पर आर्किटेक्चरल प्रभाव
Transitive Dependencies	बाहरी नेटवर्किंग, JSON, या UI लाइब्रेरीज़ को खींचता है	नेटिव OS नेटवर्किंग और पार्सर्स का उपयोग करके आत्मनिर्भर	ग्रैडल और CocoaPods संस्करण टकराव को रोकता है
Compiled Binary Footprint	प्रति आर्किटेक्चर स्लाइस मल्टी-मेगाबाइट वृद्धि	कॉम्पैक्ट फ़ुटप्रिंट (APK एनालाइज़र और ऐप थिनिंग के माध्यम से $\Delta S$ मापें)	डाउनलोड ओवरहेड और स्टोरेज दबाव को कम करता है
DEX Method Reference Count	बंडल किए गए उप-मॉड्यूल में हजारों संदर्भ	कम संदर्भ ओवरहेड के साथ केंद्रित सार्वजनिक API सतह	अतिरिक्त DEX शार्ड विस्तार को कम करता है
Native `.so` / C++ Bridges	एकाधिक वास्तुकला बाइनरी (`armeabi-v7a`, `arm64-v8a`)	शुद्ध JVM बाइटकोड / Objective-C या न्यूनतम नेटिव फ़ुटप्रिंट	ABI फ़िल्टरिंग और 64-बिट स्टोर अनुपालन को सरल बनाता है
Privacy & Policy Surface	व्यापक हार्डवेयर, स्थान और सेंसर API एक्सेस	एट्रिब्यूशन और डीप-लिंक रूटिंग तंत्र तक सीमित	Apple और Google नियमों के विरुद्ध स्वतंत्र ऑडिट की आवश्यकता है

इंजीनियरिंग टीम को समर्पित ग्रोथ SDK की आवश्यकता कब होती है

ऐसी स्थितियाँ जहाँ हल्का एट्रिब्यूशन SDK वास्तुकला से उचित है

एक समर्पित मोबाइल एट्रिब्यूशन और डीप-लिंकिंग SDK को एकीकृत करना निम्नलिखित स्थितियों में उचित है:

क्रॉस-सैंडबॉक्स पैरामीटर रिस्टोरेशन: आपका अधिग्रहण फ़नल उपयोगकर्ताओं को H5 वेब पेजों, सामाजिक शेयरों या QR कोड से App Store या Google Play के माध्यम से रूट करता है और बिना किसी मैन्युअल कोड इनपुट के पहले लॉन्च पर कस्टम पैरामीटर (जैसे कि रेफ़रल कोड या रूम आईडी) को पुनर्स्थापित करने की आवश्यकता होती है।
एकीकृत डीप-लिंक रूटिंग रखरखाव: आपकी टीम विभिन्न मोबाइल ब्राउज़रों और सोशल इन-ऐप WebView में यूनिवर्सल लिंक्स, एंड्रॉइड ऐप लिंक्स और फ़ॉलबैक कस्टम URL योजनाओं को संभालने के लिए एक सिंगल क्लाइंट कॉलबैक इंटरफ़ेस चाहती है।
मल्टी-चैनल H5 और APK पैकेज ट्रैकिंग: आपका विपणन संचालन H5 चैनल लिंक और एंड्रॉइड चैनल पैकेजों में अभियानों को वितरित करता है और इसके लिए समेकित इंस्टॉलेशन, पंजीकरण और कन्वर्जन-इवेंट रिपोर्टिंग की आवश्यकता होती है।

ऐसी स्थितियाँ जहाँ एक अन्य मोबाइल SDK जोड़ने से बचना चाहिए

इसके विपरीत, निम्नलिखित स्थितियों में तृतीय-पक्ष क्लाइंट SDK जोड़ने से बचना चाहिए:

अनावश्यक क्लाइंट क्षमताएं: यदि प्रस्तावित SDK उस कार्यक्षमता को डुप्लिकेट करता है जिसे आपका एप्लिकेशन पहले से ही नेटिव OS API या मौजूदा कोर लाइब्रेरी का उपयोग करके साफ-सुथरे तरीके से कार्यान्वित करता है।
अत्यासपित गोपनीयता या अनुपालन स्थिति: यदि SDK डिवाइस-मिलान संकेतों (जैसे iOS पर प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग) पर निर्भर करता है जिसे वर्तमान App Store Review Guidelines और क्षेत्रीय डेटा-सुरक्षा कानूनों के अनुपालन के रूप में स्वतंत्र रूप से सत्यापित नहीं किया जा सकता है।
शुद्ध रूप से बैकएंड एनालिटिक्स वर्कफ़्लो: यदि आपके द्वारा ट्रैक किए जाने वाले इवेंट पूरी तरह से प्रमाणित बैकएंड सर्वर पर होते हैं (जैसे आवर्ती सदस्यता नवीनीकरण), जहाँ एक प्रत्यक्ष सर्वर-टू-सर्वर (S2S) HTTP API किसी भी क्लाइंट बाइनरी फ़ुटप्रिंट से बचाता है।

मोबाइल SDK आर्किटेक्चर के बारे में सामान्य गलत धारणाएं

गलत धारणा 1: डाउनलोड किया गया SDK Zip साइज़ ऐप साइज़ की वृद्धि के बराबर है: डाउनलोड की गई .xcframework या .aar आर्काइव में सिम्युलेटर स्लाइस, हेडर फ़ाइलें और असंपीडित मेटाडेटा शामिल होते हैं जिन्हें रिलीज़ कंपाइलेशन के दौरान Xcode App Thinning और Android R8 द्वारा हटा दिया जाता है। रिलीज़ बिल्ड और SDK-एकीकृत रिलीज़ बिल्ड के बीच वृद्धिशील डेल्टा ( $\Delta S$ ) को हमेशा मापें।
गलत धारणा 2: शून्य ट्रांजिटिव डिपेंडेंसी का मतलब शून्य गोपनीयता समीक्षा है: यहां तक कि एक आत्मनिर्भर SDK जो शून्य तृतीय-पक्ष ओपन-सोर्स लाइब्रेरी का उपयोग करता है, वह भी आपके एप्लिकेशन की गोपनीयता सीमा के भीतर निष्पादित होता है। रिलीज़ से पहले इंजीनियरिंग टीमों को SDK द्वारा एकत्र किए गए प्रत्येक नेटवर्क अनुरोध, plist घोषणा और डिवाइस सिग्नल का ऑडिट करना चाहिए।

अक्सर पूछे جانے वाले प्रश्न (FAQ)

Android AAR और iOS XCFramework फ़ाइलों का निरीक्षण करते समय SDK का अर्थ क्या है?

मोबाइल बिल्ड सिस्टम में, SDK के अर्थ का तात्पर्य पहले से संकलित लाइब्रेरी आर्काइव से है—विशेष रूप से एंड्रॉइड पर एक `.aar` फ़ाइल (जहाँ वैकल्पिक `classes.jar` बाइटकोड और संसाधनों के साथ `AndroidManifest.xml` अनिवार्य है) या iOS पर एक `.xcframework` बंडल (अलग डिवाइस और सिम्युलेटर वेरिएंट को पैकेज करना)—जो प्रदाता के सोर्स कोड को शुरुआत से संकलित किए बिना एक होस्ट ऐप में विशेष सुविधाओं को लिंक करता है।

मैं कैसे मापूँ कि एक मोबाइल SDK मेरे ऐप में कितना आकार जोड़ता है?

समान कंपाइलर सेटिंग्स के तहत एक SDK-एकीकृत रिलीज़ बिल्ड के मुकाबले बेसलाइन रिलीज़ बिल्ड की तुलना करें। एंड्रॉइड पर, APK फ़ाइल-आकार के अंतर का निरीक्षण करने के लिए `apkanalyzer apk compare` का उपयोग करें, मेथड संदर्भों की तुलना करने के लिए दोनों बिल्ड पर `apkanalyzer dex references` चलाएं, और डाउनलोड-आकार के प्रभाव का अनुमान लगाने के लिए `apkanalyzer apk download-size` का उपयोग करें। iOS पर, Xcode Organizer में दोनों बिल्ड के लिए App Thinning साइज़ रिपोर्ट निर्यात करें और एकीकृत वैरिएंट साइज़ से बेसलाइन वैरिएंट साइज़ को घटाएं ($\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$)।

तृतीय-पक्ष SDK में ट्रांजिटिव डिपेंडेंसी बिल्ड विफलता का कारण क्यों बनती हैं?

जब कोई तृतीय-पक्ष SDK सामान्य ओपन-सोर्स लाइब्रेरीज़ (जैसे OkHttp, Gson, या Protobuf) को ट्रांजिटिव डिपेंडेंसी के रूप में घोषित करता है, तो वे संस्करण होस्ट एप्लिकेशन द्वारा उपयोग की जाने वाली उन्हीं लाइब्रेरीज़ के विभिन्न संस्करणों के साथ संघर्ष कर सकते हैं, जिससे संकलन के समय डुप्लीकेट क्लास त्रुटियां या रनटाइम पर `NoSuchMethodError` क्रैश ट्रिगर हो सकते हैं।

सारांश और बाइनरी मूल्यांकन चेकलिस्ट

मोबाइल डेवलपमेंट में वास्तविक SDK अर्थ को समझने के लिए उच्च-स्तरीय संक्षिप्त नाम परिभाषाओं से आगे बढ़कर यह देखने की आवश्यकता है कि संकलित लाइब्रेरीज़ आपके एप्लिकेशन बाइनरी में कैसे विलीन होती हैं और तकनीकी विकास प्रोटोकॉल को निष्पादित करती हैं। एक अच्छी तरह से इंजीनियर मोबाइल एट्रिब्यूशन SDK अपने बाइनरी फ़ुटप्रिंट और ट्रांजिटिव डिपेंडेंसी ट्री को न्यूनतम रखते हुए क्रॉस-सैंडबॉक्स रूटिंग, इंस्टॉल रेफरर बाइंडिंग और पैरामीटर रिस्टोरेशन को समाहित करता है।

उत्पादन रिलीज़ के लिए किसी भी तृतीय-पक्ष मोबाइल SDK को स्वीकृत करने से पहले, इंजीनियरिंग लीड को इस बाइनरी और अनुपालन सत्यापन चेकलिस्ट को निष्पादित करना चाहिए:

डिपेंडेंसी ट्री का निरीक्षण करें: ./gradlew :app:dependencies --configuration releaseRuntimeClasspath चलाएं या यह पुष्टि करने के लिए Podfile.lock का निरीक्षण करें कि क्या SDK परस्पर विरोधी ट्रांजिटिव लाइब्रेरीज़ पेश करता है।
वृद्धिशील पोस्ट-कंपाइलेशन आकार मापें ( $\\Delta S$ ): एंड्रॉइड पर apkanalyzer apk compare का उपयोग करके और iOS पर बेसलाइन-बनाम-एकीकृत ऐप थिनिंग साइज़ रिपोर्ट का उपयोग करके बेसलाइन रिलीज़ बिल्ड की तुलना SDK-एकीकृत बिल्ड से करें (वर्तमान डाउनलोड की गई आर्काइव के खिलाफ परीक्षण, जैसे v2.1.0)।
API हस्ताक्षरों और स्वच्छ निर्माण (Clean Builds) को सत्यापित करें: एक स्वच्छ निर्माण वातावरण में सभी पैकेज आयात, मेनिफेस्ट फ़िल्टर (एंड्रॉइड ऐप लिंक के लिए http और https योजनाएं), और जीवनचक्र कॉलबैक (UISceneDelegate बनाम अप्रचलित AppDelegate URL विधियाँ) की पुष्टि करें।
प्रोटोकॉल और गोपनीयता अनुपालन का ऑडिट करें: विक्रेता के साथ पुष्टि करें कि सभी डीप-लिंकिंग एंटाइटेलमेंट, इंस्टॉल रेफरर बाइंडिंग और सर्वर-साइड मिलान संकेत प्रतिबंधित डिवाइस फ़िंगरप्रिंटिंग से बचते हैं और वर्तमान Apple User Privacy Guidelines और Google Play नीतियों का अनुपालन करते हैं।

इंजीनियरिंग टीमें SDK एकीकरण का मूल्यांकन करने और स्टेजिंग बिल्ड में बाइनरी फ़ुटप्रिंट को मापने के लिए OpoInstall developer console पर एक परीक्षण एप्लिकेशन पंजीकृत कर सकती हैं।