Flutter, Fuchsia, Zircon, ChromeOS, Aluminium OS, WGPU, Tensor Modem, RIL, SeL4, FIDL будущее Андроида и других ОС №2 / Хабр

Это более глубокое продолжение к этой статье и раскрытие вопросов в комментариях к ней.

В конце 2025 года техноблоги взорвались инсайдами: Google планирует выпустить премиальный ноутбук под брендом Pixel. Но работать он будет не на ChromeOS, как привычные «Хромбуки», и не на Windows.

Кодовое имя инициативы — Aluminium. Что попалось сразу. Новость не обошла стороной и хабр.

Суть проекта как обычно для Google проста и жестока: ChromeOS как отдельная операционная система должна умереть. Будущее — это Android, который научился быть десктопом.

Но прежде чем говорить об Aluminium, нужно понять, почему Flutter стал критичным для всей стратегии Google. И здесь начинается история о том, как устаревший C API чуть не убил будущее кроссплатформенной разработки.

1. Flutter, OpenGL и 50 лет технического долга

Когда разработчики жалуются на "джанк" (подтормаживание) в Flutter-приложениях, они обычно винят Dart или "лишние слои абстракции". Реальная причина лежала глубже — в самом сердце графического стека.

Проблема OpenGL: C ABI из 1992 года

OpenGL создавался в эпоху, когда процессоры были однопоточными, память была драгоценной, а GPU не существовало в современном понимании.

Его архитектура основана на глобальном состоянии (state machine). Вы вызываете функцию glBindTexture(), и она меняет глобальное состояние всего контекста. Это как если бы в Dart каждый раз при создании объекта менялась какая-то глобальная переменная, которую видят все потоки.

Почему это убивает современные приложения?

Один контекст ��авно один поток. Flutter рендерит UI в отдельном потоке (raster thread). Если вы хотите загрузить текстуру асинхронно, вам нужен второй OpenGL контекст. Sharing contexts между потоками — это минное поле из race conditions.

C ABI означает отсутствие type safety. Вызов glUniform4f(location, r, g, b, a) — если перепутал порядок аргументов, получаешь random pixels. Компилятор не поможет, потому что все аргументы имеют тип float. В Rust или Dart это была бы ошибка компиляции.

Immediate mode — это производительность 2005 года. Каждый вызов glDrawArrays() — это синхронный вызов драйвера. CPU ждет GPU. GPU ждет CPU. На современных чипах (Apple Silicon, Snapdragon) это катастрофа.

Почему Skia не спасал ситуацию

Skia (графическая библиотека, которую использовал Flutter до Impeller) абстрагировал OpenGL, но не решал фундаментальную проблему.

Скрытая правда: когда вы запускали Flutter-приложение первый раз, оно "тормозило" на первой анимации. Это называется "shader compilation jank".

Что происходило под капотом:

Flutter отрисовывает виджет
Skia генерирует OpenGL shader на лету
Драйвер компилирует shader — это занимает 16-50 миллисекунд
Пользователь видит "заикание"

Это невозможно исправить в OpenGL, потому что спецификация не позволяет прекомпилировать шейдеры заранее. Вернее, технически можно (через расширения типа GL_ARB_get_program_binary), но реализация зависит от вендора драйвера. На Android это работает на Samsung, не работает на Xiaomi, иногда работает на Google Pixel — в зависимости от фазы Луны.

C ABI как непреодолимая стена

Dart FFI (Foreign Function Interface) позволяет вызывать C-функции из Dart. На первый взгляд, это решает проблему. Но есть нюанс.

C не знает о Dart-объектах. Dart не знает о memory layout в C. Когда вы передаете данные через FFI, происходит копирование. Для текстуры 4K (3840×2160 пикселей, RGBA) это 33 мегабайта данных. Копирование такого объема каждый кадр (60 FPS) убьет производительность любого устройства.

Можно использовать указатели и работать с сырой памятью напрямую (Pointer<Uint8> в Dart). Но теперь вы теряете все преимущества garbage collector. Вы вручную управляете malloc/free. Одна ошибка — и получаете segmentation fault, который крэшит приложение без stack trace.

Это не баг — это фундаментальное ограничение любого языка с управляемой памятью, который пытается взаимодействовать с C API.

Решение: Metal, Vulkan и смерть C API

Google приняла радикальное решение: написать новый рендерер Flutter с нуля.

Impeller (замена Skia) построен на трех принципах:

Никакого OpenGL. Только Metal (iOS/macOS), Vulkan (Android/Linux/Fuchsia), DirectX (Windows).
Shader precompilation. Все шейдеры компилируются на этапе сборки приложения (flutter build), а не в рантайме. Это физически невозможно в OpenGL, но естественно в современных API.
Command buffers вместо immediate mode. Вместо синхронных вызовов используются асинхронные очереди команд для GPU. CPU формирует буфер команд ("нарисуй треугольник, примени текстуру, выполни blend"), отправляет его GPU и идет заниматься своими делами. GPU выполняет команды параллельно.

Результат измерим в цифрах. В старом Flutter на Skia первый запуск анимации на Pixel 6 занимал 47 миллисекунд (shader compilation). На том же устройстве с Impeller — 2 миллисекунды. Разница в 23 раза.

Почему именно WGPU

При разработке Impeller команда Flutter приняла прагматичное решение. Вместо того чтобы тянуть в мобильные приложения лишние слои абстракции, они написали нативные бэкенды на C++:

Для iOS/macOS: прямые вызовы Metal.
Для Android/Fuchsia: прямые вызовы Vulkan.

Однако, для веб-версии (Flutter Web) был выбран именно WGPU (через WebAssembly). Почему это важно?

Потому что архитектурно Impeller и WGPU — близнецы-братья. Они оба реализуют концепцию Modern Graphics API:

Отсутствие глобального состояния (Stateless).
Использование Command Buffers (асинхронная отправка команд).
Предварительная компиляция шейдеров (Pipeline State Objects).

Это создает уникальную ситуацию конвергенции. На мобильных устройствах Impeller работает "на железе" через C++, а в браузере тот же Flutter использует WGPU, обеспечивая идентичное поведение рендеринга. Google не просто "чинит баги", а переводит весь свой стек (от Android до Chrome) на единую философию работы с GPU, где нет места устаревшему OpenGL.

2. Tensor Modem: Почему "Fuchsia Phone" всё ещё невозможен

В комментариях к первой статье справедливо заметили: "Google делает свои процессоры Tensor, они способны и свой модем сделать, как Apple с чипом C1".

Это логично звучит, но реальность сложнее. Намного сложнее.

История провала Apple и урок для Google

В 2019 году Apple купила модемный бизнес Intel за 1 миллиард долларов. Вместе с патентами пришла команда из 2200 инженеров. Казалось бы, проблема решена — теперь Apple независима от Qualcomm.

Первый собственный модем Apple (кодовое имя Sinope, позднее переименован в C1) должен был появиться в iPhone 2023 года. Релиз сдвинули на 2024. Потом на 2025. Сейчас в iPhone 16 всё ещё стоит модем Qualcomm Snapdragon X75.

Что пошло не так?

Модем — это не просто чип. Это результат 30 лет эволюции стандартов мобильной связи, каждый из которых наслаивается на предыдущий. LTE (4G) состоит из Release 8, 9, 10, 11, 12, 13, 14, 15. Каждый релиз добавляет фичи: carrier aggregation, MIMO, VoLTE, eMBMS.

5G добавляет ещё два стандарта: Sub-6 GHz (обычный 5G) и mmWave (миллиметровые волны для сверхвысоких скоростей на коротких дистанциях). У каждого — свой PHY layer, свой MAC protocol, своя система управления мощностью.

Даже имея исходники от Intel (которые, кстати, работали нестабильно, поэтому Intel продал этот бизнес), Apple потратила 6 лет и всё ещё не может выпустить модем, который не уступает Qualcomm по энергоэффективности.

Почему? Потому что основная сложность — не в написании кода. Сложность в сертификации.

3GPP: Бюрократия как непреодолимый барьер

3GPP (3rd Generation Partnership Project) — это консорциум, который разрабатывает стандарты мобильной связи. В него входят операторы (Verizon, AT&T, China Mobile), производители оборудования (Ericsson, Nokia, Huawei) и производители чипов (Qualcomm, MediaTek, Samsung).

Каждый стандарт описан в тысячах страниц технических спецификаций. Например, спецификация 5G NR (New Radio) состоит из 38 томов, каждый по 200-500 страниц.

Чтобы модем получил сертификацию, он должен пройти Interoperability Testing (IOT). Это означает, что ваш модем должен соединиться с базовыми станциями от всех основных вендоров (Ericsson, Nokia, Samsung, Huawei, ZTE) и отработать тысячи сценариев:

Handover между вышками разных поколений (переход из зоны 5G в зону LTE).
Carrier Aggregation (объединение нескольких частотных каналов для увеличения скорости).
VoLTE (голосовые звонки через LTE, а не через устаревший 3G).
Emergency Calls (звонки в службы спасения должны работать даже при нулевом балансе и слабом сигнале).

Тестирование проходит в лабораториях операторов. Вы приезжаете со своим модемом, подключаетесь к их оборудованию и запускаете тесты. Если хотя бы один сценарий падает, вы едете обратно, фиксите баг, пересобираете прошивку и приезжаете снова.

Qualcomm делает это 20 лет. У них есть лаборатория в Сан-Диего с эмуляторами базовых станций всех операторов мира. Когда выходит новый релиз 3GPP, Qualcomm начинает тестирование за полгода до официального утверждения стандарта, потому что у них есть инсайдеры в комитетах.

Apple и Google такой лаборатории нет. Они могут построить её (это много долларов), но на это уйдет 5-7 лет.

Патентное минное поле

Технологии мобильной связи покрыты патентами. Qualcomm владеет примерно 130 тысячами патентов, связанных с 3G/4G/5G. Nokia, Ericsson и Huawei — ещё по 50-80 тысяч каждый.

Эти патенты покрывают не только железо, но и алгоритмы:

Как модулировать сигнал для передачи данных (OFDM, QAM).
Как кодировать данные для исправления ошибок (Turbo Codes, LDPC).
Как переключаться между частотными каналами без потери соединения.

Формально патенты на стандарты 3GPP должны лицензироваться на условиях FRAND (Fair, Reasonable, And Non-Discriminatory). Это означает, что Qualcomm обязана продать вам лицензию "на разумных условиях".

