نگاهی عمیق به اندروید Q با مهندسان توسعه‌ اندروید

زوميت/ اندرويد Q خبر مهم گوگل و اکوسيستم اندرويد در سال ۲۰۱۹ محسوب مي‌شود و مهندسان داخلي سيستم‌عامل، بهترين توضيح و بررسي را پيرامون آن ارائه مي‌کنند. اندرويد Q مرکز توجه اخبار گوگل در کنفرانس Google I/O بود و مانند هميشه توجه کاربران و کارشناسان را به عضو بعدي خانواده‌ي اندرويد جلب کرد. آرس‌تکنيکا به رسم رويدادهاي قبلي گوگل مصاحبه‌اي با مهندسان داخلي اندرويد داشت تا اطلاعاتي دقيق‌تر از نسخه‌ي بعدي اين سيستم‌عامل کسب کند. مصاحبه علاوه بر پرداختن به اندرويد Q، پروژه‌ي مهندسي بزرگ‌‌تر گوگل موسوم به Project Mainline را هم پوشش مي‌دهد. هدف اصلي مين‌لاين، ايجاد امکان به‌رورزساني بخش‌هاي اصلي سيستم‌عامل بدون به‌روزرساني کلي براي گوگل و حتي توليدکننده‌هاي ديگر گوشي هوشمند است. با نگاهي اوليه به توضيح پروژه‌ي مذکور، متوجه اهميت فني و خبري آن مي‌شويم. ديو برک (Dave Burke) به‌عنوان معاون ارشد بخش مهندسي اندرويد شناخته مي‌شود. از نگاه رسانه‌ها او دانشنامه‌اي کامل از اندرويد است که هميشه پاسخ‌هايي کاربردي به سؤال‌هاي پيرامون سيستم‌عامل موبايلي گوگل دارد. ايليان مالکو (Iliyan Malchev) کارشناس ديگر اين مصاحبه است که به‌عنوان مهندس ارشد در اندرويد، مدير Project Treble و همه‌ي بخش‌هاي مرتبط با هماهنگ‌سازي لينوکس فعاليت مي‌کند. در مصاحبه‌ي امسال آرس‌تکنيکا پيرامون سيستم‌عامل اندرويد، انوار گولوم (Anwar Ghuloum) هم حضور داشت که مدير ارشد مهندسي اندرويد و همچنين مدير پروژه‌ي مين‌لاين است. مين‌لاين در کنفرانس امسال به‌عنوان «پروژه‌ي بزرگ بعدي در به‌روزرساني اندرويد» مطرح شد و به‌نوعي مهم‌ترين خبر رويداد بود. در ادامه‌ي اين مقاله‌ به مصاحبه‌ي آرس‌تکنيکا با مهندسان و مديران ارشد گوگل پيرامون سيستم‌عامل جديد و پروژه‌ي مين‌لاين مي‌پردازيم. پيش از ورود به مصاحبه،‌ ابتدا تاريخچه‌اي از Mainline را بررسي مي‌کنيم. پروژه‌ي Mainline، تغيير مسيري اساسي در توسعه‌ي اندرويد گوگل از سال‌ها پيش قصد داشت تا اندرويد را به سيستم‌عاملي تبديل کند که قابليت به‌روزرساني بخش‌به‌بخش داشته باشد. در سال‌هاي ابتدايي عمر اندرويد، اپليکيشن‌هاي اختصاصي گوگل و اپليکيشن‌هاي سيستمي در اپ‌استور اندرويد منتشر مي‌شدند. درنتيجه گوگل مي‌توانست قابليت‌هاي متعدد را هر زمان که تمايل داشت، ارائه دهد. سپس Google Play Services از راه رسيد که بسياري از APIهاي توسعه‌اي را به اپ استور اندرويد فرستاد. از آن زمان، به‌روزرساني‌هاي مرتبط با توسعه‌دهنده‌ها در API توسط گوگل ارائه مي‌شدند. در اندرويد ۸، شاهد معرفي Project Treble بوديم که سيستم‌عامل را از پشتيباني سخت‌افزاري جدا کرد. درنتيجه گوگل يک قدم به توسعه‌ي آسان‌تر به‌روزرساني‌ها نزديک‌تر شد. بزرگ‌ترين راهکار گوگل براي ماژولار کردن اندرويد در اندرويد Q و به‌نام مين‌لاين مطرح شد. در پروژه‌ي جديد رويکردي مشابه روزهاي ابتدايي اندرويد پيش گرفته مي‌شود و اين بار، قطعات هسته‌اي سيستم‌عامل به پلي‌استور مي‌روند. درواقع مين‌لاين از لايه‌هاي سطحي اپليکيشن عميق‌تر مي‌رود و قطعاتي مرتبط‌تر با کارايي سيستم همچون فريمورک‌هاي رسانه‌اي و ART به‌صورت جداگانه به‌روزرساني مي‌شوند. پروژه‌ي مين‌لاين در ادامه‌ي ماژولارسازي سيستم‌عامل اندرويد معرفي شد پلي استور هميشه اپليکيشن‌ها را به‌صورت پکيج‌هاي APK ارائه داده است. دراين‌ميان براي بسياري از قطعاتي که در پروژه‌ي مين‌لاين ماژولار مي‌شوند، چنين رويکردي ممکن نخواهد بود و نمي‌توان آن‌ها را به‌صورت APK منتشر کرد. سيستم APK براي کاربردهاي مبتني بر سيستم يا سمت کاربر طراحي شد و محدوديت‌هايي در بخش‌هاي مرتبط با مجوزهاي کاربري يا اجرا در مرحله‌ي بوت سيستم دارد. گوگل براي ماژولار کردن قطعات سيستمي اندرويد، به راهکاري کاربردي‌تر از APK به‌نام APEX رسيد. فايل‌هاي APEX قابليت کسب دسترسي‌هاي روت را دارند و در همان مراحل راه‌اندازي اوليه شروع به کار مي‌کنند. درنتيجه امکان به‌روزرساني‌هاي قطعات بيشتر سيستم را به گوگل يا توليدکننده‌هاي ديگر مي‌دهند. درنهايت نتيجه مي‌گيريم که APK براي سطوح دسترسي کاربر و سيستم طراحي شد و APEX قطعات هسته‌اي‌تر سيستم را پوشش مي‌دهد. در جدول زير نمونه‌‌اي از پکيج‌هاي مربوطه را مشاهده مي‌کنيد. ماژول‌هاي پروژه‌ي مين‌لاين در آينده بخش‌هاي بيشتري از سيستم اندرويد را اشغال خواهند کرد. گوگل اکنون و در نسخه‌هاي ابتدايي اندرويد Q، روي سه بخش متمرکز شده است: پايداري، امنيت و حريم خصوصي. به‌هرحال با نگاهي به جدول بالا متوجه برنامه‌هاي گوگل در اولويت‌بندي ماژول‌سازي از بخش‌هاي متعدد اندرويد مي‌شويم. همين جدول اولين سؤال‌ها را پيرامون برنامه‌ي توسعه‌ي پروژه‌ي مين‌لاين ايجاد مي‌کند. در انتخاب اولويت ماژول‌هاي سيستمي اندرويد در مين‌لاين، چه اصولي را مدنظر قرار مي‌دهيد؟ انوار گولوم: طرح ايده‌آل ما، الزامي بودن بخش‌بندي همه‌ي قطعات است. روش کاري ما در ماژول‌‌بندي بخش‌ها مبتني بر همکاري با توليدکننده‌هاي دستگاه بود. ما به آن‌ها اعلام کرديم که پروژه‌اي در دست توسعه داريم و درخواست همکاري داديم. توليدکننده‌ها برنامه‌‌هاي توسعه‌اي و درخواست‌هاي آتي خود را اعلام کردند و ما بر حسب همان نيازها، اولويت‌بندي ماژول‌ها را انجام داديم. به‌مرور بخش‌هاي ديگري به ماژول‌هاي الزامي اضافه مي‌شوند. چنين رويکردي به ما امکان مي‌دهد تا به‌مرور با توليدکننده‌ها هماهنگ شويم، ما قصد نداريم که روند توسعه در شرکت‌هاي توليدکننده‌ي تجهيزات را با مشکل مواجه کنيم. رويکرد کنوني به نيروهاي اين شرکت‌ها امکان مي‌دهد تا به‌مرور با روند به‌روزرساني ماژولي همراه شوند. ديو برک: من تصور مي‌کنم که بخش مهمي از اين پروژه، به همکاري با شرکا وابسته خواهد بود. منظور من از شرکا، توليدکننده‌ها هستند. آن‌ها تغييراتي را در دستگاه‌هاي محصول خود ايجاد مي‌کنند و ما قصد داريم تغييرات را به‌مرور با رويکرد مين‌لاين هماهنگ کنيم. چنين روندي درنهايت به ثبات مي‌رسد، اما قطعا به کمي زمان نياز دارد. گولوم: قطعا براي هماهنگي بيشتر به ارائه‌ي قابليت‌هاي بيشتر نياز داريم. روندي که ما در سال گذشته با ارائه‌هاي متعدد پيش گرفتيم و در سال گذشته، بيش از ۱۰ سال قبل انتقال داده و قابليت داشتيم. با بررسي بخشي از پاسخ‌هاي مهندسان گوگل و برنامه‌ي شرکت در پروژه‌ي مين‌لاين اين تصور ايجاد مي‌شود که گوگل در پي کسب مجدد مالکيت برخي از کدهاي هسته‌اي سيستم از توليدکننده‌ها است. در صورت صحيح بودن اين تصور، گوگل تصميم دارد تا همه‌ي شخصي‌سازي‌هايي که قبلا توسط توليدکننده‌ها به سيستم اضافه مي‌شد، به بخش اصلي کدهاي اوپن‌منبع اندرويد اضافه شود تا همه از آن‌ها استفاده کنند. براي تصور بهتر برنامه‌ي گوگل در اولويت‌بندي ماژول‌ها تصور کنيد که غول موتور جست‌وجو از تمامي اعضاي اکوسيستم اندرويد چنين سوالي را بپرسد: «آيا قصد داريد نحوه‌ي کار بخش DNS را شخصي‌سازي کنيد؟». اگر پاسخ منفي باشد، نسخه‌ي گوگل در آن بخش سيستمي به‌عنوان نسخه‌ي الزامي شناخته مي‌شود. در صورت ارائه‌ي پاسخ مثبت از سوي توليدکننده‌ها (يعني نياز به شخصي‌سازي بخشي خاص در سيستم‌عامل)، همه‌ي تغييرات توليدکننده به مرکز پروژه‌ي اوپن منبع اندرويد (AOSP) ارائه مي‌شوند و درنهايت با هماهنگي با تغييرات ديگر، به نسخه‌ي گوگل تبديل خواهند شد. پاسخ نهايي گولوم يعني ارائه‌‌‌ي به‌روزرساني‌هاي متعدد و شخصي‌سازي در يک سال گذشته، نشان از رويکرد رو‌ به جلوي گوگل دارد. درنهايت کدهاي بيشتري به AOSP ارسال مي‌شوند و به‌مرور کار توليدکننده‌ها در به‌روزرساني‌هاي سيستمي کمتر مي‌شود. انتخاب اولويت براي ساخت ماژول‌ها، اولين چالش تيم توسعه‌ي اندرويد بود گولوم: ما به تيم‌هاي خود توضيح داديم که با استفاده از ماژول‌هاي مين‌لاين، به‌روزرساني‌ها تنها ماهي يک بار بايد انجام شوند. به‌علاوه آن‌ها همکاري بيشتري با شرکت خواهند داشت. درنتيجه توسعه‌ي کدها، برنامه‌ريزي و بسياري بخش‌هاي ديگر با همکاري انجام خواهد شد. افراد حاضر در تيم‌هاي گوگل از شنيدن اين برنامه بسيار خشنود شدند. آيا مي‌توانيم انتشار به‌روزرساني يک بار در ماه را به‌عنوان برنامه‌ي اصلي مين‌لاين در نظر بگيريم؟ گولوم: چنين رويکردي با روندهاي قبلي ما هماهنگ خواهد بود و زمان‌بندي به‌روزرساني‌ امنيتي نيز همين‌گونه است. برخي از قطعات ماژولي مين‌لاين نيز در دسته‌بندي امنيت قرار مي‌گيرند. بخش رسانه‌اي نيز شامل کدک‌هاي اساسي و بخش‌هاي اجرايي متعدد مي‌شود. ما در ماژول‌سازي اين بخش نگاهي به آسيب‌پذيري‌هاي رايج سال گذشته داشتيم و نزديک به ۴۰ درصد از آسيب‌پذيري وصله‌هاي امنيتي در بخش رسانه‌اي ديده مي‌شدند. درنهايت نتيجه گرفتيم که بار به‌روزرساني‌ها را از دوش توليدکننده‌ها برداريم. در توضيح پاسخ گولوم بايد بدانيد که موتور پخش رسانه‌اي اندرويد وظيفه‌ي بارگذاري همه‌ي فايل‌هاي خطرناک از سرتاسر وب را بر عهده دارد و امنيت در چنين رويکردي هميشه يک چالش مهم در اکوسيستم بوده است. موتور پخش رسانه‌اي اندرويد به‌نام Stagefright شناخته مي‌شود و در سال ۲۰۱۵ اخبار مهمي را از آسيب‌پذيري‌هاي اجراي کد مخرب از راه دور به خود اختصاص داد. به‌روزرساني‌هاي ماهيانه‌ي بخش امنيتي از همان زمان شروع شدند. گوگل درحال‌حاضر به‌روزرساني‌هاي امنيتي را هر ماه در AOSP ارائه مي‌کند و آن‌ها را به توليدکننده‌ها مي‌دهد. اين رويکرد هنوز عالي به نظر نمي‌رسد و همه‌ي گوشي‌ها، از به‌روزرساني‌هاي ماهيانه پشتيباني نمي‌کنند. درنتيجه همه‌ي گوشي‌هاي اندرويدي به‌روزرساني‌هاي امنيتي را ماهي يک بار دريافت نمي‌کنند. پاسخ گولوم نشان مي‌دهد که گوگل رويکرد بررسي به‌روزرساني‌ها را بر عهده مي‌گيرد و ارائه‌ي آن‌ها را نيز خودش به‌صورت منظم به کل اکوسيستم انجام مي‌دهد. برک: مسئله‌ي مهم ديگر، آسان‌سازي فعاليت توسعه‌دهنده‌ها در اکوسيستم اندرويد خواهد بود. يکي از چالش‌هايي که عموما در رويکرد توسعه‌دهنده‌ها ديده مي‌شود، رفتارها و رويکردهاي متنوع در بخش‌هاي گوناگون سيستم‌عامل است. درواقع حتي در محصولات يک توليدکننده‌هم بعضا عملکردهاي متنوع بخش‌ها ديده مي‌شود. فريم‌ورک رسانه‌اي يکي از مهم‌ترين بخش‌هايي بود که در نگراني‌ توسعه‌دهنده‌ها ديديم. درنهايت پايداري بيشتر بين نسخه‌هاي متعدد سيستم‌عامل براي توسعه‌دهنده‌ها هم بهتر خواهد بود. چنين رويکردي منجر به کاهش خطاها مي‌شود و مسئوليت‌ آن‌ها نيز کاهش خواهد يافت. درنهايت اپليکيشن‌هاي باکيفيت‌تري مي‌بينيم که به‌نفع کاربران هم خواهد بود. گولوم: من در سخنراني از اصطلاح «ثبات باگ» براي اين رويکرد استفاده کردم (برک تأييد مي‌کند). ماژولي به‌نام ANGLE در برنامه‌ها وجود دارد که يک OpenGL پياده‌سازي شده در Vulcan است. درحال‌حاضر اين ماژول جزو دسته‌ي بخش‌هاي الزامي براي سازنده‌ها قرار مي‌گيرد، اما توسعه‌دهنده‌ها الزامي به استفاده از آن ندارند. ما قصد داريم تا به روندي هماهنگ در ارائه‌ي چنين بخش‌هايي دست يابيم. قطعا درنهايت ادعاي انتشار نرم‌افزار بدون باگ نداريم (چون هيچ‌نر‌م‌افزاري بدون باگ نيست)، اما به‌هرحال کاهش درگيري‌هاي متنوع و متفاوت توسعه‌دهنده‌ها با نسخه‌هاي گوناگون سيستم‌عامل منجر به آسا‌ن‌تر شدن فعاليت آن‌ها مي‌شود. برک: جنبه‌اي ديگر از فرايندهاي فوق نشان مي‌دهد که هماهنگي بيشتري با آن‌ها رخ خواهد داد. به‌عنوان مثال به چالش‌هاي پيش‌آمده براي سيستم GPS در ماه آوريل دقت کنيد. هواپيماهاي متعددي به‌خاطر نا‌هماهنگي با تغييرات جديد دچار چالش شدند. درواقع مشکلات نرم‌افزاري هميشه وجود دارند و همه به‌دنبال راهي براي حل کردن سريع‌تر آن‌ها هستند. خصوصا در مواردي همچون کتابخانه‌‌ي ما، Conscript يا کتابخانه‌ي SSL و TLS، به‌روزرساني و رفع مشکلات در اولويت بالايي قرار دارد. چنين مواردي با به‌روزرساني حل مي‌شوند. خصوصا در مواقعي که مجوز نرم‌افزاري باطل شود يا ارائه‌کننده‌ي مجوز به فعاليت‌هاي خود خاتمه دهد، به‌روزرساني‌هاي هماهنگ کارگشا خواهد بود. ايليان مالکو: سال‌ها پيش باگي در کتابخانه‌ي برنامه‌نويسي C اندرويد موسوم به Bionic مشاهده شد که يکي از شرکاي ما آن را شناسايي کرد. در اثر باگ مذکور، مشکلاتي در اپليکيشن‌هاي متنوع و بازي‌ها ايجاد مي‌شد. شناسايي چنين مواردي پيش از ارائه‌ي نهايي نرم‌افزار بسيار مشکل است. گولوم: تا پيش از شناسايي باگ بالا، توسعه‌دهنده‌ها تا چند سال بايد با آن کار مي‌کردند تا زماني يک وصله براي باگ منتشر شود. چنين رخدادهايي براي بسياري از اپليکيشن‌هاي اوليه‌ي ما نيز پيش مي‌آمد. آيا به‌روزرساني آزمايشي براي کاربران Beta Q عرضه شد؟ گولوم: بله ما از زمان انتشار نسخه‌ي بتا، ارائه‌ي به‌روزرساني را هم شروع کرديم. دستگاه‌هاي کاربران بتا ري‌استارت مي‌شد چون ما به‌روزرساني‌ها را ارائه و بررسي مي‌کرديم. البته اين روند تنها در فاز بتا اجرا مي‌شود. پس از ارائه‌ي نسخه‌ي نهايي اندرويد Q ديگر خبري از ري‌استارت‌هاي مکرر به‌خاطر به‌روزرساني نيست و دستگاه تنها با انتخاب خود کاربر ري‌استارت مي‌شود. به‌هرحال تاکنون به‌روزرساني‌هاي متعددي ارائه شده‌اند و نمونه‌هاي امنيتي نيز به‌صورت ماهانه اجرا مي‌شوند. در نسخه‌هاي نهايي فرايندهاي به‌روزرساني در پس‌زمينه اجرا مي‌شوند و مزاحم فعاليت کاربر نخواهند بود. برک: نکته‌ي مهمي درباره‌ي پروژه‌ي مين‌لاين وجود دارد که شايد در مقاله و پست‌هاي وبلاگي قابل توضيح نباشد. مين‌لاين را مي‌توان مهم‌ترين تغيير مسير در تاريخ توسعه‌ي نرم‌افزارهاي سيستم‌عامل ناميد. در وضعيت کنوني اندرويد، ما محتواي مرجع يا گاهي اوقات محصولي کامل را ارائه مي‌‌کنيم که مي‌تواند همان سيستم‌عامل و محصولي شبيه به پيکسل باشد. سپس کد اصلي که به‌‌صورت متن‌باز توسعه مي‌يابد، در اختيار شرکا قرار مي‌گيرد. شرکايي همچون وان‌پلاس کد را از ما مي‌گيرند و دستگاه‌هاي مورد نظر خود را مي‌سازند. البته درواقع ما کد متن‌باز را ارائه مي‌کنيم و آن‌ها کد را از همان محل متن‌باز دريافت مي‌کنند. درنتيجه‌ي چنين روندي مقياس‌دهي اکوسيستم رخ مي‌دهد. با ماژولار شدن سيستم‌عامل، وظيفه‌ي نگه‌داري آن بيشتر بر عهده تيم اصلي اندرويد خواهد بود وقتي مدلي مانند مين‌لاين اجرا شود و در آن کدهاي مشابهي براي ماژول‌ها داشته باشيم، ما يعني تيم اندرويد کد نهايي را عرضه مي‌کنيم. درنتيجه ما مسئول کدهاي اجراشده در همه‌ي دستگاه‌ها خواهيم بود. درنتيجه وقتي يک باگ در محصول يکي از توليدکننده‌ها ظاهر مي‌شود، به ما هم منتقل خواهد شد. درنهايت حل باگ و ارائه‌ي مجدد کدها بر عهده‌ي تيم اندرويد است. ما براي دسترسي به مدل بالا مجبور بوديم که توانايي‌‌هاي مهندسي و فرايندهاي خودکار بررسي را بهبود دهيم. بسياري فرايندهاي توسعه‌اي ديگر هم به‌روزرساني و تقويت شدند و به‌نوعي تمام فرايندهاي کاري هدف بازطراحي و بازسازي قرار گرفتند. به نظر مي‌رسد شما برنامه‌اي جدي براي توسعه و استفاده از مين‌لاين در آينده داريد. برک: بله من فکر مي‌کنم که فعاليت‌ها در مين‌لاين به‌مرور افزايش مي‌يابد. ما به اين پروژه مانند يک پروژه‌‌ي متن‌باز نگاه مي‌کنيم و خود را عضوي از آن مي‌دانيم که بايد با همکاري ديگر شرکا براي بهبودش تلاش کنيم. به‌هرحال زيرساخت موجود امکان همکاري بيشتر و توسعه‌هاي آتي را فراهم مي‌کند. در نسخه‌هاي کنوني که به‌همراه دستگاه‌هايي همچون پيکسل ۳ ارائه شد، تغييرات مشهود ماژولار شدن سيستم‌عامل را مشاهده مي‌کنيد. ما اعتقاد زيادي به متن‌باز بودن پروژه و اکوسيستمي مبتني بر همکاري داريم. به‌علاوه اعتقاد داريم توليدکننده‌ها بايد توانايي متفاوت عمل کردن را داشته باشند. به‌هرحال براي اجراي چنين برنامه‌هايي بايد بين همه‌ي تصورات و انتظارهاي خود از اکوسيستم تعادل برقرار کنيم. البته بخش‌هاي زيادي وجود دارند که توسط توليدکننده‌ها تغيير نمي‌کنند و از ميان آن‌ها مي‌توان کتابخانه‌ي Conscript را نام برد. تبديل کردن موارد اين‌چنيني به ماژول، دستگاه‌هاي کاربران را امن‌تر مي‌کند. به‌علاوه باگ‌ها کمتر و کار براي توسعه‌دهنده‌ها راحت‌تر مي‌شود. گولوم: درباره‌ي قابليت‌ تغيير يا شخصي‌سازي ماژو‌ل‌ها بايد بگويم که ماژول‌ها عموما در بخش‌هاي مرتبط با امنيت يا حريم خصوصي انتخاب شدند يا در دسته‌اي بودند که توليدکننده‌ها تمايلي به تغييرات آن‌چناني در آن‌ها نداشتند. به‌عنوان مثال قابليت‌هاي رسانه‌اي جزو بخشي هستند که افزونه‌هاي متعددي از سوي شرکت‌ها در آن‌ها ارائه مي‌شود. به‌همين دليل ما امکان ايجاد تغييرات را در آن مي‌دهيم. همکاران ما در اکوسيستم اندرويد مي‌توانند APEXهاي اختصاصي خود را براي سيستم رسانه عرضه کنند که در کنار فايل APEX اصلي ارائه خواهد شد. برک: بله ما از مدل افزونه‌اي استفاده خواهيم کرد. درنتيجه يک هسته‌ي مشترک به وجود خواهد آمد و ماژول‌هاي کاربردي به آن اضافه مي‌شوند. درنتيجه ما مثلا ماژولي به‌نام Samsung media خواهيم داشت که احتمالا امکانات اضافه‌تري به کاربر مي‌دهد. برک: بله، شايد شرکتي تمايل داشته باشد تا قابليت‌هايي همچون Dolby Vision يا Dolby Atoms را به ماژول رسانه‌اي اضافه کند. گولوم: شايد هم کدک‌هاي رسانه‌اي توسط شرکت‌ها ارائه شوند که ما در ماژول خود از آن‌ها پشتيباني نمي‌کنيم. پس آن‌ها کاربردهاي اوليه‌ AOSP را خواهند داشت و در ادامه جزئيات مورد نظر خود را به آن اضافه مي‌کنند. گولوم: جالب است که ما به‌صورت کلي به سمت همين رويکرد حرکت مي‌کرديم. اگر به بخش نرم‌افزاري باتري تطبيقي دقت کنيد که سال گذشته اجرا کرديم، متوجه رويکرد مشابه مي‌شويد. ما تعدادي API سيستمي داشتيم که يک مدل مبتني بر هوش مصنوعي توانايي ارتباط با آن را داشت. سيستم حاصل به‌نوعي اقدامات بعدي کاربر را پيش‌بيني مي‌کند. توليدکننده‌هاي دستگاه‌هاي اندرويدي اکنون مي‌توانند آن بخش را به‌طور کامل جايگزين کنند. اکنون ما به‌جاي رويکرد قبلي و پچ کردن کل کدها، پايه‌هاي اوليه را در اختيار شرکت‌ها قرار مي‌دهيم که قابليت توسعه‌ي آتي براساس آن را خواهند داشت. اين رويکرد در آينده بيشتر پي گرفته مي‌شود. برک: به‌نظر من بايد نامي جديد براي اين روش توسعه‌ي نرم‌افزاري انتخاب شود. وقتي شما در ۲۰ سال پيش يک نرم‌افزار مي‌نوشتيد، آن را در سي‌دي رام قرار مي‌داديد و عرضه مي‌کرديد. براي پشتيباني‌هاي آتي نيز سرويس‌هايي وجود داشت. در مدل جديد، نرم‌افزار ارائه مي‌شود و با بهره‌گيري از ابزارهاي از راه دور، فرايندهاي بررسي، عيب‌يابي، رفع اشکال و به‌روزرساني رخ مي‌دهند. در چنين رويکردي بايد فرايندهاي تست و بررسي با سرعت و شدت بالايي انجام شوند. به‌هرحال روش جديد نياز به نام جديد هم دارد و شايد بتوان آن را «توسعه‌ي نرم‌افزاري مدرن» ناميد. گولوم: پيش‌رونده؟ برک: توسعه‌ي نرم‌افزاري پيش‌رونده. البته اين اصطلاح معناي متفاوتي دارد. به‌عنوان مثال اگر سيستم‌عامل‌هاي ديگر را در نظر بگيريد و مثلا يک باگ در بخش رسانه‌اي آن‌ها ايجاد شود، بايد کل سيستم‌عامل را به‌روزرساني کنند. چنين رويکردي قطعا پيش‌رونده نيست. ازطرفي ما در حال حاضر اندرويد را در بخش‌هاي متنوع به‌روزرساني مي‌کنيم. مثلا اپليکيشن‌هاي گوگل مرتبا به‌روزرساني مي‌شوند يا Google Play Services به‌صورت منظم به‌روزرساني دريافت مي‌کند. درواقع ما اکنون نيز رويکردي پيش‌رونده داريم. چه پيش‌نيازهايي براي پشتيباني از مين‌لاين وجود دارد؟ آيا گوشي‌هاي مجهز به اندرويد Q ملزم به رعايت آن هستند؟ گولوم: بله، هر گوشي که با اندرويد Q عرضه شود، بايد از مين‌لاين پشتيباني کند. برخي ماژول‌ها هم هستند که در دستگاه‌هاي به‌روزرساني شده به اندرويد Q الزامي خواهند بود. دستگاه‌هايي که به اندرويد Q به‌روزرساني مي‌شوند بايد ExtServices و Permissions Controller را به‌عنوان ماژول داشته باشند چون اين بخش‌ها هم‌اکنون توسط گوگل ساين شده‌ و براي عرضه در سيستم‌عامل‌ها به توليدکننده‌ها ارائه شده‌اند. درنتيجه در به‌روزرساني جديد شاهد حضور آن‌ها خواهيم بود. در توضيح فرايند ساين بايد بدانيد که ساين کردن آخرين مرحله‌ي پاياني پيش از توزيع اپليکيشن است. درنتيجه ساين شدن ماژول‌هاي بالا يعني آن‌ها در اختيار گوگل قرار دارند و توليدکننده‌هاي اجازه‌ي تغييرشان را نخواهند داشت. درباره‌ي ExtServices توضيح دهيد. به‌نظر نمي‌رسد از سال‌ها پيش تغييري در آن ايجاد کرده باشيد. گولوم: در توضيح ساده، اين ماژول مجموعه‌اي از مواردي است که قصد داريم در فرايندهاي سيستمي هميشه در حال اجرا، به‌روزرساني کنيم. در توضيح دقيق‌تر، بخش‌‌هايي مرتبط با حريم خصوصي در ماژول وجود دارد که ما بايد امکان به‌روزرساني و رفع باگ‌ آن‌ها يا حتي تغيير سياست‌هاي موجود را داشته باشيم. به‌عنوان مثال بخش‌هايي از پر کردن خودکار فيلد فرم‌ها در آن وجود دارد. بخش‌هايي از مين‌لاين در ماژول ExtServices وجود دارد که قابليت به‌روزرساني هم دارند. به‌عنوان مثال مي‌توان به ناظر داخل دستگاهي مين‌لاين اشاره کرد. شما براي دستگاه‌هايي که حافظه‌ي رم پاييني دارند در پشتيباني از مين‌لاين استثناء قائل شده‌ايد. گولوم: مشکل اصلي حافظه‌ي رم نيست و حافظه‌ي داخلي مهم‌تر است. بسياري از دستگاه‌ها با حافظه‌ي رم پايين، خصوصا نمونه‌هاي ۵۱۲ مگابايتي و يک گيگابايتي، حافظه‌ي داخلي پاييني دارند. برک: ماژول APEX بايد با پارتيشن‌‌بندي‌هاي داده‌اي در دستگاه حضور داشته باشد. درنتيجه وقتي پارتيشن‌هاي سيستمي جايگزين مي‌شوند، درواقع فضاي اشغالي دو برابر مي‌شود. نام‌گذاري APEX در بخشي از مصاحبه، برک مسئله‌ي نام‌گذاري فايل‌هاي جديد يعني APEX را مطرح مي‌کند که طبق ادعاي نويسنده‌ي آرس و سند رسمي مين‌لاين، مخفّفي براي Android Pony Express است. در ادامه مهندسان گوگل داستان انتخاب اين اسم را شرح مي‌دهند. مالکو: من به شما اطمينان مي‌دهم که در انتخاب اين اسم زيبا نقش مهمي داشتم. ما ابتدا مي‌خواستيم اصطلاح NPK را به‌عنوان مخففي براي Native PacKage استفاده کنيم. همکاران ديگر ما همچون جارز و ديان هک‌بورن نيز در نام‌گذاري نقش داشتند. هک‌بورن از معماران قديمي اندرويد است و در مخالفت با NPK گفت که شباهت زيادي با APK دارد. سپس نام‌هاي ديگري ارائه شدند و من در نهايت APEX يا Android Pony Express را پيشنهاد دادم. درواقع Android Pony Express عبارتي تقريبا طنز براي توضيح دادن APEX محسوب مي‌شود. ما مي‌توانستيم از Android Portable Exchange استفاده کنيم، اما بار جذابيت عبارت کنوني بيشتر بود. ديسک زنده‌ي لينوکس براي اندرويد پس از بررسي مين‌لاين و جزئيات آن، به بخش ديگري از رونمايي‌هاي رويداد Google I/O مي‌رسيم که نمايشي اوليه از قابليت جديدي در اندرويد Q داشت. اين قابليت به‌نام Dynamic System Update شناخته مي‌شود که در نمونه‌هاي آزمايشي اندرويد ديده شد. در تعريف ساده قابليت جديد حالت بوت دوگانه را به سيستم‌عامل مي‌دهد. کاربر با استفاده از آن مي‌تواند پس از ريبوت کردن دستگاه از يک نسخه‌ي اندرويد، وارد نسخه‌ي ديگر شود. چنين قابليتي براي توسعه‌دهنده‌ها، توليدکننده‌ها، متخصصان و ديگر افرادي که تمايل به تغيير سريع نسخه‌ي اندرويد دارند، مفيد خواهد بود. در نسخه‌هاي بعدي قابليت بوت دوگانه‌ي اندرويد آسان‌تر مي‌شود قابليت جديد اندرويد Q شباهت زيادي به دستاوردهاي قبلي Project Treble دارد. دستگاه آزمايشي گوگل در رويداد I/O بين يک نسخه‌ي نهايي اندرويد و يک Generic System Image از سيستم‌عامل يا GSI تغيير حالت مي‌داد. اندرويد قبلا به‌عنوان يک سيستم‌عامل امبدد شناخته مي‌شد که سيستم‌عامل و پشتيباني از سخت‌افزار آن داخل يک ايميج تکي قرار داشتند. در پروژه‌ي Treble، سيستم‌عامل از پشتيباني سخت‌افزاري جدا شد و عبارت GSI به‌وجود آمد. با استفاده از GSI، پشتيباني سخت‌افزاري اندرويد شباهت کمتري به يک سيستم‌عامل امبدد خواهد داشت و بيشتر به ويندوز يا لينوکس شبيه مي‌شود. درنهايت نسخه‌اي از سيستم‌عامل داريم که روي دستگاه‌هاي متعددي کار مي‌کند. از زمان انتشار اندرويد ۸ يا Oreo، پشتيباني از Treble و بوت کردن حالت GSI يکي از پيش‌نيازهاي پشتيباني اندرويد محسوب مي‌شود. گوگل حتي نسخه‌اي GSI از اندرويد Q بتا را عرضه کرد. به‌هرحال با پيشرفت اين موارد، احتمالا سال آينده و در زمان عرضه‌ي اندرويد R شاهد قابليت بوت دوگانه به آن بدون نياز به پاک کردن نسخه‌هاي قبلي خواهيم بود. درباره‌ي قابليت بوت زنده توضيح دهيد. مالکو: ما ابتدا نام Live Image يا Live Boot را براي قابليت جديد انتخاب کرديم. روش کار قابليت جديد به‌گونه‌اي بود که حالتي شبيه به ديسک زنده‌ي لينوکس را القا مي‌کند. سپس تيم ما در ماه‌هاي اکتبر تا نوامبر گذشته آن را بازنويسي کردند و به محصولي بهتر رسيديم. برک: دليل بازنويسي کامل قابليت، فشارهاي تيم امنيتي اندرويد بود. آن‌ها تيم توسعه را مجبور به بازنويسي کدها کردند. ما تيم امنيتي بسيار قوي داريم که بسيار عالي هستند و به بهتر شدن اندرويد کمک شاياني مي‌کنند. مالکو: پس از بازنويسي برخي از خصوصيت‌هاي قابليت جديد تغيير کرد و ما با تغيير نام به Android on Tap رسيديم. سپس به تيم‌هاي اختصاصي انتخاب نام در گوگل مراجعه کرديم و آن‌ها گفتند که نام انتخابي آن‌چنان توصيفي نيست. درنهايت به Dynamic System Updates رسيديم. در نسخه‌هاي دمو هم همين نام به چشم مي‌خورد. قابليت جديد چگونه کار مي‌کند؟ آيا پارتيشن مجزايي براي اجراي بوت دوم داريم؟ مالکو: خير، البته يکي از پيش‌نيازهاي اندرويد Q با هدف آسان‌تر کردن به‌روزرساني‌ها و با نام پارتيشن‌هاي دايناميکي معرفي مي‌شود. آن اسم ارتباطي به اين بخش ندارد، اما مکانيزم آن‌ها تقريبا شبيه خواهد بود. پارتيشن‌هاي دايناميکي امکان تغيير ابعاد پارتيشن را در به‌روزرساني‌هاي OTA ايجاد مي‌کنند تا بدون ايجاد خلل در عملکرد سيستم‌عامل، تغييرات اعمال شود. با توجه به پاسخ بالا و در بررسي‌ نمونه‌هاي اوليه به اين نتيجه مي‌رسيم که پارتيشن‌بندي پويا براي به‌روزرساني آسان‌تر دستگاه‌هاي ارزان، کاربردي خواهد بود. هر دستگاه اندرويدي دو پارتيشن اصلي دارد. يکي به‌نام پارتيشن System شناخته مي‌شود که سيستم‌عامل کارخانه‌اي در آن قرار دارد. اين پارتيشن تنها ازطريق به‌روزرساني‌هاي سيستمي يا همان OTA تغيير مي‌کند. پارتيشن بعدي Data نام دارد که فايل‌هاي کاربر در آن قرار مي‌گيرند. درحال‌حاضر ابعاد پارتيشن‌هاي داخلي دستگاه‌هاي اندرويدي در کارخانه تنظيم مي‌شود و ثابت مي‌ماند. چنين تنظيماتي تأثير زيادي روي دستگاه‌هاي پرچم‌دار با حافظه‌ي بسيار زياد ندارد، اما براي دستگاه‌هاي ارزاني همچون نسخه‌هاي Android Go که تنها هشت گيگابايت حافظه دارند، تنظيم پارتيشن دشوار خواهد بود. کارخانه بايد به‌گونه‌اي حافظه را پارتيشن‌بندي کند که فضاي مناسب براي فايل‌‌هاي سيستمي وجود داشته باشد و همچنين، فضا براي فايل‌هاي کاربر و به‌روزرساني‌هاي بعدي سيستم‌عامل نيز فراهم شود. قابليت تغيير ابعاد پارتيشن‌ها، نگراني توليدکننده‌ها را در تخصيص فضا براي به‌روزرساني‌هاي آتي از بين مي‌برد. آن‌ها مي‌توانند در زمان عرضه‌ي محصول، پارتيشن بزرگي را براي داده به کاربر ارائه کنند و بعدا در صورت نياز به به‌روزرساني، ابعاد پارتيشن سيستمي را تغيير دهند. مالکو: مکانيزم عملکردي اين‌گونه است که ما بلوک‌هاي مورد نظر را از حافظه جمع مي‌کنيم و از آن‌ها پارتيشن‌هاي منطقي مي‌سازيم. همين مکانيزم را براي Dynamic System Updates نيز به‌کار مي‌بريم و دو فايل سيستمي ايجاد مي‌کنيم. برک: يکي از فايل‌ها شامل ايميج سيستم مي‌شود و ديگري براي داده‌هاي کاربر استفاده خواهد شد. درواقع يک پارتيشن مجازي خواهيم داشت. مالکو: بله، يکي براي سيستم و ديگري براي داده‌ها استفاده مي‌شود. پس از ساخت پارتيشن از بلوک‌هاي مورد نظر، GSI را روي آن نصب مي‌کنيم. سپس پارتيشن داده‌‌ي کاربر به‌صورت يک پارتيشن هالي F2FS يا EXT4 ايجاد مي‌شود. در مرحله‌ي بعدي تنظيماتي ايجاد مي‌شود که طبق آن، init (بخشي از فرايند بوت اندرويد) جريان بوت را از پارتيشن ذخيره‌شده هدايت مي‌کند. در تعريف ساده کاربر مي‌تواند دستگاه را از پارتيشن جديد بوت، آن را پاک کرده و بدون آسيب به سيستم‌عامل اصلي، نسخه‌هاي جديد اندرويد را امتحان کند. قابليت جديد شباهت زيادي به ماشين مجازي دارد. برک: بله شبيه به ماشين مجازي خواهد بود، منتهي دستگاه به‌صورت کامل در نسخه‌ي مورد نظر بوت مي‌شود. آيا نسخه‌ي اضافه‌ي اندرويد براي کاربر دائمي خواهد بود؟ درواقع آيا مي‌توانند هميشه از آن استفاده کنند؟ مالکو: همان‌ طور که ديو (برک) توضيح داد، ما نمي‌خواهيم کاربران در قابليت جديد گرفتار شوند. درنتيجه وقتي دستگاه را ريبوت کنند به نسخه‌ي اصلي اندرويد وارد خواهند شد. البته قابليتي براي بوت کردن به نسخه‌ي دوم هم وجود دارد، اما کاربر براي آن منظور بايد تنظيماتي را روشن کند. روشن کردن تنظيمات نيز براي هر بار بوت الزامي خواهد بود. به‌هرحال کاربر مي‌تواند بين نسخه‌هاي مختلف بوت کند و داده‌هاي شخصي نيز هيچ مشکلي نخواهند داشت. پارتيشن‌بندي نسخه‌هاي جديد اندرويد قابليت تغيير ابعاد خواهد داشت درنتيجه نيازي به آنلاک کردن بوت‌لودر هم نخواهد بود؟ مالکو: Dynamic System Update قابليت پيش‌فرض يا الزامي دستگاه‌ها نخواهد بود، اما اگر فعال باشد، نياز به آنلاک بودن دستگاه را از بين مي‌برد. درواقع نکته‌ي اصلي قابليت جديد نيز همين است. پس هدف نهايي اين است که کاربر بتواند نسخه‌اي جديد از اندرويد، مثلا حالت بتا را حتي در گوشي‌هاي قفل نيز آزمايش کند. مالکو: بله، اين قابليت اکنون در گوشي‌هاي پيکسل ما هم وجود دارد که در دموي اندرويد Q مشاهده کرديد. برک: اين قابليت يکي ديگر از مواردي است که به‌لطف Treble ايجاد شد. درواقع رابط کاربري تميز سمت سخت‌افزار به شما امکان مي‌دهد که چنين مواردي را به سيستم‌عامل اضافه کنيد. اگر سه يا چهار سال پيش چنين قابليت‌هايي را تصور مي‌کرديم، به نظر نشدني مي‌آمدند. مالکو: اگر قابليت کنوني را چند سال پيش ارائه مي‌کرديم، هيچ دستگاه يکپارچه و بدون اشکالي براي اجراي آن وجود نداشت. درنتيجه نمي‌توانستيم مکانيزم را به‌راحتي اجرا کنيم. اکنون پشتيباني از اين وضعيت آسان‌تر به نظر مي‌رسد و ما تمايل داريم همکاران آن را فعال کنند. به‌هرحال اکنون با برخي از آن‌ها براي فعال شدن قابليت‌هاي جديد صحبت مي‌کنيم. قابليت‌هاي ديگر اندرويد Q در بخش ديگري از مصاحبه به تغييرات اندرويد Q نسبت به نسخه‌هاي قبلي و همچنين تغيير قابليت‌ها در نسخه‌هاي بتا پرداخته شد. يکي از موارد، قابليت Snooze براي اعلان‌ها بود که ابتدا با اندرويد ۸ ارائه شد. سپس تا نسخه‌‌ي سوم بتا اندرويد Q نيز قابليت Snooze وجود داشت و حذف شد. اکنون در Android Q Beta 4 مجددا شاهد اين قابليت هستيم. چرا Snooze از پنل اعلان‌ها حذف شد؟ آيا قابليت بود يا باگ؟ برک: در آينده شايد شاهد اين قابليت باشيم و شايد هم آن را حذف کنيم. ما تنظيماتي به‌صورت حالت‌هاي Gentle و Priority براي اعلان‌ها ارائه کرديم. درواقع تلاش مي‌کنيم تا همه‌ي بخش‌ها ساده‌سازي شوند. مشکل کنوني اعلان‌ها، پيچيده شدن آن‌ها است. اکنون حالت‌هاي متعددي همچون channel يا snooze وجود دارد و ما مي‌خواستيم آن‌ها را ساده‌سازي کنيم. درحال‌حاضر بخشي از تيم ما اعتقاد دارد که حالت snooze بايد حذف شود تا تجربه‌ي کاري براي کاربران به سمت آسان‌‌تر شدن پيش برود. البته قطعا برخي از ما نگران کاربران علاقه‌مند به اين قابليت هستيم، اما به‌هرحال بايد اکثريت کاربران را در نظر بگيريم. آيا ساده‌تر شدن براي آن‌ها بهتر خواهد بود؟ همين سؤال‌ها باعث مي‌شود تا حالت‌هاي گوناگون را براي بخش اعلان در نظر بگيريم. در برخي از نسخه‌هاي بتا قابليت snooze را داشتيم و در برخي ديگر آن را حذف کرديم. به‌هرحال تصور مي‌کنم که به خاطر استفاده‌‌ي پايين، آن را حذف خواهيم کرد. اين وضعيت از نقاط مثبت و البته منفي عرضه‌ي نسخه‌ي بتا محسوب مي‌شود که علاوه بر بررسي قابليت‌هاي متنوع، ما را به بحث‌هاي طولاني هم مي‌کشاند. از قابليت‌هاي ديگر آزمايشي در نسخه‌هاي بتا اندرويد Q مي‌توان به Adaptive Sleep اشاره کرد که البته عملکرد مناسبي هم نداشت. درحال‌حاضر برخي دستگاه‌ها همچون گوشي‌هاي گلکسي سامسونگ، چنين قابليتي را با بهره‌گيري از دوربين جلو به کاربر ارائه مي‌کنند. گوشي با تشخيص چهره‌ي کاربر روشن مي‌شود و تا زماني‌که صورتي در مقابل آن باشد، روشن مي‌ماند. درباره‌ي قابليت Adaptive Sleep توضيح دهيد. آيا براي همه ارائه شد؟ برک: اين قابليت به‌نوعي آزمايشي بود و هنوز آماده نيست. تصور مي‌کنم در اجراي آن تاحدودي با باگ روبه‌رو بوديم. برخي کاربران از ما انتظار داشتند که اين قابليت را ارائه کنيم. قابليتي که گوشي هوشمند را در زمان نگاه کردن کاربر روشن نگه مي‌داشت. درحال‌حاضر مي‌‌توان آن را اسکلتي از قابليت نهايي دانست که هرگونه تغييري در آن محتمل خواهد بود. به‌هرحال تصور نمي‌کنم که در AOSP هم ارائه شده باشد. درواقع اکنون تنها چگونگي پياده‌سازي قابليت را شرح داده‌ايم و تصميم نهايي بر عهده‌ي توليدکننده خواهد بود. به احتمال زياد در نسخه‌ي نهايي اندرويد Q شاهد آن نخواهيم بود و من هم به‌همين خاطر از حضور Adaptive Sleep در نسخه‌هاي بتا تعجب کردم. روند بالا به دفعات از سوي گوگل ديده شده است. توليدکننده‌ها عموما به شرکت مراجعه مي‌کنند و ايده‌ي قابليتي را مي‌دهند که در اندرويد وجود ندارد. آن‌ها اغلب خودشان قابليت را اجرا مي‌کنند يا درنهايت API ارائه مي‌شود که ديگر توليدکننده‌ها هم توانايي پياده‌سازي آن را داشته باشند. به‌عنوان مثال پشتيباني تقسيم نمايشگر ابتدا توسط توليدکننده‌ها عرضه شد و کوگل در اندرويد ۷ نوقا استانداردهاي ارائه‌ي نهايي را براي کل اکوسيستم ارائه کرد. به‌هرحال در قابليت Adaptive Sleep اکنون سامسونگ جلوتر از ساير حرکت مي‌کند و شايد در آينده شاهد حضور قابليت حتي در گوشي‌هاي پيکسل هم باشيم. ويژگي مورد سؤال بعدي، حالت دسکتاپ اندرويد Q است. با اين قابليت (که توضيحات کاملي از آن در XDA Developers وجود دارد)، مي‌توان يک رابط کاربري کاملا دسکتاپ به اندرويد داد. رابط دسکتاپ شباهت زيادي به سيستم‌عامل کروم دارد. پنجره‌هاي قابل جابه‌جايي مانند سيستم‌عامل‌هاي دسکتاپ ديگر، دکمه‌ي فهرست اپليکيشن‌ها مانند استارت و موارد مشابه، از ويژگي‌هاي رابط کاربري دسکتاپ هستند. چرا گوگل بايد چنين قابليتي را در اندرويد ايجاد کند؟ آيا آن‌ها قصد جايگزيني سيستم‌عامل کروم را دارند؟ آيا اندرويد به‌دنبال تصاحب جايگاه ويندوز است؟ آيا در آينده شاهد کامپيوترهاي برند پيکسل با کيبورد و ماوس خواهيم بود؟ چرا قابليت دسکتاپ در نسخه‌ي جديد وجود دارد؟ با اجراي چند دستور ADB مي‌تواند قابليت دسکتاپ با پنجره‌هاي شناور و موارد ديگر را اجرا کرد. گولوم: اين بخش جزئي از همکاري ما با تيم Foldable (احتمالا تيمي مخصوص توسعه‌ي اندرويد براي گوشي‌هاي تاشدني) و تيم‌هايي از توليدکننده‌هاي متعدد است. ما پشتيباني از حالت‌هاي چند پنجره و چند نمايشگر را در سيستم توسعه مي‌دهيم. برخي از ويژگي‌هاي جالب وجود دارند که ما به‌صورت رسمي در پيکسل عرضه نمي‌کنيم، اما شرکت‌هاي ديگر آن را ارائه مي‌کنند. به‌عنوان مثال مي‌توان به قابليت DEX گوشي‌هاي سامسونگ يا حالت دسکتاپ گوشي‌‌هاي ديگر اشاره کرد. درنهايت تيم تلاش کرد تا نوعي دمو و تجربه‌ي اوليه ايجاد کند که پيش از توليد محصولات فيزيکي مرتبط، آزمايش شود. بحث جذاب لينوکس مالکو بعلاوه بر مسئوليت‌هاي اصلي مديريتي، برخي اوقات به‌عنوان نماينده‌ي گوگل در کنفرانس‌هاي لينوکس هم شرکت مي‌کند. به‌عنوان مثال او در رويداد Linaro Connect 2017 از سخنراناني بود که خبر سه‌برابر شدن پشتيباني از کرنل‌هاي طولاني‌مدت لينوکس (LTS) را رسانه‌اي کرد (از دو سال به ۶ سال). البته فهرست کنوني Kernel.org تنها دو نسخه را در پشتيباني ۶ ساله نشان مي‌دهد و نسخه‌هاي جديدتر به همان پشتيباني دوساله بازگردانده شده‌اند. براي شفاف‌سازي بهتر موضوع، در ادامه‌ي مصاحبه با مالکو درباره‌ي آن صحبت شد. شما به پشتيباني ۶ ساله‌ي کرنل‌ها اشاره کرديد، اما به نظر مي‌رسد همه‌ي آن‌ها چنين پشتيباني را ندارند. مالکو: کرنل‌هاي LTS با پشتيباني ۶ ساله وجود دارند و ما باز همچنين کرنل‌هايي معرفي مي‌کنيم. البته همه‌ي کرنل‌هاي دو ساله به ۶ ساله تغيير نخواهند کرد، چون همه‌ي کرنل‌ها به دستگاه‌هاي اندرويدي منتقل نمي‌شوند. در نتيجه کوالکام مسئول چنين مواردي است؟ مالکو: بله، درواقع هر کرنلي که کوالکام، مدياتک يا هر توليدکننده‌ي ديگر پردازنده استفاده کند، از طرف ما به‌عنوان کرنل ۶ ساله معرفي خواهد شد. به‌عنوان مثال براي نسخه‌ي پاي بايد از يکي از اين کرنل‌ها استفاده شود. ما حداقل نسخه‌ي قابل پشتيباني را براي هريک از کرنل‌ها معرفي مي‌کنيم. اکنون نسخه‌هاي ۴.۴ و ۴.۹ در ميان نسخه‌هاي ۶ ساله قرار دارند. به‌هرحال براي انتخاب نسخه‌ي قطعي پشتيباني ۶ ساله و اعلام آن، مراحل هماهنگي بين ما و توليدکننده‌‌ها نياز خواهد بود. مالکو در بخش‌هاي از صحبت‌هاي خود مي‌گويد که پيش‌نياز اندرويد پاي براي کرنل‌هاي ۴.۴ و ۴.۱۴ لينوکس تنها براي دستگاه‌هاي جديد مجهز به اين نسخه مطرح مي‌شود. شايان ذکر است دستگاه‌هاي اندرويدي هميشه به کرنل‌هاي جديد و بزرگ به‌روزرساني نمي‌شوند. به‌علاوه از آن‌جايي که گوگل تمايل دارد پشتيباني از اندرويد ۹ پاي در دستگاه‌هاي قديمي هم ارائه شود، اين نسخه بايد کرنل‌هاي قديمي‌تر از ۴.۴ را هم پشتيباني کند. درواقع پشتيباني پاي از کرنل‌ها به نسخه‌ي ۳.۱۸ مي‌رسد که در سال ۲۰۱۴ ارائه شد. درنهايت نتيجه مي‌گيريم که پشتيباني از کرنل‌هاي با حدود ۶ سال عمر در اندرويد امري بديهي محسوب مي‌شود. پشتيباني از نسخه‌هاي قديمي کرنل مي‌تواند توليدکننده‌ها را به به‌روزرساني نسخه‌هاي جديد اندرويد تشويق کند. با ماژولار کردن اندرويد در پروژه‌ي Treble و جدا کردن سيستم‌عامل از سخت‌افزار، کرنل در بخش سخت‌افزاري مي‌ماند. در وضعيت کنوني و در نسخه‌هاي اصلي، پياده‌سازي اندرويد به‌معناي وارد کردن لينوکس در گوشي و رها کردن آن براي هميشه خواهد بود. رويکردي که درحال‌حاضر مناسب به نظر نمي‌رسد. پشتيباني از کرنل‌هاي قديمي لينوکس، قدم مهمي براي به‌روزرساني گوشي‌هاي قديمي است سانديپ پاتيل از مهندسان ارشد تيم اندرويد سال گذشته در Linux Plumber Conference يک سخنراني ارائه کرد و آينده‌ي احتمالي همکاري لينوکس در کنار اندرويد را ترسيم کرد. و در صحبت‌هاي خود با اشاره به GSI، از برنامه‌ي توسعه‌ي مفهوم جديدي به‌نام GKI يا Generic Kernel Image رونمايي کرد. مفهوم مورد نظر او کرنلي خواهد بود که روي هر دستگاه با پشتيباني از Treble پشتيباني مي‌شود. پاتيل در ادامه‌ي صحبت‌هاي خود گفت که Treble امکان اجراي پروژه‌ي GKI را فراهم کرد و طرح اوليه براي رابط‌هاي کاربري مورد نياز را به گوگل داد. علاوه بر رابط‌هاي کاربري، همکاري‌هاي بين اکوسيستمي و تست‌هاي مهم الزامي در پروژه‌ها هم نياز خواهند بود که با اجراي Treble، درکي کلي از آن‌ها در گوگل ايجاد شد. درباره‌ي Generic Kernel Image توضيح دهيد. آيا شما کرنلي با GSI عرضه خواهيد کرد؟ آيا مطلبي براي به‌روزرساني اخبار در اين مورد داريد؟ مالکو: ما مي‌خواهيم همه‌ي بخش‌ها را به‌گونه‌اي کاربردي متحد کنيم. به‌علاوه مانند هميشه قصد داريم امکان شخصي‌سازي را به توليدکننده‌ها ارائه کنيم و مفهوم متن‌باز هميشه ادامه داشته باشد. هدف نهايي، در کنار هم بودن و نه شبيه بودن خواهد بود. ما از مدت‌ها پيش منابع کرنل را در سطح همان منابع به سمت يکپارچگي برده‌ايم. در بحث GKI ما منابع اوليه را براي توسعه و آزمايش دستگاه‌ها با کرنل‌هاي جديد ارائه مي‌کنيم. همين رويکرد در روح GSI هم وجود دارد. البته اين مفاهيم هنوز وجود ندارند و تنها در سطح مفهومي جذاب به نظر مي‌رسند. به‌هرحال ما بايد فعاليت‌هاي زيادي انجام دهيم تا از مناسب بودن نتيجه‌ي نهايي در اکوسيستم مطمئن شويم. آيا هدف نهايي ايجاد يک کرنل مين‌لاين لينوکس براي گوشي است؟ مالکو: تقريبا همين برنامه را در نظر داريم. البته فعاليت‌هاي دشوار و گسترده‌اي نياز خواهد بود. درواقع مسئله‌اي به گستردگي اکوسيستم داريم. در نتيجه مراحل را قدم به قدم پيش مي‌بريم. ما منابع را يکپارچه کرده و به‌مرور ساير را به به‌روزرساني کرنل‌ها به آخرين LTS تشويق مي‌کنيم. درحال‌حاضر چنين رويکردي داريم و به‌نوعي مسير را براي ادامه‌ي راه هموار مي‌کنيم. شما کرنل را در يک گوشي به‌روزرساني نمي‌کنيد. درست است؟ مالکو: بله کاملا روشن است که وقتي يک دستگاه به بازار عرضه شود، مثلا کرنل آن از ۴.۱۵ به ۵.۱ به‌روزرساني نخواهد شد. درنتيجه نسخه‌هاي کرنل تغيير نمي‌کنند، اما با استفاده از LTS مي‌توان توليدکننده‌ها را به دريافت به‌روزرساني‌هاي LTS تشويق کرد. ما براي چنين به‌روزرساني‌هايي بسيار تلاش مي‌کنيم. با توجه به صحبت‌هاي مالکو، به‌نظر مي‌رسد به‌روزرساني‌هاي LTS جزئي در برخي گوشي‌ها انجام مي‌شود. به‌عنوان مثال Pixel 3 XL با کرنل ۴.۹.۹۶ عرضه شد و اکنون در اندرويد Q بتا نسخه‌ي ۴.۹.۱۶۵ دارد. مصاحبه‌‌ي بالا بررسي تقريبا تخصصي بود که با مهندسان ارشد اندرويد در گوگل انجام شد تا جزئياتي هرچه بيشتر از تغييرات مهم اين اکوسيستم روشن شود. قطعا مفاهيم تخصصي موجود در اين مصاحبه براي کاربران عادي جذاب نخواهد بود.

در کانال تلگرامي آي‌تي يا همان ← ™CanaleIT هم اخبار فناوري دسته اول و جذاب داريم