Unikit открывает поиск co-founders в направление Unikit Apps 🪫

За последние годы рынок арбитража трафика значительно вырос.
Вместе с этим вырос спрос на стабильную инфраструктуру, качественные приложения и команды, готовые играть «в долгую».

В рамках масштабирования экосистемы Unikit мы запускаем отдельное направление мобильной разработки.
Мы ищем не просто исполнителей, а стратегических партнеров для совместного развития юнита.

Наши ресурсы для вашего старта:
- Финансовая мотивация: до 80% от прибыли направления
- Клиентская база: готовая инфраструктура и существующий поток входящих запросов
- Технологии: работа через удобный формат MMP, доступ к продуктовой и технической экспертизе команды Unikit
- Синергия: экосистема, которая позволяет кратно ускорить масштабирование.

Если вы обладаете экспертизой в мобильной разработке и хотите построить масштабный продукт на базе готовой инфраструктуры, давайте обсудим детали.

Контакт для связи: @unikit_support

🤖 Android XR за пару дней стал реальнее: XREAL показал очки Aura, Google — что на них строить

XREAL официально представил Aura (бывший Project Aura): лёгкие проводные очки с прозрачным дисплеем, вычисления вынесены в карманный блок на новом Snapdragon Reality Elite, Gemini в системе. Финальной цены нет, но база «не дороже $1500», резерв открыли за $99.

Google показал что на этом строить. Демка XR Geospatial Tour: надеваешь очки, поверх города висят 3D-подсказки, голосовой гид рассказывает про здания перед тобой. Внутри Geospatial API (VPS от Google в ARCore for Jetpack XR, субметровая точность и направление взгляда, точнее GPS), Gemini с Google Maps Grounding для маршрутов, Gemini TTS для озвучки и Compose for XR для 3D.

Если смотреть на рынок: смартфоны выезжены вдоль и поперёк, складные остались нишей, а лёгкие очки это правда новое место, где игра ещё не сыграна. Aura важна именно этим: форм-фактор наконец похож на то, что хочется носить, а не на шлем на полдня.

#Android #AndroidXR #XR #Gemini

🤖 Обновление верификация Android разработчиков: подключились 7 магазинов и новые API

В марте Google анонсировал верификацию для всех, кто распространяет приложения (был пост). В июне появилась конкретика, и главное в ней не про сроки.

Верификация теперь не история одного Play. К ней подключились сразу 7 магазинов: Google Play, Samsung Galaxy Store, Xiaomi GetApps, OPPO App Market, vivo V-Appstore, Honor App Market и Transsion Palm Store (кто-то вообще знал про него?). Барьер на распространение APK поднимается по всей экосистеме, а не только внутри Google, но привязка к Google Play Services экосистеме все равно остаётся.

Для автоматизации завезли API. Android Developer ID Status API проверяет, занят ли package name, Android Developer Console API регистрирует и ведёт пакеты прямо из CI/CD. Оба умеют OAuth delegation, так что регистрировать пакеты могут и сторонние платформы от твоего имени. ID Status API обещают глобально в июле, Console API сейчас в раннем доступе.

🤫 По секрету - с июня на большинство Android-устройств автоматически приезжает системный сервис, который позже будет проверять регистрацию разработчика. Раскатка уже идёт.

Сроки прежние: обязательная регистрация с 30 сентября 2026 в Бразилии, Индонезии, Сингапуре и Таиланде, глобально в 2027. Незарегистрированное по-прежнему ставится через ADB или advanced flow.

Новость показывает реальный масштаб по всем магазинам и, как я понял, чтобы проходить верификацию необязательно публиковаться в Google Play, подойдет любой доверенный магазин.

#Android #GooglePlay

📃 Сравнение скорости работы Metro DI vs Dagger/Hilt в Android проекте.

У меня по рабочей задаче встал вопрос какой DI выбрать для трансформации Android проекта в KMP с поддержка Android, iOS, Desktop и конечно нормальной работой с Compose. Решил понять чего будет стоить миграции на Metro DI и был приятно удивлен.

За день с помощью AI перевел Now In Android на Metro и запустил различные тесты сравнения влияния DI на сборку проекта. Подробности в 🪙 полной статье на Boosty

