🤖 На Google I/O 2026 Google официально переименовала Android из операционной системы в "intelligence system"

Самое интересное для разработчиков - AppFunctions. Это experimental preview API + Jetpack библиотека, которые позволяют приложению стать on-device MCP (Model Context Protocol) сервером. Агенты вроде Gemini смогут обращаться к функциям приложения через стандартный протокол, без скрейпинга UI. Для отладки выпустили тест-агент, для раннего выхода в production открыта форма early access.

По on-device моделям: ML Kit GenAI APIs теперь работают с Gemini Nano 4 (preview). Prefix Caching уже доступен — кеширует промежуточное состояние LLM для повторяющихся частей промпта, снижает время инференса. Structured Output API скоро - типизированные объекты на выходе вместо свободного текста.

Firebase AI Logic Hybrid Inference добавляет явный контроль маршрутизации — режимы PREFER_ON_DEVICE, PREFER_CLOUD, ONLY_ON_DEVICE, ONLY_CLOUD прямо в коде. ADK for Android в первой версии позволяет строить multi-agent workflows с оркестрацией между on-device и cloud моделями.

Ещё есть A2UI + Compose Renderer: агент "говорит UI", Compose рендерит ответ как нативные компоненты. Пока чистый эксперимент, но направление понятное. Вот для чего делается Compose BDUI

Меня больше всего интересует AppFunctions. MCP как стандарт уже работает в десктопных агентах, и Google принесла это на уровень ОС — правильное решение. Вопрос в том, насколько быстро экосистема это подхватит за пределами флагманских приложений и почему не подключать сервер к этому, я использовать интеграцию через приложение

🔗 Источник - Android Dev Blog

#Android #AndroidDev #GoogleIO #AI

🤩 Готовишься к OOD-собеседованию? Новая книга в помощь

10 июня в издательстве «Питер» выходит «Object Oriented Design. Подготовка к сложному интервью» Алекса Сюя — автора бестселлера про System Design и бывшего инженера Twitter, Apple, Zynga и Oracle.

🤐 Внутри:
🔗 Чёткая 4-шаговая схема решения любой OOD-задачи
🔗 Глубокий разбор ООП и принципов SOLID
🔗 14 готовых систем: парковка, кинотеатр, банкомат, лифты, ресторан и др.
🔗 11 реальных задач с интервью с подробным разбором решений
🔗 133 диаграммы архитектур и процессов
🔗 Паттерны проектирования + советы по коммуникации с интервьюером

🎁 Промокод broadcast — скидка 5% на книги издательства "Питер"!

#реклама

🤖 Google прилагает много усилий, чтобы сделать разработку адаптивных интерфейсов проще: библиотеки, поддержка в IDE, инструменты и пр. Понятно, ведь растет популярность складных устройств. Компания старается расширить Android за пределы смартфона, а складные смартфоны набирают обороты популярности (хоть и медленно).

‼️ Android 17 вскроет все недостатки ваших приложений на планшетах и складных смартфонах, потому что там теперь будут игнорироваться ограничения окон приложений.

В ближайших постах я пройдусь по основам адаптивности интерфейса, а пока вы можете изучить:
👉 Обзор экосистемы адаптивности от Google для Android
📹 Adaptive development for the expanding Android ecosystem
📹 Make your UI adaptive with Android Studio's AI agent
👉 Build adaptive apps
👉 Критерии качества адаптивных приложений (3 уровня)

#Android #AndroidDev #UI #Foldable #Планшет

🤖 ⚙️ Адаптивность под разные экраны — одна из тех вещей, которые откладывают до последнего. А когда приходит требование поддержать планшет, начинается боль. Хотя в Compose это решается в несколько строк.

GridCells.Adaptive сам рассчитывает колонки под доступное пространство — ничего не нужно задавать вручную:

LazyVerticalGrid(
    columns = GridCells.Adaptive(minSize = 160.dp),
    modifier = Modifier.fillMaxSize()
) {
    items(list) { ItemCard(it) }
}

Но почти всегда забывают про пагинацию. pageSize хардкодят, и это ломает всю адаптивность. На планшете с 4 колонками те же 20 элементов — это 5 строк. Пользователь упирается в конец страницы раньше чем успел проскроллить.

Правильно — считать pageSize от реального числа колонок:

BoxWithConstraints {
    val columns = (maxWidth / 160.dp)
        .toInt().coerceAtLeast(1)
    val rows = (maxHeight / 120.dp)
        .toInt().coerceAtLeast(1)
    val pageSize = columns * rows

    val items = remember(pageSize) {
        Pager(PagingConfig(pageSize = pageSize)) { MyPagingSource() }
    }.flow.collectAsLazyPagingItems()

    LazyVerticalGrid(
        columns = GridCells.Adaptive(minSize = 160.dp)
    ) {
        items(items.itemCount) { ItemCard(items[it]) }
    }
}