Реальность: "разумные условия" — это 5-7% от стоимости устройства. Если ваш смартфон стоит 1000 долларов, вы платите Qualcomm 50-70 долларов. Это не за чип (чип стоит отдельно), это licensing fee за использование патентов.

Apple годами судилась с Qualcomm, отказываясь платить эти деньги. В 2019 году они заключили мировое соглашение: Apple платит Qualcomm разовый платеж в 4.5 миллиарда долларов плюс роялти за каждый проданный iPhone до тех пор, пока не выпустит собственный модем.

Google оказалась в такой же ситуации. Даже если они разработают свой модем Tensor, им всё равно придется платить Qualcomm, Nokia и Ericsson за патенты. Экономическая выгода собственного модема сомнительна, если вы всё равно отдаете половину прибыли конкурентам.

Почему модем нельзя запустить через Starnix

Теоретически, можно взять готовый Linux-драйвер модема от Qualcomm и запустить его на Fuchsia через Starnix. Ведь Starnix эмулирует системные вызовы Linux?

Проблема в том, что драйвер модема — это не обычный драйвер.

Обычный драйвер (например, драйвер Wi-Fi) общается с ядром через стандартные интерфейсы: открыть файл устройства (/dev/wlan0), записать данные, прочитать ответ. Starnix умеет эмулировать эти вызовы.

Драйвер модема работает иначе. Он напрямую обращается к hardware-регистрам чипа через memory-mapped I/O (MMIO). Это означает, что драйвер пишет данные по физическому адресу памяти, который соответствует регистру модема.

В Linux это разрешено (драйвер работает в Ring 0, ядро доверяет ему). В Fuchsia это запрещено архитектурно. Zircon не позволяет userspace-процессу (а Starnix — это userspace-процесс) напрямую писать в физическую память.

Можно сделать исключение: дать Starnix-у доступ к MMIO через специальный syscall Zircon. Но это ломает всю модель безопасности. Если Starnix имеет прямой доступ к железу, он может записать что угодно куда угодно. Один баг — и вы получаете kernel panic, от которого Fuchsia должна была вас защитить.

Именно поэтому Google сначала выпустила Fuchsia на устройствах без модема (Nest Hub). Wi-Fi и Bluetooth можно эмулировать. Сотовый модем — нет.

Стратегия Google: Tensor Modem на 2027 год

Google не отказалась от идеи собственного модема. Но подход другой, чем у Apple.

В 2023 году стало известно, что Google наняла команду инженеров из Samsung Shannon (модемное подразделение Samsung). Shannon — один из трех крупных игроков на рынке модемов (после Qualcomm и MediaTek).

План Google:

Использовать наработки Samsung Shannon как основу.
Интегрировать модем в чип Tensor напрямую (а не отдельным чипом, как у Qualcomm).
Написать нативный драйвер для Zircon, а не полагаться на Starnix.

Прогноз: первый Tensor с интегрированным модемом появится в Pixel 12 (ориентировочно 2027 год). Но это будет LTE-модем, а не 5G. Причина — сертификация 5G занимает годы, а Google не может ждать.

Интересная деталь: Tensor Modem будет поддерживать dual-boot. Одна и та же железка сможет работать и под Android (через Linux-драйвер), и под Fuchsia (через нативный Zircon-драйвер). Это позволит Google протестировать Fuchsia на реальных устройствах без риска лишить пользователей сотовой связи.

RIL: Radio Interface Layer как точка интеграции

Даже когда модем заработает на Zircon, останется проблема RIL (Radio Interface Layer).

RIL — это программный слой между операционной системой и модемом. Он отвечает за:

Управление соединением (набор номера, завершение звонка, отправка SMS).
Переключение между режимами (2G/3G/4G/5G).
Управление SIM-картой (аутентификация, хранение контактов).

В Android RIL — это отдельный процесс (rild), который общается с модемом через AT-команды (текстовые команды типа "AT+CPIN?" для проверки PIN-кода SIM-карты). Это legacy от времен dial-up модемов.

Современные модемы (Qualcomm, Samsung) используют бинарные протоколы (QMI для Qualcomm, Shannon IPC для Samsung). Эти протоколы закрыты. Спецификации доступны только партнерам под NDA.

Google пришлось reverse-engineer протокол QMI для своих Pixel-телефонов. Команда потратила два года, чтобы разобрать прошивку модема Qualcomm и понять, как работает протокол.

Для Fuchsia Google пишет новый RIL с нуля. Он использует FIDL (Fuchsia Interface Definition Language) для общения между компонентами. Это означает, что модем, RIL и telephony service могут работать в разных процессах, на разных CPU-ядрах, и даже на разных виртуальных машинах (через Microfuchsia).

Преимущество: если RIL крэшится (а он крэшится часто, потому что работает с вендорским closed-source кодом), система просто перезапускает его. Звонок прервется, но телефон не уйдет в reboot. В Android крэш RIL часто приводит к kernel panic, потому что RIL имеет привилегированный доступ к ядру.

Почему Qualcomm не торопится портировать драйвера

Вы можете спросить: почему Qualcomm сама не напишет драйвер для Zircon? Ведь они заинтересованы продавать чипы для Fuchsia-устройств?

Ответ циничный: Qualcomm не заинтересована.

Модемный бизнес Qualcomm приносит прибыль не от продажи чипов, а от licensing fees. Они зарабатывают проценты от каждого проданного смартфона. Чем дольше производители зависят от Qualcomm, тем дольше они платят.

Если Google выпустит Fuchsia с собственным модемом, это создаст прецедент. Другие производители (Samsung, Xiaomi, Oppo) захотят то же самое. Это угроза для бизнес-модели Qualcomm.

Поэтому Qualcomm публично заявляет "мы открыты к сотрудничеству", но на практике тормозит. Драйвера для новых модемов выходят с задержкой. Документация публикуется выборочно. Это стандартная тактика в индустрии.

Google это понимает. Именно поэтому они инвестируют в собственный модем, даже зная, что это займет 5-7 лет и миллиарды долларов.

Сценарий для раннего запуска: eSIM-only устройства

Есть лазейка, которая позволит выпустить "Fuchsia Phone" раньше 2027 года.

eSIM (embedded SIM) — это виртуальная SIM-карта, которая программируется через интернет. Вам не нужна физическая карточка. Вы скачиваете профиль оператора и активируете его.

Проблема в том, что eSIM требует подключения к интернету для активации. Но если устройство поддерживает только Wi-Fi (или запускается первый раз в зоне Wi-Fi), это решаемо.

Google экспериментирует с концептом Fuchsia Developer Phone — устройство для разработчиков, которое работает исключительно через Wi-Fi и eSIM. Вы покупаете его, подключаете к Wi-Fi дома, активируете eSIM вашего оператора, и после этого модем начинает работать.

Такое устройство можно выпустить уже в 2026 году, потому что:

Wi-Fi-драйвер для Zircon существует (Broadcom и Intel портировали свои драйвера).
eSIM не требует сложного RIL (профиль загружается через HTTPS, а не через AT-команды).
Голосовые звонки можно делать через VoIP (Google Voice, WhatsApp), а не через традиционный GSM.

Это не массовый продукт, но это способ прощупать рынок и дать сообществу разработчиков возможность портировать приложения на Fuchsia до официального релиза.

3. Aluminium OS: Техническая анатомия убийства ChromeOS

Давайте разберем, как Google технически реализует слияние ChromeOS и Android, и почему это не просто "запустить Android на ноутбуке".

Ferrochrome: Операция по замене фундамента

Чтобы понять Aluminium, нужно вспомнить архитектуру ChromeOS.

ChromeOS — это дистрибутив Linux, основанный на Gentoo. Загружается ядро Linux, запускается init-система (upstart, позднее systemd), затем стартует Chrome browser в режиме kiosk. Браузер занимает весь экран и становится "операционной системой".

Под капотом у вас полноценный Linux со всеми утилитами: bash, tar, gzip, systemd. Файловая система — ext4. Сетевой стек — стандартный Linux TCP/IP.

Android — это тоже Linux, но радикально модифицированный. Ядро форкнуто от mainline Linux (Android Common Kernel), init-система заменена на собственную (init.rc скрипты), нет GNU-утилит (вместо bash — toybox, вместо glibc — bionic).

Project Ferrochrome — это кодовое имя операции по замене ядра ChromeOS на Android Common Kernel (ACK). Это не просто "пересобрать дистрибутив". Это переписывание низкоуровневых компонентов.

Что меняется:

Ядро: Linux из ChromeOS (обычно upstream kernel + patches от Google) заменяется на Android Common Kernel. ACK отличается подсистемами управления памятью (ION/dmabuf), планировщиком (EAS — Energy Aware Scheduler) и графическим стеком (вместо DRM/KMS используется SurfaceFlinger).
Init-система: systemd заменяется на Android init. Это означает, что все сервисы (сеть, Bluetooth, звук) запускаются через .rc-файлы в стиле Android, а не через systemd units.
Libc: glibc заменяется на bionic. Это критично, потому что bionic не совместима с glibc на уровне ABI. Программы, скомпилированные под glibc (то есть, практически весь Linux-софт), не запустятся на bionic.
Графический стек: X11/Wayland заменяется на SurfaceFlinger (композитор Android). Все окна — это Android Surfaces, управляемые Window Manager из Android.

Последний пункт самый болезненный. ChromeOS использовала Wayland (современный протокол для отрисовки окон в Linux). SurfaceFlinger работает совершенно иначе.

SurfaceFlinger: Как Android рисует окна

SurfaceFlinger — это системный сервис в Android, который отвечает за композицию (наложение) окон на экран.

Каждое приложение рисует свой контент в буфер памяти (GraphicBuffer). Этот буфер передается SurfaceFlinger через Binder IPC (межпроцессное взаимодействие в Android). SurfaceFlinger берет все буфера от всех приложений, накладывает их друг на друга (с учетом прозрачности, теней, анимаций) и отправляет финальный кадр на дисплей через Hardware Composer (HAL для работы с железом дисплея).

В ChromeOS/Linux это работает иначе. Приложение отрисовывает себя через OpenGL/Vulkan в свой собственный framebuffer. Compositor (Wayland-сервер, например Mutter или KWin) берет эти framebuffers, применяет эффекты и композирует на экран.

Разница критична: в Android приложение НЕ имеет прямого доступа к GPU. Оно рисует в CPU-память, и SurfaceFlinger решает, когда и как отправить это на GPU. В Linux приложение может напрямую дергать GPU через Vulkan/OpenGL.

