Android Broadcast

Бан без обоснований снимают очень быстро, но почему он вообще появляется?

🤖 Handoff в Android 17 — очень интересно, но пока много вопросов Handoff — новая функция и API, появляющиеся в Android 17. Она предназначена для реализации cross-device continuity — возможности начать работу с активностью приложения на одном Android-устройстве и продолжить её на другом устройстве, связанном с тем же Google-аккаунтом. На текущий момент попробовать функцию невозможно: API ещё недоступен, а сам сервис не работает даже в эмуляторе с Android 17 Beta 1. По своей идее Handoff сильно напоминает Continuity в iOS. Вероятно, эта функциональность станет важной частью развития Android в сторону desktop-сценариев и Android for Desktop. Технически Handoff основан на восстановлении состояния активности на другом устройстве. Концептуально это похоже на восстановление из Saved State, однако появляются новые ограничения и вопросы. Например, данные, сохранённые только локально, автоматически перенести не получится — их потребуется загружать заново. Также пока неясно, каким образом будет организована работа с навигацией и насколько необходимым станет общий или синхронизируемый state приложения. Пока остаётся ждать официальных примеров и рекомендаций от Google. 🔗 Источник — Android 17 Changes #Android17

💡 Есть интересная разница между тем, как разработчик видит разрешения в Android, и тем, как ими реально управляет пользователь. 🔎 Например, многие не знают, что Android показывает историю использования разрешений. В настройках конфиденциальности можно посмотреть, какие приложения и когда обращались к камере, микрофону или геолокации. Обычно туда попадают не из интереса, а когда появляется ощущение, что приложение “слишком часто что-то использует”. Дальше происходит простая вещь: доступ не обязательно отключают полностью. Его переводят в режим “только при использовании” или просто забирают. Для пользователя это выглядит как наведение порядка. Для приложения — как внезапно пропавший доступ, хотя раньше всё работало. 🎙 Похожая история с быстрыми переключателями. В шторке Android есть глобальные выключатели камеры и микрофона. Это не про конкретное приложение — пользователь может отключить доступ на уровне всей системы. В этот момент любое приложение начинает получать пустые данные, и с точки зрения пользователя всё логично: “я же выключил микрофон”. Разработчик же часто даже не рассматривает этот сценарий. ⏱️ Следующий слой защиты — автоотзыв разрешений. Если приложением долго не пользуются, система сама может забрать выданные доступы. Пользователь иногда узнаёт об этом только когда открывает приложение спустя пару месяцев и оно снова что-то просит. Система считает это защитой, но для приложения это означает возврат в состояние первого запуска. 🔋 Ещё один неочевидный момент — экран использования батареи и фоновой активности. Пользователь видит, что приложение активно работает в фоне, нажимает “ограничить” и ожидает, что оно перестанет расходовать ресурсы. После этого могут задерживаться синхронизации, пуши приходят реже, фоновые задачи начинают выполняться позже. Пользователь доволен, потому что телефон живёт дольше. Разработчик видит нестабильность. 🖼 Есть и более мягкие ограничения - доступ к отдельным фото, а не ко всей галерее. Пользователь даже не воспринимает это как ограничение — просто выбирает нужные фотографии. Но для приложения это означает, что “полного доступа” больше может никогда не быть. Если посмотреть на всё это вместе, получается важная вещь: пользователь в современном Android управляет приложением не одним решением “разрешить или нет”, а набором мелких ограничений, которые постепенно меняют его поведение. И большинство из них включаются уже после релиза, без участия разработчика. Поэтому многие странные сценарии в проде — это не ошибки системы. Это нормальное использование устройства. 🪙 Я отдельно разбирал на Boosty, как эта модель устроена внутри Android — почему система вообще позволяет так вмешиваться и как проектировать поведение приложения так, чтобы оно не ломалось при ограничениях. Там уже больше про внутреннюю механику и архитектуру ОС, чем про настройки. #Android #Безопасность

🤖 Вышла первая Beta Android 17, а Dev Preview не будет. Google ранее запустила Canary сборки Android ОС и теперь это и есть Dev Preview. Новых фичей первый апдейт этого года не принесет (всё сладкое будет в Q4), но заложит улучшения в платформу и сделаем жизнь разработчиков сложнее. Что самого важного ❌ Убирают возможность отключения принудительной работы приложения на больших экранах, которая появилась в Android 16. Флаг будет игнорироваться 🚀 Сделали улучшения для ускорения работы ОС 📷 Прокачали работу с камерой 👉 Другие улучшения по мелочи 📅 Релиз стоит ждать в мае-июне 2026. Буду отдельными постами рассказывать всё подробнее. Источник Android Dev Blog #Android #Android17

