Android और RISC-V: तैयारी के लिए जानने योग्य बातें

 (opensource.googleblog.com)
2 पॉइंट द्वारा GN⁺ 2023-11-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google ने Android को एक नए CPU architecture तक विस्तार देने के लिए AOSP में RISC-V support जोड़ा है, और इसे प्रयोग करने योग्य चरण से ecosystem collaboration की ओर बढ़ा रहा है
  • शुरुआती support rva22 profile और vector·vector crypto extensions को आधार मानता है, ताकि Android द्वारा अपेक्षित performance implementation के लिए जरूरी feature set मिल सके
  • अभी भी Cuttlefish के साथ RISC-V के लिए Android को build·test·run किया जा सकता है, लेकिन ART backend और compiler optimization अभी पूरी तरह तैयार नहीं हैं
  • 2023 के अंत में NDK ABI finalization और public CI canary builds की उम्मीद है, और 2024 में कई form factors की testing के लिए public emulator की योजना है
  • सिर्फ Android porting काफी नहीं है, इसलिए Google RISE Project, RISC-V International, toolchain·support library communities के साथ मिलकर app development environment तक तैयार कर रहा है

Android में आ रहा RISC-V support

  • Android कई device types और CPU architectures को support करने वाला open source operating system है, और नए platform target के रूप में RISC-V को जोड़ रहा है
  • RISC-V एक free और open instruction set architecture (ISA) है, जिसका approach open source software में industry-wide collaboration के तरीके को hardware ecosystem में लाने का है
  • 10 साल पहले UC Berkeley में बनाए जाने के बाद इसे embedded और microcontroller क्षेत्रों में तेजी से अपनाया गया, और हाल में यह accelerators, servers और mobile computing तक फैल गया है

Patch acceptance से support maturity चरण तक

  • Google ने नवंबर 2022 में RISC-V Summit में घोषणा की थी कि वह Android के लिए RISC-V patches स्वीकार करना शुरू करेगा
  • अब यह सिर्फ patches स्वीकार करने से आगे बढ़कर Android में RISC-V support को mature करने के चरण में पहुंच गया है
  • RISC-V एक modular ISA है, इसलिए इसमें कई optional extensions हैं; Android में अपेक्षित high performance देने के लिए शुरुआती mandatory feature set तय करना जरूरी है
    • baseline में rva22 profile शामिल है
    • vector और vector crypto extensions भी शामिल हैं

Local पर build·run किया जा सकने वाला AOSP environment

  • RISC-V के लिए Android support को अन्य AOSP platform targets की तरह Cuttlefish Virtual Device के जरिए local machine पर build·test·run किया जा सकता है
  • संबंधित code google/android-riscv64 पर देखा जा सकता है
  • चलाने का उदाहरण इस प्रकार है
$ lunch aosp_cf_riscv64_phone-userdebug
$ m -j
$ launch_cvd -cpus=8 -memory_mb=8192
  • चल रहे device से vncviewer के जरिए connect करके interaction किया जा सकता है

Optimization से जुड़े बचे हुए काम

  • मौजूदा patches basic Android Open Source Project experience को build और run करने देते हैं, लेकिन यह पूरी तरह optimized स्थिति में नहीं है
  • Android Runtime के ART optimization backend पर काम अभी जारी है
  • AOSP, external projects और compiler भी अभी ऐसे स्तर तक नहीं पहुंचे हैं कि वे latest ratified extensions का उपयोग करते हुए पूरी तरह optimized और compact code generate कर सकें
    • उदाहरण के तौर पर vector extension का उल्लेख है
  • मौजूदा चरण का उद्देश्य finished product environment से ज्यादा experimentation और collaboration को संभव बनाना है

Developer testing और emulator roadmap

  • 2023 के अंत तक NDK ABI final होने की उम्मीद है
  • Android public CI पर canary builds भी जल्द उपलब्ध कराए जाने की योजना है
  • host machine पर riscv64 Android applications को अधिक आसानी से test करने के लिए x86-64 और ARM64 पर RISC-V execution support करने की योजना है
  • 2024 में विभिन्न device form factors के applications test करने के लिए full feature set वाला public emulator planned है
  • Qualcomm के साथ collaboration announcement के अनुसार पहला form factor wearable होने की उम्मीद है

