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

💡 Есть интересная разница между тем, как разработчик видит разрешения в Android, и тем, как ими реально управляет пользователь.

🔎 Например, многие не знают, что Android показывает историю использования разрешений.
В настройках конфиденциальности можно посмотреть, какие приложения и когда обращались к камере, микрофону или геолокации. Обычно туда попадают не из интереса, а когда появляется ощущение, что приложение “слишком часто что-то использует”.

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

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

⏱️ Следующий слой защиты — автоотзыв разрешений. Если приложением долго не пользуются, система сама может забрать выданные доступы. Пользователь иногда узнаёт об этом только когда открывает приложение спустя пару месяцев и оно снова что-то просит. Система считает это защитой, но для приложения это означает возврат в состояние первого запуска.

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

🖼 Есть и более мягкие ограничения - доступ к отдельным фото, а не ко всей галерее. Пользователь даже не воспринимает это как ограничение — просто выбирает нужные фотографии. Но для приложения это означает, что “полного доступа” больше может никогда не быть.

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

Поэтому многие странные сценарии в проде — это не ошибки системы. Это нормальное использование устройства.

🪙 Я отдельно разбирал на Boosty, как эта модель устроена внутри Android — почему система вообще позволяет так вмешиваться и как проектировать поведение приложения так, чтобы оно не ломалось при ограничениях. Там уже больше про внутреннюю механику и архитектуру ОС, чем про настройки.

#Android #Безопасность

🤖 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 17 переписали один из самых старых и критичных механизмов работы UI потока.

Это изменение почти никто не увидит в changelog’ах, но оно напрямую влияет на то, насколько плавно работает интерфейс любого приложения.

MessageQueue — это очередь задач главного потока с которой работает Handler. Каждый Android-разработчик фактически работает с ней каждый день, даже если напрямую не задумывается об этом. Looper берёт из неё сообщения, передаёт их Handler’ам, выполняет UI-обновления, lifecycle-события, обработку ввода, invalidate, работу фреймворков и большую часть межпоточного взаимодействия. По сути, это диспетчер всей работы main thread.

Исторически эта очередь почти не менялась около двадцати лет. Внутри она была защищена одним lock’ом. Пока один поток добавлял сообщение, другой не мог работать с очередью. На старых устройствах это не было критично, но на современных многоядерных системах стало появляться всё чаще: background-поток держит lock, планировщик переключает CPU на другие задачи, а UI-поток в этот момент ждёт.

В Android 17 мезанизм работы очереди переписали полностью. Новая реализация стала lock-free. Вместо общего lock используются атомарные операции, а сама структура очереди разделена на две части: потоки могут добавлять сообщения без блокировок, а главный поток уже самостоятельно упорядочивает и выполняет задачи. Важное свойство такого подхода — хотя бы один поток всегда может продолжать работу независимо от поведения остальных.

Это не обновление из категории «приложение стало быстрее на X процентов». Изменение работает глубже. Оно снижает вероятность случайных блокировок главного потока, уменьшает количество missed frames и делает время кадра стабильнее под нагрузкой. Особенно это заметно в сценариях, где одновременно происходит много фоновой работы: запуск приложения, работа камеры, тяжёлые UI, интенсивные операции в фоне.

🤯 В одном из примеров Google показывают блокировку UI-потока почти на 18 мс только из-за конкуренции за lock — этого уже достаточно, чтобы пропустить кадр на экране 60 Гц, не говорю уже про 120.

‼️ Большинству приложений ничего делать не нужно — улучшение происходит автоматически. Но обратить внимание стоит тем, кто занимается производительностью, анализирует Perfetto-трейсы или использует рефлексию и внутренние поля MessageQueue. Такие вещи могут перестать работать, потому что внутренняя реализация изменилась.

На самом деле это интересный сигнал о направлении развития Android. Долгое время оптимизации происходили на уровне API и фреймворков. Сейчас Google всё чаще переписывает базовые механизмы конкурентности самой платформы. И это логично: современные устройства уже редко упираются в вычислительную мощность, чаще — в синхронизацию потоков и contention. MessageQueue находится в центре всей работы UI-потока, поэтому даже небольшие улучшения здесь масштабируются на всю экосистему.

🔗 Больше подробностей про работу механизма можно найти в техническом разборе от Google

#Android #Android17

📹 GrapheneOS как способ избавиться от тотальной слежки за твоим смартфоном

Сделал короткий обзор зачем нужна GrapheneOS, авторы которой перепили AOSP для лучшей безопасности, что им стоит Google подчернуть в этой ОС и самое главное - какой опыт использования этой ОС

#Android #AndroidBroadcast #GrapheneOS

🤖 Очередная порция ограничений для Activity в Android 17

Копался в behavior changes для Android 17 и наткнулся на очередное закручивание гаек вокруг запуска Activity из фона.

На этот раз Google расширил BAL (Background Activity Launch) ограничения на IntentSender

IntentSender - это обёртка над PendingIntent, позволяющая передать право запуска Intent другому приложению или системе. Именно через него работают уведомления, виджеты, shortcuts и межпроцессные вызовы.

Так вот, константа MODE_BACKGROUND_ACTIVITY_START_ALLOWED теперь deprecated. Если где-то передаёте её через ActivityOptions при работе с PendingIntent — нужно мигрировать на MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE. Разница в том, что теперь Activity из фона запустится только если вызывающее приложение видимо пользователю.

val options = ActivityOptions.makeBasic().apply {
    pendingIntentBackgroundActivityStartMode =
        ActivityOptions.MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE
}

Найти проблемные места просто — Google обновил lint и StrictMode под новые требования. Запускаете lint, ищете использования MODE_BACKGROUND_ACTIVITY_START_ALLOWED и получаете полный список того, что нужно поправить.

Формально это касается только targetSdk 17+, но лучше не тянуть — сами знаете, как работают дедлайны в Play Console.

🔗 Источник developer.android.com

#Android17 #androiddev #security #activity

Уже несколько недель я активно погружаюсь в разработку с помощью ИИ и решение разных задач через кодинг агентов. Буду регулярно делиться впечатлениями и находками на Boosty.

🪙 Уже доступен первый выпуск

#AndroidBroadcast #Boosty #ДневникИИКодера

🛒 Попытаемся отменить обязательную верификацию разработчиков в Google Android? 🤔

Наткнулся на сайт keepandroidopen.org, который призывает бороться с "закрытием" Android. Честно — не понимаю, на что надеются авторы.

Обязательная верификация (подробнее в этом посте) разработчиков ≠ закрытие Android 🚫. Всё что Google делает в этом направлении — происходит при поддержке правительства, а то и вовсе по их инициативе.

Тот, кто публикует вредоносное и не готов себя раскрыть — ну и ладно. Я ничего не теряю.

Пользователям, которым не нравится новый подход, есть варианты:
— прошить телефон на Android без GMS, всё будет как прежде
— купить Huawei, там Google сервисов нет в принципе

Конечно, если не бороться — ничего не сдвинется. Но обязательная верификация всё равно будет. И если она не приведёт к потерям денег у Google — значит всё устраивает 🤷

#Android #Безопасность