Three ways how to dynamically load code into an Android application at runtime
https://erev0s.com/blog/3-ways-for-dynamic-code-loading-in-android/

История редизайна иконки Android Studio

#androidstudio

https://android-developers.googleblog.com/2023/05/redesigning-android-studio-logo.html

Reader - мультиплатформенный (iOS и Android) RSS-ридер, сделанный на Kotlin Mutliplatform и Compose Multiplatform. Кроме них из большого есть Ktor, SQLDelight, Decompose и Kotlin-inject.

Reader на GitHub: https://github.com/msasikanth/reader
Платформа: кроссплатформа
⭐️: 85

Эмулятор Smali-кода на Python

Весьма интересную штуку нашел недавно, еще не успел посмотреть, но возможно будет полезно тем, кто занимается патчем smali-кода.

Это небольшой и расширяемый эмулятор для smali-кода, написанный на Python.

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

#android #smali #emulator

Flipper zero can root Xiaomi vaccum robot using usb uart app
https://www.reddit.com/r/flipperzero/comments/13sabij/flipper_zero_can_be_used_for_xiaomi_vaccum_robot/
Tutorial: https://builder.dontvacuum.me/dreame/

Начинаем работу с Detekt, статическим анализатором кода для Android

Как вы знаете, процесс code review занимает все больше времени по мере роста команды разработчиков. В этой статье я расскажу об инструменте, который облегчает этот процесс.

С помощью инструмента под названием Detekt вы можете выполнить любые проверки классов, написанных на Kotlin, запустить процесс ревью кода в любое время (например, перед коммитом) и сэкономить время.

Статья: https://apptractor.ru/info/articles/nachinaem-rabotu-s-detekt-staticheskim-analizatorom-koda-dlya-android.html
Платформа: Android

Недавно в чате в очередной раз всплыл вопрос о том, что не надо использовать expect/actual там где достаточно обычных интерфейсов. А сегодня я наткнулся на статью как раз об этом!🤌
https://proandroiddev.com/achieving-platform-specific-implementations-with-koin-in-kmm-5cb029ba4f3b
Коин классный и популярный DI фреймворк. Автор на его примере показывает, как инжектить платформенные реализации в общий код. 👍

Застрял на трёх пальцах

https://cs.uwaterloo.ca/~csk/slide/

Binder Trace: Tool for intercepting and parsing Android Binder messages Think of it as "Wireshark for Binder"
https://github.com/foundryzero/binder-trace

Брутфорс сканера отпечатка пальца в смартфоне. Как страшно жить!

#cybersec #hack #research

Platform Samples - коллекция примеров применения различных API платформы Android.

Целью этих примеров является демонстрация определенной функциональности в изоляции, и они могут использовать упрощенный код. Для лучших практик в реальных условиях разработчики рекомендуют следовать документации и Now In Android.

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

Platform Samples на GitHub: https://github.com/android/platform-samples
Платформа: Android
⭐️: 234

Разрешения в Android

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

По итогу родилась статья на Хабр.
Прошу вашего внимания и, надеюсь, что информация окажется полезной!

Всем приятного чтения и хорошего настроения!

#habr #android #permissions

Существует отличный вариант украсить заголовки страниц в приложении при перелистывании. Предлагаем вам туториал — изучайте 😎

Читать статью

#новостиproglib

Если для эксплуатации уязвимости нужно передать Parcelable класс в intent-е, то есть пара способов это сделать. Представим, что activity ожидает модель User, которая лежит в пакете com.myapp.xxx. Можно создать в эксплойте такую же структуру пакетов, и класс с таким же названием и необходимыми полями. Чтобы не писать реализацию сериализации руками, то можно воспользоваться плагином и добавить к созданному классу аннотацию @Parcelize. Но иногда классы бывают сложными или их требуется несколько сразу. В этом случае проще взять из целевого приложения .dex файлы с этими классами, положить их в assets и работать с ними через DexClassLoader. Пример здесь.
#aht

Clock of Clocks - анимированные часы, сделанные с помощью Jetpack Compose.

Clock of Clocks на GitHub: https://github.com/khoa-omega/clock-of-clocks
Платформа: Android
⭐️: 22

Хочу оформить главные, можно назвать их заповедями тестирования или постулатами, называйте как хотите. Я уже в разработке почти 6 лет и вот весь мой опыт, который есть на данный момент можно оформить так:

Зачем тесты?

👉 Тесты не избавляют от багов, не делают программу надежнее и не заставляют тебя писать чистый код. Тесты нужны лишь убедится, что ты новым кодом не сломал предыдущий, позволяют не оглядываться назад на каждом шагу
👉 Тесты имеют смысл только в том случае, если они постоянно запускаются на CI и блокируют МРы, иначе это бессмысленная трата времени, плавали знаем
👉 Тест плох, если он падает постоянно, на него перестают обращать внимания и забивают
👉 Тест плох если всегда проходит, значит он нихрена не тестирует
👉 Тест пишем только тогда, когда уверены, что нет другого механизма обеспечить качество (см. прошлые посты)
👉 Флакающие/мигающие тесты, от таких тестов нужно избавляться также быстро как гугл отказывается от проектов. Мигающие тесты приносят целый ворох проблем: не дают никакой информации, нагружают систему т.к приходится их перезапускать, и увеличивают вероятность оказаться вне поля зрения.

Как не нужно тестировать?

👉 Не нужно писать тесты для банальных вещей когда у вас репозиторий тупо в сеть ходит и выдает список или проверять правильно ли мы вызываем какой-то метод
👉 Не нужно делать тесты, которые протестируют все возможные кейсы на свете. Сосредоточтесь на базовых сценариях, для всего остального есть мониторинг, поддержка и грамотный подход к ошибкам
👉 Конкретно в мобильной разработке, нахер не нужны тесты которые тестируют цвета, иконки, правильность отображения или не дай бог анимации. Такие тесты ебанутся какие дорогие, а выхлоп от них никакущий.
👉 Не нужно делать тестов на "всякий случай", нужно чтобы у каждого теста было четкое обоснование зачем он нужен
👉 Попытки добится какого либо процента покрытия кода бессмысленная дроч, которая ничего не дает, а только вынуждает идти на хаки и писать тесты на сэтеры (кринж даже от упоминания)

Как лучше тестировать?

👉 Тесты не должны ломаться при рефакторинге, и быть обузой. Иначе разрабы просто будут боятся рефакторить код, а это приведет к протуханию кода
👉 Тесты должны писаться также легко как и основной код
👉 В тестах может быть дублирование, так как избавление от дублирование это уже абстракция, абстракция это сложно, а сложность ведет к багам. Вам нужны баги еще и в тестах?
👉 Ассинхронность. Как показывает практика лучше ничего не подменять и тестировать в условиях реальной работы. Иначе в тестах на одном потоке все прекрасно, а в проде гонка и плавающие баги (см. подход из предыдущего поста).
👉 Тесты могут потребовать изменения в архитектуре или инфраструктуре, это ок так и должно быть. Однако внутри кода проекта не должно быть упоминаний о тестах: @visiblefortesting или idling в коде проекта это сигнал о том, что вы профакапились с архитектурой