🚀 Core-Backported-Fixes 1.0: Умная проверка исправлений системных багов

Google выпустил новую библиотеку Core-Backported-Fixes 1.0. Она помогает приложениям определить, установлены ли на устройстве пользователя критические исправления системных ошибок от Google.

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

Библиотека предоставляет API для проверки статуса известных проблем (KnownIssues) по их ID.

val fixManager = BackportedFixManager()
if (fixManager.isFixed(KnownIssues.KI_398591036)) {
    // Исправление установлено, можно использовать функцию
    useFeatureSafely()
} else {
    // Исправления нет, включаем обходной путь
    useFallbackWorkaround()
}

Пока что библиотека содержит информацию об одной известной проблеме - KI_398591036: Аномальные цветовые тона при съёмке в формате JPEG-R на некоторых устройствах Pixel. Рекомендация — использовать обычный JPEG, пока проблема не исправлена.

👨‍💻 Кому это будет полезно?
👉 Разработчикам, чьи функции зависят от конкретных системных исправлений.
👉 Приложениям, работающим с аппаратными возможностями (камера, датчики), где часто встречаются специфичные для устройств баги.
👉 Тем, кто хочет повысить стабильность и избежать сбоев, связанных с прошивкой.

#AndroidDev #Jetpack #Pixel

🚀 Обновление для WebView с упором на производительность и контроль

Вышла версия 1.15.0 библиотеки AndroidX WebKit (WebView). Главное изменение — повышение minSdk с API 21 до API 23 😁

🎯 Ключевые новые возможности:

⚡️ Ускорение загрузки
👉 prerenderUrlAsync() — предварительная загрузка (prerender) страниц для мгновенного открытия.
👉 Profile.preconnect() — предварительное установление соединения с origin.
👉 Profile.addQuicHints() — подсказка WebView использовать протокол QUIC/HTTP3 для ускорения.

🔧 Больше контроля
👉 setHyperlinkContextMenuItems() — кастомизация контекстного меню для ссылок.
👉 setBackForwardCacheSettings() — настройка Back/Forward кэша (таймауты, лимиты).
👉 Profile.addCustomHeader() — установка кастомных HTTP-заголовков для запросов.

🔒 Безопасность и отладка
👉 Новый WebViewBuilder API для создания WebView с неизменяемой конфигурацией, что повышает безопасность при использовании addJavascriptInterface.
👉 Улучшенные API для отладки асинхронной инициализации WebView.
👉 Также возвращена отправка заголовка X-Requested-With, а старый API для его исключения помечен как deprecated.

#WebView #AndroidDev #Jetpack

🤖 Улучшаем работу со Stacktrace в Jetpack Compose (особенно в релизе)

Команда Compose представила opt-in API для улучшения читаемости стектрейсов во время разработки и для релизов.

Теперь становится возможным:
👉 Точно определять источник крешей в композиции, Side Effect (LaunchedEffect, DisposableEffect) и корутинах из rememberCoroutineScope.
👉 Изолировать падения для создания воспроизводимых примеров.
👉 Изучать креши, которые раньше показывали только внутренние фреймы Compose.

Достаточно добавить одну строку в точке входа в приложение (например, в Application.onCreate()):

// Включить stack trace только для минифицированных сборок (рекомендуемый способ)
Composer.setDiagnosticStackTraceMode(ComposeStackTraceMode.Auto)

// Или для локальной отладки (более точные, но тяжёлые трассировки)
Composer.setDiagnosticStackTraceMode(ComposeStackTraceMode.SourceInformation)

‼️ВАЖНО Требуется Kotlin 2.3.0, а для режимов `Auto` и `GroupKeys` - включённый R8 с минификацией.

Есть несколько режимов работы
✔️Auto (рекомендуется): использует GroupKeys для минифицированных сборок и None для отладочных.
👉 GroupKeys: для минифицированных приложений. Использует маппинг-файл от R8 для восстановления примерного местоположения.
👉 SourceInformation: для отладки. Даёт точные строки где произошел креш, но затратно по производительности. Стоит использовать только на этапе разработке.
❌ None: ничего не добавляет (поведение по умолчанию).

Под капотом любой креш в Compose коде оборачивается в DiagnosticComposeException, который добавляется в suppressed-исключения. В нём будет полная иерархия вызовов `@Composable` функций на момент падения!

java.lang.IllegalStateException: Test layout error
    at <original trace>
