Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода, и как выходит очередная статья про ssl pinning. Но на этот раз я попробовал посмотреть на этот вопрос с точки зрения необходимости применения этой технологии в мобильных приложениях. Для этого я смоделировал сценарий, когда на устройство пользователя попадает сертификат злоумышленника, и как себя в этом случае начинают вести разные компоненты мобильного приложения в зависимости от настроек безопасности.

#News #Release #Compose

Fragment Compose Artifact

В результате последнего обновления Jetpack библиотек, среди прочего, появился новый артефакт fragment-compose. Основной его задачей является поддержание проектов, которые находятся в процессе миграции с "Compose на фрагментах" на "full Compose" архитектуру.

На данный момент единственной его фичей является extension метод content, который избавляет от необходимости создавать ComposeView и выставлять нужный ViewCompositionStrategy.

:slowpoke: шикарный доклад про нутрянку корутин и способы их применения помимо асинхронности.

🟢 Разбор примитивов корутин из Kotlin stdlib
🟢 Как устроены билдеры вида sequence { yield() }
🟢 Глубокая рекурсия без отрыва стека
🟢 Парсеры

Friendly reminder разработчикам Kotlin:
⚫️ сиквенс — это бесполезная обёртка над итератором (в Rust её нет — компилятору легче оптимизировать и разворачивать длинные конструкции вида iter.map.filter.etc)
⚫️ DeepRecursiveScope.callRecursive стоило бы назвать invokeRecursive, консистентно с invoke и invokeSuspend, зашитыми в язык
⚫️ в очередной раз не хватает «:: наоборот» — fun smth() by DeepRecursiveFunction {}
Friendly reminder автору:
🟡 скоуп билдера должен быть @RestrictsSuspension
🟡 пожалуйста, не надо data-классов
Friendly reminder для организаторов:
💡 существуют нейросеточные плагины для убирания чвякания из речи

Весь прошлый год я плотно работал с ExoPlayer и решил написал статью про это.

Что внутри?
- Как ускорить процесс загрузки
- Как улучшить разрешение
- Как предотвратить ошибки воспроизведения
- Ловушки и уроки
- Производительность с Jetpack Compose
- Влияние улучшений на продуктовые метрики

Вот обосрались, так обосрались! Даже жалко. Не так давно Google выкатили обновление Play (которое, как мы знаем, ставится автоматом, в обход всего). Обновление оказалось с приколом, часть пользователей получили нерабочие Pixel смартфоны. И кажется, пока не нашлось ни одного способа решить проблему удаленно на стороне Гугла. Вместо этого они где-то в третьей жопе своих форумов предлагают нормальным людям поставить ADB и повыполнять разного в терминальчике. Причем описан только golden path (в обоих, сука, смыслах: и когда все идет хорошо, и когда «спасибо, что только обоссали»), про приколы работы ADB в разных окружениях людям, видимо, придется расспрашивать Gemini.

#google #pixel #bug

Analysis of Android settings during a forensic investigation
https://blog.digital-forensics.it/2024/01/analysis-of-android-settings-during.html

DIY: Твоя собственная библиотека для инъекции зависимостей

Лучший способ понять, какая библиотека для инъекции зависимостей вам нужна, — начать писать свою! Автор пишет DI-библиотеку и применяет ее на достаточно простом, но прикладном кейсе.

👉 Анти-паттерн. Если вы протаскиваете зависимость через десятки классов, только ради использования в последнем
👉 Автор изобретает заново шаг за шагом Google Guice, затем Dagger 1 и в конечном счете Dagger 2. Достаточно показательно, как приходили к существующим решениям в библиотеках
👉 Интересно было посмотреть, как генерируются factory-классы через KSP
👉 Красивая работа с аннотациями, которую можно рассматривать в отрыве от статьи

А что вы используете в проекте?

Jake Wharton решил исследовать как лучше делать маппинг набора значений в одну строку и какую лучше выбрать реализацию для этого по скорости/памяти. Массивы с лямбдой инициализации значений будут довольно полезны

#performance

Обновление приложения до targetSdk 34

Обязательное обновление targetSdkVersion ожидается, предположительно, в августе этого года. Добавляем задачку в беклог ближайшего спринта и не переживаем о предупреждениях из Google Play

