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

اندرويد Q مركز توجه اخبار گوگل در كنفرانس Google I/O بود و مانند هميشه توجه متخصصان و متخصص كارشناسان را به عضو بعدي خانواده‌ي اندرويد جلب كرد. آرس‌تكنيكا به رسم رويدادهاي قبلي گوگل مصاحبه‌اي با مهندسان داخلي اندرويد داشت تا اطلاعاتي دقيق‌تر از نسخه‌ي بعدي اين سيستم‌عامل كسب كند. مصاحبه علاوه بر پرداختن به اندرويد Q، پروژه‌ي مهندسي بزرگ‌‌تر گوگل موسوم به Project Mainline را هم پوشش مي‌دهد. هدف اصلي مين‌لاين، ايجاد امكان به‌رورزساني بخش‌هاي اصلي سيستم‌عامل بدون به‌روزرساني كلي براي گوگل و حتي توليدكننده‌هاي ديگر موبايل هوشمند است. با نگاهي اوليه به توضيح پروژه‌ي مذكور، متوجه اهميت متخصص و خبري آن مي‌شويم.

در مصاحبه‌ي امسال آرس‌تكنيكا پيرامون سيستم‌عامل اندرويد، انوار گولوم (Anwar Ghuloum) هم حضور داشت كه مدير ارشد مهندسي اندرويد و همچنين مدير پروژه‌ي مين‌لاين است. مين‌لاين در كنفرانس امسال به‌عنوان «پروژه‌ي بزرگ بعدي در به‌روزرساني اندرويد» مطرح شد و به‌نوعي مهم‌ترين خبر رويداد بود.

در ادامه‌ي اين مقاله‌ به مصاحبه‌ي آرس‌تكنيكا با مهندسان و مديران ارشد گوگل پيرامون سيستم‌عامل جديد و پروژه‌ي مين‌لاين مي‌پردازيم. پيش از ورود به مصاحبه،‌ ابتدا تاريخچه‌اي از Mainline را مطالعه مي‌كنيم.

پروژه‌ي Mainline، تغيير مسيري اساسي در توسعه‌ي اندرويد

گوگل از سال‌ها پيش قصد داشت تا اندرويد را به سيستم‌عاملي تبديل كند كه قابليت به‌روزرساني بخش‌به‌بخش داشته باشد. در سال‌هاي ابتدايي عمر اندرويد، اپليكيشن‌هاي اختصاصي گوگل و اپليكيشن‌هاي سيستمي در اپ‌استور اندرويد منتشر مي‌شدند. درنتيجه گوگل مي‌توانست قابليت‌هاي متعدد را هر زمان كه تمايل داشت، ارائه دهد. سپس Google Play Services از راه رسيد كه بسياري از APIهاي توسعه‌اي را به اپ استور اندرويد فرستاد. از آن زمان، به‌روزرساني‌هاي مرتبط با توسعه‌دهنده‌ها در API توسط گوگل ارائه مي‌شدند. در اندرويد ۸، شاهد معرفي Project Treble بوديم كه سيستم‌عامل را از همراهي سخت‌افزاري جدا كرد. درنتيجه گوگل يك قدم به توسعه‌ي آسان‌تر به‌روزرساني‌ها نزديك‌تر شد.

بزرگ‌ترين راهكار گوگل براي ماژولار كردن اندرويد در اندرويد Q و به‌نام مين‌لاين مطرح شد. در پروژه‌ي جديد رويكردي مشابه روزهاي ابتدايي اندرويد پيش گرفته مي‌شود و اين بار، قطعات هسته‌اي سيستم‌عامل به پلي‌استور مي‌روند. درواقع مين‌لاين از لايه‌هاي سطحي اپليكيشن عميق‌تر مي‌رود و قطعاتي مرتبط‌تر با كارايي سيستم همچون فريمورك‌هاي رسانه‌اي و ART به‌صورت جداگانه به‌روزرساني مي‌شوند.

گوگل براي ماژولار كردن قطعات سيستمي اندرويد، به راهكاري متخصصدي‌تر از 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 شناخته مي‌شود كه در نمونه‌هاي آزمايشي اندرويد ديده شد. در تعريف ساده قابليت جديد حالت بوت دوگانه را به سيستم‌عامل مي‌دهد. متخصص با استفاده از آن مي‌تواند پس از ريبوت كردن دستگاه از يك نسخه‌ي اندرويد، وارد نسخه‌ي ديگر شود. چنين قابليتي براي توسعه‌دهنده‌ها، توليدكننده‌ها، متخصصان و ديگر افرادي كه تمايل به تغيير سريع نسخه‌ي اندرويد دارند، مفيد خواهد بود.

