Kotlin Adept Notes

Как сделать свой SDK для Remote Config Если вы используете Firebase Remote Config для работы с фиче-флагами, то, возможно, для вас он станет платным, и кто-то начнёт искать альтернативу. Мы, на самом деле, уже давно с него мигрировали на другое стороннее решение из-за высоких рисков блокировки, а теперь полностью переходим на собственный сервис. Хочется поделиться особенностями разработки такого SDK. Начать стоит с выделения фасада с базовыми методами fetch, activate и get<Type> с Timber-подобным API. Тогда вы сможете с лёгкостью заменить одно решение другим. При реализации собственного SDK нужно учесть несколько важных моментов. 1. Понадобятся три вида хранилища данных: персистентное для хранения актуальных значений, персистентное для хранения временных значений (после fetch и до activate) и memory cache для моментального получения актуальных значений. 2. Нужно хорошо продумать, как исключить race condition и data race. Первичную инициализацию memory cache лучше сделать блокирующей, чтобы не потерять данные. Для методов fetch и activate лучше использовать общий mutex, чтобы не допустить рассинхронизации значений. 3. Предусмотрите throttle-механизм, чтобы не перегружать ваш бэкенд. При этом заранее продумайте, как будете реализовывать force fetch, когда значения нужно обновить как можно скорее, а также фоновое обновление, если пользователь долго не выгружает приложение из памяти. В общем, на первый взгляд кажется, что задача простая, но в ней очень много подводных камней. Так что это вполне хороший кейс для собеседования по System Design для мобильных разработчиков.

Новые AI модели и инструменты выходят каждую неделю, городские сумасшедшие хоронят программирование, а кто-то, обложившись сотней агентов, создает супер-успешные проекты. Как с этим жить, решительно непонятно. Чтобы помочь с этим справиться, ребята из подкаста Подлодка запустили закрытое сообщество инженеров, которые уже активно используют AI в работе и хотят делать это системно. Вот кому туда стоит подключиться: 👉Если вы хотите просто держать руку на пульсе происходящего в индустрии Подлодка вытаскивает очень крутых экспертов из Uber, xAI, Google, Яндекса, Cursor и других компаний. Они рассказывают, как работают их команды – и вы можете узнать у них то, о чем на конференциях начнут говорить только через год. А в закрытом чате разбирают все важные новости и изменения подходов к разработке. Если нет времени читать – вам приходит дайджест с главными выводами. 👉Если вы хотите вкатиться в лучшие практики AI разработки В клубе прошло уже больше 40 стримов на разные темы – от разбора фреймворков для Spec-Driven Development до того, как строить общий реестр скиллов для команды или автономные фабрики фичей. В чате есть специализированные комнаты по самым горячим темам – например, локальные модели, или тот же самый SDD. Клубчане делятся там своими сетапами и практиками. А еще в клубе есть бот, который может ответить на любой ваш вопрос на основе всего архива прошедших стримов и обсуждений в чате! 👉Если вы уже активно внедряете AI в свою работу или команды Это ровно то, чем занимаются все в клубе – так что вы сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как не сжечь все бюджеты на токены – все эти вопросы можно обсуждать в чате и на Random Coffee. Периодически в клубе проводят хакатоны. В мае в течение двух недель 15 команд делали свои фабрики фичей с разными архитектурами. В августе ребята стартуют новый хакатон, где будут копать в сторону самообучающихся агентов и долгосрочной памяти. 🔗Детали, расписание, заявки в клуб