👉 Если вы используете foreground сервисы, то для них появился foregroundServiceType, который нужно будет определить в манифесте
👉 Обновление Android привело к обновлению OpenJDK до 17. А это значит что могло сломаться: регулярные выражения, ProGuard и десериализация UUID.
👉 При использования BluetoothAdapter.getProfileConnectionState требуется BLUETOOTH_CONNECT (Должен быть и в манифесте и запрашиваться в рантайме)
👉 Ограничения для Intent. Тщательно проверьте, как используется android:exported в ваших приложениях. Неявный Intent может быть отправлен только к android:exported="true”
👉 У BroadcastReceiver новый параметр - ContextCompat.RECEIVER_EXPORTED. Добавляем его в зависимости от того, как вы с ним работаете
👉 Динамически подгружаемый код должен быть помечен как readOnly перед использованием
👉 Ограничения на работу с ZipFile. Теперь будет кидаться ошибка, если в имени есть модификаторы пути до файла ".." или "/".
👉 Расширение ограничений при запуске приложений в фоне. Добавляем еще один параметр в PendingIntent.

В целом, ассистент миграции поможет вам перевести приложение на новое SDK, но лучше самостоятельно проверить, что все упомянутые моменты были переведены верно, иначе рискуете получить неверное поведение приложения или просто краш

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

#coroutines

#Article #Medium #Recomposition

Jetpack Compose: Strong Skipping Mode Explained

Начиная с версии 1.5.4+ Compose компилятора, в Compose появился Strong skipping mode — новая экспериментальная фича, предназначенная для еще большей оптимизации количества рекомпозиций. Подробнее — в сегодняшней статье.

Зеркало статьи 👉 тут

Магические файлы .bak в SharedPreferences

Всем привет!

Наткнулся на крайне занятную статью, которая рассказывает о работе механизма SharedPreferences с файлами с расширением .bak

До этого момента, я даже не знал, что так можно. Оказывается, если внутри SP есть файл, например, credentials.xml и рядом лежит credentials.xml.bak, то при загрузке этого файла первый будет удален, файл бекапа будет переименован и использоваться, как оригинальный, что подтверждается анализом исходников.

Это может помочь, если у вас есть возможность записать файл в директорию, но приложение проверяет наличие файла перед записью

if(file.exists()) abort();

Я пока с таким не сталкивался, но однозначно буду иметь это поведение ввиду.

Ну или по крайней мере проверю, может оно вообще не так, но по коду выглядит логично :)

#android #sharedprefs

Я понял, что не публиковал тут шаблон EditorConfig для Android-проектов. Недавно обновил его под последнюю версию IDE — добавил парочку новых настроек и поправил порядок и заголовки в файле, чтобы они соответствовали изменениям в UI.

Что за EditorConfig?

EditorConfig — это спецификация файла конфигурации для кодстайла. Самые общие опции типа indent_size и insert_final_newline заложены в саму спецификацию. Прелесть в том, что эти опции понимают все редакторы кода, а значит будет меньше головной боли когда открываешь файлы проекта в VS Code или ещё где-то. Некоторые IDE поддерживают специфичные для них настройки кодстайла, например, все настройки относящиеся к IDEA начинаются с ij_ и настроить там можно практически всё то же самое, что и в Settings > Code Style.

И всё-таки зачем его использовать?

Согласен, идея шаринга настроек кодстайла между разными IDE звучит не убедительно. Не самый частый кейс, к тому же есть ограниченное количество общих настроек. Забудьте, есть причины гораздо круче:

1️⃣ Самое очевидное — пошарить кодстайл между всеми разработчиками. Добавляете файлик .editroconfig в корень проекта и теперь у всех разработчиков одинаковые настройки IDE и автоформатирование работает одинаково (можно ещё EditorConfig в required plugins добавить, чтобы убедиться, что плагин у всех точно включен и настройки не будут игнорироваться).
Такой способ шаринга кодстайла лучше чем распространение через Export/Import архива с настройками или добавление файлов из .idea/ в репозиторий. Во-первых, потому что формат EditorConfig не зависит от версии IDE. Во-вторых, вносить изменения в него куда проще, а проигнорировать их не получится (как в случае с распространением через архив).

