🤖 Много памяти в смартфонах — это не маркетинг, а инженерная необходимость

Современный флагманский смартфон — это система из взаимосвязанных компонентов:
- Большой экран с высоким разрешением и 120+ Гц
- Мощная камера с 4K/60FPS видео и многокадровой обработкой
- On-device ИИ без интернета
- Топовый процессор от Qualcomm

Когда ты покупаешь такой телефон, ты ожидаешь, что ничего не будет тормозить. И вот беда — для этого нужна оперативная память. Много....


🏢 Почему Pixel 8 не получил ИИ
Помните, когда Google представили Pixel 8? Фишка была в том, что ИИ работает прямо на устройстве, без облака. Звучало отлично. Но Pixel 8 получил эту фичу только в виде бета-версии. Полноценно она работала только на Pixel 8 Pro.
Причина одна: памяти не хватает.
Pixel 8 Pro имеет 12 ГБ оперативной памяти. Pixel 8 имеет 8 ГБ. Разница в одной цифре, но это критично.

Вот как распределяется память:
- Android ОС: 4 ГБ (обязательно)
- Google Play Services: 1 ГБ (постоянно работает)
- Фоновые процессы: 2-3 ГБ (система держит приложения в памяти)
- On-device ИИ: 3-4 ГБ (чтобы работал всегда готов)
Итого базовые: 12 ГБ

На Pixel 8 просто нечем запустить ИИ, не ломая остальное. На Pixel 8 Pro есть запас. Вот и вся история.


🤖 Проблема с разработчиками приложений
Кстати, есть ещё один момент, который все игнорируют. Разработчики приложений не спешат оптимизировать код.
Почему? Потому что нет критических проблем или потерь репутации. Это затратно — нужны хорошие специалисты, исследования, тестирование. А пока приложение “вроде работает”, зачем?
Разработчики рассчитывают, что пользователь просто купит себе телефон мощнее. Это же работает в разработке игр — выпустил требования на RTX 4080, и всё, проблема решена.
Но со смартфонами этот сценарий начинает ломаться.


💲 2026: год дефицита памяти
Сейчас происходит кризис памяти. AI серверы пожирают DRAM как не в себя. Цены растут. Производители уже обсуждают, как урезать объём памяти в 2026-м году.
И вот здесь наступает проблема: мы больше не сможем рассчитывать на стабильный рост памяти каждые 5 лет. Это становится роскошью.

Вопрос: что будет с телефонами? Память станет сдерживающим фактором всего развития. Флагманы смогут подороже продаваться с запасом памяти — да, давай по 16-20 ГБ и цена выше. Но бюджетный сегмент начнёт деградировать. Samsung выпускает серию A годами с одними и теми же характеристиками, только наименование меняет. Народ покупает — что ещё им остаётся? И то что телефон лагает — это уже проблема пользователя.


🤔 Вывод: память — это потолок на развитие
Всё, что мы видим в смартфонах, ограничено одной переменной: количеством оперативной памяти.
- Больше памяти → можно добавить ИИ
- Больше памяти → можно поднять разрешение экрана
- Больше памяти → можно оставить больше приложений в фоне
- Больше памяти → можно записывать 8K видео без подвисаний

Без памяти все эти фишки просто не работают.

И когда памяти становится дефицит, а цены на неё растут — рост характеристик смартфонов замораживается. Мы уже не сможем видеть стабильный апгрейд каждый год.
Первыми это почувствуют пользователи бюджетного сегмента. Их телефоны будут либо дорожать, либо худеть в характеристиках. Третьего не дано.

🛒 Save for Later — больше гибкости для релизов в Google Play Console

Google запустил функцию "Save for later" в Google Play Console. Теперь можно контролировать, какие изменения отправлять на ревью, а какие пока отложить.

Раньше все изменения автоматически группировались и отправлялись на ревью вместе.

Это создавало сложности:
👉 Приходилось задерживать hot fix или публиковать изменения, которые ещё не готовы
👉 Нельзя было разделить обновление тестовых треков и маркетинговые изменения
👉 Сложно было поменять решения касательно релиз на ходу

Теперь в разделе "Changes not yet sent for review" можно отметить группы изменений как "Save for later".