На смартфоне выйдет ~10 элементов, на планшете ~30. Никаких магических чисел — только математика от реального пространства.

Самый хороший пример тут - галерея. Они показывают адаптивную сетку контента и имеет возможность настройки другого расположения элементов

🔗 Lazy lists and grids — Android Developers

#Compose #Android #AndroidDev #Ui #Adaptive #Адаптивность

🤯 Android 17 умеет убивать ваше приложение молча. Без стектрейса. Разбираемся. И ЭТО БЕЗ КЛИКБЕЙТА

Начиная с Android 17, появился системный MemoryLimiter — лимит памяти на процесс, привязанный к общему объёму RAM устройства. Превысил лимит — процесс убит. Без exception, без стектрейса.

Как это выглядит:
👉 причина завершения в ApplicationExitInfo = REASON_OTHER
👉 в описании строка "MemoryLimiter:AnonSwap"
👉 в Crashlytics этого НЕ будет: это не краш, а системное убийство процесса

И сразу разрушим главное заблуждение: это НЕ про heap size.

getMemoryClass() и largeHeap ограничивают только Java-кучу — объекты под управлением ART. Превысил и получишь OutOfMemoryError со стектрейсом, который ловится. А новый MemoryLimiter считает другое - анонимную память ВСЕГО процесса:
👉 битмапы (с Android 8 их пиксели в нативной памяти, в Java-куче их нет)
👉 нативные библиотеки, медиакодеки, Skia
👉 веса on-device ML/LLM моделей

Всё это в getMemoryClass() не видно. Можно сидеть втрое ниже heap-лимита, никогда не словить OOM — и всё равно быть убитым, потому что суммарная нативная память процесса вылезла за порог. getMemoryClass и OOM — про Java-кучу. MemoryLimiter — про весь процесс. Это два разных предохранителя, и старый про новый вам ничего не скажет.

Важные оговорки, чтобы не было паники на пустом месте:
👉 в Android 17 лимиты заданы консервативно: цель — экстремальные утечки и выбросы, а не нормальные приложения
👉 включены только на части устройств
👉 конкретных чисел Google не публиковал. Реальный лимит своего девайса можно снять командой: adb shell am memory-limiter status

В зоне риска тяжёлые сценарии на устройствах среднего и бюджетного сегмента.
Уже есть задокументированный случай на бете — крупная on-device модель Gemma падала на Pixel 6a с 6 ГБ RAM именно из-за MemoryLimiter. 6 ГБ — это уже не бюджетник. Java-куча там небольшая, а нативка с весами модели — гигабайты в RAM.

Два мифа, которые гуляют по сети и которые повторять не надо:
👉 НЕТ подтверждения, что система шлёт «вежливое предупреждение» перед убийством
👉 НЕТ официального «дедлайна для разработчиков 30 июня». Google его не объявлял

Это первый раз, когда дисциплина по памяти не совет, а правило от ОС. Сейчас лимиты мягкие, но направление одностороннее — закручивать будут, а не отпускать. И самое неприятное тут не сам лимит, а его невидимость: пользователи будут терять сессии, а вы не узнаете, пока специально не начнёте смотреть.

💬 Как вы думаете, связаны ли меры с тем, что оперативка стала дорожать и вставить по 12–16 ГБ стало дорого?

#Android #Android17 #Производительность

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

#Android #AndroidDev #Производительность #Оптимизация

🔴 Созвон Закрытого Сообщества. Жаркая дискуссия: какой агент лучше. Best practices, ошибки и как работать с ИИ.

Гость — Никита @Nek.12. Один из немногих в русскоязычном сообществе, у кого я реально нашел много интересного для работы с ИИ. Никита не использует Claude Code, Codex или Cursor. Он написал своего агента с нуля. Builder — это CLI-хarness с супервайзером, скиллами, Docker-сэндбоксингом, клиент-серверной архитектурой и возможностью гонять агента автономно сутками. Всё сам. В одиночку.

У нас принципиально разные подходы. Я работаю с Claude Code, активно использую MCP-серверы и верю в это. Никита написал статью "MCP is Deprecated" и считает, что сложные агентные оркестраторы — это микроменеджмент, который мешает модели работать.

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

Формат — живой разговор, вы можете задавать вопросы в чате прямо во время эфира.

🪙 Стрим пройдет для платных подписчиков на Boosty

#AndroidBroadcast #LIVE

👨‍💻 Новый девайс — это хорошо. Новый уровень комфорта — ещё лучше.

Разработчики знают: иногда главный апгрейд — не новый ноутбук, а удобное место, где ты проводишь по 8–10 часов в день.

С 12 по 21 июня (включительно) Эргостол запустил акцию «Открой просторы выгоды»:

🛒 скидки до -25% на товары для рабочего пространства
➗ скидки суммируются с промокодом -10% ANDROID10

Если давно думали добавить в сетап регулируемый стол, удобное кресло или полезные аксессуары — сейчас хороший момент.

