Google Pixel अब AOSP reference device नहीं रहा

 (9to5google.com)
2 पॉइंट द्वारा GN⁺ 2025-06-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google ने Android 16 का source code AOSP में जारी किया है, लेकिन Pixel hardware repositories को सार्वजनिक नहीं किया
  • Pixel device tree और संबंधित code के सार्वजनिक न होने से community के कुछ हिस्सों में “AOSP बंद किया जा रहा है” जैसी आशंकाएँ उठीं
  • Google ने आधिकारिक तौर पर "AOSP बंद नहीं किया जा रहा" कहकर इसका खंडन किया और दोबारा स्पष्ट किया कि आगे भी AOSP source code को जारी और update किया जाता रहेगा
  • आगे चलकर AOSP का लक्ष्य मौजूदा hardware पर निर्भर न रहने वाला reference target होगा, और यह लचीले, कम-लागत वाले 'Cuttlefish' जैसे virtual devices/ generalized devices (GSI) पर केंद्रित होगा
  • इससे custom ROM developers और security researchers के लिए OS update और research में कठिनाई आ सकती है

Android 16 रिलीज़ और source code जारी करने का मुद्दा

  • Android 16 के रिलीज़ के साथ, Google ने Pixel hardware repositories और device tree code को सार्वजनिक नहीं किया
    • इससे पहले AOSP के साथ Pixel hardware के लिए code भी दिया जाता था, जो custom Android ROM development में एक ज़रूरी भूमिका निभाता था
  • इसके कारण custom ROM developers और security researchers को custom OS development, नए Android updates और security vulnerability research में कठिनाइयों का सामना करना पड़ सकता है

AOSP पर Google का आधिकारिक रुख

  • community के कुछ हिस्सों में “AOSP बंद होने वाला है” जैसी अफ़वाहें फैलीं, लेकिन Android के VP Seang Chau ने
    • "AOSP गायब नहीं हो रहा है"
    • "हम AOSP updates के लिए लगातार प्रतिबद्ध हैं"
      कहकर इसका आधिकारिक खंडन किया
  • हालांकि, Android team के आधिकारिक जवाब से संकेत मिलता है कि आगे Pixel device tree जैसी चीज़ें अब उपलब्ध नहीं कराई जाएँगी
  • AOSP जो reference target उपलब्ध कराएगा, वह किसी खास hardware से स्वतंत्र रूप में होगा
    • लक्ष्य ऐसा लचीला, configurable, कम-लागत वाला reference device देना है, जो Google सहित किसी भी खास hardware से बंधा न हो
    • कई वर्षों से community Cuttlefish (reference device) और GSI targets को source से build करके testing और development के लिए इस्तेमाल करती रही है
    • ये reference devices आगे भी developers के लिए उपलब्ध कराए जाते रहेंगे

custom ROM और security community पर असर

  • Google ने आधिकारिक तौर पर AOSP के लिए लगातार समर्थन देने की अपनी मंशा पर ज़ोर दिया
  • लेकिन सीधे hardware support के हटने से custom ROM बनाने और maintain करने या security research करने में development की कठिनाई और entry barrier काफ़ी बढ़ने की आशंका है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-13
