🚀 Пример Jetpack Media 3 Transformer API для создания приложения с обрезкой видео (EN,3м)

Разработчик решил реализовать простую затею - обрезать видео на основе выбранного отрезка текста из расшифровки дорожки. Использовал Jetpack Media3 и EventLabs API. ПО итогу вышло приложение 🐱 QuickTrim

🔗 Альтернативная ссылка тут

#android #androidjetpack #media3 #opensource #пример

🚀 Вышел Room 2.8.0

Самая важная (она и единственная) фича свежего релиза - получение SupportSQLiteDatabase, являющегося оберткой над RoomDatabase с SQLiteDriver. Честно, не знаю кому это пригодится, поэтому будет полезно узнать от вас в комментариях практический опыт.

Менее масштабные, но всё же важные изменения:
👉 minSdk подняли с 21 до 23
👉 Добавили поддержку KMP таргетов: watchOS и tvOS
🛠 Исправили баги

#android #jetpack #androidjetpack

🤖 Вышел Jetpack Window 1.5.0

Что нового:
👉 WindowSizeClass появились разделения для больших (Large - от 1200 до 1600) и очень больших (XLarge - более 1600 dp) экранов
👉 Получение WindowMetrics теперь работает с Application Context, а не только с UI Context
👉 Добавили API для автоматического сохранения и восстановления статуса встраивания Activity при перезапуске процесса
👉 Удалили экспериментальное API WindowInsets

#android #androidjetpack #jetpackupdate

🚀 Вышла новая Jetpack библиотека - Security State Provider (пока в статусе Альфа)

Основная цель библиотеки — предоставить действительные (actionable) данные о состоянии безопасности устройства и его компонентов, в частности:
👉 Версии обновляемых компонентов (updateable system components).
👉 Наличие применённых исправлений безопасности (security patches / applied fixes).
👉 Общий “security state” — то есть агрегированное представление безопасности системы.

То есть, библиотека даёт вам API, чтобы “спросить у Android”: насколько актуальна система, есть ли уязвимости, какие компоненты нуждаются в обновлении.

Она не заменяет шифрование/криптографию (как, скажем, security-crypto), но с дополняет стек безопасности: помогает принимать решения на основании состояния платформы.

#android #androidjetpack #безопасность

Вот реальная история, как знание механики работы ViewModel спасло мне вечер 👇

У меня приложение на Compose и Jetpack Navigation 3 (работает на основе состояния Back Stack). Экран «Навигатор файлов» открывает папки рекурсивно: по сути это тот же экран, но с другими данными. Все данные — из одной и той же ViewModel.❗️Баг: при переходе в папку навигация срабатывает, UI не меняется. Современные ИИ подсказали общие вещи, но не помогли — промты, видимо, подвели (тут мне ещё надо прокачать знания) 🙂

Вспомнил ключевой факт про архитектуру:
👉 Все ViewModel живут в ViewModelStore.
👉 В пределах одного ViewModelStoreOwner (Activity/Fragment/NavBackStackEntry) получение ViewModel по умолчанию идёт по типу.
👉 Если нужно несколько экземпляров одного типа на одном owner’е — используем key.

Решение в одну строку — привязать ключ к ViewModel, связанный с текущей папкой:

@Composable
fun FileNavigator(
    folderId: Id,
    modifier: Modifier = Modifier,
) {
    // новый folderId → новый экземпляр ViewModel → новый UI-стейт
    val viewModel: FileNavigatorViewModel = viewModel(
        key = "files(rootId='$folderId')"
    )
    // ...
}

Мини-чеклист, если ловите такой баг
👉 Один экран используется повторно с разными параметрами? → Нужен key.
👉 Меняется route, но owner тот же? → key обязателен.
👉 Используете Hilt/Koin? → У этих функций тоже есть параметр key (hiltViewModel(key=...), koinViewModel(key=...)).
👉 key должен детерминированно зависеть от входных данных (например, folderId).
👉 При навигации назад убедитесь, что ViewModel освобождается ожидаемо.

Ещё нюанс - если у вас сложная иерархия графов, проверьте, к какому ViewModelStoreOwner вы реально привязаны.

Рекомендую посмотреть мои видео по теме:
📹 Разбор Jetpack Navigation 3
🪙 Полный разбор Jetpack ViewModel в Android и Kotlin Multiplatform

#android #compose #androidjetpack #viewmodel #архитектура

🤖 Как проверить, какие комбинации фичей поддерживает камера смартфона

Современные смартфоны умеют снимать с HDR, 120 FPS и стабилизацией, но вот какая комбинация этих фич реально доступна — загадка. Например, стабилизация часто работает только при 1080p, а 60 FPS не всегда доступны в 4K.

С выходом Jetpack CameraX 1.5 появилось API GroupableFeature и новые параметры для SessionConfig, которые позволяют из кода проверить, какие функции камера может использовать одновременно.

// Пример проверки неподдерживаемых комбинаций
val unsupportedFeatures =
     mutableSetOf<GroupableFeature>()
val appFeatureOptions =
     setOf(HDR_HLG10, FPS_60, PREVIEW_STABILIZATION)
appFeatureOptions
    .filterNot { it in currentFeatures }
    .filter { featureOption ->
        cameraInfo.isFeatureGroupSupported(
            SessionConfig(
                useCases = useCases,
                requiredFeatureGroup =
                    currentFeatures + featureOption
            )
        )
    }
    .forEach { unsupportedFeatures.add(it) }

Так можно заранее отсеять неподдерживаемые сочетания — например, когда HDR и стабилизация не работают вместе при 60 FPS 🎥

Подробнее в статье (EN)

#android #camerax #Jetpack #androidjetpack

🚀 Вышел Jetpack WorkManager 2.11.0

Что важного в новой версии:

❗️ minSdk: 23 (Marshmallow). Lollipop (API 21–22) больше не поддерживается.

🎉 Новое API: setRemoteSessionTimeoutMillis() в Configuration.Builder — задаёт время жизни сессии RemoteWorkManager после последнего использования.

class App : Application(), Configuration.Provider {
    override fun getWorkManagerConfiguration(): Configuration {
        return Configuration.Builder()
            // Сколько живёт RemoteWorkManager-сессия после последнего использования
            .setRemoteSessionTimeoutMillis(TimeUnit.MINUTES.toMillis(5))
            .build()
    }
}

🎉 Тестирование: TestDriver.stopRunningWorkWithReason(...) — можно останавливать выполняющуюся работу с указанием причины.
Зачем: удобно эмулировать внешние условия (остановку системой/приложением) и проверять, что код корректно реагирует на «принудительное завершение».

// Arrange
val request = OneTimeWorkRequestBuilder<MyWorker>().build()
WorkManager.getInstance(context).enqueue(request).result.get()

// Act
val testDriver = WorkManagerTestInitHelper.getTestDriver(context)!!
testDriver.stopRunningWorkWithReason(
    request.id,
    /* reason */ 0 // укажите код причины, например ваш тестовый/константу из проекта
)

// Assert — далее проверяете ожидаемое состояние

🛠 Также сделали исправление багов

#android #jetpack #workmanager #jetpackupdate #androidjetpack