Страх начать сначала Три месяца назад я пытался улучшить сканер кодов маркировки на Android, и первый подход не дал мне ровным счётом ничего, что даже загнало меня в некоторую апатию. Тогда пришлось перейти к тяжёлой артиллерии, а именно к написанию кастомного пайплайна на C++ с использованием MediaPipe. Это было то ещё приключение: весь код, разумеется, писался агентами, а я пытался понять, что там вообще происходит 🚬 В итоге мне удалось добиться определённых успехов в улучшении качества сканирования, однако работа с MediaPipe была больше похожа на ад: 🔘Как это добро дебажить 🔘Как нормально поставлять собранную либу в Kotlin-проект 🔘Как задать критерии успеха, ведь сканирование статического изображения ≠ сканированию с камеры Я отложил эту задачу, переключился на другой проект, а теперь вернулся к ней снова. Логичным шагом было бы продолжить с того, на чём я остановился. Раньше я наверняка так бы и сделал, потому что банально было бы жалко бросать свои труды. Но сейчас сам код стал почти бесплатным, поэтому я решил начать с чистого листа. Я запустил deep research по поиску лучшего пайплайна для сканирования, который почти съел все лимиты. В итоге я получил лютейший нейрослоп, в котором не было ровным счётом ничего полезного 😔 Но я не стал отчаиваться и решил сделать ещё один подход к реализаёции уже без MediaPipe, но с обновлёнными LLM. И, как ни странно, буквально за час получил полностью работающее решение, которое оказалось на голову выше всего того, что я делал раньше 😎 Разумеется, мне всё ещё далеко до коммерческих решений, но благодаря тому, что я не побоялся начать сначала, теперь я хотя бы могу всё это дебажить, итеративно улучшать и смотреть, что работает, а что нет. Именно на таких задачах можно оценить, насколько улучшились LLM'ки за последнее время, потому что в повседневной разработке очень сложно заметить реальную разницу.

Регистрируйся на Android Митап от Сбера ⚡️ 14 июля новое летнее пространство Сбера на один вечер станет точкой притяжения для Android-разработчиков. Спикеры из Сбера, Авито и SberDevices разберут практические кейсы: как создать собственную библиотеку для графиков, перейти на Jetpack Compose и находить проблемы с производительностью ещё до релиза. А после докладов можно будет продолжить общение на летней террасе: обсудить выступления, познакомиться с коллегами и просто хорошо провести вечер вместе с Android Community 😎 📅 14 июля, 18:30 📍 Сбер.Среда, Москва, Земляной Вал, 9А 💻 Очно и онлайн Количество очных мест ограничено — регистрируйся скорее

Особенности безопасной реализации локального пин-кода Когда-то давно мы реализовали локальный пин-код на основе этой библиотеки. Со временем эта реализация морально устарела, поэтому мы переписали модуль на KMP и Compose Multiplatform. Однако принципы безопасной реализации локального пин-кода остаются актуальными: 🟢В идеале вообще не использовать локальный пин-код. Но если приложение работает только в офлайн, то особого выбора нет. 🟢Пин-код не должен нигде храниться. Из него криптографически выводится ключ шифрования, например с помощью PBKDF2 (реализация есть как для Android, так и для iOS) 🟢Пин-код должен защищать реальные данные, а не просто закрывать экран. Если он лишь блокирует интерфейс, такую защиту можно обойти, подменив флаг в памяти или в хранилище. Поэтому в идеале не хранить и сам ключ: если данные удалось расшифровать, значит пин-код введён верно. 🟢Для шифрования рекомендую использовать библиотеку Tink. С ней сложнее допустить ошибку при реализации, к тому же она кроссплатформенная. Для iOS Tink напрямую использовать не получится, там проще сделать реализацию с CoreCrypto. 🟢Биометрия не должна ограничиваться простой проверкой отпечатка. Лучше использовать её для шифрования ключа, выведенного из пин-кода. Также стоит инвалидировать биометрические данные, если в системе был зарегистрирован новый отпечаток. 🟢Счётчик неудачных попыток должен быть персистентным, чтобы его нельзя было сбросить простым перезапуском приложения. Какие проблемы могут возникнуть 🔘У шифрования есть своя цена. Например, если зашифровать пользовательскую сессию, то до ввода пин-кода приложение не сможет выполнять фоновые операции. Поэтому здесь важно соблюдать баланс и не ограничить дальнейшее развитие приложения и шивровать только критичные данные. 🔘Если пользователь забудет код, он может потерять важные данные. Поэтому мы добавили резервное слово, которое также шифруется по аналогии с пин-кодом и позволяет восстановить доступ. 🔒А в вашем приложении есть локальный пин-код?

