android

Ключевой вывод: Android — это открытый программный стек на базе ядра Linux. Его ценность — в многоуровневой архитектуре (ядро Linux → HAL → ART/нативные библиотеки → Java API Framework → системные приложения), которая балансирует абстракцию от железа и экосистему приложений. Разработчику понимание среды выполнения ART и эволюции уровней API необходимо для совместимости; продвинутому пользователю знание модели разрешений и механизмов многозадачности даёт реальный контроль над устройством и приватностью. На июнь 2026 года актуальная стабильная версия — Android 17, API level 37, с существенными изменениями в управлении памятью, сессионных разрешениях и взаимодействии со складными экранами.

Версии Android традиционно обозначались «десертными» кодовыми именами в алфавитном порядке, но начиная с Android 10 Google постепенно отошёл от публичных кодовых имён в пользу номера версии и уровня API.

Начало и фрагментация (2008–2013). В сентябре 2008 года Android 1.0 вышел с HTC Dream. Ранние версии сменялись очень быстро: Cupcake (1.5), Donut (1.6), Eclair (2.0–2.1), Froyo (2.2), Gingerbread (2.3) — за два года. Honeycomb (3.0, 2011) создавался для планшетов, но рынок принял его сдержанно; Ice Cream Sandwich (4.0) в том же году объединил дизайн-язык телефонов и планшетов, принёс стиль Holo и аппаратное ускорение рендеринга — ключевой момент зрелости Android.

Единый дизайн и смена среды выполнения (2014–2016). Android 5.0 Lollipop — поворотная версия. Появился Material Design, а среда выполнения Dalvik была полностью заменена на ART (Android Runtime) со смешанным режимом AOT ( ahead-of-time) и JIT (just-in-time), что заметно улучшило плавность и эффективность памяти. Marshmallow (6.0) ввёл модель разрешений времени выполнения: пользователь может отклонить или выдать отдельное разрешение во время работы приложения вместо разового согласия при установке.

Модернизация и годовой ритм (2017 — настоящее время). С Android 8.0 Oreo Google стабилизировал ритм — один мажорный релиз в год. Oreo принёс ограничения фонового выполнения и каналы уведомлений; Android 10 — жестовую навигацию и более гранулярные разрешения на местоположение; Android 12 — динамическую палитру Material You; Android 13 — песочницу приватности и настройку языка для каждого приложения; Android 14 и 15 сосредоточились на адаптации к большим экранам, уточнении типов foreground-сервисов и частичном захвате экрана. Android 17 вышел в июне 2026 года; ключевые изменения — строгие лимиты памяти для приложений, сессионная авторизация данных и игровой режим для складных устройств.

Официальная схема архитектуры Android делит систему на пять слоёв сверху вниз. Понимание роли каждого — предпосылка для локализации проблем производительности и корректного проектирования границ модулей.

Слой ядра Linux. Основа Android. Отвечает за планирование потоков, низкоуровневое управление памятью, управление питанием и драйверы оборудования (дисплей, аудио, камера, Bluetooth, Wi-Fi и т. д.). На ядре также базируются низкоуровневые функции ART. Для разработчика этот слой обычно невидим, но версия ядра определяет доступность некоторых низкоуровневых API.

Слой аппаратной абстракции (HAL). Состоит из набора библиотечных модулей, каждый из которых определяет стандартный интерфейс для конкретного аппаратного компонента (камеры, Bluetooth и т. п.). Когда Java API Framework обращается к аппаратной функции, система загружает соответствующий модуль HAL. Такая схема позволяет Android работать на устройствах разных производителей, не раскрывая проприетарные детали реализации.

Среда выполнения Android (ART) и нативные библиотеки. Начиная с Android 5.0 каждое приложение работает в отдельном процессе со своим экземпляром ART. ART исполняет байт-код DEX (Dalvik Executable), а инструменты сборки (например, d8) компилируют исходники Java/Kotlin в DEX. Ключевые возможности ART — AOT- и JIT-компиляция, оптимизированная сборка мусора (GC), а с Android 9 — преобразование DEX-файлов в более компактный машинный код. Отладка поддерживает специализированный сэмплирующий профайлер, подробные отчёты об исключениях и падениях, а также точки наблюдения за полями (watchpoint). Что это значит для разработчика: ограничение в 64K методов DEX хотя и смягчено multidex, но производительность запуска по-прежнему тесно связана со стратегией загрузки классов; поведение OOM на устройствах с малым объёмом памяти напрямую зависит от стратегии GC в ART.

