🐘 Два Gradle-механизма для supply chain, которые почти никто не включает В Android-проектах зависимости обновляются тихо: transitive upgrade пришёл, сборка не сломалась, никто не заметил. Dependency Locking фиксирует resolved версии: // build.gradle.kts dependencyLocking { lockAllConfigurations() } Запускаешь ./gradlew dependencies --write-locks , Gradle создаёт .lockfile в gradle/dependency-locks/ . После этого любое изменение версий требует явного --update-locks . Dependency Verification проверяет подлинность артефактов: # gradle.properties org.gradle.dependency.verification=strict Инициализация: ./gradlew --write-verification-metadata sha256 . Создаёт gradle/verification-metadata.xml с checksums. Оба файла идут в git. Локинг без верификации не защитит от подмены артефакта на CDN. Верификация без локинга не предотвратит silent upgrade. Работает только в паре. В большинстве Android-проектов ни одно из этого не включено, а полезно чтобы остановиться каскадные неявные обновления #Gradle #Android #DevSecOps
AnAndroid Broadcast
CategoryOtherLanguageRUFirst seenJul 06, 2026QualityVerified
Subscribers916
Avg views6.8K
ERR738.1%
Price-- RUB
Price / subscriber--
Price / view--
Metrics updated: Jul 07, 2026
Recent posts
🤖 Samsung убивает процесс во время Custom Tab, даже когда Google обещал защиту через KeepAliveService Команда Android в Банки.ру полторы недели дебажила Seamless-авторизацию (вход по номеру через HTTP Header Enrichment ): на iOS всё стабильно, на Android соединения рвались случайным образом. Логи врали, таймаут без причины, снифать мобильный трафик оператора нельзя, а сам оператор банил номер за десятки попыток авторизации подряд. Причина не в бэкенде и не в DNS. Когда открывается Custom Tab для SSO, Activity приложения уходит в onPause() → onStop() . По документации Chrome, браузер должен поднимать process importance приложения через bound KeepAliveService , и процесс не попадает под сетевые ограничения. Но проприетарные слои энергосбережения Samsung и Xiaomi этот механизм игнорируют и убивают процесс по таймеру, не глядя на bound services. У Huawei логика другая — он смотрит на реальный сетевой трафик и не трогает активный процесс, поэтому там всё работало стабильно. Фикс — ForegroundService с типом shortService : override fun onCreate() { super.onCreate() if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.UPSIDE_DOWN_CAKE) { startForeground( NOTIFICATION_ID, createNotification(), ServiceInfo.FOREGROUND_SERVICE_TYPE_SHORT_SERVICE, ) } else { startForeground(NOTIFICATION_ID, createNotification()) } } `shortService доступен с Android 14 (лимит ~3 минуты, для 10–15 секунд поллинга с запасом), на более старых версиях работает как обычный ForegroundService . Процесс получает importance PERCEPTIBLE_APP_ADJ , и даже Samsung не трогает foreground service на One UI 6+. ‼️ ВАЖНО: сервис стартует и работает, даже если пользователь запретил приложению уведомления — POST_NOTIFICATIONS` для запуска foreground service не требуется, просто плашка не появится в шторке. Хороший повод лишний раз не доверять только официальной доке по process lifecycle и тестировать не на одном Pixel, а хотя бы на паре вендоров с разной агрессией энергосбережения. 🔗 Полная статья — там же разбор всех отвергнутых гипотез (DNS, оператор, регион) и код привязки к жизненному циклу SSO. #Android #AndroidDev
🐱 Poseidon : посмотри, куда реально ходят твои сторонние SDK Подключаешь аналитику, рекламный или нативный SDK и приложение сразу получает разрешение INTERNET . Android тут всё или ничего: один permission, весь процесс. Куда ходит каждая библиотека внутри отследить из коробки нельзя. Poseidon даёт allowlist в манифесте: <poseidon mode="monitor"> <!-- или enforce, если хочешь блокировать --> <allow host="api.mybackend.com"/> <allow host="*.cdn.example.com"/> </poseidon> Работает на трёх уровнях: JVM HTTP-клиенты (OkHttp, Volley, HttpURLConnection), нативный C/C++, Go и raw-syscall через seccomp. В Logcat видишь решение по каждому запросу каждой библиотеки отдельно. monitor — самый полезный режим для начала: просто смотришь, куда ходят все твои SDK, ничего не блокируешь. #Android #Security #SDK
🔴 Отказались от Compose Multiplatform и вернулись в натив. Разбираем кейс компании Когда: вторник, 30 июня, 19:00 GMT+3 В прямом эфир буду обсуждать с разработчиком из компании, которая перешла на Kotlin Multiplatform, а теперь отказались и возвращаются назад! С другой стороны - я который переводит разработку банка на Compose Multiplatform. Эфир пройдет на 🪙 Boosty , запись будет опубликована позже там же #Kotlin #KMP #CMP #Compose #AndroidBroadcast
🛒 Google Play делит комиссию на две части и разрешает сторонние системы платежей С 30 июня в США, EEA и UK заработает новая модель. Вместо единого процента: service fee (берётся всегда) и billing fee (+5% только при оплате через Google Play Billing). Ставки ещё зависят от того, "новый" или "старый" пользователь — поставил приложение до или после даты запуска новой модели в его регионе. 👉 Подписки (recurring) : 10% service fee для всех. Через Play Billing итого 15%, через альтернативный биллинг — 10%. 👉 Первый $1M/год : 10% service fee на любые транзакции, включая existing installs. 👉 Разовые покупки, new installs, стандарт : 20% + 5% billing = 25%. 👉 Разовые покупки, existing installs, стандарт : 25% + 5% billing = 30% . Те же цифры, что были до. Для existing installs есть один выход: если переводишь пользователя на свой сайт (external web link), billing fee нет — получается 20% вместо 30%. По сути Google разгрузил будущий трафик, а существующую базу оставил на старых ставках. Снижение на разовые покупки по-настоящему заработает только по мере переустановки — растянется на годы. Для команд с оборотом до $1M всё ровно лучше: 10% service fee вне зависимости от типа транзакции и статуса инсталла. 🔗 Источник - Android Dev блог #Android #GooglePlay #Монетизация