Эти изменения:
👉 Не попадут в текущее ревью
👉 Можно в любой момент вернуть обратно
👉 После начала ревью автоматически вернутся в очередь

Функция работает вместе с проверками перед ревью.

Новая фича позволяет быстрее итерировать и минимизировать влияние реджектов на график релизов. Особенно полезно, когда часть изменений готова, а часть — нет.

🔗 Подробности в блоге

💬 В комментариях расскажите сталкивались ли вы с подобной задачей и что новая функция упростит вам работу

#Android #GooglePlay

🏝 Когда стоит убить Kotlin демона для ускорения сборки

Если у вас тяжёлая Android-сборка (много модулей, R8, CI с ограниченной памятью), имеет смысл принудительно завершать Kotlin Daemon после компиляции и до запуска R8 🔪

Kotlin Daemon нужен только на этапе компиляции Kotlin. После этого он спокойно живёт до конца сборки и держит память. R8 — один из самых прожорливых этапов по CPU и RAM 🔥 По итогу Daemon и R8 начинают конкурировать за ресурсы памяти

Что вы реально получаете если убивает Kotlin демона после компиляции кода:
🚀 снижение пикового потребления памяти примерно на 13–15%
🚀 ускорение R8 вплоть до ~7%
🚀 небольшое, но стабильное сокращение общего времени сборки
🚀 максимальный эффект на CI, где нет долгоживущих демонов и инкрементальности

‼️ Этот подход сработал для автора статьи, но для вас может ничем и не помочь, особенно в сборке на локальной машине.

🔗 Источник с измерениями и подробным разбором

#Android #Kotlin #R8 #Gradle

🤖 Разница между Permission и Ability в Android ОС

Чтобы получить доступ к пользовательским данным или сенсорам, разработчику приходится работать с механизмом разрешений (permissions): пользователь должен выдать приложению право на использование соответствующего ресурса. Однако наличие Permission не гарантирует, что приложение действительно сможет получить эти данные.

Например, приложению выдали доступ к геолокации, и формально оно имеет право узнать, где находится пользователь. Но при запросе локации приложение получает null. Почему?

Здесь и появляется понятие Ability — фактическая возможность получить данные в текущий момент времени. И она может отсутствовать даже при наличии разрешения.

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

Итог: Permission — это юридическое право, Ability — это реальная техническая возможность.

С точки зрения архитектуры, наличие permission не должно рассматриваться как гарантия наличия данных. Бизнес-логика и use case’ы должны быть спроектированы так, чтобы корректно работать в ситуации отсутствия ability.

Другими словами: приложение должно быть готово к тому, что внешний мир в любой момент может стать недоступным — даже если формально все разрешения выданы. Это означает:
1️⃣ отсутствие жёстких предположений о доступности данных;
2️⃣ обработку null, ошибок и таймаутов как нормального сценария;
3️⃣ явное моделирование состояний «данные недоступны» в доменной модели.

Permission — это контракт с пользователем. Ability — это контракт с реальностью. И именно второй чаще всего нарушается.

#AndroidDev #AndroidOS #Архитектура

🤖 Android Gradle Plugin 9 упрощает запуск unit-тестов

По умолчанию Android Gradle Plugin создаёт Gradle-задачи для запуска unit-тестов во всех доступных build types, что на практике почти никогда не нужно. Обычно тесты запускаются только для debug-сборки.

В реальных проектах (особенно с product flavors и большим количеством модулей) это приводит к сотням лишних задач, увеличению времени конфигурации и дополнительной нагрузке на IDE и CI.

Чтобы оптимизировать работу Gradle, начиная с AGP 9.0, можно в gradle.properties добавить:

android.onlyEnableUnitTestForTheTestedBuildType=true

После этого unit-тесты будут генерироваться только для основного тестируемого build type (как правило, debug). Это:
👉 убирает лишние Gradle-задачи;
👉 сокращает время конфигурации проекта;
👉 снижает потребление памяти;
👉 ускоряет локальную разработку и CI-пайплайны.

Если вы не запускаете unit-тесты для release-сборок (а так делают почти все), то включение этого флага — бесплатная оптимизация сборочной инфраструктуры.

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

#Android #AndroidDev #Gradle

