نگاهی عمیق به اندروید 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 هم اخبار فناوری دسته اول و جذاب داریم

بيمه سامان آگهی