Почему Android использует такую архитектуру? Энергоэффективность. На мобильном устройстве батарея ограничена. Если каждое приложение будет будить GPU, батарея сядет за пару часов. SurfaceFlinger батчит (группирует) запросы: собирает изменения от всех приложений, и обновляет экран один раз за frame (16.6ms для 60Hz дисплея).

Проблема для десктопа: латентность. В Linux, когда вы двигаете мышку, курсор обновляется моментально (GPU рисует новый кадр). В Android SurfaceFlinger ждет следующего vsync (вертикальной синхронизации дисплея). Это добавляет задержку 8-16ms. Для смартфона незаметно. Для десктопа — ощутимо.

Desktop Windowing: Android учится работать с окнами

Android изначально проектировался для полноэкранных приложений. Концепция "окна" появилась только в Android 7 (2016 год) в виде Multi-Window Mode (разделенный экран).

Но это не полноценные окна. Вы не можете изменить размер окна произвольно. Вы не можете перетащить окно в другое место экрана. Вы не можете свернуть окно в панель задач.

В Android 12L (2022 год, специальная версия для планшетов и складных устройств) появился Freeform Window Mode. Это режим, где приложения могут открываться в плавающих окнах.

Проблема: это был экспериментальный режим, скрытый за флагом разработчика. Большинство приложений не были готовы к такому режиму. UI ломался, кнопки вылезали за границы экрана, прокрутка работала некорректно.

Для Aluminium Google переписала Window Manager с нуля. Начиная с Android 15 QPR (Quarterly Platform Release) и Android 16, появился полноценный десктопный режим.

Что изменилось:

Окна имеют заголовок (title bar) с кнопками "свернуть", "развернуть", "закрыть" — как в Windows или macOS.
Окна можно перетаскивать мышкой за заголовок.
Окна можно растягивать за края и углы. При этом приложение получает callback onConfigurationChanged() и должно пересчитать layout.
Появилась панель задач (Taskbar), которая показывает запущенные приложения. Панель всегда видна (не скрывается, как на планшетах).
Реализовано Alt+Tab для переключения между окнами.

Но это только верхушка айсберга. Настоящая проблема — в приложениях.

Проблема legacy-приложений: Fixed Layout vs Responsive Layout

Миллионы Android-приложений написаны в предположении, что экран вертикальный и имеет фиксированный размер (например, 1080x2400 пикселей для типичного смартфона).

Разработчики использовали абсолютные координаты (setX(100), setY(200)) вместо адаптивных layout (ConstraintLayout, LinearLayout). Такие приложения просто ломаются, когда их запускают в окне произвольного размера.

Google решила эту проблему через Compatibility Mode. Если приложение не поддерживает resize (изменение размера), Android открывает его в фиксированном окне (например, 1080x2400) и добавляет черные полосы по краям, как при запуске старой игры на современном мониторе.

Приложения, которые правильно используют адаптивные layout, получают атрибут resizeableActivity="true" в AndroidManifest.xml. Такие приложения могут растягиваться на весь экран ноутбука.

Интересный факт: Flutter-приложения поддерживают resize из коробки. Когда размер окна меняется, Flutter Engine вызывает onMetricsChanged(), и все виджеты автоматически перес��итывают свои размеры (благодаря Flex layout). Это одна из причин, почему Google делает ставку на Flutter для Aluminium.

Проблема ввода: Мышь, клавиатура и тачпад

Android был создан для сенсорных экранов. События тачскрина (MotionEvent) отличаются от событий мыши.

На тачскрине нет концепции "наведение курсора" (hover). Вы либо касаетесь экрана (ACTION_DOWN), либо не касаетесь. На десктопе вы можете навести курсор на кнопку, не нажимая её, и кнопка должна подсветиться (hover effect).

В Android 15/16 добавили полноценную поддержку hover events. Теперь приложения получают ACTION_HOVER_ENTER и ACTION_HOVER_EXIT. Проблема — старые приложения эти события игнорируют.

Google решила это через автоматическую эмуляцию. Если приложение не обрабатывает hover, система эмулирует его через изменение визуального состояния (state_hovered в XML drawable). Кнопка автоматически меняет цвет при наведении, даже если разработчик не написал для этого код.

Клавиатура — отдельная боль. На смартфоне физической клавиатуры нет, поэтому разработчики не тестируют горячие клавиши. На ноутбуке пользователь ожидает, что Ctrl+C скопирует текст, Ctrl+V вставит, Ctrl+Z отменит действие.

Android 16 добавил KeyboardShortcutManager — системный сервис, который перехватывает стандартные комбинации клавиш и транслирует их в соответствующие действия, даже если приложение не поддерживает их явно.

Например, Ctrl+C перехватывается, система извлекает выделенный текст из TextView (через accessibility API), копирует его в буфер обмена и показывает toast "Скопировано". Это работает автоматически для всех приложений, использующих стандартные компоненты UI.

Тачпад (trackpad) — третья проблема. Жесты тачпада (двумя пальцами скроллить, тремя пальцами переключать приложения, щипок для зума) не были стандартизированы в Android.

Google портировала libinput из Linux — это библиотека, которая обрабатывает ввод от тачпадов. libinput работает поверх ядра Linux (через /dev/input/eventX), распознает жесты и транслирует их в Android MotionEvents.

Это позволило сохранить совместимость. Старые приложения получают обычные scroll events, а новые могут подписаться на gesture events и реализовать кастомное поведение (например, трехпальцевый свайп для смены вкладки в браузере).

Chrome Desktop на Android: Главная фича Aluminium

Самая большая проблема Android на ноутбуке — это браузер.

Chrome для Android — это мобильный браузер. В нем нет:

Расширений (extensions). Вы не можете установить AdBlock, LastPass, Grammarly.
Полноценных DevTools. Инструменты разработчика урезаны.
Менеджера закладок в стиле десктопа (с папками и drag-and-drop).
Синхронизации вкладок между устройствами в полном объеме.

Google потратила два года, чтобы портировать Desktop Chrome на Android. Это не просто "пересобрать с другими флагами". Desktop Chrome использует совершенно другую архитектуру.

В мобильном Chrome каждая вкладка — это отдельный процесс Android (через Activity). В Desktop Chrome каждая вкладка — это renderer process внутри browser process (multi-process архитектура Chromium).

Desktop Chrome использует Aura (фреймворк для отрисовки UI в Chromium). Aura работает поверх Views (библиотека виджетов C++). На Linux Aura рисует через Wayland/X11. На Windows — через GDI+. На macOS — через Cocoa.

На Android нет Wayland и нет X11. Есть только SurfaceFlinger. Google написала Aura backend для Android, который транслирует Aura drawing commands в Android Canvas API.

Результат: Desktop Chrome на Android выглядит и работает идентично Desktop Chrome на Windows. Вы открываете Chrome Web Store, устанавливаете расширения, и они работают. Вы открываете DevTools, и там полноценный debugger с breakpoints, network inspector, performance profiler.

Это убирает последнее препятствие для использования Android как десктопной ОС.

AVF: Android Virtualization Framework для Linux-контейнеров

Разработчики любили ChromeOS за Crostini — возможность запустить контейнер с Debian Linux и работать с VS Code, Docker, Python, Node.js.

Aluminium сохраняет эту возможность, но через другой механизм.

AVF (Android Virtualization Framework) появился в Android 13. Это подсистема виртуализации, основанная на pKVM (protected KVM). pKVM — это модификация KVM (Kernel-based Virtual Machine), которая изолирует виртуальные машины друг от друга и от host-системы на уровне гипервизора.

В обычном KVM гипервизор работает в Ring 0 (режим ядра). Он имеет полный доступ к памяти и может читать данные виртуальных машин. В pKVM гипервизор работает в отдельном адресном пространстве (EL2 в ARM терминологии). Он не видит память виртуальных машин и не может вмешиваться в их работу.

Это критично для безопасности. Если host-система скомпрометирована (например, через уязвимость в браузере), атакующий не может получить доступ к данным внутри виртуальной машины.

Aluminium использует AVF для запуска Linux-контейнеров:

Вы запускаете "Linux Terminal" из меню приложений.

Android стартует микро-VM с Debian внутри AVF.

Виртуальная машина загружается за 2-3 секунды (это быстрее, чем Docker, потому что используется минимальный initramfs).

Вы получаете полноценный Bash с apt, gcc, python3, node.

Графические Linux-приложения (VS Code, GIMP, LibreOffice) работают через Wayland forwarding. VM запускает Wayland compositor, который пробрасывает окна в Android через virtio-gpu (виртуальный GPU драйвер). Android рисует эти окна как обычные Android Surfaces, поэтому Linux-приложения выглядят как нативные Android-приложения.

Файловая система shared между Android и Linux через virtio-fs (виртуальная файловая система). Вы видите папку /sdcard/Linux внутри Android, и она соответствует /home/user внутри Linux VM. Вы можете редактировать файл в VS Code (Linux) и открыть его в Android Studio (Android) без копирования.

Производительность близка к нативной. Бенчмарки показывают, что компиляция C++ кода внутри AVF Linux VM на 5-8% медленнее, чем нативная компиляция на голом железе. Это приемлемо.

Единственное ограничение — Docker. Внутри виртуальной машины нельзя запустить вложенную виртуализацию (nested virtualization). Docker работает, но только в режиме rootless (без KVM). Это означает, что вы не можете запустить Docker с полной изоляцией. Для большинства сценариев разработки это не критично.

Зачем убивать ChromeOS? Бизнес-логика

После всех этих технических изменений возникает вопрос — зачем? ChromeOS работает. У неё есть аудитория (школы, корпорации, студенты). Зачем ломать то, что работает?

Причина первая: фрагментация экосистемы. Google приходилось поддерживать две разные ОС, два разных набора API, два разных магазина приложений. ChromeOS использует Chrome Web Store (расширения для браузера) и Linux-приложения через Crostini. Android использует Google Play Store. Приложения не пересекаются.

Разработчик, который написал приложение для Android, не может просто выложить его в ChromeOS. Нужно портировать на PWA (Progressive Web App) или на Linux. Это дополнительная работа, которую большинство не делает.

Слияние в Aluminium решает эту проблему. Один магазин (Google Play). Одно приложение работает на телефоне, планшете и ноутбуке.

Причина вторая: провал Android-планшетов. iPad доминирует на рынке планшетов с долей 60%. Android-планшеты страдают от нехватки качественного софта. Большинство приложений — это растянутые мобильные приложения с гигантскими кнопками.