Обманчивая легкость из-за AI Продолжая тему захода в чужие роли с помощью AI, в комментариях справедливо отметили, что AI лишь создает иллюзию легкости. И это действительно так, особенно когда речь идет о легаси-проектах, в которых весь контекст хранится в головах разработчиков. Мне нужно было всего лишь вынести в публичное API некоторую функциональность из Telegram-бота. При этом бэкенд был написан на Kotlin 🏝 Казалось, что это просто подарок судьбы и все можно сделать с агентом за пару часов. Но что-то пошло не так 🤔 🔴AI отлично подстраивается под проект и хорошо работает по аналогии. Но если проект состоит из большого количества легаси и в нем используется множество разных подходов, то AI просто не знает, как делать правильно. И ты тоже не знаешь 🙃 🔴API в бэкенде — это только верхушка айсберга. Пришлось разбираться с кучей технологий: как работать с очередями в RabbitMQ, как читать логи в Elastic, как устроен отдельный сервис авторизации, как делать миграции в MongoDB и другим зоопарком внутренних решений. 🔴Несмотря на один и тот же язык, подходы в бэкенде и мобильной разработке могут значительно отличаться, что тоже создает когнитивную нагрузку. В итоге вместо пары часов мое путешествие по бэкенду затянулось на несколько недель, хотя задача была далеко не самой сложной. При этом эта история не масштабируется: нельзя просто дать любому разработчику подписку на LLM и ожидать, что он сможет сделать что угодно в любой области.

Тестировщики, общий сбор! Что успеете сделать за 100 минут работы? Делимся идеей: можно запустить параллельные тесты приложения на разных устройствах, проверить производительность, нажатия и UI. И все это — бесплатно в Мобильной ферме от Selectel, потому что при регистрации вы получаете 100 бонусных минут в сервисе. Что дает Мобильная ферма Selectel: ● Парк из 50+ моделей от популярных до редких смартфонов на Android и iOS. ● Удобство — настройки сохраняются, пока устройство закреплено за вами вне зависимости от количества тестов и длины сессии. ● Безопасность — информация о ваших сессиях автоматически удаляется после завершения аренды. Регистрируйтесь и получите промокод на 100 минут при первом заказе: https://slc.tl/z6ujt Реклама. АО "Селектел". erid:2W5zFHq1xQH

Насколько AI ускоряет TTM в большой компании 🧠 Мы запустили первое приложение, которое целиком написано с помощью AI: от прототипов и бэкенда до мобильных приложений. И хочется обсудить, насколько это реально ускорило общий TTM. Можно услышать сотни историй о том, как вайбкодеры одновременно работают над десятком проектов и пишут по 30 тысяч строк кода в день. Это всё работает, пока ты делаешь это один. Но в большой компании, где куча команд, ещё больше микросервисов, своя инфраструктура, дизайн-система, правила безопасности и многое другое, тогда без полноценной перестройки процессов на уровне всей компании такой подход просто не получится внедрить. Поэтому сейчас речь идёт именно о применении AI-агентов для написания кода, без глобального изменения процессов и с тем же уровнем качества кода, что и раньше. Итак, я замерил показатели предыдущих MVP наших проектов и получил интересные цифры. 🟡Разработка действительно ускорилась, но не драматически — примерно на 50%. Всё потому, что раньше мы тратили большую часть времени на написание кода, попутно уточняя требования и валидируя результат. Теперь это время, по сути, переместилось в фазу планирования и валидации. 🟢А вот ускорение time to market получилось действительно разительным: от идеи до релиза приложения стало проходить в три раза меньше времени, чем обычно. Но, по сути, AI здесь ни при чём. Это произошло потому, что значительно сократилось количество людей в цепочке. Разумеется, это всего лишь один пример, который проще всего было измерить. На большом масштабе цифры могут сильно отличаться. 📊 А какие цифры получаются у вас?