➡️ Собери свой идеальный сетап разработчика: по ссылке
Промокод ANDROID10 действует и на Ozon 🛒

#реклама

🤖 Android CLI 1.0: зачем это нужно, если всё уже есть

В Android-разработке с помощью агентов есть конкретная проблема — инструменты разбросаны:
👉 Хочешь запустить эмулятор — avdmanager
👉 Поставить пакет SDK — sdkmanager
👉 Задеплоить APK — adb
👉 Получить версии зависимостей — отдельный запрос к Google Maven
👉 Получить актуальную информацию по гайдам — Web-поиск или Google Developer Knowledge API

Агент вынужден знать синтаксис каждого, склеивать их через shell-команды и угадывать правильные пути. Android CLI 1.0 — это единая точка входа, которая агрегирует всё это в один инструмент с предсказуемым интерфейсом.

Почему CLI, а не MCP-сервер? Вопрос разумный. Но ответ простой: CLI работает с любым агентом без дополнительной интеграции. Настроил инструмент один раз, и он работает с Gemini CLI, Codex, Antigravity, чем угодно. Никаких зависимостей от протокола, никакого выбора поставщика. Хочешь взять только часть — берёшь только её.

Конкретно для агентов в 1.0 есть три вещи, которые раньше было негде взять:
1️⃣ Скиллы. android init ставит android-cli skill с Android-контекстом, android skills add --all добавляет готовые паттерны под конкретные задачи: CameraX, Perfetto SQL, Adaptive UI, AppFunctions. Агент работает не вслепую.
2️⃣ Анализ экрана девайса/эмулятора. android screen capture --annotate делает скриншот с числовыми лейблами на каждом UI-элементе, android screen resolve переводит лейбл в координаты. android layout отдаёт дерево UI в JSON без скриншота вообще.
3️⃣ Запуск Journeys. Описываешь сценарий словами, агент проходит его на устройстве и проверяет результат.
4️⃣ Поиск по Android-документации.

Можно было бы сделать MCP. Он дал бы более тесную интеграцию, но CLI универсальнее и проще в поддержке с любой стороны инструмента, который должен работать везде — это правильное решение.

#Android #AndroidDev #GoogleIO

🐘 Room тихо ломает ваш build cache

Команда прогнала свой браузер (открытый проект на 160 модулей) через открытые Develocity Build Validation Scripts. Скрипты гоняют сборку в разных условиях и показывают, какие задачи зря выполняются заново вместо того, чтобы взяться из кеша.

Главная находка про Room. Пути экспорта схем были заданы абсолютными, значит на каждой машине (ноутбук разработчика, CI-агент) получался свой input и свой ключ кеша. Любая сборка на другой машине била мимо. Лечится переходом на Room Gradle Plugin, который держит относительные пути. После фикса в эксперименте с разными путями на диске выполняемых задач стало 27 вместо 440.

😁 Вторая находка про Dagger. Либа генерила классы с непредсказуемым порядком методов: один и тот же исходник на двух CI-ранах давал побайтно разный вывод и промах по кешу. Апгрейд до Dagger 2.53+ с детерминированным выводом вернул в кеш 1619 задач. Опять же важность обновления до свежих версий.

Цифрами по статье манипулируют знатно. Заголовочные 57% относятся к лучшему локальному сценарию: сборке в git worktree после CI. Сквозной выигрыш по реальному CI скромнее, 19% на полном пайплайне с тестами и 39% на сборке debug APK. Инструментальные и Firebase-тесты не кешируются в принципе, поэтому потолок там ниже. Но даже из этого уже есть простые оптимизации, которые стоит проверить.

🔗 Источник - статья на Gradle блоге

#android #gradle #room #buildcache #dagger

🤖 Android XR Developer Preview 4: можно потрогать без железа

Google выпустили Developer Preview 4 XR SDK. Главное, что снижает порог: XR Emulator встроен в Android Studio, итерировать можно без Samsung Galaxy XR в руках.

Для мобильных разработчиков добавили нормальный способ расширить существующее приложение на display glasses. Jetpack Projected получил Device Availability API — привязывается к стандартным Android Lifecycle-состояниям, апп адаптируется к очкам нативно. Ускорить переезд помогает Android CLI с display glasses skill — специализированные скиллы, которые делают UI на Compose Glimmer по паттернам Google. Сам Glimmer в этом превью обновили под прозрачные дисплеи: читаемость текста и touchpad-навигация.

Для game dev: Unreal Engine и Godot теперь официально поддерживаются наряду с Unity. Вместе с ними выпустили Android XR Engine Hub под Windows — real-time тест прямо во viewport движка.

Открылась Android XR Developer Catalyst Program: пре-релизное железо (display glasses + wired XR), поддержка и помощь с запуском на Google Play. Заявки принимают прямо сейчас.

🔗 Источники - android-developers.googleblog.com

#AndroidXR #Jetpack #Android