Ecosystem collaboration और RISE Project

  • सिर्फ Android operating system को port करना पर्याप्त नहीं है; आसपास के software ecosystem की तैयारी भी साथ में जरूरी है
  • Google community और RISE के साथ collaboration कर रहा है
  • RISE Project high-level operating systems चलाने वाले high-performance और power-efficient RISC-V processor cores पर software availability को तेज करने के लिए बनाया गया है
  • इसका scope Android ही नहीं, Linux और अन्य operating systems को भी शामिल करता है
  • target application domains में high-performance computing भी शामिल है
  • participants हैं Andes, Google, Intel, Imagination Technologies, MediaTek, Nvidia, Qualcomm Technologies, Red Hat, Rivos, Samsung, SiFive, T-Head, Ventana

Standardization और contribution paths

  • Google RISC-V International में existing Premium membership और board participation से आगे भी investment बढ़ा रहा है
  • कई contributors horizontal committees, working groups और technical committees में key roles निभाते हुए specifications design और ratification में भाग लेते हैं
  • Android का RISC-V support LLVM toolchain से लेकर basic support libraries तक, व्यापक contributions पर निर्भर करता है
  • contribution और testing के लिए मुख्य resources इस प्रकार हैं
    • google/android-riscv64: Android में RISC-V support को build·test करने के तरीके, known issues, और AOSP व toolchain·support libraries में contribution opportunities प्रदान करता है
    • RISC-V Android SIG: progress देखने और suggestions·feedback देने के लिए mailing list
  • Google ऐसे तरीके खोज रहा है जिनसे native code लिखने वाले Android developers भी नए platform को आसानी से target कर सकें, जैसे Java और Kotlin developers नए platform को target करते हैं

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