🤖 Улучшения R8 - минификатора кода в Android

В AGP 9.0 R8 получил несколько изменений, в основном направленных на оптимизацию Kotlin-кода, упрощение desugaring-пайплайна и улучшение диагностики.

Основные изменения:

👉 Новая опция -processkotlinnullchecks для обработки null-проверок, сгенерированных компилятором Kotlin. Можно задать одно из значений:
- keep - оставить проверки;
- remove_message - убрать сообщения об ошибках;
- remove - полностью удалить проверки.

Опция используется для уменьшения байткода и снижения runtime-накладных расходов в production. Я еще в 2019 писал статью про это и удалял код с помощью -assumenosideeffects

👉 Keep rules больше не применяются к companion methods
R8 перестал переносить keep-информацию на синтетические companion-методы, сгенерированные при desugaring интерфейсов.
Это ломает редкий кейс с minSdk < 24, но делает поведение более консистентным с остальными синтетическими элементами.

👉 Минимизированные имена синтетических классов в L8
L8 теперь генерирует более короткие имена для synthetic-классов ($1, $2 вместо длинных $$ExternalSynthetic...), что уменьшает размер DEX.

L8 — это утилита, стоящая за library desugaring в Android. Позволяет использовать новые API на старых версиях Android и править баги в них, делая использование API прозрачным.

AGP 9.0 прокачало R8 и L8, чтобы делать меньше лишнего байткода, более агрессивно оптимизировать Kotlin. Большинство изменений работают прозрачно, но в сумме дают более компактные сборки и более предсказуемый build-процесс.

🔗 Источник - документация по AGP 9.0

#Android #AndroiDev #Gradle #R8

🤖 Если используете AndroidX Paging, то вам стоит обновить код. Для лучшего определения позиции на основе которой генерировать ключ для обновления появилось API PagingState.closestItemAroundPosition()

override fun getRefreshKey(state: PagingState<Int, UiItem>): Int? {
    val anchor = state.anchorPosition ?: return null

    val closestItem = state.closestItemAroundPosition(
        anchorPosition = anchor,
        // например, пропускаем разделители/заглушки
        predicate = { it.isAnchorable }
    )

    return closestItem?.id
}

#Android #AndroidX

🤖 Разбираюсь с системой разрешений в Android и снова упираюсь в один и тот же вопрос: почему до сих пор нет AndroidX‑решения, которое бы упростило всю эту рутину?

В каждом проекте встречается тонны похожего кода для работы с разрешениями — и чаще всего без учёта лучших практик. Разработчики нередко просто запрашивают разрешение “в лоб”, не обрабатывая отказы корректно. Если пользователь отказал — то сразу перекидывают в настройки, и на этом всё.

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

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

💬 Какой у вас опыт от запроса разрешений в Android?

#Android

🤖 Посмотрел на обновлённую статистику распространения версий Android на 1 декабря 2025 и вот что интересно.

📈 Android 16 набирает обороты быстрее предшественников
За два месяца после релиза Android 16 (API 36) уже захватил 7,5% рынка. Для сравнения, Android 15 (API 35) за аналогичный период имел всего 4,5%. Такой стремительный рост объясняется новой стратегией Google — Android 16 вышел раньше обычного (во втором квартале вместо третьего) и был разделён на два релиза. Это дало производителям больше времени на подготовку обновлений, и многие флагманы 2025 года уже выходили с Android 16 из коробки.

✔️ Минимальная версия: Android 7.0 всё ещё актуален
Если смотреть на цифры, то Android 7.0 Nougat (API 24) и выше охватывает 99,2% устройств. Это значит, что отказавшись от поддержки Android 6.0 Marshmallow, вы теряете меньше 1% аудитории. Но помните — это глобальная статистика. Обязательно проверьте свою консоль Google Play: в некоторых регионах или нишах (например, бюджетные устройства для развивающихся рынков) картина может сильно отличаться.

