Google Android विकास के कैदी

 (solutional.ee)
2 पॉइंट द्वारा GN⁺ 2023-08-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लेगेसी Android ऐप के targetSdkVersion को Google की requirements के अनुसार बढ़ाने वाला एक छोटा maintenance task Android 13 production crash और Google Play review में लंबी प्रतीक्षा में बदल गया
  • मौजूदा ऐप को target level से ऊंचे Android version वाले device users को उपलब्ध बने रहने के लिए API level 31 या उससे ऊपर target करना था, और लेखक ने API level 30 से 33 पर बढ़ाकर deploy किया
  • पहला release 1 घंटे के अंदर approve हो गया, लेकिन Android 13 के real device पर login के तुरंत बाद crash हुआ, और पिछले stable version पर rollback करने का कोई तरीका नहीं था
  • Fix build code changes के तुरंत बाद submit किया गया, लेकिन करीब 72 घंटे तक review pending रहा, और बाद में 4 सितंबर को ही 11 दिन बाद production में publish हुआ
  • Native mobile apps में, source code और infrastructure खुद operate करने पर भी final delivery channel को app store operator control करता है, जिससे emergency fixes, rollback और deployment speed में constraints आते हैं

छोटा SDK update production incident में बदल गया

  • Maintenance का target customer द्वारा इस्तेमाल किया जाने वाला लेगेसी Android application था
    • Features कई सालों से complete state में थे और यह actively developed app नहीं था
    • आदर्श रूप से stable version को वैसा ही छोड़ देना चाहा जा रहा था
  • Google ने 18 अगस्त 2023 को email से Android API level requirements की जानकारी दी
  • Google guidance का मुख्य point यह था कि मौजूदा ऐप को ऊंचे Android version devices वाले users को उपलब्ध बने रहने के लिए API level 31 या उससे ऊपर target करना होगा
  • पहले से installed apps पर exact impact साफ नहीं था, और ज्यादा safe interpretation के तहत update को प्राथमिकता दी गई
  • Deadline में 3 हफ्ते से भी कम समय बचा था, और Google ने इस requirement के बारे में पहले कोई reminder नहीं भेजा था

targetSdkVersion 30 से 33 में बदला

  • काम 23 अगस्त को शुरू हुआ और ऐप के targetSdkVersion को API level 30 से 33 पर बढ़ाया गया
  • पहला build incompatible analytics dependency की वजह से fail हुआ
    • यह dependency business logic से गहराई से जुड़ी नहीं थी, इसलिए इसे remove किया जा सका
  • इसके बाद Android emulator में ऐप चलाया गया, और core features पहले की तरह काम करते दिखे
  • यह change कोई नया business value देने वाला नहीं, बल्कि policy compliance update था

पहला Google Play deployment और Android 13 crash

  • Google Play deployment process शुरुआत में smooth रहा
    • लेगेसी ऐप साल में सिर्फ एक-दो बार update होता था, इसलिए कई surveys complete करने पड़े
    • Release 1 घंटे के अंदर review पास करके production में deploy हो गया
  • उसी शाम करीब 21:30 पर, customer ने नए app version में login न कर पाने वाले users की रिपोर्ट की और समस्या सामने आई
  • Real Android device पर test करने पर login के तुरंत बाद application crash हो गया
  • आगे जांच में पता चला कि समस्या उस समय के latest Android version Android 13 पर हो रही थी, जबकि पुराने versions ठीक चल रहे थे
  • शुरुआती काम में सिर्फ पुराने emulator images test किए गए थे, इसलिए compatibility issue सामने नहीं आया
  • अगर कई Android versions test किए जाते, तो यह समस्या पकड़ी जा सकती थी
    • Change का scope छोटा था और deadline pressure था, इससे गलत confidence बना, लेकिन test coverage की कमी team की गलती थी

Rollback रोक देने वाला deployment structure

  • सबसे safe शुरुआती response पिछले stable release को restore करना और अगले working hours में crash investigate करना था, लेकिन Google Play में यह option नहीं था
  • Latest production release को withdraw करके पुराने version को फिर से activate करने का कोई तरीका नहीं था
  • अगले उपाय के रूप में targetSdkVersion को 30 पर वापस करके app version बढ़ाकर नया build publish करने की कोशिश की गई, लेकिन Google Play ने reject कर दिया
    • Published guidance ऐसा लग रहा था कि 1 सितंबर तक lower target allow है, लेकिन error आया कि नए update को API level 33 target करना होगा
  • API level 30 को 1 नवंबर तक allow करने के लिए extension request किया गया, लेकिन publishing error वैसा ही रहा
  • उपलब्ध रास्ता सिर्फ Android 13 crash fix करके नया release submit करना था