Hacker News राय

  • लोग मुझे अजीब समझ सकते हैं, लेकिन हाल में Pixel खरीदने का मेरा एकमात्र कारण यह था कि खरीदते ही उस पर तुरंत GrapheneOS इंस्टॉल कर सकूँ। अब तक का अनुभव सचमुच बहुत संतोषजनक रहा है। काम से जुड़ी ज़रूरत न हो तो मैं Google से जुड़ी चीज़ों से यथासंभव बचने की कोशिश करता हूँ, क्योंकि Google के बारे में मुझे बहुत सी बातें नापसंद हैं। सच यह है कि Google पर ऐसे binary blobs देते रहने की कोई बाध्यता नहीं है, लेकिन इतने लंबे समय से जो काम होता आ रहा था उसे बिना किसी पूर्व सूचना के अचानक बंद कर देना फिर एक बार निराशाजनक लगा। जैसे वे कई सेवाएँ बंद करते समय करते हैं, वैसे ही पहले से पर्याप्त सूचना देनी चाहिए थी। बेशक binaries को लगातार वितरित करना और उनके काम करने की गारंटी देना अतिरिक्त बोझ है, यह मैं समझता हूँ, लेकिन अंदरूनी तौर पर तो उन्हें वह काम वैसे भी करना ही पड़ता है। मेरे हिसाब से Google ने रणनीतिक तौर पर यह चुना है कि वह कुछ GrapheneOS उपयोगकर्ताओं के लिए डिवाइस पर नुकसान उठाने के बजाय बंद इकोसिस्टम, data mining, विज्ञापन जैसी दूसरी चीज़ों पर ध्यान दे, जहाँ से बाद में पैसा बनता है

    • मैंने भी बिल्कुल इसी वजह से Pixel खरीदा था। अब लगभग हर layer पर tracking होती है, यह बात सब जानते हैं, इसलिए Pixel खरीदकर तुरंत उस पर GrapheneOS flash करना सबसे समझदारी भरा विकल्प लगता है। हमारे घर के सभी फ़ोन, मेरी पत्नी का और मेरा, इसी तरह इस्तेमाल हो रहे हैं। Play Services, Google apps, Facebook वगैरह की बिल्कुल चिंता नहीं करनी पड़ती। मैं नहीं चाहता कि मेरी ज़िंदगी targeted ads का हिस्सा बने या ऐसे data का हिस्सा बने जिसका भविष्य में पता नहीं किस काम में इस्तेमाल हो। उल्टा मुझे हैरानी होती है कि इतने लोग privacy को लेकर इतने बेपरवाह कैसे हैं

    • आपने बहुत उदार मूल्यांकन किया है। मैं भी बिल्कुल यही करता हूँ

    • “Google ने पहले से पर्याप्त सूचना दिए बिना binaries देना बंद कर दिया” इस दावे पर मेरा थोड़ा अलग नज़रिया है। किसी undocumented behavior पर निर्भर रहकर फिर उसके बदलने पर शिकायत करना अजीब है। एक software engineer के लिए ऐसी चीज़ों पर निर्भर न रहना सामान्य समझ होनी चाहिए। अगर कोई यह उदाहरण दे कि उसने Pixel को paperweight की तरह इस्तेमाल किया और camera bump की वजह से अब वह ऐसा नहीं कर सकता, तो उसका दोष कंपनी पर डालना भी कुछ वैसा ही होगा

  • मुझे हमेशा यह बात बहुत अच्छी लगी कि Pixel (या पहले के Nexus) जैसे असली consumer hardware खरीदकर, AOSP और proprietary blobs लेकर, बिना ज़्यादा अतिरिक्त काम के ऐसा build बनाया जा सकता था जिसमें सारा hardware काम करे। Cuttlefish शायद एक अधिक प्रभावी reference device हो सकता है, लेकिन वह Pixel की तरह GrapheneOS जैसे उपयोगों के लिए डिवाइस को अलग-अलग तरह से इस्तेमाल करने वाली बात से अलग है। अपने हाथ से build किए गए Android को असली डिवाइस पर चलाने का अनुभव, मेरे हिसाब से, VM पर करने से कहीं अधिक आकर्षक है

    • लेख के मुताबिक GSI(Generic System Image) को भी reference device के रूप में support किया जाता है, और यह असली hardware के काफ़ी करीब का विकल्प है। हालांकि GSI के साथ कई असुविधाएँ हैं; डिवाइस के low-level specs, जैसे partition scheme या Android का शुरुआती release version, के अनुसार build के प्रकार अलग-अलग होते हैं। फिर भी विकल्प के तौर पर यह बुरा नहीं है। आजकल GKI(Google Generic Kernel Image) भी आया है, जिसे इस तरह डिज़ाइन किया गया है कि custom modules और blobs को छोड़कर यह नए डिवाइसों पर चल सके। हालांकि यह Linux kernel mainline से अलग है और अब भी कई custom patches वाले downstream branch पर आधारित है। फिर भी यह असली डिवाइस से स्वतंत्र होकर एक समान तरीके से testing और development आसान बनाता है

  • मुझे लगता है GrapheneOS ने इस समस्या को बढ़ा-चढ़ाकर पेश किया और खुद ही गलती की, यानी ‘भेड़िया आया’ जैसा असर पैदा किया। जिन आलोचनाओं को आसानी से झूठ बताया जा सकता है, उनका कंपनी के लिए खंडन करना भी आसान हो जाता है। “Google is killing AOSP” जैसी बातें ध्यान तो खींचती हैं, लेकिन कंपनी के लिए उनका जवाब देना बहुत आसान है। अभी जो हो रहा है वह बस इतना है कि GrapheneOS, Google की सद्भावना पर निर्भर होकर binary blobs पा रहा था, और Google पर कोई बाध्यता नहीं थी, इसलिए उसने अपने कारणों से देना बंद कर दिया। ऊपर से GrapheneOS ने कानूनी और monopoly से जुड़े विवादों का ज़िक्र किया, तो developers तो पूरी तरह दूर हो गए और मामला सीधे legal team तक पहुँच गया

    • खास तौर पर क्या बढ़ा-चढ़ाकर कहा गया, यह जानने की उत्सुकता है। क्या झूठ है, GrapheneOS ने पहले भी ऐसा किया है या नहीं, और ठीक-ठीक कौन-सा हिस्सा गलत था, यह जानना चाहता हूँ

    • मेरा मानना है कि इस घटना के बाद GrapheneOS शायद Pixel के बाहर भी और अधिक डिवाइसों को support करने लगेगा। सच कहूँ तो यह काम उसे पहले ही करना चाहिए था, और hardware support कितना भी अच्छा हो, उसके बिना भी यह stock Android से कहीं ज़्यादा सुरक्षित है

    • मेरा रुख यह है कि Google को सक्रिय रूप से बचाने की ज़रूरत नहीं है, क्योंकि वह व्यवहारिक रूप से उन दो कंपनियों में से एक है जिनका लगभग monopoly जैसा दबदबा है

  • मुझे हमेशा यह चिंता रही है कि अगर Pixel hardware repositories, जैसे device trees और driver binaries, उपलब्ध न हों, तो custom Android ROM के लिए OS updates विकसित करना बहुत कठिन हो जाएगा। इससे security research पर भी असर पड़ सकता है

    • खासकर GrapheneOS के आधिकारिक Twitter पर ऐसी बात पोस्ट होने के बाद चिंता और बढ़ गई है

  • अगर GrapheneOS न रहा, तो शायद मैं iPhone पर चला जाऊँगा। लंबे समय से GrapheneOS इस्तेमाल करते हुए मुझे उसका हल्का, सरल और अनावश्यक Google तत्वों से मुक्त अनुभव बहुत पसंद आया है। अब आधिकारिक Google Pixel मेरे लिए उपयुक्त नहीं लगता

  • Google Graveyard की सूची में एक और नाम जुड़ गया। अगर मैं खुद उसे नियंत्रित नहीं कर सकता, तो Pixel इस्तेमाल करने का कोई कारण नहीं बचता। मैं फिर से iPhone आज़माने और उसकी कमियों को स्वीकार करके उसके कई फ़ायदों का लाभ उठाने की योजना बना रहा हूँ

  • “AOSP अभी भी ज़िंदा है, कम से कम emulator में तो इस्तेमाल हो सकता है” जैसी प्रतिक्रिया का खयाल आता है। लेख में कहा गया है, “सालों से developers Cuttlefish(GitHub reference) और GSI targets को source से build करके reference targets की तरह इस्तेमाल करते रहे हैं। आगे भी testing और development के लिए इन्हें उपलब्ध रखा जाएगा।” मैं AOSP के मामले में नया हूँ, इसलिए समुदाय के नज़रिए से यह जानना चाहता हूँ कि क्या ऐसे reference devices वास्तव में custom ROM development में काम के होते हैं, या यह सिर्फ दिखावे की बात है

  • मुझे लगता है कि शायद यही वजह थी कि GrapheneOS Pixel पर इतना अच्छा चलता था। अगर शुरुआती बाधाओं को पार करने के बाद मुख्य बदलावों को समझ लिया जाए, तो हो सकता है support और अधिक डिवाइसों तक फैल सके

    • यह सिर्फ आंशिक रूप से सही है। आधिकारिक FAQ के अनुसार मुख्य कारण हैं: (1) memory tagging जैसी सर्वोच्च स्तर की hardware security features, (2) तेज़ patch delivery, और (3) लंबी आधिकारिक support अवधि

    • या फिर इस बदलाव के कारण GrapheneOS आगे नए devices को support ही न करे

  • Pixel खरीदने का मेरा एकमात्र कारण GrapheneOS था

  • यह कुछ हद तक दोहराया हुआ विषय है संबंधित लिंक