🤖 Каждый раз, открывая новое приложение, я надеюсь на ту самую магию, когда одноразовый код авторизации сам считывается из пуша и подставляется в нужное поле. Но зачастую приходится разочароваться 🥲 В реальности этот UX сейчас стремительно деградирует, и виноват в этом не столько бэкенд приложений, сколько экономика и архитектурная слепота Google в Android.

Причина на поверхности — стоимость отправки классических SMS для бизнеса выросла настолько, что мобильная связь как канал верификации уходит на второй план. Практически любой крупный ритейлер, банк или сервис сегодня используют каскадную доставку: код сначала летит вам пушом (потому что бесплатный), потом в Telegram, WhatsApp, Viber, и только в крайнем случае — в старую добрую сим-карту. Бизнес банально экономит бюджеты.

И на этом фоне анонсы Android 17 выглядят как привет из прошлого века. Google тратит колоссальные ресурсы на то, чтобы заделать дыры в безопасности SMS, полностью игнорируя тот факт, что коммуникация людей и брендов давно переместилась в мессенджеры.

В новой версии ОС вводится жесткая трехчасовая задержка на доступ к входящим SMS с OTP-кодами для обычных приложений, чтобы защитить пользователей от троянов-перехватчиков. Разработчикам безальтернативно говорят: используйте нативный SMS Retriever API, который автоматически парсит сообщения по специальной хэш-подписи. Но это лечит симптомы старой болезни. Даже с SMS этот API внедрили далеко не все, потому что поддерживать уникальные хэши под разные сборки на бэкенде — та еще головная боль. А для мессенджеров никакого аналога просто не существует.

В итоге мы упёрлись в глухой тупик для UX:
👉 Если код авторизации пришел в Telegram, ваше приложение не может перехватить его легально.
👉 Пытаться читать пуши сторонних приложений через NotificationListenerService в Google Play строго запрещено — за это прилетает моментальный бан.
👉 Никакого доверенного и безопасного NotificationRetrieverAPI для мессенджеров Google не предлагает.

Пользовательский опыт в Android не развивается в соотвествии с трендами. Пользователь вынужден совершать кучу лишних движений: свернуть экран, открыть мессенджер, скопировать код, вернуться и вставить его руками. Пока Apple в iOS пытается развивать автоподстановку кодов из встроенной почты и системных уведомлений, Android-разработчики остаются заложниками ситуации, где безопасность SMS доведена до стерильности, а реальные сценарии из жизни брошены на произвол судьбы. Готовимся к тому, что процесс авторизации в приложениях на Android 17 станет еще чуть более «ручным».

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

🤖 Kimi K3, GPT 5.6, Qwen3.8 Max и OPUS 5 добавили в результаты официального AI Android Бенчмарка

Как поменялся рейтинг?
🏆 Claude Opus 5 новый лидер с результатов 91.8%. Прошлый лидер Fable 5 был с результатов 90.9%. По цене Opus вышел дороже
🥉 GPT 5.6 Sol попал на 3 строку с результатом 90.8%
‼️ На 4 месте расположился Kimi K3 с результатов 90.2%
👉 GPT 5.6 Luna показала результат 86.8% но при этом стоимость указана 7.2$ 🤯 (кажется тут закралась ошибка все верно и это шок по эффективности)
👉 GPT 5.6 Terra набрала 86.8% потратив 48$, что сейчас точно является лучшим показателем в соотношение результата на затраченный 1$.
🤔 Qwen3.8 Max показал достойные 87.0% но при этом потратил больше всех моделей - 196.7$

Бенчмарк все также игнорирует Grok и Compose модели 😡 Что-то не так в отношениях между компаниями Google и Илоном - загадка

UPD Kimi K3 не считается открытой моделью, что неверно. Изначально веса были закрыты и потом открываются. Видно в бенч попадают данные на момент запуска проверки модели.

#AI #Android #AndroidDev

🚀 Вышел AndroidX Tracing 2.0.0 — серьёзный апгрейд трейсинга

Tracing - это инструмент для низкооверхедного in-process трейсинга — записи временных срезов выполнения кода прямо внутри процесса приложения.

Полезен, когда нужно:
👉 понять, где именно тормозит код (особенно в корутинах);
👉 собирать детальные трейсы в поле / на проде, а не только в Studio;
👉 инструментировать библиотеки без жёсткой привязки к Android;
👉 потом мёржить эти трейсы с системными (Perfetto).

Особенно пригодится:
👉 Android-разработчикам, которые занимаются перформансом;
👉 авторам библиотек (в т.ч. KMP);
👉 командам с тяжёлым использованием корутин;
👉 тем, кто пишет бенчмарки (хорошо дружит с AndroidX Benchmark 1.5+).