दबाव में fix और लंबा review wait

  • Broken version automatic updates के जरिए users तक धीरे-धीरे पहुंच रहा था, और fix build जितनी जल्दी production तक पहुंचता, उतने कम customers प्रभावित होते
  • Crash Android 13 emulator पर reproduce हो सकता था, और required code changes ज्यादा नहीं थे
  • लेकिन देर शाम pressure में काम करना पड़ा, और comprehensive regression testing के लिए समय सीमित था
  • उस समय plan practical response जैसा था
    • सभी known crashes fix करना
    • सबसे important flows test करना
    • Fix version तुरंत submit करना
    • Wider testing जारी रखना और जरूरत हो तो additional update तैयार रखना
  • New build Google Play पर submit किया गया, लेकिन 2 घंटे बाद भी review pending था, और करीब 01:00 बजे भी approve नहीं हुआ था
  • अगली सुबह भी ऐप in review state में ही था
  • दिन का ज्यादातर हिस्सा Android 13 testing और Google Play Console check करने में गया, और login crash जितनी गंभीर नहीं थीं ऐसी कुछ छोटी समस्याएं ढूंढकर fix की गईं
  • उस दिन के अंत तक भी production fix approve नहीं हुआ था
  • उस समय fix build करीब 72 घंटे से pending था, और code fix हो चुका था लेकिन deployment opaque review queue में फंसा था

बाद के updates: review, support chat, staged rollout

  • 27 अगस्त को Hacker News पर post डाली गई, और discussion में Android release strategy और criticism दोनों आए
    • Post front page पर गई और कुछ दिनों में करीब 1.3 लाख unique visitors मिले
    • लगभग €5/month लागत वाले VPS पर चल रही static site ने traffic संभाल लिया
    • इस attention से Google की response नहीं आई और app update review में ही रहा
  • 1 सितंबर को Google Play Console के question mark icon के पीछे मौजूद support chat मिला
    • Support agent ने review तेज कराने का वादा किया, लेकिन clear timeline या solution नहीं दिया
    • बड़ी Hacker News discussion में किसी ने इस route का जिक्र नहीं किया था, यह बात ध्यान देने लायक थी
    • Google support तक पहुंचना मुश्किल है, ऐसी reputation के कारण developers शायद direct help की उम्मीद नहीं करते
  • 4 सितंबर को fix update 11 दिन के review के बाद आखिरकार publish हुआ
  • इसके बाद तुरंत 100% users को deploy करने के बजाय staged rollout इस्तेमाल करते हुए एक छोटा follow-up release submit किया गया, और यह update 1 घंटे के अंदर review पास कर गया
  • 7 सितंबर को 99.9999% users तक पहुंच चुके version को replace करने के लिए एक और छोटा update submit किया गया
    • New version review में जाते ही Google ने बिना warning पिछले rollout को automatically stop कर दिया
    • अगर नया review कई दिन चलता, तो बचे हुए users को पिछला release भी उपलब्ध नहीं होता
    • New submission withdraw करने पर भी पिछला rollout restore नहीं हुआ
    • सौभाग्य से यह review 1 घंटे में खत्म हो गया

Platform control production responsibility को बदल देता है

  • Mobile developers ने ऐसे कई similar cases देखे हैं, जहां Google या Apple emergency production fixes delay करते हैं, app remove करते हैं, या decisions की बहुत कम explanation देते हैं
  • Technical team defect को जल्दी diagnose और fix कर दे, तब भी users तक solution कब पहुंचेगा, यह app store operator control करता है
  • सामान्य users के पास rollback, alternative distribution route, या review accelerate कराने का reliable तरीका नहीं हो सकता
  • Source code और infrastructure own करने पर भी final delivery channel control न हो, तो production ownership का nature बदल जाता है
  • जिन cases में native mobile app जरूरी नहीं है, वहां open web platform को prefer करने की वजह मजबूत होती है
    • Web applications अक्सर required features देते हुए deployment, monitoring और rollback team को खुद करने देते हैं
  • Native apps के भी valid use cases हैं
    • Device features पर dependency
    • Background behavior
    • App store distribution की जरूरत
  • Mobile चुनना product benefits के साथ-साथ release process में एक powerful third party के आने की operational cost स्वीकार करने का decision है

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

