Если еще не подключились к KotlinConf 2023 - то уже пора :)

Серёжа Чумиков сделал классный доклад про оптимизацию количества рекомпозиций в Compose. Если формат видео вам заходит больше чем статьи — вот оно!

По секрету скажу, что есть ещё одна запись доклада — про анимации. Надеюсь её тоже выложат.

#compose

Чем новее, тем лучше: как мы с GSON на Kotlinx.Serialization переезжали

Подводные камни, неочевидные моменты библиотеки Kotlinx.Serialization и сравнение ее работы с популярной Gson.

P.S. А я предпочитаю Moshi =))

Читать (Ru)

Оказавшись без любимого набора инструментов - можно и приуныть. Но не нужно. Используя только стандартные утилиты из Android SDK можно сделать многое. Рассмотрим на примере aapt2, adb и apkanalyzer:
- aapt2 dump strings target.apk | grep -E '[a-fA-F0-9]{32}' - найти все md5 хэши в приложении
- aapt2 dump xmltree target.apk --file AndroidManifest.xml - получить содержимое манифеста
- adb shell screenrecord /sdcard/demo.mp4 - записать видео с экрана
- adb shell dumpsys package my.target.app - получить много полезной информации о приложении. Например - какие диплинки оно обрабатывает
- adb shell input text <string> - ввести текст в выбранное поле ввода
- apkanalyzer manifest print target.apk - получить содержимое манифеста в xml формате
- apkanalyzer dex code --class com.google.crypto.tink.proto.JwtRsaSsaPkcs1PrivateKey target.apk показать smali-код класса из apk
И все это работает без декомпиляции apk файла. При чем, работает очень быстро. Узнать больше о стандартных cli утилитах можно здесь.
#aht

“Google в шоке, так как Samsung рассматривает возможность перехода на Bing в качестве поисковой системы по умолчанию на телефонах Galaxy”, — такой заголовок у статьи на sammobile, но это конечно преувеличение. Думаю, Гугл останется поиском по умолчанию на самсунге, просто цена за предустановку немножко возрастет.

https://www.sammobile.com/news/samsung-galaxy-phones-tablets-bing-search-replace-google-default-search-engine/

Подробный разбор использования MVI в мультиплатформенных мобильных проектах:
https://habr.com/ru/companies/kts/articles/729832/

Не компоузом единым! 🚀

Рецепты решения популярных задач на корутинах
👉 Asynchronous map
👉 Ленивая инициализация в suspend функции
👉 Переиспользование соединений
👉 Гонка между корутинами
👉 Повторное выполнение suspend функции

Репозиторий с кодом

#coroutines

Migrate your build configuration from Groovy to Kotlin

Надеюсь уже все видели (раз, два и три) о том, что Kotlin DSL теперь будет использоваться по умолчанию в Gradle скриптах вместо Groovy.

Поэтому, для тех, кто еще не мигрировал, оставляю список полезных ссылок👇

👉 Migrate your build configuration from Groovy to Kotlin
👉 Migrating build logic from Groovy to Kotlin
👉 What is Gradle Kotlin DSL
👉 Kotlin DSL: Gradle noscripts in Android made easy
👉 Migrate from Groovy to Kotlin DSL

FlorisBoard - это бесплатная клавиатура с открытым исходным кодом для устройств Android 7.0+. Ее цель - быть современной, удобной и настраиваемой, при этом полностью уважая конфиденциальность пользователя. В настоящее время находится в состоянии ранней бета-версии.

FlorisBoard на GitHub: https://github.com/florisboard/florisboard
Платформа: Android
⭐️: 4.1K

Photo picker, который был добавлен в Android 13, теперь доступен и в старых версиях, начиная с Android KitKat (4.4).

#android #picker #media #photo

https://android-developers.googleblog.com/2023/04/photo-picker-everywhere.html

Первый пост чисто для разогрева, тут ничего супер нового, однако я обозначу пару проблем с пониманием типов тестирования.

Большинство разработчиков черпают идеи о тестировании из книг или статей, которые читают в начале карьеры. Все после прочтения Фаулера с идеей пирамиды тестирования и Кена Бека с TDD обретают непоколебимую уверенность, что все можно решить юнит тестами и пирамида тестирования это универсальная модель которая подходит любому проекту. Реальность разумеется не так проста.

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

По пирамиде тестирования есть 4 типа тестов:
👉 end-to-end
👉 системные
👉 интеграционные
👉 юниты

С end-to-end тестами вроде как все понятно. Поднимаем все приложение, библиотеку или что мы там разрабатываем, которая работает в условиях очень близко к продовым. А вот остальные 3 это котел холивара. Юнит тесты мы пишем вроде как на один модуль или класс. Интеграционные тесты затрагивают несколько компонентов, классов, модулей и т.д. Системные это вроде как что-то между интеграционным и end-to-end. Даже из описания системного теста появляется вот какая проблема.