Сделав Android десктопным, Google убивает двух зайцев. Приложения, оптимизированные для Aluminium-ноутбуков, автоматически работают хорошо на планшетах (потому что используют те же API для adaptive layout).

Причина третья: экономия ресурсов. Поддержка двух ОС стоит денег. Каждый security patch нужно портировать дважды (в ChromeOS и в Android). Каждая новая фича требует двух команд разработчиков.

По оценкам аналитиков, Google тратит на ChromeOS около 500 миллионов долларов в год (зарплаты инженеров, инфраструктура, поддержка). Слияние в Aluminium позволит сократить эти расходы вдвое.

Причина четвертая: ARM-процессоры. Весь мир переходит на ARM. Apple Silicon (M1/M2/M3/M4) показал, что ARM может конкурировать с x86 на десктопе. Qualcomm выпустила Snapdragon X Elite — первый ARM-чип для Windows-ноутбуков, способный тягаться с Intel Core i7.

Android изначально заточен под ARM. ChromeOS теоретически поддерживает ARM (через Crostini с эмуляцией x86), но на практике производительность плохая.

Aluminium — это ответ Google на MacBook Air M3/M4. Ноутбук на Android с чипом Tensor, который работает 20+ часов от батареи (как MacBook), стоит дешевле (потому что Android-экосистема дешевле macOS), и имеет доступ к миллионам мобильных приложений.

Что теряется при переходе на Aluminium

Не всё идеально. ChromeOS имела фичи, которые теряются при переходе на Android.

Verified Boot. ChromeOS проверяет целостность ОС при каждой загрузке через криптографическую подпись. Если кто-то модифицировал системные файлы (например, установил руткит), устройство откажется загружаться.

Android имеет dm-verity (аналог Verified Boot), но он работает только для /system раздела. ChromeOS проверяет весь rootfs. Это более строгая модель безопасности.

Auto-update в фоне. ChromeOS обновляется автоматически, без участия пользователя. Обновление скачивается в фоне, применяется к неактивному разделу (A/B partition scheme), и активируется при следующей перезагрузке. Пользователь не видит progress bar.

Android тоже поддерживает A/B updates, но требует подтверждения ("Обновление готово. Перезагрузить?"). Google обещает, что Aluminium будет обновляться как ChromeOS (silent updates).

Управление через Google Admin Console. ChromeOS широко используется в образовании и корпорациях, потому что IT-администратор может управлять тысячами устройств централизованно (блокировать установку приложений, настраивать Wi-Fi, удаленно вайпать устройство).

Android имеет Android Enterprise, но он менее зрелый. Google работает над тем, чтобы Aluminium поддерживал все фичи ChromeOS Admin Console.

Powerwash (сброс к заводским настройкам за 10 секунд). В ChromeOS все пользовательские данные хранятся в зашифрованном виде. При Powerwash система просто удаляет ключ шифрования, и все данные моментально становятся нечитаемыми. Физически файлы остаются на диске, но без ключа их невозможно расшифровать.

Android тоже поддерживает File-Based Encryption, но сброс занимает 2-3 минуты (нужно очистить /data раздел). Google обещает ускорить этот процесс в Aluminium.

4. SeL4 vs Zircon: Почему Google изобрела велосипед

В комментариях к первой статье справедливо спросили: "Микроядро SeL4 стало открытым в 2014, а Zircon представлен в 2016. Почему не взяли готовое передовое микроядро?"

Это отличный вопрос, который вскрывает фундаментальный конфликт между академической чистотой и промышленной реальностью.

SeL4: Формальная верификация как святой Грааль

SeL4 — это микроядро, разработанное в NICTA (позднее переименованной в Data61, подразделение CSIRO в Австралии). Оно знаменито тем, что это первое ядро операционной системы, полностью формально верифицированное.

Что означает формальная верификация? Математическое доказательство того, что код ядра делает ровно то, что написано в спецификации, и ничего больше. Никаких buffer overflows, никаких race conditions, никаких memory leaks — по определению. Это доказано математически, как теорема в геометрии.

Доказательство SeL4 занимает 200 тысяч строк на языке Isabelle/HOL (proof assistant). Команда потратила 11 лет на верификацию ядра размером всего 8700 строк C-кода.

Результат впечатляющий. SeL4 использует capabilities-based security (как и Zircon). Оно поддерживает hard real-time (гарантированное время отклика). Оно открыто под лицензией GPL v2 (позднее переведено на BSD).

Казалось бы, идеальное решение. Почему Google не взяла его?

Проблема первая: Licensing и вендоры

SeL4 изначально было лицензировано под GPL v2. Это copyleft-лицензия. Если вы используете GPL-код в своем продукте, вы обязаны открыть исходники всего продукта.

Для Google это приемлемо. Но для вендоров (Samsung, Qualcomm, Xiaomi, Oppo) это катастрофа. Они не хотят открывать свои драйвера, потому что там trade secrets и патентованные алгоритмы.

В 2020 году SeL4 переведен на dual licensing (GPL v2 или BSD). Но к тому моменту Zircon уже работал, и менять фундамент было поздно.

Zircon лицензирован под BSD-подобной лицензией (с некоторыми файлами под MIT). Это permissive license. Вы можете взять код, модифицировать его, добавить закрытые компоненты и не публиковать исходники. Samsung может написать свой драйвер камеры для Fuchsia, закрыть его, и это легально.

Это критично для экосистемы. Android стал успешным именно потому, что вендоры могли закрывать код. Если бы Android был под GPL, китайские производители не стали бы его использовать.

Проблема вторая: Hard Real-Time — не всегда преимущество

SeL4 гордится поддержкой hard real-time. Что это означает?

В обычной ОС (Linux, Windows, Zircon) планировщик работает по принципу "best effort". Если поток запросил CPU, он получит его "когда-нибудь скоро". Если система перегружена, поток может ждать миллисекунды.

В hard real-time системе есть гарантии. Если поток с приоритетом 10 запросил CPU, он получит его в течение 50 микросекунд. Гарантированно. Всегда. Даже если система под нагрузкой.

Это достигается через priority-based preemptive scheduling. Поток с высоким приоритетом мгновенно вытесняет поток с низким приоритетом, без задержек.

Где это нужно? Авионика (управление самолетом), медицинские устройства (кардиостимулятор), промышленная автоматика (управление станками).

Где это не нужно? Смартфоны, ноутбуки, умные дисплеи.

Более того, hard real-time вредит общей производительности. Вот почему.

В обычной ОС планировщик может оптимизировать throughput (общее количество выполненной работы). Он может отложить выполнение низкоприоритетного потока на 10 миллисекунд, чтобы дать высокоприоритетному потоку закончить работу. Это увеличивает latency (задержку), но уменьшает context switches (переключения контекста), что в итоге быстрее.

В hard real-time ОС планировщик обязан соблюдать дедлайны. Если низкоприоритетный поток должен получить CPU через 50 микросекунд, он его получит, даже если это означает прервать высокоприоритетный поток в неудобный момент.

Результат: больше переключений контекста, больше cache misses, меньше throughput.

Для смартфона это катастрофа. Вы хотите максимальную производительность при минимальном энергопотреблении. Hard real-time гарантии вам не нужны. Вам всё равно, отрисуется кадр через 15 или 17 миллисекунд. Пользователь не заметит разницу.

Zircon использует soft real-time. Есть приоритеты, есть дедлайны, но они не абсолютные. Планировщик старается их соблюдать, но если система перегружена, он может отложить низкоприоритетную задачу.

Это даёт больше гибкости. Zircon может агрессивно батчить операции (группировать несколько мелких задач в одну большую), что снижает overhead и увеличивает throughput.

Проблема третья: Размер кодовой базы и интеграция

SeL4 — это микроядро размером 8700 строк C-кода. Это красиво. Это элегантно. Это легко верифицировать.

Но это бесполезно без userspace. Вам нужны драйвера, файловая система, сетевой стек, графический композитор. SeL4 предоставляет только примитивы (threads, IPC, memory management).

Существуют проекты, которые строят полноценные ОС поверх SeL4. Например, CAmkES (Component Architecture for microkernel-based Embedded Systems) и Genode OS Framework.

Проблема в том, что эти проекты академические. Genode работает в эмуляторах и на специфичном железе (некоторые ARM-платы). Чтобы портировать его на Snapdragon или Tensor, нужны месяцы работы.

Google нужна была ОС, которая работает на:

ARM64 (Snapdragon, Tensor, Apple Silicon в будущем для совместимости через эмуляцию)

x86-64 (Intel/AMD для ноутбуков и серверов)

RISC-V (будущие чипы, Google инвестирует в RISC-V)

С поддержкой тысяч разных устройств (GPU от Qualcomm, Mali, PowerVR; дисплеи AMOLED, LCD; сенсоры от десятков вендоров).

Zircon изначально разрабатывался с учетом этого. Он основан на Little Kernel (LK) — микроядре, которое использовалось в Android bootloader (fastboot). LK уже работало на ARM и x86, уже имело драйвера для базовых устройств.

Google взяла LK как базу, выбросила ненужное, переписала на C++ (для type safety и RAII), добавила capabilities и назвала это Zircon.

К 2016 году, когда SeL4 стал по-настоящему open source, Google уже потратила два года на Zircon. Переключиться на SeL4 означало выбросить всю работу и начать с нуля.

Проблема четвертая: Философия разработки

SeL4 разрабатывается академически. Приоритет — формальная корректность. Каждое изменение проверяется через Isabelle/HOL. Это медленно. Добавить новую фичу в SeL4 может занять годы, потому что нужно обновить formal proof.

Google работает по принципу "move fast and iterate". Fuchsia меняется каждую неделю. В репозитории тысячи коммитов в месяц. Формальная верификация при таком темпе невозможна.

Более того, Google не нужна формальная верификация всего ядра. Они используют другой подход: defence in depth (эшелонированная защита).

Zircon написан на C++ с активным использованием RAII (Resource Acquisition Is Initialization). Это означает, что объекты автоматически освобождают ресурсы при уничтожении. Нет ручного malloc/free, нет забытых delete — компилятор гарантирует корректность.

Google использует sanitizers (AddressSanitizer, ThreadSanitizer, UndefinedBehaviorSanitizer) на всех стадиях разработки. Каждый коммит прогоняется через fuzzing (автоматическая генерация random inputs для поиска крэшей).