1 टिप्पणियां

 
GN⁺ 2023-08-28
Hacker News की रायें

  • मुझे यह ईमेल निजी तौर पर भी मिला और काम के सिलसिले में भी
    निजी तौर पर, मैं 16 शहरों के public transport systems के लिए अपनी इच्छा से एक open source app बनाता और चलाता हूँ, और ऐसे काम की वजह से जिससे किसी को कोई फायदा नहीं था, मुझे 2 हफ्तों के भीतर 16 apps अपडेट करने पड़े
    मेरा app एक PWA है, और Android version Cordova और कुछ plugins के साथ थोड़ा-सा native options जोड़ने जैसा है. नए target Android API को support करने के लिए Cordova upgrade किया तो जो plugins अभी अपडेट नहीं हुए थे वे टूट गए, इसलिए पूरा weekend काम और testing में लगाना पड़ा
    सच कहूँ तो मैं app हटाकर users से website पर जाकर PWA install करवाना चाहता हूँ, लेकिन औसत user को अभी भी यह तरीका नहीं पता. Users app खोजने के लिए अब भी सबसे पहले Play Store पर ही जाते हैं. अगर Google बस PWA को app store में सीधे submit करने दे, तो भी अच्छा होगा; मैं इसे हर साल दोहराना नहीं चाहता
    काम के लिहाज़ से भी हम हड़बड़ी में निपट रहे हैं. साल के अंत तक कुछ support customers द्वारा इस्तेमाल किया जाने वाला एक legacy app है, और वह काफी complex app है, इसलिए सिर्फ target API version बदलने से ही basic testing में कई हिस्से टूट गए. Extension मिल गया है, लेकिन मुझे पता है कि Google को शांत करने के अलावा किसी भी feature change के बिना वाले update में developer के 1–2 हफ्ते और QA के 1–2 हफ्ते लगेंगे. जबकि सभी customers नए app पर migrate हो जाने के बाद साल के अंत में इसी app को store से आधिकारिक रूप से हटाया जाना है

    • ऐसे समय के लिए ही Trusted Web Activities(TWA) है. Cordova जैसे framework के बिना भी PWA को Play Store पर डाला जा सकता है
      https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
      https://developers.google.com/codelabs/pwa-in-play#0
    • साफ कहें तो बात सिर्फ यह नहीं है कि users को तरीका नहीं पता. वजह यह है कि Google और Apple ने इसे अपने app stores से app install करने जितना आसान नहीं बनाया. यह एक चुनाव है, और जानबूझकर किया गया चुनाव है
    • लगता है आपने users को गलत समझा है. यह सिर्फ अज्ञानता की समस्या नहीं है. मैं चाहता हूँ कि apps फिर से सचमुच native apps, यानी Cordova नहीं, उस दिशा में लौटें. ढीले-ढाले web-based सामान की बजाय, अच्छी तरह बने वास्तविक app के experience की बराबरी करने वाले web apps बहुत कम हैं
    • सहमत हूँ. मेरे कुछ personal apps भी प्रभावित हुए
      हालांकि यह deadline कई महीनों से बताई जा रही थी, और यह तय था कि किसी समय इसे और साफ-साफ दिखाया जाएगा. wording मुझे पसंद नहीं आई, और यह शिकायत करना भी बेतुका था कि production version ठीक है लेकिन test version criteria पूरा नहीं कर रहा
      साथ ही, बात हमेशा नया update push करने की ही थी, और हर साल ऐसा ही होता है. app को कुछ समय तक public state में रखा जा सकता था
      इसलिए यह कहना कि सिर्फ 2 हफ्ते थे सही नहीं है
    • पता नहीं मदद होगी या नहीं, लेकिन मेरी स्थिति होती तो मैं कुछ app updates जारी करते हुए PWA version install करने का तरीका बताने वाली screen डालता, और इन समस्याओं से धीरे-धीरे बाहर निकलता. Users को होने वाली दिक्कतों के लिए feedback form भी दिया जा सकता है

  • Android development की कठिनाइयों से सहमत हूँ, लेकिन लेखक ने दो बड़ी गलतियाँ कीं
    पहली, latest Android version पर app test नहीं किया. यह बहुत बड़ी गलती है, और इसी वजह से हम जिन सभी Android versions को support करते हैं उनके लिए 11 virtual machines maintain करते हैं
    दूसरी, Google Play पर app distribute करते समय शुरुआत से ही 100% users को distribute कभी नहीं करना चाहिए. staged rollout default होना चाहिए, और release publish करने के बाद हम शुरुआत में users के 10% से ऊपर नहीं जाते. भरोसा बढ़ने पर 100% नहीं, 99% पर distribute करते हैं. इससे अगर किसी भी वजह से distribution रोकना पड़े, तो जब तक 100% पर distribute नहीं हुआ है, उसे आसानी से रोका जा सकता है
    पसंद हो या न हो, ये दोनों तरीके अनुभवी Android developers के लिए अच्छी तरह जाने-पहचाने tactics हैं

    • मैं सहमत हूँ कि कई पहलुओं में बेहतर किया जा सकता था. लेकिन जैसा बताया, यह आजकल actively develop होने वाला app नहीं, बल्कि एक legacy application है, इसलिए इतना मजबूत QA system बनाना समझदारी नहीं है. यह app बहुत पहले किसी दूसरी company ने लिखा था और इसमें साधारण unit tests तक नहीं हैं. यही वास्तविकता है
      लेकिन इतना complex system होने पर भी गलतियाँ होती हैं, और असली समस्या यह है कि release को revert, cancel या rollback करने का कोई तरीका नहीं है
      इस स्थिति में staged rollout सभी customers की कैसे मदद करता है? जब end user को टूटा हुआ version मिल जाए, तो क्या उसे working version पाने का कोई तरीका है?
    • एक tip: वह input field decimal भी स्वीकार करता है. हम हमेशा उसे 99.99999999% पर set करते हैं ताकि कोई user गलती से छूट न जाए. और जैसा कहा, फिर भी rollout cancel करना संभव हो जाता है
    • अगर हर Android support version के लिए virtual machine maintain करनी पड़े, तो ठीक है, लेकिन फिर आखिर revenue की 30% commission किस चीज़ के लिए ली जाती है, यह सोचने वाली बात है
    • यह थोड़ा victim blaming जैसा लगता है. उन दो बातों का शुरुआत से ही समस्या होना नहीं चाहिए
    • आपने जो कहा वह पूरी तरह सही है, और updates और releases करने का यही एकमात्र practical तरीका है. लेकिन यह अफसोसजनक है कि API update compile हो जाए तो उससे सीधे काम करने की उम्मीद नहीं की जा सकती

  • मूल लेख लिखने वाले पर इस तरह चढ़ बैठने वाली प्रतिक्रियाएँ समझ में नहीं आतीं। हाँ, वे और सावधान हो सकते थे, और नए Android पर लॉगिन टेस्ट कर सकते थे। लेकिन अगर यह लॉगिन क्रैश न होता तो? अगर यह नए वर्ज़न पर चलता, लेकिन किसी दूसरे वर्ज़न पर नहीं चलता तो? सीमा कहाँ खींची जाए?
    किसी न किसी बिंदु पर कहना पड़ेगा कि “यह सचमुच ऐसा platform है जिसे लाखों apps और लाखों developers इस्तेमाल करते हैं; गलतियाँ हो सकती हैं; और अगर किसी को अपनी deployment रोकना या staged rollout जैसे तरीकों की जानकारी न हो, तब भी पहले से approved पुराने version को तुरंत फिर से publish करके इसे आसानी से ठीक किया जा सकना चाहिए।” खासकर app store जैसी जगहों में rollback और recovery को संभव बनाना बुनियादी design principle है

    • मैं ही मूल लेख का लेखक हूँ, और मेरे साथ सोचने के लिए धन्यवाद। जैसा कि कई replies में पहले ही कहा है, testing के मामले में मैं बेहतर कर सकता था—इससे मैं पूरी तरह सहमत हूँ। बेशक, उस हिस्से में हमेशा सुधार की गुंजाइश रहती है
      deadline Google ने तय की थी, और फिर कहूँ तो मुझे इसके बारे में पहली बार 18 अगस्त को पता चला; उससे पहले नहीं। उस समय change मामूली लगा था, और app पुराने Android versions पर पहले की तरह चल रहा था, इसलिए मैंने अंदाज़ा नहीं लगाया था कि यह इतने बुरी तरह fail होगा
      मैं अनुभवी Android developer नहीं हूँ, लेकिन software development में कुल मिलाकर 15 साल से ज़्यादा का अनुभव है, इसलिए किसी चीज़ के कैसे काम करने, क्या उम्मीद करने और किससे डरने की एक अपनी समझ है। मुझे सच में नहीं पता था कि latest release को आंशिक रूप से भी “वापस लेने” की संभावना बनाए रखने के लिए 99.99999999% staged rollout best practice है
      मैंने सपने में भी नहीं सोचा था कि latest release को cancel या delete करके पिछले ठीक version पर लौटने का कोई तरीका नहीं होगा। लगता है ऐसी स्थिति से गुजरने पर ही यह सीख मिलती है
      सभी Android versions पर हर feature test न करने के लिए आप मुझे दोष दे सकते हैं, और मैं भी ऐसा ही सोचता हूँ, लेकिन कृपया आँखें खोलकर समझें कि Play Store अभी releases को जिस तरह handle करता है, वह Play Store के बाहर कोई सामान्य समझ वाला व्यक्ति जिस तरह करेगा वैसा नहीं है। कोई भी कभी न कभी ऐसी समस्या में फँस सकता है, और उम्मीद है कि यह लेख और यह thread ऐसी स्थिति से गुजरने वाले developers की संख्या कम करेंगे
    • “अगर यह नए version में तो चला लेकिन दूसरे version में नहीं चला?” यह कमजोर बहाना है। web app हो तब भी कई browsers में test करना पड़ता है
      नए release के लिए smoke test करना basic professional ethics है
      rollback के साथ staged rollout भी कोई नई concept नहीं है
    • Android 13, यानी targetSdkVersion 33 पर app port करने के काम में Android 13 testing न करना माफ़ी के लायक नहीं है

  • “open web standards पर लौटकर control वापस लें” वाली बात शायद तब बदल जाए जब यह पता चले कि web को भी वही कंपनी, Google, लगभग आधा control करती है जो अभी समस्या पैदा कर रही है। iOS पर व्यवहार में लगभग इकलौते browser Safari वाली Apple भी कोई खास दोस्त नहीं है

    • यह भी सही है, लेकिन कम से कम ऐसी समस्याओं को rollback जैसे तरीकों से handle किया जा सकता है। अभी स्थिति यह है कि खराब build production में जा चुकी है और phones अपने-आप उसी पर update हो रहे हैं, यह जानते हुए भी कुछ नहीं किया जा सकता। यही सबसे खराब है
    • web पर host करने में सिर्फ cost चुकाने से ज़्यादा maintenance भी लग सकती है
      मैं किसी ऐसे app के बजाय website को निश्चित रूप से पसंद करूँगा जिसका मकसद सिर्फ बेहतर tracking हो, लेकिन यह लेख मुझे maintenance को आधा-अधूरा करने के उदाहरण की तरह लगा
    • अगर आप user privacy और security को प्राथमिकता देने की दिशा में साथ आने से इनकार करते हैं, तो Apple निश्चित रूप से दोस्त नहीं है। कारण बताना हो तो यही है

  • यह ऐसी स्थिति है जिसमें जीता नहीं जा सकता
    Microsoft backward compatibility पर बहुत ज़्यादा मेहनत करता है, और यह बात वाकई काबिले-तारीफ है। लेकिन इससे attack surface भी उतना ही बड़ा हो जाता है
    इसी तरह C++ की कई सबसे खराब बातें, जिनके लिए उसे अक्सर नाइंसाफी से कोसा जाता है, backward compatibility को लेकर उसके कड़े रुख से आती हैं। जितना हो सके पुराना code, यहां तक कि पुराना C code भी compile होता रहे और उम्मीद के मुताबिक काम करे; यहां तक कि जिन पुराने binaries का source code खो चुका है, उनसे link करने तक की कीमत चुकाई जाती है
    ज़्यादातर लोग इतनी मेहनत नहीं करते और maintainability, reliability, security के कारण पुरानी चीज़ों को अमान्य कर देते हैं
    आप कोई भी branch point चुनें, किसी न किसी को नुकसान होगा। अगर नहीं, तो इसका मतलब है कि कोई भी वह code इस्तेमाल नहीं कर रहा

    • सही। यही समस्या का एक पहलू है, और मैं भी अत्यधिक backward compatibility की मांग नहीं कर रहा। इस खास स्थिति में सबसे बड़ी चिंता यह है कि Android में release को वापस लेने, cancel करने या rollback करने का कोई तरीका नहीं है, और सब कुछ Google की review प्रक्रिया के पीछे अटका है
      किसी problematic release को “withdraw” करके पिछली release को latest version के रूप में दिखाते रहना असंभव क्यों है? इस समस्या के संदर्भ में इससे ज़्यादातर बात हल हो जाएगी
    • मेरे हिसाब से सबके लिए मददगार बीच का रास्ता API बदलना और compilation तोड़ना है। developer compile errors ठीक करे और API को सही तरीके से इस्तेमाल करे
      लेकिन वही signature रखने वाले मौजूदा function का behavior नहीं बदलना चाहिए। अगर आप API provider हैं, तो आपको compilation को अर्थपूर्ण बनाने की पूरी कोशिश करनी चाहिए
    • कोई perfect जीत वाला विकल्प नहीं है, लेकिन app को अलग से distribute भी किया जा सकता है। यह Android requirement नहीं, बल्कि Play Store requirement है
      कई मामलों में यह बिल्कुल आसान नहीं होगा और Play Store version जितना इस्तेमाल भी नहीं होगा, लेकिन exit route होना अच्छी बात है
    • लेखक की मुख्य शिकायत यह लगी कि Google यह judge बन बैठा है कि user कौन-सा software चला सकता है। API deprecation का मुद्दा बस वह वजह बना जिसने हमें एहसास कराया कि हम Google की मनमर्जी के प्रति कितने vulnerable हो गए हैं
    • इसे Google का बहाना मानना मुश्किल है
      Android पर distribute होने वाली ज़्यादातर applications Android bytecode को target करती हैं। वे native compiled applications नहीं हैं
      C++ security समस्याएं इसलिए पैदा करता है जिन्हें पार करना मुश्किल है, क्योंकि उसकी low-level प्रकृति है और native binary बन जाने के बाद बात वहीं खत्म हो जाती है
      लेकिन memory-safe language के bytecode के लिए security fixes backport न कर पाने की क्या वजह है? ऐसा code चलाने का मतलब ही है कि bytecode लगातार recompile होता रहता है
      Google का यह रुख कितना बेतुका है, यह देखने के लिए: JVM आज भी 1996 में आए Java 1.0 target classes को चला और इस्तेमाल कर सकता है
      यह security समस्या नहीं, बल्कि “Google platform को support नहीं करना चाहता” वाली समस्या है
      जिन artifacts में native compiled code हो, उन पर Google का कुछ ज़्यादा सख्त होना एक हद तक समझ आता है। लेकिन “app पुराने Android version को target करके build हुई है, इसलिए अब support नहीं करेंगे” जैसी blanket policy बेतुकी है। यह security से ज़्यादा पुराने apps को store से prune करने का तरीका लगती है
      खासकर ऐसी policy मूल रूप से Android developers पर बड़ा maintenance burden डालती है। application को सबसे व्यापक रूप से support करना हो तो जितना हो सके उतने पुराने Android version को target करना पड़ता है। latest Android version को target करने पर बहुत सारे customers छूट जाएंगे, इस डर से ऐसा बहुत कम लोग करते हैं
      अगर Google security और latest Android technology की व्यापक accessibility को गंभीरता से लेता, तो वह Android runtime को operating system version से अलग करने की कोशिश करता। ART और Dalvik runtime को Android ecosystem के बाकी हिस्सों की तरह Google Play के जरिए distribute न कर पाने की कोई वजह नहीं है। “इसके लिए Android 17 चाहिए… ओह, hardware manufacturer driver update नहीं कर रहा” जैसी मूर्खतापूर्ण स्थिति भी खत्म हो सकती है
      लेकिन तब नए devices की बिक्री पर असर पड़ेगा, इसलिए शायद यह स्वीकार्य नहीं होगा

  • यह हमेशा साफ था कि Play Store और उसके अंदर फंसी developer “community” एक trap है। forced API upgrades उसका सिर्फ एक पहलू हैं
    कुछ काम ऐसे ज़रूर हैं जो phone या mobile app सबसे अच्छे से करते हैं। आमतौर पर navigation जैसे movement से जुड़े काम, या phone sensors पर निर्भर काम जैसे यह पता लगाना कि कौन-सी दिशा “ऊपर” है। लेकिन लगभग बाकी सब website से किया जा सकता है
    अगर कोई developer अकेले cross-platform mobile app maintain कर रहा है, तो सच में बहुत मुश्किल होगा और मुझे सहानुभूति है। हालांकि मैंने बहुत पहले ही तय कर लिया था कि मैं proprietary platforms और gatekeepers के खेल में शामिल नहीं होना चाहता, इसलिए मेरी सहानुभूति पूरी तरह outsider के नजरिए से ही है

    • दरअसल वे दोनों चीज़ें भी browser app में आसानी से की जा सकती हैं
      अभी mobile पर आसानी से न हो पाने वाली लगभग इकलौती चीज़ GPU compute shaders जैसी है। लेकिन WebGPU जब desktop browsers से mobile पर आएगा, तो वह भी टूट जाएगा
      एक और चीज़ जो ध्यान में आती है, वह है general system-wide file management। वह शायद कभी नहीं आएगी। File System API user को किसी खास directory की access permission देने देती है, लेकिन मुझे नहीं पता कि वह permission page refresh के बाद भी बनी रहती है या नहीं
    • मुझे पूरा यकीन था कि app stores fail होंगे। क्योंकि मुझे नहीं लगा था कि developers इतने इकट्ठा होंगे कि अपनी app सच में distribute कर पाने की guarantee छोड़ दें
    • इसे उस site पर पढ़ना मजेदार है जो अक्सर Google पर हमला करती है कि वह Android पर software gatekeeping पर्याप्त नहीं करता, और अधिक aggressive enforcement के कारण iPhone को बेहतर बताती है
    • आप शायद user की अपनी device पर sovereignty को ideological तौर पर पकड़े रहना नहीं चाहेंगे, है न? इसके बजाय smart और practical बनिए, और सबसे कम resistance वाले रास्ते से चलते हुए बाड़े के अंदर चले जाइए

  • Google के SRE सिद्धांतों में से एक “rollback सामान्य है” है, यह सोचें तो विडंबना लगती है
    https://cloud.google.com/blog/products/gcp/reliable-releases...
    “Google में हमारा दर्शन यह है कि ‘rollback सामान्य है’। अगर किसी नए release में गलती मिलती है या उस पर वाजिब शक होता है, तो release team पहले rollback करती है और उसके बाद समस्या की जांच करती है। rollback request को release team या buggy code लिखने वाले व्यक्ति पर हमले के रूप में नहीं देखा जाता। इसके बजाय, इसे users के लिए system को जितना संभव हो उतना reliable बनाने का सही काम माना जाता है। जब तक rollback change list में देखी गई समस्या का वर्णन है, कोई नहीं पूछता कि ‘इस change को rollback क्यों किया?’”

    • पिछले साल तक, Google Play policies और Android updates के मिले-जुले नतीजे के रूप में, अगर आप Play Store के जरिए app distribute करते हैं, तो rollback करने का एकमात्र तरीका delete करके user data reset करना है
      कम versionCode पर downgrade नहीं किया जा सकता, और versionCode developer define करता है
      Android 11, media exceptions या local folders को cloud storage जैसा मानने वाली DocumentFile API के इस्तेमाल को छोड़कर, phone के “permanent” storage में लिखने पर रोक लगाता है। DocumentFile कई use cases में इस्तेमाल करने लायक नहीं है
      developer hasFragileUserData set कर सकता है, और तब delete करते समय user से पूछा जाना चाहिए कि data मिटाना है या नहीं। लेकिन Google/Android bug की वजह से यह dialog दिखाई नहीं दे सकता
      अगर app delete कर दिया गया और user data नहीं मिटाता, तो Android कम versionCode पर downgrade को रोकता है
      MANAGE_EXTERNAL_STRORAGE request करने पर सामान्य java.io.File का इस्तेमाल किया जा सकता है
      Google Play सिर्फ exceptional cases में ही MANAGE_EXTERNAL_STRORAGE की अनुमति देता है
    • “मेरे लिए rollback, तुम्हारे लिए rollback नहीं”

  • मेरे बनाए framework-based कई apps में भी यही हुआ। नए API version का मौजूदा dependencies से conflict हो गया, और जो state पहले से थी उसी पर वापस जाने के लिए सचमुच बहुत भारी काम करना पड़ा
    4 साल पहले Android पर लिखे mobile app की तुलना में, 90s की चीजें latest Windows पर ज्यादा बिना समस्या चलाने वाले Microsoft के लिए मेरा सम्मान कहीं ज्यादा बढ़ गया

    • अगर इस्तेमाल किया गया framework Google का नहीं था, तो यह कहना unfair है
      Windows 11 Store में Adobe Flash नहीं चलता, इसके लिए आप Microsoft को दोष नहीं देते न?

  • ऐप्स को सिर्फ़ एक “self-approved” app store के ज़रिए ही distribute करने के लिए मजबूर करने में नुकसान बहुत ज़्यादा हैं और फायदे लगभग नहीं के बराबर लगते हैं
    फायदा कहें तो विडंबना यह है कि app store का admin publishing से पहले malware और virus चेक कर देता है। लेकिन Google ads और Google/Facebook trackers से भरे ऐप्स का हर तरह से स्वागत होता है
    एक और बात यह है कि इससे users के लिए apps खोजना, install करना और update करना आसान हो जाता है। बशर्ते वे अरबों game apps और ads भेजने या personal data collect करने के लिए ही publish किए गए बेहद मिलते-जुलते apps के बीच अपनी ज़रूरत की चीज़ ढूंढ पाएं
    नुकसान यह है कि आप app store admin की मनमर्जी से बंध जाते हैं, और app publishing process पर control नहीं रहता। मैं यह तय नहीं कर सकता कि app publish कर सकता हूं या कब कर सकता हूं; App Store admin अपनी सुविधा के हिसाब से तय करता है। मुझे लगता है यह अधिकार सिर्फ़ user के पास होना चाहिए
    commercial native apps, जैसे home banking app, मैं developer website के private area में login करके download करना चाहूंगा। app GPG-signed होना चाहिए और package integrity verify की जा सकनी चाहिए। auto-update feature भी संभव है
    open source apps के लिए F-Droid store है, और आप अपनी repositories add कर सकते हैं। मानता हूं कि यह थोड़ा technical है और सबके लिए ठीक नहीं होगा। अगर नए phone में F-Droid पहले से installed मिले तो बहुत मदद होगी, लेकिन नहीं लगता कि Google इसकी इजाज़त देगा
    एक और practical विकल्प PWA है। मेरी राय में native features की ज़रूरत बहुत कम apps को होती है, और बाकी लगभग सब कुछ PWA technology से संभव है। users को updates भेजने या upgrade के लिए कहने की भी ज़रूरत नहीं
    users की जिंदगी आसान बनाने और “better security” देने के बहाने चलाए जाने वाले proprietary, commercial app stores Apple और Google के लिए independent developers की मेहनत से अरबों डॉलर कमाने का “शानदार” तरीका हैं; और Google के मामले में, users की personal information collect/sell करने और हर तरह से ads बेचने का भी

    • एक और फायदा छूट गया था। Boston Strangler[0] को घर के बाहर रखा जा सकता है। अगर user के हाथ पीछे बांध दिए जाएं, तो आप तय कर सकते हैं कि user आपके काम को किन शर्तों पर इस्तेमाल करेगा। कोई piracy नहीं, कोई ad blocking नहीं
      80–90 के दशक में game developers ने आम तौर पर “Licensed by Nintendo” model अपनाया, और 2000s के आखिर में mobile app developers ने iOS App Store के साथ वही किया—कारण यही था। वे platform owner को bypass करके users के साथ सीधे सहयोग करना नहीं चाहते। वे चाहते हैं कि platform owner users के हाथ बांधे, और इस प्रक्रिया में अपने हाथ बंधने को भी स्वीकार करते हैं
      उदाहरण के लिए banking app को देखें: bank safe remote attestation चाहता है। वह app पर credential stuffing attack करने वाले users को block करना चाहता है, malware को banking app खोलकर “fraudster को पैसे भेजें” button दबाने से रोकना चाहता है, users को tap-to-pay से जुड़े cryptographic secrets extract करने से रोकना चाहता है, और stolen secrets को phone app में inject करने से भी रोकना चाहता है
      app खुद verify नहीं कर सकता कि user के हाथ बंधे हैं या नहीं। boot chain या EL3 में मौजूद, user के बजाय bank के लिए trustworthy third party चाहिए। इसलिए बात सिर्फ़ app और signature देने की नहीं है; वे चाहते हैं कि Google users के हाथ बांध सके, और Google यह उनके लिए करे
      महत्वपूर्ण बात यह है कि app stores के user-side benefits सब बाद की rationalization हैं। शुरुआत से ही लक्ष्य users को बांधकर रखना था। क्योंकि उनके लिए users छोटे चोर मच्छरों जैसे हैं। यही वह “quiet part” है जिसे वे ज़ोर से नहीं कहते
      कृपया Google का WEI proposal reality न बने और PWA को attestation capability तक access न मिले। Google पहले से ही “unknown browsers में login नहीं करने देंगे” जैसी बकवास कर रहा है, और इस cancer को फैलने की ज़रूरत नहीं
      F-Droid बेहतरीन है। Android पर Google की चालबाज़ियों को रोका जाना चाहिए। EU यह कर सकता था, लेकिन अमेरिका को भी ऐसा करना चाहिए और इसे international level पर लागू कराना चाहिए
      [0] MPAA द्वारा non-commercial small-scale copying, यानी VCR से TV programs record करने, के लिए इस्तेमाल किया जाने वाला code name था। Jack Valenti सच में बहुत खराब इंसान था, है न?

  • जिस पल आप mobile app develop करने का फैसला लेते हैं, आप अपने product या service का control किसी third party को सौंप देते हैं—इसी वजह से मैं भी कई सालों से mobile app development के खिलाफ रहा हूं
    सहमत होना मुश्किल नहीं है
    अगर “support” का मतलब HN या Twitter पर मददगार attention मिलने की उम्मीद भर है, तो हम गलत रास्ते पर जा रहे हैं