2️⃣ Более гибко настраивать кодстайл. К примеру, вы решили, что ненавидите wildcard-импорты и запрещаете их использование в проекте. При этом в скриптах .kts хочется их разрешить. Как это сделать средствами IDE? Не знаю. А в EditorConfig можно определять разный кодстайл для разных файлов и каталогов. Для .kt один кодстайл, для .kts немного другой. Для res/*.xml один, для остальных XML-файлов другой.

3️⃣ IDE-независимость. Я там чуть выше сказал забыть про шаринг настроек между IDE, но всё-таки упомяну, что во Fleet (новом редакторе от JetBrains) формат EditorConfig вообще считается основным форматом для настройки кодстайла. Помимо IDE формат EditorConfig понимает, например, ktlint. То есть это отличная точка синхронизации для любых инструментов, которые хотят знать про кодстайл проекта.

Ок, продал, но зачем нужен шаблон?

Файл EditorConfig можно создать для своего проекта из настроек IDE, но у этого способа есть один минус — не всегда понятно какие опции что означают. Чтобы сгладить этот минус, я сгруппировал опции в файле таким образом, чтобы иерархия совпадала с тем как эти опции отображаются на экране настроек в IDE. Теперь можно легко сопоставить опцию в конфиге с пунктом настроек и понять что она делает.

Шаблон не стоит использовать "as is", проверьте, что настройки не противоречат кодстайлу проекта. Если ваша IDE уже настроена в соответствии с кодстайлом, проще всего экспортировать ваши настройки в формат EditorConfig и посмотреть насколько сильно они отличаются от шаблона (для этого можно предварительно отсортировать строки и взять diff).

#tooling

Чего ждать от Java ближайшие 10 лет?

Новые фичи в Java не создаются в вакууме, а объединяются в группы с конкретной целью. Каждый релиз — небольшие шаги в сторону этой цели. Расскажу про основные текущие проекты.

⭐️ Project Loom

Цель: добавить легковесные(виртуальные) потоки

Самая заметная фича со времён Stream API. Большинство проектов получат огромный буст от внедрения виртуальных потоков. Что важно — с минимальными изменениями в коде.

В Java 21 вышло базовое апи по работе с виртуальными потоками. Предстоит ещё много работы внутри JVM и в рамках языка, чтобы удобно управлять тысячами задач.

⭐️ ZGC / Shenandoah

Цель: сборщик мусора с минимальными паузами

Сборщики чуть отличаются по реализации, но задача одна — обеспечить минимум простоя во время сборки мусора. Разумеется, не бесплатно. Паузы уменьшаются, но увеличивается расход памяти и снижается пропускная способность.

Для большинства проектов это не актуально. Сборщик по умолчанию G1 отлично работает и становится лучше с каждым релизом.

⭐️ Project Panama

Цель: упростить работу с native кодом и памятью за пределами JVM

Проект делится на 2 направления:

🔹 Новый вариант JNI

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

🔹 Работа с памятью за пределами JVM

Нужна проектам, которые хотят управлять памятью без посредничества Java. Самим делать сборку мусора, сжимать и раскладывать данные по определённым структурам.

⭐️ Project Amber

Цель: упростить язык, добавить новые конструкции

Самые "народные" фичи, которые часто попадают в обзоры и статьи: var, текстовые блоки, records, pattern matching, sealed классы, string templates и так далее.

Что-то получается хорошо, что-то не очень. Где-то много пафосных разговоров про data-oriented programming. Есть странные фичи, вроде упрощения написания Hello world.

⭐️ Project Leyden

Цель: ускорить время старта Java программ

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

⭐️ Project Valhalla

Цель: оптимизировать работу с данными

Здесь так же два направления:

🔹 Создать value types — объект с полями и методами, работа с которым идёт как с примитивом:
✅ Передаётся по значению
✅ Компактно лежит в памяти
✅ Не может быть null

🔹 Создать общую схему работы с примитивами, объектами и value types, избавить разработчика от мыслей про boxing/unboxing

❓ А когда будет готово?

Плохая новость — реализации всех проектов растягиваются на десятки лет.

10 лет — не преувеличение. Лямбда-выражения в java обсуждались с 2004 года, а увидели свет только в 2014.

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

На java пишут большие системы, которые работают десятки лет. Поэтому основательный подход абсолютно оправдан😌

Продолжаем разбирать прикольные уязвимости. На этот раз у нас уязвимость в библиотеке Jetpack Navigation. Суть ее в том, что она позволяет стороннему приложению открыть любой экран атакуемого приложения и передать туда параметры. Круто звучит? Вот и я так думаю. А Google не считает это уязвимостью и после получения репорта нам ответили, что "поправят документацию". Не будь как Google, исправляй ошибки в своих приложениях! И знай чем грозит использование библиотеки Navigation.

штош: Джейк сдержал слово и аргументированно рассказал, почему не стоит использовать toolchain-ы в ваших билдах! Приглашаю к ознакомлению 🧑‍💻
https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/

decomposer - Gradle плагин для декомпиляции Java bytecode от Jetpack Compose Compiler Plugin. В результата получается Java класс. Позволит понять вам что происходит под капотом и погрузиться глубже

#tooling @compose_broadcast