Это не даёт математических гарантий, как SeL4. Но это находит 99.9% багов до релиза, и это не тормозит разработку.

Capabilities в Zircon: Практическая реализация

И SeL4, и Zircon используют capabilities-based security. Но реализации отличаются.

В SeL4 capability — это токен, который даёт право на определенную операцию. Например, capability на чтение файла, capability на отправку IPC-сообщения конкретному потоку.

Capabilities неподделываемы (unforgeable). Вы не можете создать capability из воздуха. Вы получаете его от ядра или от другого процесса, который уже имеет право передавать capabilities.

Zircon работает похоже, но с одним отличием: capabilities в Zircon — это Handle (дескриптор). Это 32-битное число, которое идентифицирует объект ядра (Process, Thread, Channel, VMO).

Когда вы создаёте объект, ядро возвращает вам Handle с определёнными правами (ZX_RIGHT_READ, ZX_RIGHT_WRITE, ZX_RIGHT_EXECUTE и так далее). Вы можете передать этот Handle другому процессу через Channel, но при передаче права могут быть уменьшены, но не увеличены.

Пример: у вас есть Handle на VMO (Virtual Memory Object) с правами READ | WRITE. Вы передаёте его процессу-рендереру, но с правами только READ. Рендерер может читать память, но не может модифицировать. Если рендерер скомпрометирован, он не сможет испортить данные.

Это гениально просто и эффективно. В отличие от Unix permissions (где проверка прав происходит на каждый syscall), в Zircon проверка происходит один раз — при передаче Handle. Дальше ядро просто проверяет, что Handle валиден, а права уже известны.

Конкретный пример атаки, невозможной в Zircon

Представим сценарий: вы открыли PDF в браузере. PDF содержит эксплойт, который использует уязвимость в парсере шрифтов.

В Linux (традиционная архитектура):

Браузер работает с правами вашего пользователя.

Парсер шрифтов — это библиотека (libfreetype), загруженная в адресное пространство браузера.

Эксплойт получает control flow (управление выполнением кода) внутри процесса браузера.

Теперь атакующий имеет доступ ко всем файлам, которые доступны вашему пользователю: документы, пароли в браузере, SSH-ключи.

Даже если браузер использует sandboxing (песочницу), атакующий может эскалировать привилегии через kernel exploit (уязвимость в ядре).

В Zircon (Fuchsia):

Браузер — это набор процессов. Каждая вкладка — отдельный процесс с минимальными правами.
Парсер шрифтов работает в отдельном процессе (font service). Он не имеет доступа к файловой системе. Он получает данные шрифта через Channel (IPC), парсит их и возвращает результат.
Эксплойт получает control flow внутри font service.

Что может сделать атакующий? Он контролирует процесс, у которого нет никаких capabilities. Процесс не имеет Handle на файловую систему (потому что они не были переданы при запуске). Процесс не имеет права создавать новые процессы. Он не может открыть сетевое соединение.

Единственное, что может сделать процесс — крэшнуться. Ядро детектирует крэш, логирует его и уведомляет браузер. Браузер показывает пользователю: "Не удалось отобразить шрифт". Вкладка продолжает работать (потому что парсер шрифтов был в отдельном процессе).

Никакой эскалации привилегий. Никакого доступа к данным. Атака нейтрализована архитектурно.

Почему Linux не может это реализовать

Вы можете спросить: почему Linux не использует capabilities?

Ответ: legacy. Linux существует с 1991 года. Огромное количество софта полагается на Unix permissions (owner/group/other, read/write/execute bits).

Попытки добавить capabilities в Linux были (POSIX capabilities, SELinux capabilities). Но они наслоены поверх старой модели. Они опциональные. Если разработчик не использует их явно, они не работают.

В Zircon capabilities — это не опция. Это единственный способ получить доступ к чему-либо. Ядро физически не может дать процессу доступ к объекту без Handle. Это встроено на уровне архитектуры.

Formal Verification vs Pragmatic Engineering

SeL4 доказывает, что их ядро корректно математически. Zircon доказывает корректность эмпирически — через тестирование, fuzzing и реальную эксплуатацию.

Что надёжнее?

SeL4 гарантирует отсутствие багов в ядре. Но это не гарантирует отсутствие багов в драйверах (которые в userspace и не верифицированы). Это не гарантирует отсутствие багов в приложениях.

Zircon не гарантирует отсутствие багов в ядре. Но архитектура построена так, что баг в драйвере или приложении не может повредить систему. Это defence in depth.

Что важнее для consumer-устройства? Google выбрала второе. Им важнее, чтобы система была resilient (устойчива к ошибкам), чем provably correct (доказуемо корректна).

Есть ещё один аспект. Формальная верификация работает только для того кода, который вы верифицировали. Если вы добавляете новую фичу, вам нужно переписать доказательство. Это медленно и дорого.

Google добавляет фичи в Zircon каждую неделю. Async IPC появился в 2022 году. Profile-Guided Optimization для планировщика — в 2023. Поддержка RISC-V — в 2024. Всё это было бы невозможно с формальной верификацией.

Интеграция с существующей инфраструктурой Google

Google имеет огромную инфраструктуру: дата-центры, внутренние тулы, build системы. Всё это заточено под определенные технологии.

Zircon написан на C++ и использует GN/Ninja для сборки (те же тулы, что Chrome и Android). Это означает, что инженеры Google могут работать с Zircon без изучения новых инструментов.

SeL4 использует CAmkES (специфичный фреймворк для компонентной архитектуры) и Isabelle/HOL (proof assistant). Это экзотические технологии. Найти инженеров, которые знают Isabelle/HOL, почти невозможно (это академическая ниша).

Google могла бы обучить команду. Но зачем, если можно использовать знакомые инструменты и двигаться быстрее?

Вывод: Прагматизм побеждает академизм

SeL4 — это невероятное достижение компьютерной науки. Формальная верификация ОС — это святой Грааль, который искали десятилетиями.

Но для массового продукта (смартфона, ноутбука, умного дисплея) важны другие факторы:

Скорость разработки (Google выпускает фичи каждую неделю).
Совместимость с вендорами (licensing, closed-source драйвера).
Производительность (throughput важнее hard real-time гарантий).
Экосистема (integration с существующими тулами и инфраструктурой).

Zircon — это pragmatic choice. Он не идеален. Он не формально верифицирован. Но он работает на миллионах устройств (Nest Hub), он постоянно улучшается, и он готов к mass market.

SeL4 останется в нише, где формальная верификация критична: авионика, военные системы, медицинское оборудование. Это почётная ниша. Но это не массовый рынок.

Google сделала правильный выбор для своих целей. И это не "изобретение велосипеда". Это инженерное решение, основанное на бизнес-требованиях и технических ограничениях реального мира.

5. FIDL и ABI Stability: Как решить проблему обновлений

В комментариях к первой статье прозвучал скептический вопрос: "Вы уверены, что протоколы не будут меняться?"

Это самый важный вопрос. Потому что именно нестабильность ABI (Application Binary Interface) в Linux — это корень всех проблем с обновлениями Android.

Linux Kernel ABI Hell: Почему ваш телефон не получает обновления

Представим ситуацию. Qualcomm выпускает чип Snapdragon 888 в 2021 году. Они пишут драйвер GPU для Linux kernel 5.4. Драйвер — это kernel module (.ko файл), который загружается в ядро.

Драйвер обращается к внутренним структурам ядра. Например, структура struct device (определение устройства в ядре) имеет поля name, parent, driver, bus_type и так далее.

Проблема: эти структуры меняются от версии к версии ядра. В Linux 5.4 struct device имеет 40 полей. В Linux 5.10 — 45 полей (добавили новые для поддержки IOMMU). В Linux 6.1 — 48 полей.

Если вы скомпилируете драйвер для Linux 5.4 и попытаетесь загрузить его в Linux 5.10, произойдёт одно из двух:

Kernel panic (ядро крэшнется), потому что драйвер обращается к полю по неправильному offset.

Undefined behavior (неопределённое поведение) — система вроде бы работает, но GPU рандомно крэшится, потому что драйвер читает мусор из памяти.

Единственное решение — перекомпилировать драйвер для новой версии ядра. Но это не всегда возможно. Qualcomm пишет драйвера на закрытом C/C++ коде с использованием внутренних библиотек. Исходники не публикуются.

Что делает Qualcomm? Они поддерживают драйвера только для определённых версий ядра. Snapdragon 888 официально поддерживает Linux 5.4, 5.10 и 5.15. Если Google хочет обновить Android до Linux 6.1, Qualcomm должна портировать драйвера. Это стоит денег и времени.

Qualcomm не будет делать это бесплатно. Они потребуют от производителя телефона (Samsung, Xiaomi, OnePlus) оплатить портирование. Производители считают: стоимость портирования драйверов для трёхлетнего телефона — 500 тысяч долларов. Прибыль от владельцев этих телефонов (которые уже купили устройство) — почти ноль.

Решение: не обновлять. Телефон остаётся на Linux 5.4 навсегда. Security patches применяются (backporting уязвимостей в старое ядро), но новые фичи не появляются.

Это Linux Kernel ABI Hell. И это фундаментальная проблема, которую невозможно решить в рамках архитектуры Linux.

Почему в Linux нет стабильного ABI

Linus Torvalds (создатель Linux) неоднократно заявлял: "Мы не гарантируем стабильность internal kernel ABI. Это сознательное решение".

Причина: гибкость. Если вы зафиксируете структуру struct device, вы не сможете добавлять новые поля без breaking changes. Это затормозит развитие ядра.

Linux kernel развивается быстро. Новая версия выходит каждые 2-3 месяца. Каждая версия добавляет новые фичи: поддержку нового железа, новые файловые системы, новые планировщики, новые подсистемы безопасности.

Если бы Linux гарантировал ABI stability, многие из этих фич было бы невозможно реализовать. Поэтому принято решение: внутренний ABI нестабилен. Если вы хотите работать с новой версией ядра, пересобирайте драйвера.

Это работает для open source драйверов (они лежат в основном дереве ядра и обновляются автоматически). Но это катастрофа для проприетарных ��райверов.

Nvidia годами воюет с Linux community именно из-за этого. Драйвер Nvidia GPU — closed source. Каждый раз, когда выходит новая версия ядра, Nvidia вынуждена обновлять драйвер. Иногда это занимает недели, и пользователи сидят на старом ядре.

FIDL: Интерфейсы как контракт

FIDL (Fuchsia Interface Definition Language) решает эту проблему радикально иначе.