Выход 2.0 обусловлен полностью новым API и архитектурой работы:
👉 Появился полноценный in-process tracing с собственным буфером (не зависит от system trace buffer).
👉 Новая модель: TraceDriver + Tracer + TraceSink (можно подключать свои бэкенды).
👉 Настоящая поддержка корутин с отслеживанием suspend/resume и переключений потоков.
👉 Поддержка KMP (Android + JVM).
👉 Существенно ниже оверхед по сравнению со старым android.os.Trace / trace {}.

Старый API не deprecated его по-прежнему рекомендуют для редких критичных событий, которые обязаны попасть в system trace.

🔗 Полные release notes по ссылке

#AndroidDev #Perfromance #AndroidJetpack

🚀 Обновление AndroidX Fragment

Вышел androidx.fragment:fragment-*:1.9.0.

Три изменения, которые реально заметны:
👉 Fragment теперь реализует ContextAware. Можно повесить OnContextAvailableListener и выполнить код в момент, когда контекст стал доступен (аналог того, что давно есть у Activity).

👉 У composable AndroidFragment {} появился параметр maxLifecycle. Можно жёстко ограничить lifecycle вложенного фрагмента — удобно в пейджерах, табах и других сложных UI, где не хочется, чтобы offscreen-фрагмент уезжал в RESUMED.

👉 Добавили system tracing lifecycle-событий через Jetpack Tracing. В Perfetto теперь видно, что происходит с фрагментами.

Плюс куча фиксов predictive back и setMaxLifecycle + popBackStack, которые тянулись с 1.8.x.

Если живёте на Fragment + Compose interop — обновляться имеет смысл. Чистый Compose-проект может спокойно пропустить.

#Android #AndroidDev #Jetpack #Fragment

🚀 Вышел AndroidX WebKit 1.17.0 — обновленная навигация и контроль над кэшем

Самое полезное в новом минорном релизе:
👉 WebViewCompat.navigate наконец-то нормальная замена loadUrl. Можно заменять страницу в истории, получать объект Navigation и корректно сохранять/восстанавливать заголовки. Для приложений, где WebView — не просто «открыть ссылку», а нормальный флоу, это давно было нужно.

if (WebViewFeature.isFeatureSupported(WebViewFeature.WEBVIEW_NAVIGATE_EXPERIMENTAL_V1)) {
    val params = NavigationParameters.Builder()
        .setShouldReplaceCurrentEntry(true) // заменяет текущую запись в истории
        .addAdditionalHeader("X-Custom-Header", "value")
        .build()

    val navigation: Navigation
         = WebViewCompat.navigate(webView, "https://example.com", params)
    
    // navigation можно потом матчить в NavigationListener
}

👉 Контроль HTTP-кэша через Profile.getHttpCache. Можно посмотреть квоту и при необходимости подкрутить. Полезно, если много статики, или наоборот — когда кэш только место жрёт.

if (WebViewFeature.isFeatureSupported(WebViewFeature.HTTP_CACHE_MANAGER)) {
    val profile = ProfileStore.getInstance().getOrCreateProfile("my_profile")
    val httpCache = profile.httpCache   // или profile.getHttpCache()

    // Посмотреть текущую квоту
    val currentQuota = httpCache.quotaBytes
    val defaultQuota = httpCache.defaultQuotaBytes
    val isDefault = httpCache.isUsingDefaultQuota

    // Задать свою квоту (например, 50 МБ)
    httpCache.setQuotaBytes(50L * 1024 * 1024)

    // Или вернуть автоматическое управление
    // httpCache.useDefaultQuota()
}

👉enqueuePreconnect — можно заранее поставить preconnect в очередь, не заставляя WebView стартовать прямо сейчас.

👉 Можно отключить автоматическую загрузку фавиконок (setDownloadFaviconsEnabled). Мелочь, но экономит память и трафик, особенно если иконок много.

👉 Плюс Android Lint, который теперь ругается, если кастомный WebViewClient не переопределил onRenderProcessGone. Полезно, потому рендерер падает регулярно.

🔗 Подробности релиза

#Android #AndroidDev #WebView #AndroidJetpack

🐱 DI Yatagan 2.0.0 RC: можно попробовать без переписывания Dagger-вызовов

Яндекс выкатил первый мажор своего DI-фреймворка. Основное:

👉 Единый backend-agnostic Yatagan entry point в api-public. Reflection или codegen подхватываются автоматически, имплементация с генерацией кода имеет приоритет.