⚖️ Что изменилось за 8 месяцев
С апреля (пост с прошлой статой) по декабрь 2025 года произошёл серьёзный сдвиг поколений. Android 14 вырос с 31,9% до 44%, став фактическим лидером. Android 13 упал с 48,7% до 57,9% (кумулятивно), но всё ещё держит солидную базу. А вот старички Android 11 и ниже продолжают уверенно терять позиции — теперь на них меньше 30% устройств против 38,5% восемь месяцев назад.
Интересно, что Android 15 за это время вырос до 26,8%, хотя многие производители только начали раскатывать обновления. Samsung, Xiaomi и другие гиганты обычно тянут с апдейтами до весны следующего года, так что пик Android 15 мы увидим ближе к середине 2026.

🏆Лидер всё тот же - Android 14
Самая популярная версия сейчас — Android 14 (API 34) с долей 44%. Это логично: устройства 2024 года выходили именно на этой версии, плюс многие флагманы 2023 года получили обновление. Android 13 на втором месте с 13,9% чистой доли (57,9% - 44% = 13,9%), но его позиции постепенно размываются.

Для разработчиков это означает простую вещь: если вы таргетируетесь на API 34 (что обязательно для новых приложений в Google Play), вы автоматически находитесь на самой массовой платформе. А вот с минимальной версией стоит балансировать между охватом и необходимостью поддерживать легаси-код. Android 8.0 Oreo (API 26) даёт вам 98,4% охвата, что для большинства проектов более чем достаточно.

💬 В комментах делитесь совпадает ли статистика Google с реальностью вашего приложения

#Android

🤖 Как не утонуть в океане версий Android: расставляем приоритеты в поддержке

Каждый Android-разработчик сталкивался с этой болью: сотни версий ОС, десятки производителей с уникальными оболочками, тысячи моделей устройств. И все это нужно поддерживать. Или нет? Я считаю, что не нужно. И вот почему. Ресурсы тестирования конечны. Ваша команда — не Google с его армией QA-инженеров (да и им не хватает на всё). У вас ограниченное время, бюджет и люди. Попытка качественно поддерживать все версии Android, все оболочки вендоров и все устройства — прямой путь к выгоранию команды и багам в проде. Лучше отлично поддерживать 70-80% пользователей, чем посредственно — 100%.

1️⃣Анализируйте данные регулярно

Google Play Console — ваш главный источник правды. Там есть всё: распределение по версиям Android, моделям устройств, размерам экранов. Альтернативно используйте Firebase Analytics, Amplitude или любую другую систему аналитики, которая у вас встроена. Важно смотреть на тренды. Если доля Android 6.0 упала с 5% до 1% за полгода — это сигнал пересмотреть поддержку. Рекомендую проводить такой анализ минимум раз в квартал, максимум — раз в год. Привяжите это к циклу планирования или мажорным релизам.

2️⃣Считайте не головы, а деньги

У вас 1000 пользователей на Android 6.0? Звучит внушительно. Но задайте себе три вопроса:
— Сколько из них активны за последний месяц?
— Кто из них делает заказы / смотрит рекламу / оформляет подписки?
— Какой у них engagement по сравнению с пользователями на свежих версиях?

Если это мертвые души или их монетизация стремится к нулю — может, стоит сокращать поддержку этих версий ОС?

Пример из практики: 1000 пользователей на Android 7 могут приносить $50/месяц, а 200 на Android 14 — $2000. Какую версию вам выгоднее поддерживать и проще?

3️⃣Сегментируйте пользователей

Не все пользователи одинаково важны. Разделите их на категории:

Сегмент A — высокий LTV, активные, платящие
Сегмент B — средняя активность, периодические покупки
Сегмент C — низкая активность, бесплатные пользователи

Теперь посмотрите на распределение этих сегментов по версиям Android. Возможно, окажется, что ваши самые ценные пользователи уже давно на Android 10+, а на старых версиях сидят только "зомби". Это даст вам аргументы для приоритизации — и для разговора с бизнесом.

4️⃣Внедрите систему тиров поддержки

Вместо бинарного "поддерживаем/не поддерживаем" используйте гибкую систему приоритетов:

Tier 1 — Критичные версии
Android 11-16 (условно — актуальные версии)
Покрывают 70-80% вашей базы
Уровень поддержки: полное ручное тестирование всех фичей перед каждым релизом, быстрые хотфиксы при багах

Tier 2 — Важные версии
Android 8-10
Покрывают еще 15-20% пользователей
Уровень поддержки: проверка основных сценариев вручую + автотесты, хотфиксы по приоритету