Смотрите, я делаю класс A. Затем пишу тесты только на этот класс. Казалось бы это юнит тест. Затем в этом классе A из-за сложности, я выношу часть функционала в другой класс B. Класс A использует код капотом класс B. И вот юнит тесты которые я написал на первый класс А это все еще юнит тесты или уже интеграционные, ведь вроде как уже несколько компонентов?

Еще можно на юнит тесты посмотреть с другой стороны, они запускают кучу процессов под капотом, это и jvm и загрузка классов и выделение памяти. Если думать про это в таком ключе то даже самый простой юнит тест на самом деле системный.

Эта баллада к тому, что не существует абсолютной шкалы или разделения тестов. То что для одного проекта будет интеграционным тестом, для другого будет просто юнитом и наоборот. Например если мы делаем какую-то библиотеку, то в ней end-to-end тестом может быть просто проверка вызова метода какого-то системного API.

Поэтому когда в каком-то проекте есть четкая направленность или даже правило писать только юнит тесты, это ничего кроме смеха не вызывает. Потому как это вообще ни о чем не говорит. Я сторонник того, чтобы вообще на запариваться об этом разделении и подбирать подходы в тестировании исходя из архитектуры приложения, слоев и т.д.

Другими словами когда мы не думаем о том, юнит это тест или интеграционный, а когда мы сосредотачиваемся на разделении, тестов на условно тесты для ViewModel и на тесты для Interactor. Помимо этого если мы говорим конкретно о тестах на Android, стоит больше уделять внимания разделению на тесты которые гоняются на эмуляторе и тесты которые можем прогнать локально.

Короче, как бы это не звучало банально, все сводится к старому доброму “все относительно“ и не слушайте фанатиков пирамиды.

​​Вход в приложение
#security #android

Почти в любом приложении, которое хоть как-то связано с хранением и работой с приватными данными, имеется аутентификация: или вход по паролю, или вход по биометрии + паролю.

И кажется, что задача супер простая: добавь сверху экран, который будет появляться при старте приложения, сохрани пароль на устройстве и сверяй с тем, что ввёл пользователь. Но на практике — большинство приложений в большей или меньшей степени реализуют вход некорректно: неправильно хранят пароль, не используют CryptoObject , дают возможность обойти экран входа и т.д.

Я поискал за вас и даю сразу несколько статей и уроков, которые с огромной вероятностью помогут вам корректно реализовать вход в приложение:

1️⃣ Тут автор рассказывает про пример некорректной авторизации в приложение и про свойства CryptoObject, setUserAuthenticationRequired и о том, как эксплуатировать эти хаки.

2️⃣ Отличное видео, где по шагам описывается процесс создания биометрической авторизации в приложение: разницу между различными классами для авторизации, как затащить alpha-версию библиотеки для входа (удивился, что она до сих пор в alpha) и наконец-то сделать корректный вход по отпечатку.

3️⃣ Библиотека PINkman, которая позволяет добавить вход по пину в приложение: можете не тащить всю либу в проект, но внутри — много крутых идей по корректному хранению пароля в системе. А можете и затащить, если не хочется разбираться.

4️⃣ Статья, где автор описывает ещё одно хитрое свойство — setUserAuthenticationValidityDurationSeconds, которое также может быть использовано как уязвимость для входа.

5️⃣ Ну и напоследок — больше информации про составляющие качественной криптографии в Android: KeyStore, MasterKeys, Blocking, Padding и другие страшные слова.

Конечно, идеальной защиты не существует и от "паяльника" в руках злоумышленника врядли поможет какой-то из методов защиты. Но для всех остальных случаев ваша защита способна защитить приложение и приватные данные пользователя.

Автоматизация публикации Android приложений в Google Play и Huawei AppGallery — инструкция от А до Я

Детальный гайд по тому, как автоматизировать процесс релизов Android-приложений в Google Play и Huawei AppStore.

👉 Структура Gradle‑проекта
👉 Android App Bundles (AAB) vs Android Packages (APK)
👉 Генерация номеров версий
👉 Получение ключей доступа от Google Play
👉 Загрузка сборок в Google Play
👉 Управление метаданными Google Play
👉 Получение ключей доступа от Huawei AppGallery
👉 Загрузка сборок и release notes в Huawei AppGallery
👉 Добавление CI/CD
👉 Заключение

Читать (Ru)

Только что провели в Отус открытый урок, где я показала, как писать полноценное приложение KMM от начала до конца с бизнес-логикой, сетью и DI
https://www.youtube.com/watch?v=aZhsZbF8CEg