FIDL — это язык описания интерфейсов. Вы не вызываете функции ядра напрямую. Вы описываете интерфейс (набор методов и типов данных) в .fidl файле, и компилятор генерирует код для обеих сторон: клиента и сервера.

Пример. Вы хотите написать драйвер для дисплея. В Linux вы бы вызвали функции DRM (Direct Rendering Manager): drm_mode_create_dumb(), drm_mode_map_dumb() и так далее.

В Fuchsia вы описываете интерфейс:

library fuchsia.hardware.display;

protocol Display {
    /// Создать framebuffer заданного размера
    CreateFramebuffer(struct {
        width uint32;
        height uint32;
        format PixelFormat;
    }) -> (struct {
        buffer_id uint64;
    }) error zx.Status;

    /// Отобразить framebuffer на экране
    PresentFramebuffer(struct {
        buffer_id uint64;
    }) -> () error zx.Status;
};

Компилятор FIDL генерирует C++ код (или Rust, или Dart — FIDL поддерживает множество языков). Драйвер дисплея реализует этот интерфейс. Приложение вызывает методы через прокси-объект.

Критично: общение происходит через сообщения, которые передаются по Channel (IPC-механизм Zircon). Клиент не знает, как реализован сервер. Сервер не знает, кто его вызывает.

Это означает: вы можете обновить реализацию сервера (драйвер дисплея), и старые клиенты продолжат работать. Потому что контракт (интерфейс) не изменился.

Версионирование интерфейсов: Как не сломать совместимость

Но что, если вам нужно изменить интерфейс? Например, добавить новый метод или новое поле в структуру?

FIDL поддерживает эволюцию интерфейсов через несколько механизмов.

Добавление методов. Вы можете добавить новый метод в протокол без breaking change. Старые клиенты просто не будут его вызывать. Новые клиенты смогут проверить, поддерживает ли сервер новый метод (через feature detection).

Пример:

protocol Display {
    CreateFramebuffer(...) -> (...);
    PresentFramebuffer(...) -> (...);

    // Новый метод, добавленный в версии 2
    [Transitional]
    SetBrightness(struct {
        level uint8;
    }) -> () error zx.Status;
};

Атрибут [Transitional] говорит компилятору: "Этот метод опциональный. Сервер может его не реализовать".

Старый драйвер (который не знает про SetBrightness) компилируется без ошибок. Новый клиент, который вызывает SetBrightness, получит ошибку ZX_ERR_NOT_SUPPORTED, если драйвер старый. Клиент может обработать эту ошибку (например, показать пользователю: "Настройка яркости недоступна").

Добавление полей в структуры. FIDL поддерживает table — расширяемую структуру. В отличие от обычной struct, table может иметь опциональные поля.

Пример:

type FramebufferInfo = table {
    1: width uint32;
    2: height uint32;
    3: format PixelFormat;
    4: refresh_rate uint32; // Добавлено позже
};

Старый клиент, который ожидает только width, height, format, получит эти поля. Поле refresh_rate будет отсутствовать (null). Новый клиент может проверить наличие поля и использовать его, если оно есть.

Числа 1, 2, 3, 4 — это ординалы (ordinals). Они фиксированы навсегда. Вы не можете изменить ординал (это сломает wire format — бинарный формат сообщений). Но вы можете добавлять новые ординалы.

Удаление полей. Вы не можете удалить поле из table, но вы можете пометить его как deprecated и перестать его использовать. Старые клиенты продолжат отправлять это поле, новые серверы будут его игнорировать.

Это гарантирует forward compatibility (новый клиент работает со старым сервером) и backward compatibility (старый клиент работает с новым сервером).

Wire Format: Бинарная совместимость на уровне байтов

FIDL определяет не только API (какие методы вызывать), но и wire format (как сообщения кодируются в байты).

Когда клиент вызывает метод, FIDL encoder упаковывает аргументы в бинарное сообщение. Это сообщение отправляется по Channel. Сервер получает байты, FIDL decoder распаковывает их в структуры.

Wire format зафиксирован навсегда. Это означает, что сообщение, созданное FIDL compiler версии 1.0 (2017 год), может быть декодировано FIDL decoder версии 5.0 (2025 год).

Как это достигается?

Чёткая спецификация. Wire format описан в документе на 100+ страниц с точностью до бита. Каждое поле имеет фиксированный offset, alignment, byte order.

Расширяемость. Неизвестные поля (которые появились в новой версии протокола) не вызывают ошибку. Decoder сохраняет их как raw bytes и передаёт дальше. Если сообщение пересылается через цепочку сервисов, неизвестные поля не теряются.

Валидация. Decoder проверяет корректность сообщения: размеры полей, alignment, отсутствие циклических ссылок. Если сообщение повреждено (например, атакующий подменил байты), decoder возвращает ошибку, а не крэшит процесс.

Это принципиально отличается от Linux syscall ABI, где структуры передаются напрямую через память. Если размер структуры изменился, вы получаете segmentation fault.

Сравнение с Protobuf и gRPC

FIDL похож на Protocol Buffers (Protobuf) от Google. Оба используют схему (описание интерфейса), генерируют код, поддерживают версионирование.

Но FIDL оптимизирован для IPC (межпроцессного взаимодействия), а Protobuf — для сети и хранения данных.

Ключевые отличия:

Zero-copy. FIDL поддерживает передачу больших объектов (например, framebuffer 4K изображения) без копирования. Вы передаёте Handle на VMO (Virtual Memory Object), и получатель мапит эту память в своё адресное пространство. Данные физически не копируются.

Protobuf всегда копирует данные (сериализация в байты, десериализация обратно в объекты). Для 33 мегабайт (4K RGBA framebuffer) это катастрофа по производительности.

Handles. FIDL поддерживает передачу Handles (ссылок на объекты ядра) как часть сообщения. Вы можете отправить Handle на Channel, и получатель сможет использовать этот Channel для дальнейшего общения. Это позволяет строить сложные топологии IPC.

Protobuf не поддерживает это (потому что он предназначен для сети, где нет концепции kernel objects).

Synchronous и asynchronous API. FIDL генерирует оба варианта. Вы можете вызвать метод синхронно (блокируя поток до получения ответа) или асинхронно (через callback или Future).

Protobuf обычно используется через gRPC, который асинхронен по умолчанию. Синхронные вызовы требуют дополнительной обёртки.

Низкий overhead. FIDL encoder/decoder написан на C++ с ручной оптимизацией. Encoding простого сообщения (10 полей) занимает 50-100 наносекунд. Для IPC это критично (вызовы происходят миллионы раз в секунду).

Protobuf медленнее (200-500 наносекунд для аналогичного сообщения), потому что использует более универсальный формат.

Практический пример: Обновление Nest Hub

Nest Hub (вто��ое поколение) работает на Fuchsia. Google регулярно выпускает обновления ОС. Давайте посмотрим, как это работает.

Устройство имеет два раздела: A и B (A/B partition scheme). Сейчас загружен раздел A с Fuchsia версии 10.0.

Google выпускает версию 11.0. Обновление содержит:

Новое ядро Zircon с оптимизациями планировщика.

Обновлённый драйвер Wi-Fi с поддержкой Wi-Fi 6E.

Новый системный сервис для управления умным домом.

Обновление загружается в фоне и устанавливается на раздел B. Устройство продолжает работать с раздела A.

Критичный момент: драйвер Wi-Fi использует FIDL интерфейс fuchsia.wlan.device. Этот интерфейс определён в версии 1.0 и не изменился.

Новый драйвер (версия 11.0) реализует тот же интерфейс плюс новые методы для Wi-Fi 6E. Старые клиенты (системные сервисы из версии 10.0) вызывают старые методы — вс�� работает.

При следующей перезагрузке устройство стартует с раздела B (версия 11.0). Если что-то пошло не так (например, баг в новом ядре), устройство автоматически откатывается на раздел A (версия 10.0) при следующей загрузке.

Пользователь не видит ничего из этого. Устройство обновляется бесшумно. Никаких "Installing update, please wait 20 minutes". Никаких кирпичей (bricked devices), если обновление провалилось.

Это возможно только благодаря ABI stability. Если бы интерфейсы ломались между версиями, откат был бы невозможен (старая система не смогла бы общаться с новыми драйверами, оставшимися в памяти).

Почему Android не может это реализовать

Android использует HAL (Hardware Abstraction Layer) — аналог FIDL для общения с драйверами. Начиная с Android 8 (2017 год), HAL перешёл на HIDL (HAL Interface Definition Language), а позже на AIDL (Android Interface Definition Language).

AIDL похож на FIDL. Он тоже использует описание интерфейсов, генерирует код, поддерживает версионирование.

Но есть проблема: ядро Linux. AIDL описывает интерфейсы между Android framework и HAL. Но HAL всё равно общается с ядром через старые механизмы (ioctl, sysfs, procfs).

Ядро Linux не использует AIDL. Оно не предоставляет стабильный ABI. Поэтому даже если HAL поддерживает старые интерфейсы, ядро может сломать всё при обновлении.

Google пытается решить это через GKI (Generic Kernel Image) — стандартное ядро для всех Android-устройств. Идея: вендоры (Qualcomm, MediaTek) не модифицируют ядро, а используют loadable modules для своих драйверов.

Проблема: loadable modules всё равно зависят от версии ядра. Модуль, скомпилированный для Linux 5.10, не работает на Linux 5.15.

Google добавила KMI (Kernel Module Interface) — стабильный набор символов (функций и структур), которые гарантированно не меняются между версиями GKI.

Но KMI покрывает только базовые функции. Для специфичных вещей (например, управление GPU через custom IOCTL) KMI не помогает.

Результат: частичное решение. Некоторые устройства могут обновлять ядро независимо от вендора. Но большинство всё ещё застряли в ABI hell.

Fuchsia решает это радикально: нет ядра Linux, нет legacy ABI. Всё общение через FIDL. Всё стабильно by design.

Скептицизм из комментариев: "Протоколы тоже будут меняться"

Да, FIDL-протоколы будут меняться. Но изменения контролируемы и обратно совместимы.

В Linux изменения в kernel ABI хаотичны. Разработчик подсистемы DRM решает: "Я добавлю новое поле в struct drm_device". Он отправляет патч, его принимают, и всё ломается для out-of-tree драйверов.

В Fuchsia изменения в FIDL проходят через API review. Команда API Council (группа инженеров, ответственных за стабильность API) проверяет каждое изменение.