Java API Framework. Слой SDK, с которым разработчик сталкивается ежедневно. Предоставляет View System, менеджер ресурсов, менеджер уведомлений, Activity Manager, Content Provider и другие ключевые компоненты. Системные и сторонние приложения используют один и тот же набор API — это значит, что стороннее приложение может стать браузером по умолчанию, приложением для SMS или клавиатурой, за исключением немногих системных приложений вроде «Настроек». Что это значит для разработчика: уровень API (API Level) слоя Framework — жёсткая граница совместимости, которой нужно управлять через minSdkVersion, targetSdkVersion и проверки версии во время выполнения.

Слой системных приложений. Предустановленные核心-приложения (телефон, почта, календарь, камера и т. д.). Они равноправны с установленными пользователем приложениями, но предоставляют ключевые функции, которые могут вызывать другие приложения (например, при отправке SMS вызывается установленное приложение для SMS, а не собственная реализация).

3.1 Уровни API и стратегия совместимости

Соответствие версий Android и уровней API — базовая система координат в разработке. Ближайшие ключевые точки: Android 13 → API 33, Android 14 → API 34, Android 15 → API 35, Android 16 → API 36, Android 17 → API 37. targetSdkVersion влияет не только на включение изменений поведения, но и на требования Google Play к публикации. Рекомендуемая стратегия: новые проекты сразу ориентировать на актуальный стабильный API; в поддерживаемых проектах как минимум раз в год просматривать список изменений поведения, уделяя особое внимание ограничениям фона, разрешениям и доступу к хранилищу.

3.2 Среда выполнения и производительность

Смешанный режим компиляции ART означает, что приложение не обязательно полностью AOT-компилируется при установке — в процессе работы «горячий» код компилируется JIT, а результат компиляции сохраняется. Практические рекомендации: избегать массовой загрузки классов и рефлексии на пути запуска; использовать Baseline Profiles, чтобы ART предварительно компилировал критические пути при установке — это заметно улучшает первый запуск и переходы между экранами. Android 17 дополнительно ужесточает лимиты памяти приложений: система накладывает жёсткий потолок в зависимости от общего объёма RAM устройства, и процесс, превысивший лимит, немедленно завершается. Это значит, что последствия утечек памяти серьёзнее, чем раньше, — к логике освобождения ресурсов в колбэке onTrimMemory нужно относиться внимательно.

3.3 Последовательное ужесточение модели разрешений

От разрешений времени выполнения в Android 6 до ограничений фонового доступа к местоположению в Android 10, разовых разрешений и автоматического сброса в Android 11 — гранулярность разрешений постоянно растёт. Android 17 вводит сессионную авторизацию данных: приложению больше не нужно запрашивать доступ ко всей адресной книге ради получения контактов — пользователь может авторизовать только конкретные номера телефонов или адреса электронной почты, причём доступ действует лишь в рамках текущей сессии. Что это значит для разработчика: функциональный дизайн, опирающийся на «чтение всех контактов» или «постоянную точную геолокацию», нужно пересматривать. Рекомендуется заранее адаптироваться к модели запроса по требованию и поштучной авторизации, иначе на устройствах с Android 17 может не хватить прав доступа к данным.

3.4 Адаптация к большим экранам и складным устройствам

Android 16 и 17 последовательно усиливают работу с большими экранами. Android 17 вводит для складных устройств игровой макет 50/50: верхняя половина экрана показывает игровое изображение, нижняя — динамический интерфейс геймпада, с поддержкой нативного переназначения кнопок внешних контроллеров. Кроме того, «пузыри» (Bubbles) позволяют превратить любое приложение в плавающее окно и централизованно управлять ими на панели задач больших устройств. Рекомендации по адаптации: не предполагать фиксированное соотношение сторон или ориентацию; использовать WindowSizeClass из WindowManager для динамической подстройки макета; тестировать сохранение состояния и изменения конфигурации при переключении форм-фактора (сложен/разложен).

3.5 Безопасность и эволюция подписи

Android 17 начинает поддерживать постквантовую криптографию — подписи ML-DSA — и вводит схему подписи APK v3.2, сочетающую традиционную подпись с подписью ML-DSA. Для подавляющего большинства приложений это изменение прозрачно (обрабатывается Play Store и цепочкой инструментов сборки), но сценарии с собственной проверкой подписи или корпоративным распространением требуют внимания к совместимости обновлений хранилища ключей (Keystore).

4.1 Тщательный аудит и отзыв разрешений