Как устроены продукты, которые задают тренды? Т-Банк готовит летний фест для тех, кому важно не просто слушать, а разбираться, как реально устроены продукты 20 июня «Сезон кода» собирает разработчиков, аналитиков и продактов в Санкт-Петербурге, чтобы показать, как создаются продукты — от первых гипотез до продакшена. Вас ждут: — прикладные доклады команд Т-Банка и других компаний про архитектуру, бэкенд и интеграции; — демо-зоны с ключевыми платформенными и коммуникационными сервисами и графовой аналитикой; — продуктовый стрим «Продуктовая кухня»: разберем, как данные превращаются в решения, а гипотезы — в рост продукта и ценность для пользователя; — формат, где знакомства происходят прямо по ходу программы. А еще — баскетбольная площадка, пинг-понг и большое афтепати с диджеем. Фест пройдет в ИТ-хабе Группы компаний «Т-Технологии». Количество мест ограничено — успейте зарегистрироваться

Как сделать аналог availability check из iOS в KMP В Swift есть специальный механизм проверки доступности API на разных версиях ОС: ``swift if #available(iOS 17.4, *) { newAPI() } else { legacyAPI() }

Это позволяет выполнять код только на определённых версиях ОС, где нужный API гарантированно существует.

Но, к сожалению, такого механизма нет в Kotlin Native при работе над KMP-проектами. И если мы хотим реализовать данную возможность только в Kotlin-коде, то придётся искать обходное решение.

В первую очередь понадобится метод для определения версии iOS:

```kotlin
internal fun isIosVersionAtLeast(major: Int, minor: Int = 0, patch: Int = 0): Boolean {
    val target = cValue<NSOperatingSystemVersion> {
        majorVersion = major.toLong()
        minorVersion = minor.toLong()
        patchVersion = patch.toLong()
    }
    return NSProcessInfo.processInfo.isOperatingSystemAtLeastVersion(target)
}

Однако само по себе это не поможет. Приложение всё равно будет крашиться при запуске на старых версиях ОС, если во фреймворке есть символы несуществующего класса. Поэтому придётся добавить в настройки сборки shared-фреймворка специальный флаг линковки, который будет подключать указанный системный фреймворк только в том случае, если он доступен:

it.binaries.framework {
    linkerOpts.addAll(listOf("-weak_framework", "AuthenticationServices"))
}

Однако если обратиться к несуществующему классу, то приложение всё равно упадет в рантайме. Поэтому для дополнительной безопасности можно также проверять наличие класса через NSClassFromString("ClassName").

✅ kmp-telegram-login Решил реализовать пример работы с OAuth 2.0 в KMP, как и обещал, но делать просто пример в вакууме не хотелось, и я вспомнил про недавно вышедший android-telegram-login. Подумал, что было бы полезно адаптировать его под KMP. Но что бы вы думали? Разумеется, кто-то уже навайбкодил это до меня здесь, причём всего пару дней назад 💅 В целом код из репозитория и наша реализация довольно схожи, за исключением некоторых важных моментов. Там также используется безопасный Code Flow + PKCE, но если Telegram не установлен на устройстве, то вместо нового AuthTabIntent используется CustomTabsIntent и есть подозрение, что с https-схемой могут быть проблемы на некоторых браузерах. ⚠️ Однако в либе есть очень критичная проблема. Похоже, разработчики ещё не запускали код на устройствах с iOS ниже 17.4 или не удосужились написать, как это исправить. Если собрать KMP-фреймворк с этой библиотекой, приложение просто крашнется при запуске, поскольку ASWebAuthenticationSessionCallback доступен только начиная с этой версии ОС. Именно поэтому мы у себя в итоге отказались от использования Universal Links и оставили только кастомную схему. На самом деле это можно исправить, и о том, как это сделать, я расскажу в следующем посте, так что stay tuned!

Недушное изучение и практика разговорного английского в онлайн-школе Authentic Pigeon, чтобы привести язык в порядок и дотянуться до офферов за рубежом. Узнать подробнее и записать на бесплатное демо-занятие можно в телеграм-боте.

Абсолютно кайфую от подхода … Занятия тут это не потогонка, а крутой дружеский разговор.

Студент школы — Иван Реклама. ИП Моисеева А.А. ИНН 270393875959

Решили тут перейти в дизайн-системе на state-based TextField, чтобы порешать разные проблемы предыдущей версии. И, как говорится, что же могло пойти не так 😐 Какие плюсы получили: 🟢Упростилась работа с курсором — страшные хаки больше не нужны 🟢Перестали лагать быстрые изменения текста на старых устройствах 🟢VisualTransformation теперь разделился на InputTransformation и OutputTransformation, что позволяет гибче работать с изменением текста Какие минусы: 🔘Пришлось костылить обёртку с двумя LaunchedEffect, чтобы сохранить перегрузку с предыдущим API 🔘Ну и самое бесячее: в новом TextField почему-то решили поменять отступ от клавиатуры. Теперь экран подскролливается к каретке ввода, и выглядит это как на изображении выше. А фиксится всё ужасно костыльным образом. 💬 Так что вопрос к знатокам: кто-нибудь уже сталкивался с подобной проблемой? И если да, то как её решили?

Особенности работы с OAuth 2.0 в KMP Во многих мобильных приложениях аутентификация и авторизация пользователей происходят через протокол OAuth 2.0, который является индустриальным стандартом. В нём предусмотрены различные флоу авторизации, и наиболее подходящим для мобильных приложений считается Authorization Code + PKCE. Этот флоу предотвращает перехват данных благодаря генерации временных параметров: codeChallenge и codeVerifier. Я не сторонник использования сторонних неофициальных библиотек в целом, и тем более для такой критичной вещи, как аутентификация. А в мире KMP найти что-то подходящее ещё сложнее, поэтому часто приходится делать всё самому. 🤖 Android Для Android в пакете androidx.browser появился очень удобный механизм AuthTabIntent, который берёт на себя почти всю работу, хотя и не без нюансов. Если выбранный в системе браузер по умолчанию не поддерживает AuthTab, ничего работать не будет. А кроме Chrome и Firefox, насколько я знаю, его почти никто не поддерживает. Поэтому придётся либо явно указывать пакет браузера, либо делать fallback, если подходящего браузера нет. 🍏iOS На iOS есть аналогичный удобный механизм ASWebAuthenticationSession. Но, как это часто бывает у Apple, не все фичи работают на старых версиях iOS. Например, редирект через https-схему (Universal Links) поддерживается только начиная с iOS 17.4, а на более ранних версиях придётся использовать кастомную схему. И в KMP это довольно сложно разграничить — приходится прибегать к чёрной магии чтобы исключать символы при загрузке фреймворка 🤨 ⭐️Если тема для вас актуальна и нужен KMP-сэмпл, ставьте реакции и я постараюсь собрать полноценный пример. #KMP #OAuth

Твой код — в сердце мощного ИИ! 💚 Команда GigaChat зовёт на One Day Offer амбициозных Java-разработчиков, которые готовы создавать AI‑продукты уровня BigTech и стать частью крупнейшего AI-комьюнити. Если ты дружишь с Java (версии 8–25), ладишь со Spring и Hibernate, а PostgreSQL и ClickHouse для тебя — не просто слова, переходи по ссылке и занимай слот на One Day Offer. Встречаемся 23 мая — очень ждём именно тебя!

Переход на AGP 9 в KMP-проектах Мы долго откладывали миграцию на AGP 9, ждали, пока всякие авторы по типу Huawei адаптирует свои плагины, и наконец решились ⚪️ Казалось бы, спустя столько времени это должна была быть легкая прогулка, но не тут-то было. С какими проблемами столкнулись 🟢Теперь нельзя использовать плагин android.application в KMP-модулях. 🟢Все модули нужно было мигрировать на новый Android Gradle Plugin. 🟢Больше нельзя генерировать BuildType в KMP-модулях. 🟢Значительно изменились многие API, которые мы использовали в своих Gradle-плагинах. Помимо этого, обновление Kotlin и Compose нам тоже вставило палки в колеса, но сегодня не об этом. Так что поделюсь рекомендациями для тех, кто еще не перевел свои проекты. Скиллы для агентов 🟢Официальный skill от Google для миграции KMP-проектов абсолютно не подходит: он лишь понаделал кучу deprecated свойств в gradle.properties. 🟢А вот аналогичный skill от JetBrains хорош! К сожалению, мы узнали о нем поздно, поэтому пришлось делать свой, но с pet-проектом он справился отлично. Что еще почитать 🟢Переход на Android Gradle Plugin для KMP 🟢Миграция на built-in Kotlin 🟢Гайд по миграции на AGP 9 💬 А как прошла ваша миграция на APG 9?

Особенности работы с Passkeys в Android и iOS Мы наконец-то реализовали мультиплатформенный модуль для работы с Passkeys и хочу поделиться нюансами, с которыми столкнулись.

Passkeys — более безопасная и простая альтернатива паролям, где аутентификация в сервисе происходит по биометрии.

В случае с Android поддержка Passkeys появилась с Android 9, в то время как на iOS только с iOS 16. При этом технология значительно совершенствовалась в последних версиях ОС, например, предоставляя выбор кастомного менеджера паролей. 🤖 В Android работа с Passkeys происходит через CredentialManager и реализована довольно удобно: почти всё происходит под капотом, достаточно лишь передать JSON с бэкенда. Но есть две проблемы: обработка ошибок и необходимость в Activity context, что создаёт определённые архитектурные сложности. В случае обработки ошибок приходится вручную извлекать из текста через регулярки коды ошибок, чтобы отображать понятные пользователю сообщения. 🇨🇳 А вот пользователи Huawei, к сожалению, не смогут воспользоваться этой фичей, так как CredentialManager просто отказывается работать с другими менеджерами паролей. Хотя для Huawei существует своя реализация FIDO2, API там реализован далеко не лучшим образом, и всё это делается через отдельную Activity, которая будет открываться даже если ключей нет 😐 🍏В iOS же работа с Passkeys происходит через ASAuthorizationController, где приходится вручную мапить каждое поле, конвертировать NSData в Base64URL и обратно. В общем, работать со всем этим добром не очень удобно. Также имеются отличия от Android: например, нельзя передать excludeCredentials для исключения дубликатов ключей, и не поддерживается direct attestation, который позволяет определить, что устройство подписано корневым сертификатом производителя. 💬 А вы интегрировали Passkeys в свой проект или планируете это сделать? #Passkeys #KMP #Android #iOS

Mobius 2026 Spring: конференция для мобильных разработчиков Почему мобильные приложения тормозят на проде? Как строить архитектуру, которая масштабируется с ростом пользователей? Где AI уже помогает решать инженерные задачи? Эти и многие другие вопросы разберем на Mobius этой весной. 📅 12–13 мая, Москва + онлайн Два дня докладов, воркшопов и живого общения мобильного сообщества. В программе — интеграции с бэкендом, управление состоянием, CI/CD, инструменты, оптимизация перфоманса и поддержка крупных проектов. Листайте карточки — собрали топовые доклады из программы. Используйте промокод, чтобы купить персональный билет со скидкой — KOTLINADEPT Купить билет Реклама. ООО «Джуг Ру Груп». ИНН 7801341446

Генерация макетов через Figma MCP 🖌 Пока все говорят про "убийцу Figma", хочу рассказать о том, как мне удалось примерить шапочку дизайнера и собрать макеты приложения в Figma с использованием корпоративной дизайн-системы с помощью Figma MCP. Не так давно Figma сделала скил под названием figma-use, который даёт доступ к рисованию на канвасе, переменным, стилям и компонентам. И это стало отличным шансом собрать макеты приложения без навыков работы в Figma. Я не стал сразу пытаться собирать макеты в Figma, а начал с генерации макетов в виде сайта, скормив бизнес-сценарии приложения и несколько изображений-референсов по стилю AI-агенту. В целом Claude с одного промта справился очень даже неплохо, дальше пришлось просто допилить некоторые моменты. И уже после этого я решил зафиксировать макеты в Figma на основе сгенерированного сайта. Но первое, во что я упёрся — это лимиты Figma: они закончились буквально за пару вызовов MCP, так что на бесплатном тарифе можете даже не пытаться что-то сделать 🙃 Далее я попробовал выборочно перенести экран как есть, без использования дизайн-системы, и это сработало хорошо, всё перенеслось так, как я и ожидал. Но проблемы начались, когда нужно было использовать компоненты существующей дизайн-системы. В нашем случае ключевой проблемой оказались кастомные шрифты, которых нет в Figma, из-за чего MCP не может редактировать текст в компонентах 😠 В итоге, чтобы добиться хоть какого-то вменяемого результата, мне пришлось создать ещё два скила: один для корректной работы с палитрой, чтобы правильно выбирать цвета, и отдельно для работы с дизайн-системой, где описаны id всех компонентов и их свойства, а также решения для всех проблем, возникших по пути. Через боль и страдания я перенёс все макеты. И что могу сказать по текущему статусу работы Figma MCP: пока что это очень сырая штука. Механизм self-валидации через скриншоты работает ужасно — такое ощущение, что работаешь со слепым дизайнером. Да и в целом всё это работает очень долго, даже банальные задачи могут занимать несколько минут, которые профессиональный дизайнер сделает в разы быстрее. 💬 А что вы думаете: сможет ли Figma адаптироваться к новому миру? Или макеты уже прошлый век, и всё сразу будет верстаться в коде? #Figma #MCP #AI

Как защитить API от нежданных клиентов На днях я делал приложение для bug bounty активности на конференции, в котором нужно будет найти секретную ссылку. Мне не хотелось, чтобы всё решилось простым запросом в AI или пересборкой приложения с отключением SSL-пиннинга, поэтому я задумался о том, как защититься от пересборки приложения, чтобы только версия с моей подписью могла делать запросы к серверу. Я решил попробовать Play Integrity. Всё бы ничего, но приложение должно быть обязательно опубликовано в Google Play, хотя бы во внутреннем тестировании, иначе аттестация устройства не будет проходить. Поэтому этот вариант мне не подошёл, и я решил реализовать собственный сервер аттестации, который проверяет цепочку сертификатов, извлекает из сертификата отпечаток подписи приложения и сравнивает его с заданным. Звучит круто, но почему тогда это не используется массово? Дело в том, что, во-первых, это работает не на всех версиях Android. Кроме того, устройство должно поддерживать Hardware Attestation, что может отсечь часть устройств и на них приложение просто не будет работать. Если вас заинтересовала тема, вы ещё успеваете залететь на Podlodka Android Crew и послушать доклад про Play Integrity, где разберут как работают эти механизмы. А ещё вы сможете попробовать сами обойти эту защиту в нашей bug bounty активности 💻 Так что присоединяйтесь, будет не только полезно, но и интересно 😉