Добавляете новый метод? Нужно доказать, что он обратно совместим (через атрибут [Transitional] и тесты).

Меняете wire format? Запрещено. Если нужно изменить формат, создаёте новую версию протокола (fuchsia.hardware.display.v2), и оба протокола существуют параллельно.

Удаляете метод? Только через deprecation cycle. Метод помечается deprecated, даётся 6-12 месяцев на миграцию клиентов, затем метод удаляется.

Это инженерная дисциплина. Это не гарантирует, что протоколы никогда не сломаются. Но это гарантирует, что ломание осознанно, контролируемо и минимизировано.

Linux не имеет такой дисциплины, потому что сообщество слишком велико, изменения происходят слишком быстро, и приоритет на новых фичах, а не на стабильности.

Долгосрочное видение: 10 лет поддержки устройств

Google публично заявила: цель Fuchsia — поддерживать устройства 10+ лет.

Это радикально. Сейчас топовый Android-телефон получает обновления 3-4 года (Pixel, Samsung Galaxy S). Бюджетный телефон — 1-2 года.

Причина — не отсутствие желания у Google. Причина — техническая невозможность. Ядро Linux 5.4 (которое было актуально в 2020 году) несовместимо с драйверами для Linux 6.10 (2024 год). Портирование драйверов стоит миллионы долларов.

Fuchsia решает это через ABI stability. Драйвер, написанный в 2025 году, будет работать на Fuchsia 2035 года. Потому что FIDL-интерфейс не изменится (или изменится обратно совместимо).

Это открывает путь к sustainable computing. Вы покупаете устройство один раз, оно получает обновления десять лет, и вам не нужно менять его из-за "устаревшей ОС".

Это хорошо для экологии (меньше электронных отходов), хорошо для пользователей (экономия денег), хорошо для Google (долгосрочные отношения с клиентами).

И это невозможно в Linux. По архитектурным причинам.

6. Конвергенция: Как всё это складывается в единую картину

Мы прошли долгий путь — от проблем OpenGL и C ABI до модемов, от микроядер до интерфейсных языков. Теперь давайте соединим все точки и увидим полную картину стратегии Google.

Единая графическая платформа: WGPU как связующее звено

В 2020 году Flutter, Chrome и Fuchsia были тремя разными проектами с разными графическими стеками. Flutter использовал Skia поверх OpenGL. Chrome использовал Skia поверх собственного бэкенда. Fuchsia экспериментировала с Scenic (композитором на базе Vulkan).

В 2026 году все три проекта сходятся на современных графических API, но используют разные пути к ним.

Flutter Impeller использует прямые нативные API. На iOS — Metal. На Android — Vulkan. На Windows — DirectX 12. Никаких промежуточных слоёв. Максимальная производительность.

Chrome использует WGPU (Rust-библиотеку) для реализации WebGPU API в браузере. Веб-разработчик пишет код на WebGPU, и WGPU транслирует его в Metal/Vulkan/DirectX под капотом.

Fuchsia использует Vulkan через Magma (userspace GPU драйвер). Flutter на Fuchsia работает через цепочку: Impeller → Vulkan → Magma. Системный UI написан на Flutter и использует Impeller. WGPU используется только для WebGPU в браузере на Fuchsia.

Ключевой момент: это не "один стек WGPU для всего". Это философская конвергенция на современных графических API, где каждый проект выбирает оптимальный путь для своих задач.

Представьте Pixel ноутбук на Aluminium OS (Android). Вы открываете Chrome, запускаете веб-приложение, которое использует WebGPU (через WGPU) для 3D-графики. Рядом открыто Flutter-приложение (через Impeller напрямую на Vulkan). Системный UI (панель задач) тоже Flutter (Impeller → Vulkan).

Что общего:

Все пути ведут к Vulkan. Chrome через WGPU → Vulkan. Flutter через Impeller → Vulkan. Системный UI через Impeller → Vulkan.

Один драйвер GPU (Vulkan) загружен в память. Нет дублирования на уровне драйвера.

Все шейдеры компилируются в SPIR-V (стандартный промежуточный формат Vulkan). Impeller прекомпилирует их при сборке приложения. WGPU компилирует на лету или использует pipeline cache.

Единый memory allocator на уровне Vulkan управляет GPU-памятью для всех компонентов.

Результат: батарея живёт дольше, система работает быстрее, потому что нет overhead на переключение между разными графическими API.

Сравните с Windows. Там веб-браузер использует DirectX через ANGLE (транслятор OpenGL в DirectX). Некоторые приложения используют DirectX напрямую. Другие используют OpenGL. Системный UI использует DWM (Desktop Window Manager) на базе DirectX. Это три-четыре разных стека, работающих параллельно. Overhead огромен.

Flutter как универсальный UI фреймворк

Google позиционирует Flutter не как "фреймворк для мобильных приложений", а как "UI toolkit для любой платформы".

В 2026 году Flutter работает на:

Мобильных устройствах (iOS, Android) — это очевидно.

Десктопах (Windows, macOS, Linux, Aluminium) — с полноценной поддержкой мыши, клавиатуры, окон.

Вебе (через Flutter Web, который компилируется в WebAssembly и использует CanvasKit или HTML рендерер).

Встраиваемых системах (automotive, smart displays) — Nest Hub работает на Flutter.

Fuchsia — системный UI полностью на Flutter.

Ключевой момент: один и тот же код работает везде. Вы пишете виджет один раз, и он адаптируется к платформе.

На мобильном устройстве виджет реагирует на тач-жесты (swipe, pinch, long press).

На десктопе тот же виджет реагирует на мышь (hover, click, drag) и клавиатуру (Tab для навигации, Enter для активации).

На веб-платформе виджет работает в браузере, но с нативной производительностью (благодаря WebAssembly и WebGPU).

Это радикально отличается от подхода React Native или Electron.

React Native транслирует JavaScript-код в нативные компоненты платформы (UIButton на iOS, Button на Android). Это работает, но у вас нет единообразия. iOS-кнопка выглядит иначе, чем Android-кнопка. Поведение отличается.

Electron запускает полноценный браузер Chromium для каждого приложения. Приложение Slack на десктопе — это по сути веб-страница, работающая в отдельном экземпляре Chrome. Это пожирает гигабайты RAM.

Flutter рендерит всё сам, используя собственный движок (Impeller). Он не зависит от платформенных компонентов. Кнопка выглядит одинаково на iOS, Android, Windows, потому что Flutter её рисует пиксель за пикселем. Но при этом вы можете кастомизировать стиль (Material Design для Android, Cupertino для iOS, Fluent для Windows).

Для Google это стратегически важно. Когда (и если) Fuchsia заменит Android на смартфонах, миллионы Flutter-приложений продолжат работать без изменений. Разработчикам не нужно портировать код. Пользователи не заметят разницы.

Kotlin Multiplatform и десктопная экспансия

Проект Aluminium — это не просто "Android на ноутбуке". Это открытие шлюзов для десктопных приложений на Kotlin.

Kotlin — официальный язык для Android-разработки (с 2017 года Google рекомендует Kotlin вместо Java). Но Kotlin никогда не был популярен на десктопе. Почему? Потому что десктоп — это Windows и macOS, а там доминируют C++, C#, Swift.

Aluminium меняет это. Когда Android становится десктопной ОС, Kotlin становится десктопным языком.

Kotlin Multiplatform (KMP) позволяет писать общий код для Android, iOS, Web и Desktop (JVM). До Aluminium "Desktop" означал "Java-приложения на Windows/macOS/Linux через Swing или JavaFX". Это нишевый рынок.

После Aluminium "Desktop" означает "Android-приложения на ноутбуках Pixel и других устройствах на Aluminium OS". Это потенциально десятки миллионов устройств (если Google удастся захватить хотя бы 5-10% рынка ноутбуков).

Представьте сценарий: вы разработчик корпоративного софта. Вам нужно приложение для управления складом. Сотрудники используют Android-планшеты на складе, менеджеры используют ноутбуки в офисе.

Раньше вы писали два приложения: Android-версия (Kotlin + Jetpack Compose) и десктопная версия (JavaFX или Electron). Два кодовых репозитория, двойная работа, двойные баги.

Теперь вы пишете одно приложение на Kotlin Multiplatform. Бизнес-логика общая (работа с БД, API-запросы, валидация данных). UI адаптивный (Jetpack Compose автоматически подстраивается под размер экрана).

Приложение работает на Android-планшетах (ARM), на Aluminium-ноутбуках (ARM или x86), и даже на iOS (через KMP для iOS, хотя это сложнее из-за ограничений Apple).

Это огромный рынок. Enterprise-приложения — это миллиарды долларов. Aluminium делает Kotlin Multiplatform мейнстримом в этом сегменте.

Microfuchsia: Тихое проникновение в Android

Пока СМИ ждали "Fuchsia Phone", Google тихо интегрировала Fuchsia в Android через Microfuchsia.

Напомню концепцию: современные Android-устройства поддерживают AVF (Android Virtualization Framework). Это позволяет запускать виртуальные машины рядом с основным Android.

Microfuchsia — это урезанная версия Fuchsia (только ядро Zircon и минимальный набор сервисов), которая запускается в защищённом анклаве через AVF.

Зачем это нужно?

Обработка биометрии. Отпечаток пальца, сканирование лица — критичные данные. Если их украдут, вы не можете "сменить лицо". В Android эти данные обрабатываются в TEE (Trusted Execution Environment) — специальной защищённой зоне процессора.

Проблема TEE: это проприетарная реализация от вендора (Qualcomm TrustZone, ARM TrustZone). Google не контролирует код. Были случаи уязвимостей в TrustZone, которые позволяли извлекать биометрические данные.

Решение: запустить Microfuchsia в pKVM (protected KVM). pKVM гарантирует, что даже если основной Android скомпрометирован (например, через malware), атакующий не может получить доступ к VM с Microfuchsia.

Zircon идеален для этой роли. Ядро маленькое (легко аудировать код на уязвимости), использует capabilities (минимальная поверхность атаки), не имеет legacy-кода (который часто источник багов).

Хранение ключей шифрования. Android использует Keystore для хранения криптографических ключей (например, ключи для шифрования данных приложений). Keystore работает в TEE.

С Microfuchsia ключи хранятся в Zircon VM. Даже если злоумышленник получит root на основном Android, он не сможет извлечь ключи. VM изолирована на уровне гипервизора.

