Android Broadcast
Подборка новостей и статей для Android разработчиков. Реклама и связь с автором @ab_manager РКН https://abdev.by/rkn_tg_ab #MQRZR
نمایش بیشتر📈 تحلیل کانال تلگرام Android Broadcast
کانال Android Broadcast (@android_broadcast) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 14 586 مشترک است و جایگاه 8 770 را در دسته فناوری و برنامهها و رتبه 45 383 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 14 586 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 08 ژوئیه, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 21 و در ۲۴ ساعت گذشته برابر -4 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 45.54% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 24.25% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 6 640 بازدید دریافت میکند. در اولین روز معمولاً 3 536 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 37 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند api, kotlin, gradle, сборка, androiddev تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Подборка новостей и статей для Android разработчиков.
Реклама и связь с автором @ab_manager
РКН https://abdev.by/rkn_tg_ab #MQRZR”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 09 ژوئیه, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
kotlinx.coroutines появился issue: AtomicReferenceFieldUpdater, которым корутины управляют состоянием Job, на Android работает в 2–4 раза медленнее, чем обычный AtomicReference на операциях compareAndSet и lazySet.
Корень проблемы в том, что корутины используют atomicfu, который на JVM компилируется в Atomic*FieldUpdater ради совместимости с KMP. На десктопном JDK это нормально, но ART на Android оптимизирует их хуже. Бенчмарк на Pixel 4a давал 135 нс против 50 нс — разница почти в 3 раза на compareAndSet.
R8 в составе AGP 9.2 закрывает этот разрыв на уровне компилятора: он определяет, где Atomic*FieldUpdater можно заменить на Unsafe-вызовы, и генерирует одну инструкцию вместо цепочки. ART тоже получит аналогичную оптимизацию в JIT, но она имеет ограничения по версии платформы и хуже масштабируется по тестам автора.
Для нас это значит: никаких изменений в коде, просто обновить AGP. Бесплатное ускорение каждого launch и cancel в приложении.
На мой взгляд, абсолюнто правильно решать проблему именно на стороне R8, а не правки всех библиотек.
🔗 Источник - X Andrei Shikov
#kotlin #coroutines #performanceval 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 #Безопасность #Passkeysmedia3-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 #МедияСайдлоадинг умрёт?Нет. Верификация направлена против мошенников, а не против свободы установки. Верифицированные разработчики распространяют APK через любые каналы как раньше.
Что будет с установкой по ADB?Нет. Сборка, отладка и деплой через ADB работают как прежде без регистрации. Регистрация нужна только если тестирование идёт через Firebase App Distribution, Play Internal Testing или APK отдаётся тестировщикам вне ADB.
Я занимаюсь разработкой как хобби, мне нужно будет пройти верификацию?Нет. Для студентов и хобби-разработчиков вводится бесплатный аккаунт с ограниченным числом устройств без идентификации.
Зачем это вообще нужно?На Play Store аналогичная схема уже дала двузначное снижение активности мошенников. Создать тысячи верифицированных аккаунтов с реальными документами несравнимо дороже, чем сделать это один раз как честному разработчику. Это не убирает всех, но делает порог выше. Плюс опыт пользователей с мошенничеством в разных странах разный, как и схемы обмана. Ранний доступ стартует в октябре 2025 года, можно записаться уже сейчас. #Android #AndroidDev #Безопасность
MOB26BROADCAST
Купить билет
#Реклама. ООО «Джуг Ру Груп». ИНН 7801341446apksigner.
Квантовые компьютеры, способные реально угрожать текущим подписям,появятся не скоро, да и натравливать его на взлом APK - странный сценарий использования такой машины. Но инфраструктурные вещи лучше внедрять заранее, и хорошо, что Play App Signing снимает эту задачу с большинства из нас.
🔗 Источник: developer.android.com
#Android #Android17 #Безопасностьstatic final по определению константа, но на практике это использовалось годами для разных хаков.
👉 Попытка изменить такое поле через рефлексию бросает IllegalAccessException
👉 Попытка через JNI SetStaticLongField() и аналоги — сразу краш приложения
👉 Ограничение включено только для приложений с targetSdk = 37, но в Beta 1 проверка активна для всех приложений, чтобы выловить проблемы раньше
Зачем это нужно? Пока static final поле формально могло меняться, рантайм не мог агрессивно оптимизировать код, который к нему обращается. Теперь — может. На практике это чаще всего задевает тесты, которые через рефлексию подменяют константы в production-коде, и старые хаки с логированием или конфигурацией. Где-то жить станет чуть сложнее, но в целом всё закономерно — меньше хаков, честнее код.
🔗 Источник: developer.android.com
#android #android17