#Dagger #Metro #KMP #Performance

🤖 Gradle-плагин, который сам защищает APK от рута, хукинга и клонирования

Hydra — это RASP-плагин для Android: подключаешь одной строкой в build.gradle.kts, и на выходе assembleRelease APK несёт обфусцированное нативное ядро с защитой.

plugins {
    id("com.android.application")
    id("com.github.iamjosephmj.hydra") version "1.9.0"
}

Что проверяет на старте процесса: рут-доступ, Frida/hooking-инструменты, клонирование через virtual spaces (Parallel Space и похожие), эмуляторы, целостность APK. Нашёл критичное — завершает процесс. Без advisory-режима, сразу kill.

secrets {} в конфиге шифрует строки при сборке, в classes.dex попадает только цифертекст, расшифровка только на чистом устройстве:

val url = withContext(Dispatchers.IO) { Hydra.secret("apiUrl") }

Всё on-device, без сети, без телеметрии. INTERNET permission не объявляется вообще.

⚠️ Ядро libdicore.so закрыто и обфусцировано — проверить что именно кладётся в APK нельзя. Для финтех-продакшна это принципиальный вопрос. Kill-by-default сломает эмуляторы в QA — тестировать только на реальных чистых устройствах. QUERY_ALL_PACKAGES потребует декларации в Play Console.

В продакшн только после того, как понял, что именно ты кладёшь в свой APK.

🐱 GitHub

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

‼️ Maven Central вводит лимиты на публикацию

С 16 июня появятся предупреждения про превышение бесплатных лимитов на месяц, с 11 августа 2026 начнётся реальное ограничение бесплатных публикаций.

Пороги у 90 перцентиля: 1 167 файлов в месяц, 78 МБ суммарно, 7 релизов. Большинство open source разработчиков не заметят. Кто публикует много и часто — проверьте Usage Center уже сейчас.

Лично мне интересно, как это ляжет на KMP-проекты. Один multi-target релиз — это десятки файлов на каждую платформу: sources, javadoc, pom, подписи. Sonatype говорит, что работает с JetBrains над смягчением. Посмотрим.

💬 Не станет ли это движением в стороны децентрализации от Maven Central?

🔗 Официальная документация о лимитах

#Maven

🐱 Coroutine Tracer: иерархия корутин прямо на устройстве без внешних профайлеров

Стандартный Android Profiler показывает потоки. Не корутины. Kotlinx-coroutines-debug работает в unit-тестах, но не на реальном девайсе с живым UI. Яндекс Go сделали для этого отдельный инструмент.

Coroutine Tracer — плагин в их открытой библиотеке Demeter. Gradle-плагин на этапе сборки находит все launch/async через ASM и вставляет хук без единой правки в исходниках. В рантайме хук перехватывает возвращённый Job, регистрирует invokeOnCompletion и всё отображается как интерактивное дерево прямо на девайсе.

Два технических момента, которые зацепили:

👉 Перехватывают launch$default, а не только launch. Это та версия, которую компилятор Kotlin генерирует для вызовов с default-параметрами. Именно она выполняется в большинстве реальных вызовов.

👉 Parent-child связи строятся через обратный индекс Job → traceId. Без него launch-в-цикле даёт квадратичный оверхед на горячем пути. Дерево собирается итеративно — страховка от StackOverflowError на глубоких иерархиях.

Zero overhead по умолчанию: без includedClasses в конфиге плагин ничего не инструментирует.

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

🔗 Статья на Хабре

#Kotlin #Coroutines #AndroidDev

🛒 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 #Монетизация

🔴 Отказались от Compose Multiplatform и вернулись в натив. Разбираем кейс компании
Когда: вторник, 30 июня, 19:00 GMT+3

В прямом эфир буду обсуждать с разработчиком из компании, которая перешла на Kotlin Multiplatform, а теперь отказались и возвращаются назад! С другой стороны - я который переводит разработку банка на Compose Multiplatform.

Эфир пройдет на 🪙 Boosty, запись будет опубликована позже там же

#Kotlin #KMP #CMP #Compose #AndroidBroadcast

🐱 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

🤖 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

🐘 Два 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