Обработка DRM-контента. Когда вы смотрите фильм в Netflix или Disney+ в высоком качестве (4K HDR), контент защищён DRM (Digital Rights Management). Декодирование происходит в защищённой среде, чтобы предотвратить пиратство.

Android использует Widevine (DRM-система Google). Widevine Level 1 (наивысший уровень защиты) требует hardware-backed security. Обычно это TEE.

Microfuchsia может заменить TEE для Widevine. Декодирование видео происходит в изолированной VM. Даже если основная система скомпрометирована, поток видео не может быть перехвачен.

Результат: Fuchsia уже на миллионах Android-устройств. Пользователи не знают об этом. Система работает как "невидимый телохранитель".

Это гениальная стратегия. Google не заменяет Android на Fuchsia революционно. Она встраивает Fuchsia постепенно, компонент за компонентом. Сначала безопасность. Потом, возможно, драйвера. Потом — системные сервисы.

Через 5-10 лет Android может превратиться в тонкую обёртку над Fuchsia. Пользователи не заметят разницы. Но под капотом будет совершенно другая ОС.

Экосистемный эффект: Почему это работает только у Google

Вы можете спросить: почему Microsoft или Apple не делают то же самое?

Ответ: у них нет экосистемы такого масштаба.

Apple контролирует железо и софт, но только для своих устройств. У них нет открытой экосистемы. Samsung не может взять iOS и поставить на свои телефоны.

Microsoft контролирует Windows, но не контролирует мобильный рынок. Windows Phone умер. Android доминирует на смартфонах.

Google контролирует Android (доминирует на смартфонах), Chrome (доминирует в браузерах), Flutter (растущая доля в кроссплатформенной разработке), и создаёт Fuchsia (будущее всей экосистемы).

Это позволяет делать вещи, невозможные для других компаний:

Unified философия работы с GPU (современные API вместо OpenGL) работает везде: Chrome использует WGPU для WebGPU, Flutter использует Impeller с прямыми вызовами Metal/Vulkan/DX12, Fuchsia использует Vulkan через Magma.

Unified язык UI (Flutter) работает везде, где есть экран.

Unified IPC (FIDL) обеспечивает стабильность обновлений на десятилетия вперёд.

Это конвергенция на уровне, который никто другой не может повторить. Microsoft пытается (Project Reunion, WinUI 3), но они ограничены Windows. Apple пытается (SwiftUI, Catalyst), но они ограничены своей экосистемой.

Google играет в долгую игру. Они создают инфраструктуру, которая будет работать следующие 20 лет.

Что это значит для разработчиков: Новая золотая эра кроссплатформенной разработки

Для разработчиков, особенно тех, кто работает с Flutter и Kotlin, наступает золотая эра.

Раньше кроссплатформенная разработка означала компромиссы. React Native даёт код-sharing, но производительность хуже нативной. Xamarin (C#) работает, но экосистема маленькая. Electron простой, но пожирает ресурсы.

Flutter с Impeller — это первый кроссплатформенный фреймворк, который даёт нативную производительность без компромиссов благодаря прямому использованию современных графических API.

Это шанс писать десктопные приложения на том же языке, что и мобильные, без необходимости учить C++ или C#.

Конкретные преимущества:

Единая кодовая база. Вы пишете UI на Flutter и это работает на iOS, Android, Web, Windows, macOS, Linux, Aluminium, Fuchsia.

Нативная производительность. Нет JavaScript-моста (как в React Native). Нет интерпретации (как в старых frameworks). Код компилируется в машинный код (Dart AOT compilation) или в WebAssembly (для веба).

Доступ к платформенным API. Flutter имеет plugins для всех основных API: камера, GPS, Bluetooth, NFC, биометрия. Если нужного API нет, вы пишете platform channel и вызываете нативный код (Swift для iOS, Kotlin для Android).

Горячая перезагрузка (Hot Reload). Вы меняете код, нажимаете кнопку, и изменения применяются мгновенно, без перезапуска приложения. Это радикально ускоряет разработку.

Огромная экосистема. pub.dev (репозиторий пакетов для Dart/Flutter) содержит 50 тысяч пакетов. Всё, что вам нужно (HTTP-клиенты, state management, анимации, UI-компоненты), уже написано и протестировано.

Для пользователей: Конец фрагментации и начало долголетия устройств

Для обычных пользователей вся эта техническая сложность невидима. Но результаты будут очевидны.

Устройства, которые получают обновления 10 лет. Благодаря ABI stability (FIDL), Google сможет поддерживать устройства десятилетиями. Вы купили Pixel телефон в 2025 году? Он будет получать обновления до 2035 года. Security patches, новые фичи, улучшения производительности.

Приложения, которые работают везде. Вы купили приложение на Android. Оно автоматически работает на вашем Aluminium-ноутбуке. Синхронизация данных через облако (Google Drive, Firebase). Единый интерфейс на всех устройствах.

Батарея, которая живёт дольше. Unified графический стек (WGPU) и оптимизации Zircon (или Fuchsia, если вы используете Nest Hub) означают меньше энергопотребления. Ноутбук на Aluminium с чипом Tensor может работать 20+ часов от одной зарядки (как MacBook на Apple Silicon).

Безопасность по умолчанию. Capabilities в Zircon, изоляция через pKVM, Microfuchsia для критичных данных — всё это работает без участия пользователя. Вы защищены архитектурно, а не через антивирусы и файрволы.

Меньше электронных отходов. Если устройство получает обновления 10 лет, вам не нужно менять его каждые 2-3 года. Это экономит деньги и защищает планету.

Риски и препятствия: Что может пойти не так

Было бы наивно думать, что всё пройдёт гладко. Google имеет историю убивания проектов (Google Reader, Google+, Stadia, Inbox). Что может помешать Fuchsia и Aluminium?

Сопротивление вендоров. Samsung, Xiaomi, Oppo — они инвестировали миллиарды в свои кастомные оболочки Android (One UI, MIUI, ColorOS). Aluminium может сделать эти оболочки ненужными. Вендоры могут саботировать переход.

Но Google держит козырь: Google Play Services. Если вы хотите продавать телефоны с доступом к Play Store, Gmail, YouTube, вы подчиняетесь требованиям Google. Google может сделать Aluminium обязательным для новых устройств (как когда-то сделали обязательным Treble).

Недостаток приложений для Fuchsia. Starnix решает проблему для Android/Linux-приложений. Но нативные Fuchsia-приложения нужно писать заново. Разработчики не будут делать это, пока нет пользователей. Пользователи не придут, пока нет приложений. Классическая проблема "курицы и яйца".

Решение Google: постепенная миграция. Сначала Microfuchsia (невидима для пользователей). Потом Aluminium (Android-приложения работают). Потом, когда база пользователей достаточно большая, стимулировать разработчиков портировать приложения на нативный Fuchsia (через гранты, маркетинговую поддержку, featured listings в Play Store).

Технические баги и нестабильность. Новые ОС всегда имеют баги. ChromeOS была нестабильной первые годы. Android 1.0 был катастрофой. Fuchsia может столкнуться с теми же проблемами.

Google минимизирует риск через долгое бета-тестирование. Nest Hub — это полигон. Два поколения устройств работают на Fuchsia уже несколько лет. Google собирает телеметрию, фиксит баги, улучшает производительность. К моменту, когда Fuchsia появится на смартфонах, она будет mature.

Регуляторное давление. Антимонопольные регуляторы в ЕС и США внимательно следят за Google. Если Aluminium будет слишком жёстко интегрирован с сервисами Google (Search, Maps, Assistant), регуляторы могут потребовать разделения.

Google учла это. Aluminium, как и Android, будет open source (AOSP-подобная модель). Вендоры смогут создавать форки без Google-сервисов (как Amazon делает с Fire OS). Это даёт защиту от антимонопольных исков.

Философский вопрос: Нужна ли нам новая ОС?

Критики скажут: "Linux работает. Android работает. Windows работает. Зачем изобретать новую ОС?"

Ответ: потому что мир изменился.

Linux создавался в 1991 году для серверов и десктопов. Мобильных устройств не существовало. IoT не существовало. Облачные вычисления не существовали.

Android создавался в 2007 году для топовых смартфонов с одним ядром процессора, 256 МБ RAM и резистивным экраном. Сейчас топовые смартфоны имеют 8-16 ядер, 12-18 ГБ RAM, AI-ускорители, 5G-модемы.

Старые ОС адаптировались. Но адаптация — это накладывание заплаток на старый фундамент. Linux kernel вырос с 10 тысяч строк кода (1991) до 30 миллионов строк (2025). Это монстр. В нём багов больше, чем было строк кода в оригинальной версии.

Fuchsia — это шанс начать с чистого листа, зная всё, что мы узнали за 30 лет. Микроядро вместо монолита. Capabilities вместо permissions. FIDL вместо syscalls. WGPU вместо OpenGL.

Это не "изобретение велосипеда". Это проектирование автомобиля, когда вы всю жизнь ездили на велосипеде.

Да, велосипед работает. Но автомобиль быстрее, безопаснее, комфортнее. И мир движется к автомобилям.

Заключение: Тихая революция продолжается

В 2016 году, когда Google открыла репозиторий Fuchsia, медиа кричала: "Убийца Android!" В 2020 году, когда проект замедлился, медиа объявила: "Мёртвый проект!"

Оба прогноза были неправильными.

Fuchsia не убивает Android. Она его трансформирует. Сначала через Microfuchsia (безопасность). Потом через Aluminium (десктопная экспансия). Возможно, через 10 лет через полную замену ядра.

Это не революция с баррикадами. Это эволюция на уровне системных вызовов, ABI, IPC. Для пользователей невидимая. Для инженеров — фундаментальная.

Мы живём в переходный период. Flutter стал мейнстримом. WGPU вошёл в спецификацию W3C (WebGPU). Aluminium готовится к запуску. Zircon работает на миллионах устройств.

Через 10 лет мы оглянемся назад и скажем: "Это было начало новой эры операционных систем".

А пока — мы пишем код. На Dart. На Kotlin. На Rust (для тех, кто работает с WGPU напрямую). Мы строим будущее, одну строку кода за раз.

И это будущее выглядит захватывающим.

Статья получилась объёмной, но - иначе нельзя. Техническая глубина требует детализации. Каждый раздел раскрывает один аспект огромной мозаики. Только увидев всю картину целиком, можно понять масштаб того, что делает Google.

Если вы дочитали до конца — спасибо. Надеюсь, это было полезно. Если есть вопросы или уточнения — пишите в комментариях. Обсудим.