🤖 TLRU — эволюция LRU-кэша с учётом времени

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

Команда Grab описала подход TLRU (Time-Aware LRU) — форк DiskLruCache с тремя дополнительными параметрами:

1️⃣ TTL — время жизни записи. Если (текущее_время - время_последнего_доступа) > TTL, запись удаляется

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

3️⃣ Максимальный размер — наследуется от LRU без изменений

Реализация аккуратная: метка времени последнего доступа хранится прямо в journal-файле, переживает перезапуски. Алгоритм оптимизирован — если самая старая запись ещё не устарела, остальные не проверяются.

Миграция со старого LRU безопасна в обе стороны: оригинальный DiskLruCache читает TLRU journal, просто игнорируя временны́е суффиксы.

Мне нравятся такие решения, когда не надо переписывать с нуля, а точечно расширить проверенную реализацию. Три параметра поверх существующего механизма — и кэш наконец умеет забывать ненужное. Ну и честно - решение лежало на поверхности и вполне логичное.

🔗 Источник: engineering.grab.com

#Android #AndroidDev #Производительность #Оптимизация

🤖 Android 17 закручивает гайки для фонового аудио

В Android 17 появилось новое ограничение, которое затронет авторов музыкальных плееров, подкаст-приложений и всего, что воспроизводит звук в фоне без видимого UI.

Суть в следующем: теперь аудио фреймворк проверяет, имеет ли приложение право взаимодействовать с аудио в фоне. Без корректно запущенного foreground service с While-In-Use (WIU) возможностями звук просто отключится.

WIU — это условие, при котором Foreground Service запущен из видимого UI или в ответ на MediaSessionEvent. Если FGS запущен, например, по BOOT_COMPLETE и лезет в аудио — он будет заблокирован.

Рекомендуемый путь — использовать Jetpack Media3 MediaSessionService, который сам управляет жизненным циклом и не требует дополнительных телодвижений. Если media3 не используется, нужно вручную следить за тем, чтобы mediaPlayback FGS запускался из foreground и оставался живым на время транзиентных сбоев (не дольше 10 минут).

На мой взгляд, изменение правильное. Баги, когда приложение просыпается через несколько часов после заморозки и неожиданно начинает воспроизведение — реальная проблема. Другой вопрос, что тихая блокировка без каких-либо ошибок в API сделает диагностику неочевидной. Инструменты вроде `adb dumpsys audio` и logcat помогут, но разработчики, которые не читают changelog, узнают об этом только от пользователей.

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

#Android #AndroidDev #Android17

🤖 Вышла CameraX 1.6.0 с крутыми улучшениями

Вышел стабильный релиз CameraX 1.6.0. Цикл разработки был долгим, зато список изменений получился весомым.

👉 Переход на CameraPipe — CameraX теперь работает на том же стеке, что и приложение камеры Pixel. Все оптимизации и новые computational photography фичи отныне приходят в CameraX автоматически.

👉 Media3 Muxer по умолчанию — видеозапись через VideoCapture теперь использует Media3 Muxer. Если приложение упадёт во время записи, файл не повредится. Плюс более эффективный процессинг в целом.

👉 Feature Group обновился — GroupableFeatures пополнился константами VIDEO_STABILIZATION и UHD_RECORDING. Теперь их можно комбинировать с другими фичами в одном SessionConfig, туда же вписываются CameraEffect и ImageAnalysis.

👉 SessionConfig стал стабильным API — вышел из experimental вместе с HighSpeedVideoSessionConfig. Появился isSessionConfigSupported для проверки совместимости конкретной комбинации фич до биндинга к lifecycle. Также появился ExtensionSessionConfig для работы с CameraX Extensions.

Также исправили баг на Android 17. Версия 1.5.2 падает.

🔗 Источник - developer.android.com
🐱 Примеры на Github

#Android #AndroidDev #CameraX #Jetpack #Камера

🤖 Android 17 меняет подход к приватности геолокации.

Вышла Android 17 Beta 3 и все изменения там касаются геолокациии

👉 Location Button — разовый доступ к точной геолокации
Новый UI-элемент из Jetpack, который даёт доступ к точным координатам прямо в момент нажатия, без постоянного разрешения. Пользователь нажал кнопку "поделиться местоположением" в вашем приложении — получил данные один раз в рамках сессии. Никаких диалогов с выбором "разрешить всегда / только сейчас". Кнопку можно кастомизировать: цвет, форма, текст из предопределённого списка. Иконка местоположения остаётся обязательной и неизменной. На Android 16 и ниже Jetpack автоматически откатывается к стандартному диалогу разрешений.

👉 Примерная геолокация стала умнее
До этого "приблизительный" режим использовал фиксированную сетку 2×2 км. В малонаселённых районах это фактически деанонимизирует пользователя, потому что в квадрате 2 км может быть буквально несколько человек. В Android 17 размер ячейки теперь зависит от плотности населения — чем меньше людей, тем больше область. Логично, что давно должно было быть так.

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

👉 Переработанный диалог разрешений
"Точное" и "Приблизительное" местоположение теперь визуально сильнее разделены, чтобы пользователь осознанно выбирал нужный уровень доступа.

🔗 Источник: android-developers.googleblog.com

#Android #AndroidDev #Android17 #Приватность

🤖 В Android 17 нельзя менять `static final` поля через рефлексию или JNI. Звучит логично — static final по определению константа, но на практике это использовалось годами для разных хаков.

👉 Попытка изменить такое поле через рефлексию бросает IllegalAccessException
👉 Попытка через JNI SetStaticLongField() и аналоги — сразу краш приложения
👉 Ограничение включено только для приложений с targetSdk = 37, но в Beta 1 проверка активна для всех приложений, чтобы выловить проблемы раньше

Зачем это нужно? Пока static final поле формально могло меняться, рантайм не мог агрессивно оптимизировать код, который к нему обращается. Теперь — может. На практике это чаще всего задевает тесты, которые через рефлексию подменяют константы в production-коде, и старые хаки с логированием или конфигурацией. Где-то жить станет чуть сложнее, но в целом всё закономерно — меньше хаков, честнее код.

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

#android #android17

🤖 Улучшение подписи APK в Android 17

Android 17 добавляет поддержку гибридной схемы подписи APK с постквантовым алгоритмом ML-DSA. Классический ключ подписи комбинируется с постквантовым и подпись становится устойчивой к атакам с использованием квантовых вычислений.

Схема гибридная, а не замена старому подходу, поэтому обратная совместимость сохраняется. Старые устройства верифицируют подпись через классический ключ, новые получают дополнительный слой защиты через ML-DSA.

‼️ ВАЖНО Старый классический ключ переиспользовать нельзя. Это не обновление существующего ключа, а смена подписи, нужно создавать новую пару. Если используете Google Play App Signing, всё сделает Google Play, просто дождитесь опции в консоли. При самостоятельном управлении ключами понадобится обновлённый apksigner.

Квантовые компьютеры, способные реально угрожать текущим подписям,появятся не скоро, да и натравливать его на взлом APK - странный сценарий использования такой машины. Но инфраструктурные вещи лучше внедрять заранее, и хорошо, что Play App Signing снимает эту задачу с большинства из нас.

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

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