AOSP स्रोत रिलीज़ इतने देर से आते हैं कि डेवलपर्स बग रिपोर्ट करने के लिए लाइब्रेरीज़ को डिसअसेंबल करते हैं
Android के open-source code की रिलीज़ में Google की लगातार बढ़ती देरी डेवलपर्स को bugs का निदान और रिपोर्ट करने के लिए shipped binaries को reverse-engineer करने के लिए मजबूर कर रही है, जिससे transparency, security, और Android ecosystem के दीर्घकालिक स्वास्थ्य पर चिंताएँ बढ़ रही हैं। टिप्पणीकार इस बात पर बहस करते हैं कि यह slowdown EU regulatory दबाव, anti-competitive रणनीति, या साधारण mismanagement से प्रेरित है, और इसका custom ROMs, वैकल्पिक mobile OSes, तथा open source के साथ Google के संबंधों के लिए क्या अर्थ है। कई लोगों के लिए AI-assisted reverse engineering एक workaround भी है और इस बात का संकेत भी कि व्यापक रूप से deployed platforms को “close” करने की कोशिश अब शायद realistic नहीं रही।
देरी से आने वाले AOSP स्रोत रिलीज़ को लेकर चिंताएँ
- कई लोगों का मानना है कि AOSP स्रोत प्रकाशित करने में Google की बढ़ती देरी खुलेपन, सुरक्षा शोध, और downstream ROMs (GrapheneOS, LineageOS, /e/OS) के लिए एक गंभीर गिरावट है।
- इन देरी के कारण डेवलपर्स को समस्याएँ डिबग करने और बग रिपोर्ट करने के लिए शिप की गई लाइब्रेरीज़ को reverse-engineer या disassemble करना पड़ता है।
- कुछ लोगों का तर्क है कि इससे third-party और aftermarket Android distributions को वास्तविक नुकसान होता है जो समय पर AOSP drops पर निर्भर हैं।
स्पष्टीकरण: EU नियम और कॉर्पोरेट प्रोत्साहन
- एक बार-बार उठने वाला सिद्धांत: EU के नियम (विशेष रूप से Cyber Resilience Act और smartphone ecodesign regulation) source या updates को सार्वजनिक किए जाने के साथ ही compliance का एक “timer” शुरू करते हैं।
- OEMs को patches ship करने के लिए अधिक समय देने और कानूनी/संचालन जोखिम कम करने के लिए, संदेह है कि Google AOSP source रोककर और private partner drops का समन्वय करके काम कर रहा है।
- अन्य लोग इसका जवाब देते हैं कि कानून केवल “no undue delay” की माँग करता है, active exploits और reporting पर केंद्रित है, और इतनी लंबी embargo अवधि को सख्ती से मजबूर नहीं करता; उनके अनुसार यह corporate overreaction या opportunistic lock-down है।
- इस बात पर मतभेद है कि कितना हिस्सा कानूनी गलत व्याख्या, जानबूझकर regulatory gaming, या सिर्फ under-resourcing और MBA-शैली के management drift का है।
Android को fork करना और वैकल्पिक OSes
- कुछ का कहना है कि Android अब इतना जटिल हो गया है कि इसे अर्थपूर्ण तरीके से fork नहीं किया जा सकता; कोई भी fork जल्दी ही पीछे रह जाएगा।
- अन्य लोग Linux के इतिहास का हवाला देकर इसका विरोध करते हैं और HarmonyOS, AOSP-आधारित ROMs, तथा संभावित OEM forks (Samsung, Xiaomi) की ओर इशारा करते हैं, हालांकि Harmony को अब Android नहीं और काफी हद तक closed बताया जाता है।
- GrapheneOS, LineageOS, /e/OS, Sailfish, Ubuntu Touch, postmarketOS/Nura, और Linux phones जैसे प्रोजेक्ट्स को आंशिक विकल्पों के रूप में उद्धृत किया गया है, लेकिन hardware support, app availability (खासकर WhatsApp और banking), और funding बड़ी सीमाएँ हैं।
- कई लोग नोट करते हैं कि ये प्रोजेक्ट अभी भी AOSP पर निर्भर हैं; समय पर source न मिलने पर इनके stagnate होने का जोखिम है।
उपयोगकर्ता स्वतंत्रता, attestation, और platform lock-in
- Play Integrity और इसी तरह के attestation systems को “Google के लिए trusted computing” माना जाता है, जो apps (खासकर banking, smart home, automotive) को non-approved OSes को अस्वीकार करने में सक्षम बनाते हैं।
- कुछ लोग ऐसे नियम चाहते हैं जो device को modify करने के अधिकार की गारंटी दें, बिना apps के टूटे; अन्य चेतावनी देते हैं कि इससे अधिक आक्रामक tamper detection बढ़ सकती है।
- bootloader locking के रुझान (विशेष रूप से Pixels के बाहर) Android की ऐतिहासिक openness को कमज़ोर करते हुए देखे जाते हैं, जिससे “average” Android devices लगभग iPhones जितने closed हो जाते हैं।
iOS, प्रतिस्पर्धा, और “third platform” का सवाल
- iOS को इससे भी अधिक closed माना जाता है, फिर भी वह व्यावसायिक रूप से अधिक सफल है, जिससे freedom-respecting platforms की market demand पर संदेह पैदा होता है।
- कुछ लोग “third option” की उम्मीद रखते हैं, लेकिन अन्य लोग नोट करते हैं कि बड़े पैमाने पर मायने रखने के लिए इसे सैकड़ों मिलियन से लेकर एक अरब devices ship करने होंगे—जो किसी भी वर्तमान alternative से कहीं अधिक है।
AI और reverse engineering
- कई टिप्पणियाँ बताती हैं कि आधुनिक AI पहले से ही decompilation, binary diffing, और disassembly से bug-finding में मदद कर सकता है, जिससे source की कमी कुछ हद तक संतुलित हो जाती है।
- इस पर बहस है कि क्या यह open development को तेज़ करता है या मुख्यतः copied features और low-quality clones की “slop avalanche” को बढ़ाता है।