1 टिप्पणियां

 
GN⁺ 2023-11-02
Hacker News की राय

  • क्या डेवलपर्स से तैयारी करने की उम्मीद की जा रही है? तरीका गलत है। Apple ने M1 transition के समय जैसा किया था, वैसा होना चाहिए: डिफॉल्ट रूप से काम लगभग 0 हो, और उसके बाद वैकल्पिक optimization संभव हो
    याद करें जब Google ने Android apps को x86 पर test करने को कहा था, फिर दोबारा MIPS पर भी test करने को कहा था। आखिर में कुछ भी नहीं हुआ, और डेवलपर्स अपना समय बर्बाद नहीं करेंगे

    • काम 0? लगता है यादें कभी-कभी जल्दी धुंधली हो जाती हैं
      Apple ने डेवलपर्स को ARM hardware आज़माने और apps port करने के लिए DTK systems 500 डॉलर में किराये पर दिए थे। काम 0 से बहुत दूर था, hardware भी वापस करना पड़ता था, और शुरुआत में mass-production product खरीदने के लिए 500 डॉलर credit तक नहीं था। अनुमानित विरोध के बाद ही इसे ठीक किया गया
      इसके बजाय Google software emulator देता है, इसलिए इसे संभालना कहीं आसान है और जटिल device logistics की ज़रूरत भी नहीं। असल में तैयारी का काम उन लोगों को करना है जो NDK apps बनाते हैं या RISC-V hardware support करते हैं
      Java/Kotlin apps को porting की ज़रूरत नहीं है, इसलिए मेरे हिसाब से यह काम 0 के करीब है
    • Android apps और libraries के x86 builds emulator में सबसे आम target हैं, इसलिए वे बहुत आम हैं
      MIPS को Google ने बहुत ज़ोर से push किया था, ऐसा नहीं लगता; वह बस मौजूद था
      ऊपर से यह लेख app developers की तुलना में device manufacturers को ज़्यादा target करता है और AOSP builds व pending patches पर बात करता है। यह app developers से कुछ करने की मांग करने वाला लेख नहीं है; बल्कि अंत में कहा गया है, “हम देखेंगे कि Java और Kotlin developers के लिए नए platform को target करना जितना आसान है, native Android developers के लिए भी वैसा आसान कैसे बनाया जाए”
    • Android में MIPS 2013 में Imagination Technologies द्वारा acquisition के बाद लगभग खत्म हो गया। नए SoC या नए phone न हों तो Google भी कुछ नहीं कर सकता
      x86 Chromebook की वजह से अब भी व्यापक रूप से इस्तेमाल होता है। अगर आप NDK नहीं इस्तेमाल करते, तो नए target की वजह से developer की तरफ से करने को कुछ नहीं है
    • सामान्य अर्थ में ऐसा नहीं लगता कि डेवलपर्स से तैयारी करने की उम्मीद की जा रही है। शीर्षक भी “तैयारी के लिए आपको क्या जानना चाहिए” है, यानी अगर आप तैयारी करना चाहते हैं तो जानकारी और सलाह दी जा रही है। मानना या न मानना आपकी पसंद है
      यहां “you” शीर्षक की अभिव्यक्ति के अनुसार है, किसी खास व्यक्ति की ओर इशारा नहीं
    • क्योंकि उस architecture पर कोई सार्थक device launch नहीं हुआ

  • क्या C extension, जिसका Qualcomm इतना विरोध करता है, ज़रूरी हो जाएगा?
    संबंधित sub-thread के लिए देखें https://news.ycombinator.com/item?id=37996820
    Qualcomm की ताज़ा सामग्री https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS... है, जहां वे दावा करते हैं कि उनकी प्रस्तावित “RISC-V को aarch64 जैसा थोड़ा बनाना” वाली Zics extension और 32-bit long jumps, RV64GC से बेहतर code density देती हैं, और C extension की वे कमियां भी नहीं हैं जिन पर वे लगातार सवाल उठाते रहे हैं

    • समझ नहीं आ रहा कि इसे downvote क्यों किया जा रहा है। यह सवाल सचमुच अभी चल रहा मुद्दा है
      अगर Qualcomm C extension के बिना RISC-V Snapdragon बनाने का फैसला करता है, तो उस extension का इस्तेमाल करने वाले Android NDK apps कैसे चलेंगे, यह समझना मुश्किल है। किसी trap के बाद emulation जैसे तरीके के बिना यह हास्यास्पद रूप से धीमा होगा
    • Qualcomm की बात में कुछ हद तक दम लगता है, लेकिन ऐसा भी लगता है कि वे ARM technology reuse ज़्यादा करना चाहते हैं
      अगर Google RV64GC या RV64G_Zics को अनिवार्य कर दे, तो यहां फैसला हो सकता है
      हालांकि C instructions को हटाना या बदलना वास्तविक deployment के बाद विकल्प नहीं है, और अभी ज्यादातर emulator testing stage है, इसलिए वे शायद इसकी बहुत चिंता न करें
    • यह ARM के Thumb instruction set से काफी मिलता-जुलता दिखता है
      असली सवाल है, क्यों
      संदर्भ: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...

  • थोड़ा अलग विषय है, लेकिन जब मुझे नए AOSP emulator के बारे में पता चला, तो न जाने क्यों लगा कि AOSP में Goldfish की जगह Cuttlefish emulator इस्तेमाल करने के लिए acloud चलाना होगा। लेकिन acloud ने Ubuntu न होने पर चलने से इनकार कर दिया
    मैंने uname function की output बदलने वाला LD_PRELOAD hack भी आज़माया, लेकिन उसके बाद वह dpkg चलाने की कोशिश करने लगा। मैं NixOS इस्तेमाल करता हूं
    पुराना emulator ठीक से चलाना वाकई झंझट भरा है, और नए emulator के कई फायदे हैं
    लेकिन अजीब तरह से मुझे बिल्कुल पता नहीं था कि सीधे launch_cvd चला देना काफी है

    • अगर याद न रहे तो https://github.com/tadfisher/android-nixpkgs पर feature request डाल दें। कम से कम मैं इसे अपने SDK repository में package करने लायक बनाना चाहता हूं

  • उम्मीद है “Android for RISC-V”, पूरी तरह disaster रहे “Android for x86” से ज्यादा सफल होगा। मेरे पास अब भी Lenovo x86 Android tablet है
    फिर भी यह लेख पढ़कर बहुत भरोसा नहीं बनता। उम्मीदें बड़ी हैं, लेकिन अपेक्षाएं कम

    • ऐसा लगता है कि RISC-V implementations को main processor के रूप में इस्तेमाल करने वाले सस्ते consumer devices से बाजार भरना टाला नहीं जा सकता
      बल्कि ARM support के ठहर जाने की चिंता ज्यादा करनी चाहिए
    • Chromebook अभी ज्यादातर x86 हैं और Android apps चलाते हैं। Android emulator भी ऐसा ही है
      हर कोई ARM MacBook रखने वाला अमीर अमेरिकी नहीं है

  • कुछ साल पहले, phone या tablet नहीं बल्कि graphical touchscreen की जरूरत वाले embedded क्षेत्रों में Android काफी व्यापक रूप से इस्तेमाल होता था, लेकिन अब यह लगभग phone-केंद्रित और कुछ हद तक tablet-केंद्रित हो गया है
    वजह यह है कि phone/tablet manufacturers के उलट छोटी कंपनियां Android के बेहद जटिल नए बदलावों के साथ तालमेल नहीं रख सकीं और धीरे-धीरे हटती गईं

    • जानना चाहूंगा कि वे इसके बजाय क्या इस्तेमाल कर रहे हैं
    • लगता है DJI अभी भी controllers में Android इस्तेमाल करता है

  • स्थिति पूरी तरह समझ नहीं आ रही, क्या RISC-V लागू करने वाले प्रमुख फोन मौजूद हैं? और क्या इसके लिए पूरे stack में बदलाव चाहिए? यह सिर्फ operating system बदलने जैसा तो नहीं लगता

    • अभी नहीं, लेकिन लॉन्च करीब आ रहा है
      “stack” और “operating system” की सीमा आप कहाँ मानते हैं, यह मुझे साफ नहीं है। थोड़ा और विस्तार से बता सकते हैं?
    • नहीं। हालांकि Qualcomm RISC-V smartwatch processor तैयार कर रहा है। यह कोई मामूली बात नहीं है
      LiCheePi 4A के लिए AOSP port अभी आज़माया नहीं है। शायद बस यह देखने के लिए एक बार चलाकर देखना होगा कि काम करता है या नहीं
      PolyMC चलाने के लिए जरूरी पूरा toolchain bootstrap करने की तुलना में, Play Store से Minecraft डाउनलोड करके देखना आसान है

  • RISC-V पर install करने वाली चीज़ों में Google Android सबसे आखिरी विकल्प है

    • अगर RISC-V mobile CPU में आम तौर पर इस्तेमाल होने लगे, तो सोचता हूँ कि क्या इसका ecosystem पर सकारात्मक असर पड़ेगा, या बड़ी कंपनियाँ RISC-V को ज्यादा enterprise use cases की तरफ धकेलकर hobby developers के लिए इसे कम friendly बना देंगी
    • फिर भी हो सकता है कि हम Android pre-installed RISC-V device खरीदें और फिर उसे मिटा दें

  • अगर बचा जा सके तो Android चलाना मूर्खतापूर्ण विकल्प है, और architecture बदलते हुए vanilla Linux पर जाने का मौका हो तो तो और भी ज्यादा
    समस्या banking है। कम से कम Sweden में अभी भी mobile BankID पर निर्भरता है। उदाहरण के लिए, 20 dollar से ज्यादा की online खरीदारी के लिए भी इसकी जरूरत पड़ती है, और यह सिर्फ iOS और Android पर चलता है

    • क्या फोन पर non-Android operating system चलाते हुए भी power efficiency, multi-touch और GPU acceleration के साथ Android app support हासिल करने का कोई व्यावहारिक तरीका है?
      जैसे Android को KVM में efficiently चलाने वाला कोई ready-made solution, या Android kernel features और user-space RPC server देने वाला तरीका वगैरह
      अगर ऐसा नहीं है, तो mobile apps तक access के लिए Android चलाना ही पड़ेगा, और यह लगभग जरूरी है
    • Denmark में banks और government sites के लिए MitID है। खरीदारी authentication के लिए भी कभी-कभी इस्तेमाल होता है
      अगर आपके पास smartphone नहीं है या आप इस्तेमाल नहीं करना चाहते, तो authentication के लिए इस्तेमाल होने वाला छोटा device मिल सकता है। Sweden का bank account रखने वाले हर व्यक्ति पर smartphone रखना भी अनिवार्य करना अजीब लगता है। खासकर जब बहुत से बुज़ुर्गों के पास smartphone नहीं होगा