This media is not supported in your browser
VIEW IN TELEGRAM
Я попробовал подключить Pixel 9 Pro к внешнему 4K монитору по Type-C. Итог - зернистость такая, что пользоваться невозможно. В настройках выбрать выше FullHD не дает (возможно, ограничение моего устройства). Приложения можно растягивать как угодно, что порой приводит к проблемам их отображения и они не перестраиваются полностью. Начало хорошее, но очень много работы с разработчиками по адаптации под больши экраны и ресайз на лету.
Google дала множества библиотек и руководств по адаптации под большие экраны, а также как работать с несколькими дисплеями.
🔗 Источник - Android Developers Blog
#Android #AndroidDev
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥41👍9👎6❤5🤔2
Разработчики популярного ORM для Android и KMP решили выпустить мажорную версию, чтобы отразить всю важность изменений:
👉 Полный переход на
androidx.sqlite driver API.👉 Генерация кода будет только на Kotlin, никакой больше Java.
👉 APT и KAPT больше не будут поддерживаться. Остается только KSP.
👉 Room API теперь будет делаться в подходе "Kotlin Coroutines first", делая весь ORM асинхронным по умолчанию.
Что нас ждет из новых фичей и возможностей:
👉 Появится полноценная поддержка JS и WASM-таргетов.
👉 Можно будет добавить собственные возвращаемые типы в Room. Например, Room, RxJava, Paging и пр.
Новая версия Room будет выпущена под новым пакетом androidx.room3. Room 2.X не получит новых фичей, только багфиксы.
🔗 Источник - блог Android Developers.
🔗 Release Notes Room 3.0.0-alpha01
#Android #AndroidDev #Room #SQLite #Jetpack #AndroidJetpack #KMP
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥86👍21👎7❤3🤯1
Команда LLVM toolchain в Google рассказала, как они применили AutoFDO (Automatic Feedback-Directed Optimization) к ядру Android — и результаты интересные.
Идея простая: обычный компилятор принимает решения об оптимизациях на основе статических эвристик. Встроить функцию или нет, какая ветка условия чаще выполняется — всё это угадывается без реальных данных из приложений и пользовательских сценариев.
AutoFDO меняет подход: компилятор получает профили реального выполнения кода и на их основе принимает куда более точные решения.Эта техника Google уже давно применяется к своей серверной инфраструктуре и ChromeOS, так что подход обкатанный и зарекомендовавший себя.
Кто знаком с ART Profiles — идея покажется знакомой. Там тот же принцип: собираем данные о реальном выполнении, отдаём компилятору, получаем более точный нативный код. Только ART Profiles работают на уровне ART для Java/Kotlin-кода конкретного приложения, а AutoFDO — на уровне ядра, C/C++ и LLVM. Разные слои, одна философия.
Для ядра профили собирают не с реальных устройств, а в лабораторных условиях: запускают топ-100 самых популярных приложений, используют
simpleperf и аппаратные возможности ARM для записи истории ветвлений. Собранные данные показывают 85% совпадение с профилями реального парка устройств — этого достаточно, чтобы считать подход рабочим.Результаты на ядрах 6.1, 6.6 и 6.12:
👉 холодный старт приложений стал быстрее на ~4%
👉 время загрузки сократилось на ~1%
👉 ядро занимает ~40% CPU-времени на Android, так что любая оптимизация здесь ощутима
Важный момент: AutoFDO не меняет логику кода, только влияет на решения компилятора — инлайнинг, раскладку кода. Функции, которые не попали в профили («холодные»), компилируются стандартным образом, без изменений.
Сейчас это уже в проде — профили включены в ветки android15-6.6 и android16-6.12, так что устройства на этих ядрах уже собираются с AutoFDO. Pixel-устройства точно попадают в эту категорию. С другими производителями сложнее: многие используют сильно модифицированное ядро и не переходят на GKI из AOSP, так что там это может быть не применено вовсе. В планах — GKI-модули, вендорные модули через DDK и поддержка новых версий ядра.
🔗 Источник - блог Android Developers
#Android #AndroidDev #Производительность #LLVM #Native
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥49👍8❤6👎4
Компания активно продвигает адаптацию Android-приложений под ноутбуки и десктопы, где управление происходит мышью и клавиатурой. Неудивительно, ведь скоро появится Android-ноутбук, есть Chromebook'и, да и телефоны уже давно предлагают подключать к большому монитору.
1️⃣ Появилось новое руководство по Desktop Experience. Это про то, как ваше приложение должно выглядеть и работать, когда пользователь запускает его в desktop-режиме. Там разобраны принципы компоновки под большие экраны, работа с курсором (включая кастомные иконки), windowing с header bar и подход к более высокой плотности информации в UI. Всё это логично вытекает из того, что Android всё активнее движется в сторону десктопа через функцию connected display.
2️⃣ Запустили Android Design Gallery — живой каталог с примерами хорошего дизайна под разные форм-факторы и паттерны UX. Обещают пополнять регулярно. Полезно хотя бы как источник вдохновения, когда застреваешь на том, как должен выглядеть адаптивный экран.
Честно говоря, руководство давно напрашивалось — адаптивная разработка под Android остаётся одним из самых недооценённых направлений. Большинство приложений на планшетах и десктопах до сих пор выглядят как растянутый телефон. Особенно что в Andorid 17 система будет игнорировать ограничения приложений на размеры окна и ориентацию, картина будет интересной.
🔗 Источник: Android Developers Blog
#Android #AndroidDev #Дизайн #UI
Please open Telegram to view this post
VIEW IN TELEGRAM
❤32👍12👎6🔥3
Помните историю с обязательной верификацией разработчиков за пределами Google Play? Ту, где сообщество буквально взорвалось возмущением — мол:
Google закрывает открытую платформу, прощай сайдлоадинг для всех, кто не хочет светить паспорт и платить регистрационный взнос.
Google тогда обещал прислушаться к обратной связи и решил понизить градус требований.
Теперь у пользователей будет так называемый advanced flow для установки приложений от неверифицированных разработчиков. Выглядит это как небольшой квест:
Официальная причина такой сложности — борьба с мошенниками. По данным GASA, в 2025 году 57% взрослых пользователей в мире столкнулись с мошенничеством, а суммарные потери составили $442 млрд (информация из анонса). Типичная схема: звонок с угрозами, давление и просьба срочно отключить защиту и установить "нужное" приложение. Многоэтапный флоу с ожиданием сутки как раз ломает эту цепочку — дать человеку время подумать.
Ещё одна приятная деталь — бесплатные аккаунты с ограниченным распространением для студентов и энтузиастов. До 20 устройств, без ID, без оплаты. Для тех, кто просто хочет поделиться своей поделкой с друзьями.
Google реально постарался найти баланс. Угроза мошенничества через сайдлоадинг — не выдуманная, суммы потерь говорят сами за себя. При этом hardcore-разработчики и опытные пользователи ничего принципиально не теряют, просто теперь нужно пройти однократный ритуал. Другой вопрос — насколько этот "ритуал" будет раздражать тех, кто устанавливает сторонние приложения регулярно. Я вижу два лагеря: одни скажут "ну наконец-то хоть что-то для безопасности обычных людей", другие — "очередное закручивание гаек под видом заботы". И честно — оба правы по-своему.
Вступает в действие в августе 2026 с разворачиванием новый системы верификации разработчиков
🔗 Источник - Блог Android Developers
#Android #AndroidDev #GooglePlay #Безопасность
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👎46👍32🔥5🤔5
Стандартный LRU-кэш не знает ничего о времени — он выбрасывает записи только когда заканчивается место. Поэтому в дисковом кэше Glide могут месяцами лежать устаревшие изображения, пока не будет достигнут лимит размера.
Команда Grab описала подход TLRU (Time-Aware LRU) — форк DiskLruCache с тремя дополнительными параметрами:
1️⃣ TTL — время жизни записи. Если
(текущее_время - время_последнего_доступа) > TTL, запись удаляется2️⃣ Минимальный порог — защита от полного сброса. Если пользователь долго не заходил и все записи устарели, кэш всё равно не очищается полностью — иначе при возвращении все изображения загружались бы заново
3️⃣ Максимальный размер — наследуется от LRU без изменений
Реализация аккуратная: метка времени последнего доступа хранится прямо в journal-файле, переживает перезапуски. Алгоритм оптимизирован — если самая старая запись ещё не устарела, остальные не проверяются.
Миграция со старого LRU безопасна в обе стороны: оригинальный
DiskLruCache читает TLRU journal, просто игнорируя временны́е суффиксы.Мне нравятся такие решения, когда не надо переписывать с нуля, а точечно расширить проверенную реализацию. Три параметра поверх существующего механизма — и кэш наконец умеет забывать ненужное. Ну и честно - решение лежало на поверхности и вполне логичное.
🔗 Источник: engineering.grab.com
#Android #AndroidDev #Производительность #Оптимизация
Please open Telegram to view this post
VIEW IN TELEGRAM
👍39❤15👎6🔥3🤔1👌1
🔥 Firebase Crashlytics получил MCP-сервер
В экспериментальном режиме Firebase запустили MCP-сервер для Crashlytics. Раньше, чтобы вытащить данные для анализа, нужно было настраивать экспорт в BigQuery, разбираться с Cloud Logging, писать SQL-запросы. Целый пайплайн ради того, чтобы понять что происходит со стабильностью приложения. Теперь всё это стало ощутимо проще.
Через MCP агент получает прямой доступ к данным Crashlytics: может вытащить список активных проблем с приоритетами, разобрать конкретный краш по ID со всеми стектрейсами и метаданными, получить агрегированную статистику по событиям и затронутым пользователям. Плюс умеет добавлять заметки к ишью и менять его статус прямо в ходе разговора.
Многие крашлитиковские ишью на практике достаточно простые, и агент вполне способен с ними справиться самостоятельно. Можно выстроить полный цикл: агент ночью смотрит новые крашы, разбирает их, создаёт задачи, предлагает или сразу делает фиксы, оставляет комментарии со всем контекстом. Раньше для этого не хватало именно доступа к данным мониторинга — теперь этот кусок закрыт.
🔗 Источник: firebase.google.com
#Firebase #Crashlytics #MCP #AndroidDev #Android
В экспериментальном режиме Firebase запустили MCP-сервер для Crashlytics. Раньше, чтобы вытащить данные для анализа, нужно было настраивать экспорт в BigQuery, разбираться с Cloud Logging, писать SQL-запросы. Целый пайплайн ради того, чтобы понять что происходит со стабильностью приложения. Теперь всё это стало ощутимо проще.
Через MCP агент получает прямой доступ к данным Crashlytics: может вытащить список активных проблем с приоритетами, разобрать конкретный краш по ID со всеми стектрейсами и метаданными, получить агрегированную статистику по событиям и затронутым пользователям. Плюс умеет добавлять заметки к ишью и менять его статус прямо в ходе разговора.
Многие крашлитиковские ишью на практике достаточно простые, и агент вполне способен с ними справиться самостоятельно. Можно выстроить полный цикл: агент ночью смотрит новые крашы, разбирает их, создаёт задачи, предлагает или сразу делает фиксы, оставляет комментарии со всем контекстом. Раньше для этого не хватало именно доступа к данным мониторинга — теперь этот кусок закрыт.
🔗 Источник: firebase.google.com
#Firebase #Crashlytics #MCP #AndroidDev #Android
👍58👎9
Вышла отдельная статья в блоге со скриншотами — можно наконец посмотреть как пикер выглядит в живую.
Из того, что не было в анонсе: на Android 17 старые
ACTION_PICK с контактными типами автоматически апгрейдятся до нового пикера. То есть часть приложений получит приватный выбор контактов вообще без изменений кода. Приятный бонус для тех, кто не торопится мигрировать.В Compose интегрируется через
rememberLauncherForActivityResult — код в статье рабочий, можно брать напрямую.🔗 Источник: android-developers.googleblog.com
📖 Документация: developer.android.com
#Android #AndroidDev #Android17
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍45👎9
В 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
Please open Telegram to view this post
VIEW IN TELEGRAM
👍41👎14
Android Developers Blog
Beyond Infotainment: Extending Android Automotive OS for Software-defined Vehicles
News and insights on the Android platform, developer tools, and events.
Оказывается Android Automotive всё ещё жива. Новостей про неё мало, но вот иногда доносится. Подробнее в блоге
#Android #Android17 #Automotive
#Android #Android17 #Automotive
👎11👍4
Вышел стабильный релиз 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
#Android #AndroidDev #CameraX #Jetpack #Камера
Please open Telegram to view this post
VIEW IN TELEGRAM
👍39👎6
Вышла Android 17 Beta 3 и все изменения там касаются геолокациии
👉 Location Button — разовый доступ к точной геолокации
Новый UI-элемент из Jetpack, который даёт доступ к точным координатам прямо в момент нажатия, без постоянного разрешения. Пользователь нажал кнопку "поделиться местоположением" в вашем приложении — получил данные один раз в рамках сессии. Никаких диалогов с выбором "разрешить всегда / только сейчас". Кнопку можно кастомизировать: цвет, форма, текст из предопределённого списка. Иконка местоположения остаётся обязательной и неизменной. На Android 16 и ниже Jetpack автоматически откатывается к стандартному диалогу разрешений.
👉 Примерная геолокация стала умнее
До этого "приблизительный" режим использовал фиксированную сетку 2×2 км. В малонаселённых районах это фактически деанонимизирует пользователя, потому что в квадрате 2 км может быть буквально несколько человек. В Android 17 размер ячейки теперь зависит от плотности населения — чем меньше людей, тем больше область. Логично, что давно должно было быть так.
👉 Индикатор использования геолокации
По аналогии с микрофоном и камерой, при любом обращении к геолокации теперь будет появляться системный индикатор. Плюс — диалог с историей последних обращений с возможностью сразу перейти в настройки разрешений.
👉 Переработанный диалог разрешений
"Точное" и "Приблизительное" местоположение теперь визуально сильнее разделены, чтобы пользователь осознанно выбирал нужный уровень доступа.
🔗 Источник: android-developers.googleblog.com
#Android #AndroidDev #Android17 #Приватность
Please open Telegram to view this post
VIEW IN TELEGRAM
👍64👎8
static final по определению константа, но на практике это использовалось годами для разных хаков.👉 Попытка изменить такое поле через рефлексию бросает
IllegalAccessException 👉 Попытка через JNI
SetStaticLongField() и аналоги — сразу краш приложения 👉 Ограничение включено только для приложений с
targetSdk = 37, но в Beta 1 проверка активна для всех приложений, чтобы выловить проблемы раньшеЗачем это нужно? Пока
static final поле формально могло меняться, рантайм не мог агрессивно оптимизировать код, который к нему обращается. Теперь — может. На практике это чаще всего задевает тесты, которые через рефлексию подменяют константы в production-коде, и старые хаки с логированием или конфигурацией. Где-то жить станет чуть сложнее, но в целом всё закономерно — меньше хаков, честнее код.🔗 Источник: developer.android.com
#android #android17
Please open Telegram to view this post
VIEW IN TELEGRAM
👍54👎7
Android 17 добавляет поддержку гибридной схемы подписи APK с постквантовым алгоритмом ML-DSA. Классический ключ подписи комбинируется с постквантовым и подпись становится устойчивой к атакам с использованием квантовых вычислений.
Схема гибридная, а не замена старому подходу, поэтому обратная совместимость сохраняется. Старые устройства верифицируют подпись через классический ключ, новые получают дополнительный слой защиты через ML-DSA.
apksigner.Квантовые компьютеры, способные реально угрожать текущим подписям,появятся не скоро, да и натравливать его на взлом APK - странный сценарий использования такой машины. Но инфраструктурные вещи лучше внедрять заранее, и хорошо, что Play App Signing снимает эту задачу с большинства из нас.
🔗 Источник: developer.android.com
#Android #Android17 #Безопасность
Please open Telegram to view this post
VIEW IN TELEGRAM
👍38👎5
В Swift 6.3 вышел первый официальный Swift SDK для Android. До этого поддержка была только в nightly-сборках, теперь это стабильный релиз.
Я делал про это видео на 📹 YouTube и на
Кому это реально пригодится? iOS-разработчикам, у которых есть Swift-библиотеки с бизнес-логикой и которые хотят переиспользовать их на Android без переписывания на Kotlin. Через Swift Java и Swift Java JNI Core Swift-код встраивается в существующее Kotlin/Java-приложение — не нужно всё переписывать с нуля.
🔗 Источник: swift.org
#Swift #Android
Please open Telegram to view this post
VIEW IN TELEGRAM
👍25👎14
Сайдлоадинг умрёт?
Нет. Верификация направлена против мошенников, а не против свободы установки. Верифицированные разработчики распространяют APK через любые каналы как раньше.
Что будет с установкой по ADB?
Нет. Сборка, отладка и деплой через ADB работают как прежде без регистрации. Регистрация нужна только если тестирование идёт через Firebase App Distribution, Play Internal Testing или APK отдаётся тестировщикам вне ADB.
Я занимаюсь разработкой как хобби, мне нужно будет пройти верификацию?
Нет. Для студентов и хобби-разработчиков вводится бесплатный аккаунт с ограниченным числом устройств без идентификации.
Зачем это вообще нужно?
На Play Store аналогичная схема уже дала двузначное снижение активности мошенников. Создать тысячи верифицированных аккаунтов с реальными документами несравнимо дороже, чем сделать это один раз как честному разработчику. Это не убирает всех, но делает порог выше. Плюс опыт пользователей с мошенничеством в разных странах разный, как и схемы обмана.
Ранний доступ стартует в октябре 2025 года, можно записаться уже сейчас.
#Android #AndroidDev #Безопасность
Please open Telegram to view this post
VIEW IN TELEGRAM
👎35👍6
Google начала глобальный роллаут верификации разработчиков в Play Console и новом Android Developer Console.
В Android Studio через пару месяцев прямо при сборке подписанного App Bundle или APK будет видно статус регистрации приложения. Для студентов и энтузиастов готовят бесплатный аккаунт с ограниченным распространением до 20 устройств — без паспорта, только email. Ранний доступ открывается в июне.
С 30 сентября 2026 года в Бразилии, Индонезии, Сингапуре и Таиланде незарегистрированные приложения можно будет установить только через ADB или специальный Advanced Flow. С 2027 года это распространится на весь мир.
🔗 android-developers.googleblog.com
#Android #GooglePlay
Please open Telegram to view this post
VIEW IN TELEGRAM
👎69👍6
Вышла новая версия Media3, и там заметное обновление для тех, кто строит плеерный UI на Compose. Главное в этом релизе — продолжение развития модуля
media3-ui-compose-material3. Добавили готовый Player composable, который объединяет ContentFrame с настраиваемыми элементами управления сверху, по центру и снизу. Рядом появился ProgressSlider для перемотки через жесты и PlaybackSpeedControl с кнопкой переключения скорости. На мой взгляд, это уже почти полноценный out-of-the-box плеер на Compose Material3.Breaking changes:
👉
FrameExtractor вынесен в отдельный модуль media3-inspector-frame 👉
LottieOverlay переехал в media3-effect-lottie🔗 Источники: android-developers.googleblog.com
#Android #AndroidDev #Jetpack #Медия
Please open Telegram to view this post
VIEW IN TELEGRAM
👍24👎6
Авторизация в Android-приложениях исторически была болью: Smart Lock, One Tap, FIDO2, Google Sign-In — каждый жил отдельно, со своими проблемами и способом интеграции. Credential Manager заменяет всё это единым Jetpack API.
val request = GetCredentialRequest(
listOf(
GetPasswordOption(),
GetPublicKeyCredentialOption(requestJson = fetchJsonFromServer())
)
)
coroutineScope.launch {
try {
val result = credentialManager.getCredential(
context = activityContext,
request = request
)
when (val credential = result.credential) {
is PublicKeyCredential -> sendToServer(credential.authenticationResponseJson)
is PasswordCredential -> signInWith(credential.id, credential.password)
is CustomCredential -> handleFederatedSignIn(credential)
}
} catch (e: GetCredentialException) {
handleError(e)
}
}
Суть простая: один вызов
getCredential() показывает пользователю bottom sheet, где агрегированы passkeys, сохранённые пароли и Sign in with Google. Пользователь выбирает аккаунт, а не метод входа — API само подбирает подходящий тип учётной данных.По возможностям:
👉 Passkeys — беспарольная аутентификация через публичный ключ с подтверждением биометрией или PIN. Работает с Android 9+, синхронизируется через Google Password Manager
👉 Пароли — поддержка через
GetPasswordOption с Android 4.4, то есть покрывает всю реальную аудиторию👉 FIDO — Sign in with Google теперь нативно встроен в тот же bottom sheet, никаких отдельных SDK
Что происходит в реальных приложениях с passkeys — числа впечатляют. Zoho после интеграции ускорил авторизацию в 6 раз и видит рост использования passkeys на 31% месяц к месяцу. X за 4 недели мигрировал с SmartLock/One Tap/Google Sign-In, удалил сотни строк кода и вдвое улучшил показатели успешного входа.
‼️ ВАЖНО: поддержка сторонних менеджеров паролей (1Password, Bitwarden и т.д.) появилась только с Android 14. На более ранних версиях работает только Google Password Manager.
На мой взгляд, это тот редкий случай когда Google реально упростила жизнь разработчикам, а не наоборот. Если в приложении до сих пор живут отдельные интеграции авторизаций — посмотрите в сторону миграции, оно того стоит и по коду, и по UX.
А вы уже интегрировали Credential Manager к себе? Если да — что больше всего зашло или наоборот споткнулись? Если нет — что останавливает?
#Android #Безопасность #Passkeys
Please open Telegram to view this post
VIEW IN TELEGRAM
👍60👎5
Media is too big
VIEW IN TELEGRAM
🔗 Источник Android Dev Blog
#AI #ИИ #Android
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27👎4