👉 Экспериментальный Dagger compatibility mode. Включаешь yatagan.experimental.enableDaggerCompatibility и Yatagan генерит DaggerMyComponent фасады. Старые DaggerMyComponent.create() / .builder() продолжают работать. Поддерживается ядро (components, modules, scopes, multibindings, assisted), без Hilt/Android/producers.

👉 Conditions API почистили: legacy @Condition/@AnyCondition deprecated в пользу @ConditionExpression, @Provides(Conditional(...)) → отдельный @Conditional на методе.

👉 Runtime-конфиг стал declarative (processor options + parameters.properties), убрали глобальный mutable state.

Есть подробный migration guide и даже скилл для агента:
npx skills add yandex/yatagan

Это RC. Compatibility mode экспериментальный — граф лучше провалидировать. Но для тех, кто уже страдает от Dagger на больших проектах и смотрел в сторону Yatagan, порог входа заметно снизился.

🔗 Release Notes

#Android #AndroidDev #DI #Яндекс

🤖 Jetpack XR SDK: core-библиотеки добрались до Beta

XR SDK - набор библиотек для разработки приложения для очков и шлемов дополненной реальности на Android XR ОС

Google выкатил beta для трёх ключевых кусков:
- androidx.xr.scenecore:scenecore:1.0.0-beta02
- androidx.xr.arcore:arcore:1.0.0-beta02
- androidx.xr.runtime:runtime:1.0.0-beta02

Compose for XR пока ещё 1.0.0-alpha17 (обещают beta скоро).

Тестировать можно на Samsung Galaxy XR или в Android XR Emulator.

🔗 Официальный анонс

#Android #AndroidXR #XR #AndroidDev

🤖 Лимиты памяти на приложение раскатывают на большее кол-во устройств с Android 17

В Android 17 на Pixel уже работают per-app memory limits. Сегодня Google написал, что в течение года их начнут включать всё больше производителей на устройствах от 4 ГБ RAM и больше.

Как это работает на практике:
1. Превысил бюджет → страницы приложения насильно уходят в zRAM (сжатая RAM). CPU-оверхед → jank и тормоза.
2. Приложение продолжает есть много памяти дальше → процесс убивают.

Можно отловить причину это ловится через ApplicationExitInfo:
- reason == REASON_OTHER
- description содержит "MemoryLimiter:AnonSwap"

Можно ещё повесить TRIGGER_TYPE_ANOMALY в ProfilingManager и автоматически снимать heap dump в момент, когда лимит сработал.

Для локального теста поведения можно использовать adb:

adb shell am memory-limiter status
adb shell am memory-limiter manual <pid> <limit_mb>
adb shell am memory-limiter ignore <uid>|all|none

В Android Vitals и Crashlytics 20.1.0 уже есть отдельные сигналы по этим убийствам. Если у тебя в приложении есть тяжёлые экраны, кэши, игры или foreground-сервисы - следи за метриками.

🔗 Источник - блог Android Developers

#Android #AndroidDev #Android17

🔥 Android-разработчик, твоё приложение — это песочница, но пользователь может пробить в ней дыру в любой момент.

Многие думают, что разрешения — это просто диалог «Разрешить / Запретить». На самом деле это многослойная система с двумя уровнями проверок, временными разрешениями, автоматическим отзывом и политиками Google Play, которые могут заблокировать твоё приложение ещё на этапе публикации.

В этом видео мы копаем глубже документации и разбираем:
👉 Скрытый фреймворк AppOps — второй слой защиты, который может тихо заблокировать доступ, даже если у тебя есть грант.
👉 URI Permission Grants — механизм делегирования доступа без необходимости запрашивать широкие разрешения.
👉 Как проектировать архитектуру, чтобы приложение не падало, когда пользователь говорит «Нет».

Разрешение — это не гарантия доступа. Это формальное разрешение внутри сложной многоуровневой системы ограничений. Если твоя фича не работает без разрешения — это не проблема пользователя. Это баг архитектуры.

🎯 Кому смотреть:
👉 Android-разработчикам, которые хотят строить стабильные и устойчивые приложения
👉 Техлидам и архитекторам, которые проектируют приватность-first системы
👉 Всем, кто устал от крашей после отзыва разрешений в настройках
👉 Хочет лучше формировать требования для AI агентов и понимать что происходит

📌 В видео:
👉 Реальный путь разрешения — от манифеста до системного сервиса
👉 Почему checkSelfPermission — это только начало
👉 Как обходиться без разрешений через системные пикеры
👉 Google Play политики, которые могут забанить твоё приложение

Разрешения — это не техническая деталь. Это контракт доверия между твоим продуктом и пользователем.
———
Ставь 🔥, если хочешь видеть больше глубоких разборов Android-архитектуры! (будут только под платной подпиской)

🪙 Полный разбор на Boosty