Suppressed: androidx.compose.runtime.DiagnosticComposeException:
Composition stack when thrown:
    at ReusableComposeNode(Composables.kt:<unknown line>)
    at Layout(Layout.kt:79)
    at <lambda>(TempErrorsTest.kt:164) <-- Ваша функция!
    ... и т.д.

⚠️ Известные ограничения:
👉 В режиме SourceInformation для первых фреймов могут не указываться номера строк (<unknown line>).
👉 GroupKeys указывает только на первую строку @Composable функции.
👉 Если сам сбор стектрейса упадёт, его исключение будет добавлено как suppressed.

Подробнее в официальной документации

💬 А вы уже пользовались этой фичей? Делитесь в комментариях! 👇

#AndroidDev #Kotlin #Compose #R8 #Android

🔨 Лучше поздно, чем никогда - Material Symbols из Google Fonts встроили в Android Studio. Пока только в Canary версии Panda.

Для тех кто не в курсе, Material Symbols пришли на замену Compose Material Icons, которые больше не рекомендуется к использованию (подробности тут)

Источник - Android Developers

#Android #AndroidDev #Compose #AndroidStudio

🔨 Включите эту настройку в Android Studio чтобы получить доступ ко всем AI фичам.

Копался в новых фичах Android Studio и не могу понять почему у меня нету фичи ⭐️ "Generate Compose Preview".

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

#AndroidStuduio #Android #AndroidDev #AI

🤯 Dagger Hilt блокирует переход на AGP 9.0

UPD. 21 января вышел Dagger 2.59 с поддержкой AGP

Android Gradle Plugin 9.0 официально зафиксировал новый стабильный конфигурационный API (вышла стабильная версия с релизом AS Otter FD 3) — это одно из самых значимых изменений в инфраструктуре Android и Kotlin Multiplatform за последние годы. Цели понятны и правильные лучше работа с кэшем и общая скорость сборок. Подробнее про все изменения я писал в отдельном посте

Google несколько релизов подряд аккуратно готовил экосистему к этому переходу, заранее добавив новый API и дав время авторам плагинов адаптироваться. Но на практике всё упирается в плагины.

Я столкнулся с тем, что Gradle-плагин Dagger Hilt до сих пор использует старую модель конфигурации и несовместим с новым DSL из AGP 9.0. В результате проект нельзя перевести на новую версию без отключения Hilt или включения режим совместимости. Иронично, что именно официальный инструмент от Google сейчас становится блокером для обновления.

Да, в AGP оставили compatibility-флаги, позволяющие продолжать сборку по старым правилам. Это спасает проекты от немедленного падения, но полностью отключает все ключевые преимущества AGP 9.0 — configuration cache, ускоренную конфигурацию и новую модель плагинов.

💬 Вы уже пробовали миграцию на AGP 9.0? Что блокирует? Делитесь в комментариях мнением.

UPD. По заявлениям подписчиков также есть проблемы в работе KAPT и KSP

#Android #AndroidDev #Gradle #Dagger #Hilt

🚀 Google взялась за упрощение Picture‑in‑Picture

PiP на Android долго был зоопарком: разный API на версиях, разный UI‑стейт, много if (SDK_INT…) и бойлерплейта. Новая Jetpack‑библиотека androidx.core:core-pip как раз и создана, чтобы это спрятать: она выравнивает вызовы PiP между версиями Android, даёт единый способ задавать параметры (особенно для видео/плееров), объединяет разрозненные колбэки состояния PiP и уменьшает количество кода за счёт готовых пресетов действий для типовых сценариев.

Требования: обновляем Activity

Чтобы всё это заработало, мало просто подключить core-pip — нужно обновиться до свежей Activity 1.13.0 (пока в альфе). В этой версии есть новые API для отслеживания состояния PiP (PictureInPictureUiStateCompat и слушатели), на которых удобно строить логику поведения UI, когда окно уходит в PiP или, например, «прячется» в угол.

// Пример кода: реагируем на состояние PiP
class PlayerActivity : ComponentActivity() {

    private val pipUiStateListener =
        Consumer<PictureInPictureUiStateCompat> { state ->
          if (state.isStashed) {
            /* спрятать контролы плеера */
          } else {
            /* показать контролы плеера */ 
          }
        }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ... инициализация UI / плеера ...
        addOnPictureInPictureUiStateChangedListener(pipUiStateListener)
    }

    override fun onDestroy() {
        removeOnPictureInPictureUiStateChangedListener(pipUiStateListener)
        super.onDestroy()
    }
}

🔗 Подробности про библиотека в документации

#Android #AndroidDev #AndroidJetpack #PIP

🤖 Разница между 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