Переключатели разрешений, которые обычный пользователь видит в настройках, — лишь первый уровень. Продвинутому пользователю стоит освоить команду adb shell appops: она позволяет просматривать и изменять операции (app ops) на уровне отдельных действий, зачастую более гранулярные, чем разрешения времени выполнения (например, READ_CLIPBOARD, RUN_IN_BACKGROUND, WAKE_LOCK). Сессионная авторизация в Android 17 дополнительно снижает необходимость в долгосрочных разрешениях, но appops даёт дополнительный рычаг для ограничения «упрямого» фонового поведения устаревших приложений.

4.2 Активное управление фоном и памятью

Механизм строгих лимитов памяти в Android 17 означает, что система будет активнее, чем раньше, завершать процессы, превышающие квоту. Для задач, которым нужно долго работать в фоне (синхронизация файлов, обработка аудио), одной опоры на foreground-сервис уже недостаточно. Рекомендуемые подходы: использовать WorkManager для отложенных задач; для сценариев с постоянным уведомлением — корректно объявлять тип foreground-сервиса (обязательно с Android 14) и управлять моментом показа уведомления через setForegroundServiceBehavior. Продвинутый пользователь может имитировать условия нехватки памяти через «Ограничение фоновых процессов» и «Не сохранять активности» в параметрах разработчика, проверяя поведение критичных приложений.

4.3 Новое измерение многозадачности: Bubbles и Continue On

Bubbles в Android 17 позволяют любому приложению постоянно присутствовать в виде плавающего пузыря. С точки зрения пользователя это гибче классического разделения экрана: пузыри можно перетаскивать, складывать в стопку, закреплять на специальной панели внизу больших устройств. Вместе с Continue On (продолжение задачи между устройствами) на планшете можно прямо с панели задач вызвать последнее использованное приложение с телефона. Практические сценарии: плавающее приложение для заметок во время видеоконференции, наложение управления музыкой поверх навигации, просмотр гайда в паузе игры. Учтите: злоупотребление пузырями расходует дополнительные системные ресурсы (каждый пузырь по сути — отдельное окно/процесс), поэтому включайте их только для часто переключаемых приложений.

4.4 Запись экрана и создание контента

Screen Reactions — встроенная в Android 17 функция для авторов контента: запись себя с фронтальной камеры одновременно с захватом экрана, без хромакея и сторонних приложений. Технически она объединяет MediaProjection и превью камеры и предоставляет упрощённую панель инструментов. Для продвинутого пользователя это означает, что системная запись экрана больше не ограничивается «картинка + микрофон» — можно накладывать живой комментарий, что удобно для обучающих роликов, реакций или воспроизведения багов. Учтите: функция доступна только при настройке записи экрана «Полный экран», а флаг безопасности (FLAG_SECURE) некоторых приложений по-прежнему блокирует запись.

4.5 Проактивное усиление безопасности

Find Hub в Android 17 расширяет функцию «Пометить как потерянное»: даже если посторонний узнал PIN-код устройства, для разблокировки устройства в режиме потери или отключения геолокации потребуется биометрическая аутентификация. Кроме того, уменьшено допустимое число последовательных неверных вводов PIN и увеличено время ожидания — для противодействия перебору. Рекомендации продвинутому пользователю: включить «Режим расширенной защиты» (Advanced Protection Mode) для более строгого обнаружения и блокировки угроз; регулярно проверять состояние разрешений и appops приложений через adb shell dumpsys package, своевременно выявляя аномальные авторизации.

Сложность Android — в многослойной абстракции: под Java API Framework, который видит разработчик, скрываются стратегии компиляции ART, аппаратная абстракция HAL и механизмы планирования ядра Linux; над экосистемой приложений, которую видит пользователь, — постоянное ужесточение модели разрешений, управления памятью и фоновых ограничений. Для разработчика в 2026 году ключевые действия: адаптироваться к сессионным разрешениям и строгим лимитам памяти Android 17, проверить макеты для складных и больших экранов, оценить выгоду Baseline Profiles для производительности запуска. Для продвинутого пользователя ключевые действия: использовать appops и параметры разработчика для гранулярного аудита, понимать границы применимости Bubbles и WorkManager, активно включать расширенную защиту на основе усилений безопасности Android 17. Общая для обоих истина: открытость Android никогда не означала отсутствие ограничений — она лишь переносит ограничения с «разовой авторизации при установке» на «непрерывные переговоры во время выполнения и на уровне системы».