Tier 3 — Минимальная поддержка
Android 7
Остаток пользовательской базы
Уровень поддержки: только автотесты на smoke-сценарии, приложение работает, но активно не тестируется. Баги фиксим, только если они критичные

Tier 4 — Best effort
Всё, что осталось (Android 5-6 и старше)
Совсем старые версии, которые еще технически поддерживаются
Уровень поддержки: билд собирается, но тестирование отсутствует. Поддержка только на основе user reports

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

5️⃣Коммуникация с командой и стейкхолдерами

Самое сложное — донести эту стратегию до бизнеса и команды. Для бизнеса важны цифры: сколько стоит (денег и времени) и сколько приносит, как можно инвестировать это время Для команды ценность понятна и так — четкие критерии избавляют от хаоса в процессах. Разработчики и QA будут знать, на что тратить время, а на что — нет.

Также на принятие решение может влиять сложность поддержки старых версий Android, так как со временем Google и популярный Open Source постепенно откажется от этих версий. Apple вообще тут поступает жестко и убирает в XCode поддержку версий ОС. Например, сейчас Google поддерживает только Android 6.0+

#Android

💬 Как вы решаете, какие версии поддерживать, а какие нет? Какая у вас минимальная поддерживаемая версия сейчас?

#Android

🪙 РАЗБОР. Как устроена система разрешений в Android (40 мин)

Система разрешений в Android - супер нетривиальная задача. А если я вам скажу, что это не баг, а фича? Да, авторы Android сделали ее именно такой, чтобы защитить пользователя от сторонних приложений. Разработчикам приходится сражаться!

В новом разборе вы НЕ узнаете как получить разрешение, но погрузитесь в то как получается разрешение, какие сервисы ОС участвуют в этом, а также как правильно на самом старте проектировать фичи с учетом разного состояния разрешений.

Видео доступно всем подписчикам на Boosty, а полный список на витрине

#AndroidBroadcast #Android #AndroidOS

🔨 Вышла Android Studio Panda 1 и там только одно существенное изменение — упрощённое управление JDK для Gradle через Gradle Daemon JVM Criteria.

Теперь в новых проектах студия по умолчанию использует критерии JVM для Gradle Daemon: Gradle сам находит совместимый JDK, установленный на машине, а если подходящего нет — включает auto-provisioning и скачивает нужный JDK. Фича стабилизирована в Gradle 9.2.0.

Что это даёт разработчику:

✅ Меньше ошибок на импорте и старте проекта. Больше не нужно вручную угадывать “правильный” JDK для конкретного проекта — меньше типичных проблем вида Unsupported class file major version и прочих сюрпризов из-за неверно выбранной Java.

✅ Консистентные сборки в IDE и в терминале. Раньше Studio могла собирать проект на одном JDK, а CLI — на другом. В итоге появлялись разные Gradle Daemon, падала предсказуемость и иногда производительность. С JVM Criteria выбор JDK становится единым — поведение сборки стабильнее.

Для существующих проектов (при совместимой версии Gradle) Android Studio покажет уведомление и предложит автоматически мигрировать текущую настройку Gradle JDK на Daemon JVM criteria, сохранив те же требования к JDK.

💡 Для работы требуется Gradle 9.2 или выше, ну и придется мигрировать на AGP 9.0

#AndroidStudio #Gradle

🤖 Вышла первая Beta Android 17, а Dev Preview не будет. Google ранее запустила Canary сборки Android ОС и теперь это и есть Dev Preview.

Новых фичей первый апдейт этого года не принесет (всё сладкое будет в Q4), но заложит улучшения в платформу и сделаем жизнь разработчиков сложнее.

Что самого важного
❌ Убирают возможность отключения принудительной работы приложения на больших экранах, которая появилась в Android 16. Флаг будет игнорироваться
🚀 Сделали улучшения для ускорения работы ОС
📷 Прокачали работу с камерой
🤯 Handoff: Перенос Activity между девайсами для продолжения работы
👉 Другие улучшения по мелочи

📅 Релиз стоит ждать в мае-июне 2026.
Буду отдельными постами рассказывать всё подробнее в @android_broadcast
Источник Android Dev Blog

#Android #Android17