🪫 Как перестать “разваливаться” к вечеру: Апгрейд рабочего места с Ergostol Я давно заметил: рабочее место — это не про “красиво на фото”, а про то, как вы себя чувствуете в конце дня. 🧑‍💻 У меня в офисе Ergostol — Terra первого поколения — и это редкий случай, когда покупка реально улучшила повседневную работу: меньше затекаешь, проще держать фокус, легче переживать длинные созвоны. Я сам пользуюсь и мне правда нравится. ⚡️Сейчас у Ergostol вышли новые модели: столы Optima 3.0 и Terra 3.0, а ещё кресла Exo Aura и Exo Flex. Я не буду грузить характеристиками — суть в том, что всё стало ещё удобнее: умный пульт, зарядка прямо на столе, плюс много аксессуаров для кастомизации и аккуратного рабочего места без хаоса. 🟡 Отличный момент обновиться или собрать сетап с нуля — тем более в преддверии 23 февраля / 8 марта: 🎁 получается не “символический”, а реально полезный каждый день. 👉 Мои обзоры на Ergostol: стол One 2.0 и стол Terra 🚀 Промокод: ANDROID10 — -10% на столы и аксессуары к ним, а также кресла Exo Aura и Flex 🚀 #реклама

С головой ушел в изучени и практику ИИ разработки. Одна из проблем - следить за лимитами. Рекомендую вам поставить open source софт Codex Bar для macOS. Показывает текущий статус и можете трекать когда пойдете на обед или закачиваете текущий рабочий день #ai

🔨 Вышла 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

🪙 РАЗБОР. Как устроена система разрешений в Android (40 мин) Система разрешений в Android - супер нетривиальная задача. А если я вам скажу, что это не баг, а фича? Да, авторы Android сделали ее именно такой, чтобы защитить пользователя от сторонних приложений. Разработчикам приходится сражаться! В новом разборе вы НЕ узнаете как получить разрешение, но погрузитесь в то как получается разрешение, какие сервисы ОС участвуют в этом, а также как правильно на самом старте проектировать фичи с учетом разного состояния разрешений. Видео доступно всем подписчикам на Boosty #AndroidBroadcast #Android #AndroidOS

✅ Вакансия Software architect в e-commerсe Компания в поиске опытного специалиста в создании сложных IT-систем (микросервисы, облачные технологии). Знание Java и современных инструментов разработки. 📍Локация: Минск или Москва (гибрид). 👉 Подробнее о требованиях и вакансии по ссылке ❗️Для отклика на вакансию пишите @Irina_HRD (или 📧vishneuskaya.iryna@gmail.com) с указанием от Android Broadcast #вакансия

💬 Как вы решаете, какие версии поддерживать, а какие нет? Какая у вас минимальная поддерживаемая версия сейчас? #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 на 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 и снова упираюсь в один и тот же вопрос: почему до сих пор нет AndroidX‑решения, которое бы упростило всю эту рутину? В каждом проекте встречается тонны похожего кода для работы с разрешениями — и чаще всего без учёта лучших практик. Разработчики нередко просто запрашивают разрешение “в лоб”, не обрабатывая отказы корректно. Если пользователь отказал — то сразу перекидывают в настройки, и на этом всё. Google, кажется, слишком усложнила саму концепцию. Система разрешений должна была быть прозрачной и удобной для разработчика, но на практике реализована ею далеко не всегда. Один из выходов, который вижу — жёстче ревьюить сценарии работы с разрешениями и проверять, насколько реализация соответствует рекомендациям платформы. 💬 Какой у вас опыт от запроса разрешений в Android? #Android

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

🤖 Если используете 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

🤖 Улучшения 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 — это shrinker для library desugaring. Позволяет использовать новые API на старых версиях Android и править баги в них, делая использование API прозрачным.

AGP 9.0 делает R8 и L8 более «production-oriented»: меньше лишнего байткода, более агрессивные оптимизации Kotlin, чище пайплайн с desugaring и лучшая поддержка диагностики. Большинство изменений работают прозрачно, но в сумме дают более компактные сборки и более предсказуемый build-процесс. 🔗 Источник - документация по AGP 9.0 #Android #AndroiDev #Gradle #R8

🤖 AI в практике разработчиков: новый сезон Podlodka AI Crew «Мы поигрались с промптом, но пока не внедряли» — часто разговоры про AI в разработке заканчиваются именно так. Инструментов всё больше, а вот времени на то, чтобы разобраться и сделать так, чтобы магия заработала, порой не хватает. С 16 по 20 февраля у Podlodka AI Crew пройдёт сезон «AI-агенты в разработке»: проверенные рабочие сценарии от практиков индустрии. 👀 В программе: • единый AI-workflow для разработчика • автоматизация стендапов и работы с документацией • Claude Code, субагенты для кодинга • практические кейсы внедрения AI в SRE • подходы к созданию промптов с насыщенным контекстом Формат — классический для Podlodka Crew: 5 дней, 10+ спикеров, 10 сессий и закрытое комьюнити в Telegram. 👉 Если тема AI в разработке вам интересна и хочется меньше хайпа, больше дела — держите ссылку. До 10 февраля можно забрать билет по early-bird цене! А по промокоду BROADCAST_AI получите скидку 🎁 #реклама