از زمان انتشار اندرويد ۸ يا 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 و جدا كردن سيستم‌عامل از سخت‌افزار، كرنل در بخش سخت‌افزاري مي‌ماند. در وضعيت كنوني و در نسخه‌هاي اصلي، پياده‌سازي اندرويد به‌معناي وارد كردن لينوكس در موبايل و رها كردن آن براي هميشه خواهد بود. رويكردي كه درحال‌حاضر مناسب به انديشه متخصصين نمي‌رسد.

پاتيل در ادامه‌ي صحبت‌هاي خود گفت كه Treble امكان اجراي پروژه‌ي GKI را فراهم كرد و طرح اوليه براي رابط‌هاي متخصصي مورد نياز را به گوگل داد. علاوه بر رابط‌هاي متخصصي، همكاري‌هاي بين اكوسيستمي و تست‌هاي مهم الزامي در پروژه‌ها هم نياز خواهند بود كه با اجراي Treble، دركي كلي از آن‌ها در گوگل ايجاد شد.

درباره‌ي Generic Kernel Image توضيح دهيد. آيا شما كرنلي با GSI عرضه خواهيد كرد؟ آيا مطلبي براي به‌روزرساني اخبار در اين مورد داريد؟

مالكو: ما مي‌خواهيم همه‌ي بخش‌ها را به‌گونه‌اي متخصصدي متحد كنيم. به‌علاوه مانند هميشه قصد داريم امكان شخصي‌سازي را به توليدكننده‌ها ارائه كنيم و مفهوم متن‌باز هميشه ادامه داشته باشد. هدف نهايي، در كنار هم بودن و نه شبيه بودن خواهد بود. ما از مدت‌ها پيش منابع كرنل را در سطح همان منابع به سمت يكپارچگي برده‌ايم. در مباحثه GKI ما منابع اوليه را براي توسعه و آزمايش دستگاه‌ها با كرنل‌هاي جديد ارائه مي‌كنيم. همين رويكرد در روح GSI هم وجود دارد. البته اين مفاهيم هنوز وجود ندارند و تنها در سطح مفهومي جذاب به انديشه متخصصين مي‌رسند. به‌هرحال ما بايد فعاليت‌هاي زيادي انجام دهيم تا از مناسب بودن نتيجه‌ي نهايي در اكوسيستم مطمئن شويم.

آيا هدف نهايي ايجاد يك كرنل مين‌لاين لينوكس براي موبايل است؟

مالكو: تقريبا همين برنامه را در انديشه متخصصين داريم. البته فعاليت‌هاي دشوار و گسترده‌اي نياز خواهد بود. درواقع مسئله‌اي به گستردگي اكوسيستم داريم. در نتيجه مراحل را قدم به قدم پيش مي‌بريم. ما منابع را يكپارچه كرده و به‌مرور ساير را به به‌روزرساني كرنل‌ها به آخرين LTS تشويق مي‌كنيم. درحال‌حاضر چنين رويكردي داريم و به‌نوعي مسير را براي ادامه‌ي راه هموار مي‌كنيم.

شما كرنل را در يك موبايل به‌روزرساني نمي‌كنيد. درست است؟

مالكو: بله كاملا روشن است كه وقتي يك دستگاه به بازار عرضه شود، مثلا كرنل آن از ۴.۱۵ به ۵.۱ به‌روزرساني نخواهد شد. درنتيجه نسخه‌هاي كرنل تغيير نمي‌كنند، اما با استفاده از LTS مي‌توان توليدكننده‌ها را به دريافت به‌روزرساني‌هاي LTS تشويق كرد. ما براي چنين به‌روزرساني‌هايي بسيار تلاش مي‌كنيم.

با توجه به صحبت‌هاي مالكو، به‌انديشه متخصصين مي‌رسد به‌روزرساني‌هاي LTS جزئي در برخي موبايل‌ها به‌عنوان مثال Pixel 3 XL با كرنل ۴.۹.۹۶ عرضه شد و اكنون در اندرويد Q بتا نسخه‌ي ۴.۹.۱۶۵ دارد.

مصاحبه‌‌ي بالا مطالعه تقريبا تخصصي بود كه با مهندسان ارشد اندرويد در گوگل انجام شد تا جزئياتي هرچه بيشتر از تغييرات مهم اين اكوسيستم روشن شود. قطعا مفاهيم تخصصي موجود در اين مصاحبه براي متخصصان عادي جذاب نخواهد بود.