اندروید Q مرکز توجه اخبار گوگل در کنفرانس Google I/O بود و مانند همیشه توجه کاربران و کارشناسان را به عضو بعدی خانواده‌ی اندروید جلب کرد. آرس‌تکنیکا به رسم رویدادهای قبلی گوگل مصاحبه‌ای با مهندسان داخلی اندروید داشت تا اطلاعاتی دقیق‌تر از نسخه‌ی بعدی این سیستم‌عامل کسب کند. مصاحبه علاوه بر پرداختن به اندروید Q، پروژه‌ی مهندسی بزرگ‌‌تر گوگل موسوم به Project Mainline را هم پوشش می‌دهد. هدف اصلی مین‌لاین، ایجاد امکان به‌رورزسانی بخش‌های اصلی سیستم‌عامل بدون به‌روزرسانی کلی برای گوگل و حتی تولیدکننده‌های دیگر گوشی هوشمند است. با نگاهی اولیه به توضیح پروژه‌ی مذکور، متوجه اهمیت فنی و خبری آن می‌شویم.
دیو برک (Dave Burke) به‌عنوان معاون ارشد بخش مهندسی اندروید شناخته می‌شود. از نگاه رسانه‌ها او دانشنامه‌ای کامل از اندروید است که همیشه پاسخ‌هایی کاربردی به سؤال‌های پیرامون سیستم‌عامل موبایلی گوگل دارد. ایلیان مالکو (Iliyan Malchev) کارشناس دیگر این مصاحبه است که به‌عنوان مهندس ارشد در اندروید، مدیر Project Treble و همه‌ی بخش‌های مرتبط با هماهنگ‌سازی لینوکس فعالیت می‌کند.
در مصاحبه‌ی امسال آرس‌تکنیکا پیرامون سیستم‌عامل اندروید، انوار گولوم (Anwar Ghuloum) هم حضور داشت که مدیر ارشد مهندسی اندروید و همچنین مدیر پروژه‌ی مین‌لاین است. مین‌لاین در کنفرانس امسال به‌عنوان «پروژه‌ی بزرگ بعدی در به‌روزرسانی اندروید» مطرح شد و به‌نوعی مهم‌ترین خبر رویداد بود.
در ادامه‌ی این مقاله به مصاحبه‌ی آرس‌تکنیکا با مهندسان و مدیران ارشد گوگل پیرامون سیستم‌عامل جدید و پروژه‌ی مین‌لاین می‌پردازیم. پیش از ورود به مصاحبه، ابتدا تاریخچه‌ای از Mainline را بررسی می‌کنیم.
پروژه‌ی Mainline، تغییر مسیری اساسی در توسعه‌ی اندروید
گوگل از سال‌ها پیش قصد داشت تا اندروید را به سیستم‌عاملی تبدیل کند که قابلیت به‌روزرسانی بخش‌به‌بخش داشته باشد. در سال‌های ابتدایی عمر اندروید، اپلیکیشن‌های اختصاصی گوگل و اپلیکیشن‌های سیستمی در اپ‌استور اندروید منتشر می‌شدند. درنتیجه گوگل می‌توانست قابلیت‌های متعدد را هر زمان که تمایل داشت، ارائه دهد. سپس Google Play Services از راه رسید که بسیاری از APIهای توسعه‌ای را به اپ استور اندروید فرستاد. از آن زمان، به‌روزرسانی‌های مرتبط با توسعه‌دهنده‌ها در API توسط گوگل ارائه می‌شدند. در اندروید 8، شاهد معرفی Project Treble بودیم که سیستم‌عامل را از پشتیبانی سخت‌افزاری جدا کرد. درنتیجه گوگل یک قدم به توسعه‌ی آسانتر به‌روزرسانی‌ها نزدیک‌تر شد.
بزرگ‌ترین راهکار گوگل برای ماژولار کردن اندروید در اندروید Q و به‌نام مین‌لاین مطرح شد. در پروژه‌ی جدید رویکردی مشابه روزهای ابتدایی اندروید پیش گرفته می‌شود و این بار، قطعات هسته‌ای سیستم‌عامل به پلی‌استور می‌روند. درواقع مین‌لاین از لایه‌های سطحی اپلیکیشن عمیق‌تر می‌رود و قطعاتی مرتبط‌تر با کارایی سیستم همچون فریمورک‌های رسانه‌ای و ART به‌صورت جداگانه به‌روزرسانی می‌شوند.
پلی استور همیشه اپلیکیشن‌ها را به‌صورت پکیج‌های APK ارائه داده است. دراین‌میان برای بسیاری از قطعاتی که در پروژه‌ی مین‌لاین ماژولار می‌شوند، چنین رویکردی ممکن نخواهد بود و نمی‌توان آن‌ها را به‌صورت APK منتشر کرد. سیستم APK برای کاربردهای مبتنی بر سیستم یا سمت کاربر طراحی شد و محدودیت‌هایی در بخش‌های مرتبط با مجوزهای کاربری یا اجرا در مرحله‌ی بوت سیستم دارد.
گوگل برای ماژولار کردن قطعات سیستمی اندروید، به راهکاری کاربردی‌تر از APK به‌نام APEX رسید. فایل‌های APEX قابلیت کسب دسترسی‌های روت را دارند و در همان مراحل راه‌اندازی اولیه شروع به کار می‌کنند. درنتیجه امکان به‌روزرسانی‌های قطعات بیشتر سیستم را به گوگل یا تولیدکننده‌های دیگر می‌دهند. درنهایت نتیجه می‌گیریم که APK برای سطوح دسترسی کاربر و سیستم طراحی شد و APEX قطعات هسته‌ای‌تر سیستم را پوشش می‌دهد.
ماژول‌های پروژه‌ی مین‌لاین در آینده بخش‌های بیشتری از سیستم اندروید را اشغال خواهند کرد. گوگل اکنون و در نسخه‌های ابتدایی اندروید Q، روی سه بخش متمرکز شده است: پایداری، امنیت و حریم خصوصی. به‌هرحال با نگاهی به جدول بالا متوجه برنامههای گوگل در اولویت‌بندی ماژول‌سازی از بخش‌های متعدد اندروید می‌شویم. همین جدول اولین سؤال‌ها را پیرامون برنامه‌ی توسعه‌ی پروژه‌ی مین‌لاین ایجاد می‌کند.
در انتخاب اولویت ماژول‌های سیستمی اندروید در مین‌لاین، چه اصولی را مدنظر قرار می‌دهید؟
انوار گولوم: طرح ایده‌آل ما، الزامی بودن بخش‌بندی همه‌ی قطعات است. روش کاری ما در ماژول‌‌بندی بخش‌ها مبتنی بر همکاری با تولیدکننده‌های دستگاه بود. ما به آن‌ها اعلام کردیم که پروژه‌ای در دست توسعه داریم و درخواست همکاری دادیم. تولیدکننده‌ها برنامههای توسعه‌ای و درخواست‌های آتی خود را اعلام کردند و ما بر حسب همان نیازها، اولویت‌بندی ماژول‌ها را انجام دادیم. به‌مرور بخش‌های دیگری به ماژول‌های الزامی اضافه می‌شوند. چنین رویکردی به ما امکان می‌دهد تا به‌مرور با تولیدکننده‌ها هماهنگ شویم، ما قصد نداریم که روند توسعه در شرکت‌های تولیدکننده‌ی تجهیزات را با مشکل مواجه کنیم. رویکرد کنونی به نیروهای این شرکت‌ها امکان می‌دهد تا به‌مرور با روند به‌روزرسانی ماژولی همراه شوند.
دیو برک: من تصور می‌کنم که بخش مهمی از این پروژه، به همکاری با شرکا وابسته خواهد بود. منظور من از شرکا، تولیدکننده‌ها هستند. آن‌ها تغییراتی را در دستگاه‌های محصول خود ایجاد می‌کنند و ما قصد داریم تغییرات را به‌مرور با رویکرد مین‌لاین هماهنگ کنیم. چنین روندی درنهایت به ثبات می‌رسد، اما قطعا به کمی زمان نیاز دارد.
گولوم: قطعا برای هماهنگی بیشتر به ارائهی قابلیت‌های بیشتر نیاز داریم. روندی که ما در سال گذشته با ارائه‌های متعدد پیش گرفتیم و در سال گذشته، بیش از 10 سال قبل انتقال داده و قابلیت داشتیم.
با بررسی بخشی از پاسخ‌های مهندسان گوگل و برنامه‌ی شرکت در پروژه‌ی مین‌لاین این تصور ایجاد می‌شود که گوگل در پی کسب مجدد مالکیت برخی از کدهای هسته‌ای سیستم از تولیدکننده‌ها است. در صورت صحیح بودن این تصور، گوگل تصمیم دارد تا همه‌ی شخصی‌سازی‌هایی که قبلا توسط تولیدکننده‌ها به سیستم اضافه می‌شد، به بخش اصلی کدهای اوپن‌منبع اندروید اضافه شود تا همه از آن‌ها استفاده کنند.
برای تصور بهتر برنامه‌ی گوگل در اولویت‌بندی ماژول‌ها تصور کنید که غول موتور جست‌وجو از تمامی اعضای اکوسیستم اندروید چنین سوالی را بپرسد: «آیا قصد دارید نحوه‌ی کار بخش DNS را شخصی‌سازی کنید؟». اگر پاسخ منفی باشد، نسخه‌ی گوگل در آن بخش سیستمی به‌عنوان نسخه‌ی الزامی شناخته می‌شود. در صورت ارائهی پاسخ مثبت از سوی تولیدکننده‌ها (یعنی نیاز به شخصی‌سازی بخشی خاص در سیستم‌عامل)، همه‌ی تغییرات تولیدکننده به مرکز پروژه‌ی اوپن منبع اندروید (AOSP) ارائه می‌شوند و درنهایت با هماهنگی با تغییرات دیگر، به نسخه‌ی گوگل تبدیل خواهند شد. پاسخ نهایی گولوم یعنی ارائهی به‌روزرسانی‌های متعدد و شخصی‌سازی در یک سال گذشته، نشان از رویکرد رو به جلوی گوگل دارد. درنهایت کدهای بیشتری به AOSP ارسال می‌شوند و به‌مرور کار تولیدکننده‌ها در به‌روزرسانی‌های سیستمی کمتر می‌شود.
گولوم: ما به تیم‌های خود توضیح دادیم که با استفاده از ماژول‌های مین‌لاین، به‌روزرسانی‌ها تنها ماهی یک بار باید انجام شوند. به‌علاوه آن‌ها همکاری بیشتری با شرکت خواهند داشت. درنتیجه توسعه‌ی کدها، برنامه‌ریزی و بسیاری بخش‌های دیگر با همکاری انجام خواهد شد. افراد حاضر در تیم‌های گوگل از شنیدن این برنامه بسیار خشنود شدند.
آیا می‌توانیم انتشار به‌روزرسانی یک بار در ماه را به‌عنوان برنامه‌ی اصلی مین‌لاین در نظر بگیریم؟
گولوم: چنین رویکردی با روندهای قبلی ما هماهنگ خواهد بود و زمان‌بندی به‌روزرسانی امنیتی نیز همین‌گونه است. برخی از قطعات ماژولی مین‌لاین نیز در دسته‌بندی امنیت قرار می‌گیرند. بخش رسانه‌ای نیز شامل کدک‌های اساسی و بخش‌های اجرایی متعدد می‌شود. ما در ماژول‌سازی این بخش نگاهی به آسیب‌پذیری‌های رایج سال گذشته داشتیم و نزدیک به 40 درصد از آسیب‌پذیری وصله‌های امنیتی در بخش رسانه‌ای دیده می‌شدند. درنهایت نتیجه گرفتیم که بار به‌روزرسانی‌ها را از دوش تولیدکننده‌ها برداریم.
در توضیح پاسخ گولوم باید بدانید که موتور پخش رسانه‌ای اندروید وظیفه‌ی بارگذاری همه‌ی فایل‌های خطرناک از سرتاسر وب را بر عهده دارد و امنیت در چنین رویکردی همیشه یک چالش مهم در اکوسیستم بوده است. موتور پخش رسانه‌ای اندروید به‌نام Stagefright شناخته می‌شود و در سال 2015 اخبار مهمی را از آسیب‌پذیری‌های اجرای کد مخرب از راه دور به خود اختصاص داد. به‌روزرسانی‌های ماهیانه‌ی بخش امنیتی از همان زمان شروع شدند.
گوگل درحال‌حاضر به‌روزرسانی‌های امنیتی را هر ماه در AOSP ارائه می‌کند و آن‌ها را به تولیدکننده‌ها می‌دهد. این رویکرد هنوز عالی به نظر نمی‌رسد و همه‌ی گوشی‌ها، از به‌روزرسانی‌های ماهیانه پشتیبانی نمی‌کنند. درنتیجه همه‌ی گوشی‌های اندرویدی به‌روزرسانی‌های امنیتی را ماهی یک بار دریافت نمی‌کنند. پاسخ گولوم نشان می‌دهد که گوگل رویکرد بررسی به‌روزرسانی‌ها را بر عهده می‌گیرد و ارائهی آن‌ها را نیز خودش به‌صورت منظم به کل اکوسیستم انجام می‌دهد.
برک: مسئله‌ی مهم دیگر، آسان‌سازی فعالیت توسعه‌دهنده‌ها در اکوسیستم اندروید خواهد بود. یکی از چالش‌هایی که عموما در رویکرد توسعه‌دهنده‌ها دیده می‌شود، رفتارها و رویکردهای متنوع در بخش‌های گوناگون سیستم‌عامل است. درواقع حتی در محصولات یک تولیدکننده‌هم بعضا عملکردهای متنوع بخش‌ها دیده می‌شود. فریم‌ورک رسانه‌ای یکی از مهم‌ترین بخش‌هایی بود که در نگرانی توسعه‌دهنده‌ها دیدیم. درنهایت پایداری بیشتر بین نسخه‌های متعدد سیستم‌عامل برای توسعه‌دهنده‌ها هم بهتر خواهد بود. چنین رویکردی منجر به کاهش خطاها می‌شود و مسئولیت آن‌ها نیز کاهش خواهد یافت. درنهایت اپلیکیشن‌های باکیفیت‌تری می‌بینیم که به‌نفع کاربران هم خواهد بود.
گولوم: من در سخنرانی از اصطلاح «ثبات باگ» برای این رویکرد استفاده کردم (برک تأیید می‌کند). ماژولی به‌نام ANGLE در برنامه‌ها وجود دارد که یک OpenGL پیاده‌سازی شده در Vulcan است. درحال‌حاضر این ماژول جزو دسته‌ی بخش‌های الزامی برای سازنده‌ها قرار می‌گیرد، اما توسعه‌دهنده‌ها الزامی به استفاده از آن ندارند. ما قصد داریم تا به روندی هماهنگ در ارائهی چنین بخش‌هایی دست یابیم. قطعا درنهایت ادعای انتشار نرم‌افزار بدون باگ نداریم (چون هیچ‌نر‌م‌افزاری بدون باگ نیست)، اما به‌هرحال کاهش درگیری‌های متنوع و متفاوت توسعه‌دهنده‌ها با نسخه‌های گوناگون سیستم‌عامل منجر به آسانتر شدن فعالیت آن‌ها می‌شود.
برک: جنبه‌ای دیگر از فرایندهای فوق نشان می‌دهد که هماهنگی بیشتری با آن‌ها رخ خواهد داد. به‌عنوان مثال به چالش‌های پیش‌آمده برای سیستم GPS در ماه آوریل دقت کنید. هواپیماهای متعددی به‌خاطر نا‌هماهنگی با تغییرات جدید دچار چالش شدند. درواقع مشکلات نرم‌افزاری همیشه وجود دارند و همه به‌دنبال راهی برای حل کردن سریع‌تر آن‌ها هستند. خصوصا در مواردی همچون کتابخانهی ما، Conscript یا کتابخانهی SSL و TLS، به‌روزرسانی و رفع مشکلات در اولویت بالایی قرار دارد. چنین مواردی با به‌روزرسانی حل می‌شوند. خصوصا در مواقعی که مجوز نرم‌افزاری باطل شود یا ارائه‌کننده‌ی مجوز به فعالیت‌های خود خاتمه دهد، به‌روزرسانی‌های هماهنگ کارگشا خواهد بود.
منبع: https://www.zoomit.ir/2019/7/12/337835/android-qa-android-engineers-deep-dive-android-q/
