🛒 Google Play на I/O 2026: что изменится для разработчиков

На I/O 2026 Google анонсировал пачку изменений в Play — часть из них работает сама по себе, часть требует действий от разработчика. Разберу в двух постах: сначала discovery и охват, потом монетизация и инструменты.

⭐️ Главное изменение в поиске и открытии приложений через Gemini. В ближайшие недели приложения начнут появляться в ответах Gemini на Android и в вебе. Позже туда добавятся фильмы, сериалы и спорт с deep-link прямо в твоё приложение. Ничего делать не нужно — но это меняет то, как работает органика.

⭐️ Следом идёт Ask Play: AI-оверлей поверх поиска, который понимает контекст запроса и уточняющие вопросы. Google говорит, что AI Q&A уже закрывает 95% запросов. Практическое следствие: описание приложения теперь важнее как семантический текст, а не набор ключевиков.

🚀 Engage SDK вырос на 45% год к году при 30M MAU. Добавляют показ контента прямо на странице приложения в сторе, планшетные поверхности и расширение на 80+ рынков. Если ещё не интегрировал - момент подходящий, обновлений от разработчика для новых фич не нужно.

😁 Play Shorts — вертикальный short-video формат для демонстрации приложений внутри стора. Пока только США и ограниченный круг разработчиков, расширение обещают позже.

🔗 Источник

#Android #GooglePlay

🪙 7 стадий AI в разработке: от скептика к архитектору — доклад с Mobius

Опубликовал запись своего выступления с конференции Mobius Москва Весна 2026 в Москве. Рассказал о своём пути адаптации к ИИ, какие вызовы пришлось решать и как я менял отношение и подход к работе с ИИ, чтобы достигать ожидаемых результатов при разработке программного обеспечения.

📹 Публичная версия будет опубликована позже в каналах конференции Mobius.

#Mobius #AI #ИИ

📹 Не знаете чем заняться в выходные? Стали доступны записи докладов с Google I/O 2026

#Android #GoogleIO

🤖 На 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

🤖 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