Android Runtime Resource Overlay -- крутая, но совсем не распиаренная тема. Технология позволяет приложению модифицировать собственные ресурсы и ресурсы других приложений прямо в рантайме, на лету. В основном RRO пользуются разработчики мобильных ОС для создания системных оверлеев для системных приложений. Однако и обычные приложения могут воспользоваться преимуществами оврлеев ресурсов, и для этого не требуются какие-либо специальные разрешения от пользователя.

Почему тема не очень популярна среди обычных приложений? Тут есть несколько мыслей, которые образуют ответ. Во-первых, self-targeting оверлеи, которые могут создать и применять обычные, не системные приложения появились относительно недавно, с Android API 34. Второй момент -- отсутствует документация, так что данное API можно вполне назвать незадокументированным. Разработчики привыкли полагаться на проверенные официальные источники и гайдлайны, а здесь буквально нужно читать код ОС, чтобы понять что к чему.

Я, как исследователь операционной системы Андроид, практически все время провожу за изучением кода ОС и проверке гипотез, которые могли бы повлиять на безопасность системы. И когда я обнаружила такой функционал, очень удивилась, что он вообще никак не задокументирован. Мне кажется, это может быть связано с тем, что тема достаточно новая, и есть еще ряд сырых моментов в ее имплементации. Уверена, Google со временем сможет опубликовать данный API и сделать его полноценным.

Что расскажу в своем докладе:

1. Android Runtime Resource Overlay: обсудим сперва в общих чертах, что это, как это работает и зачем оно нужно, где применяется.

2. Разберем виды оверлеев ресурсов. Бывают системные оверлеи и self-targeting оверлеи. Также бывают приложения-оверлеи, когда источником ресурсов выступает отдельный APK (статический оверлей), а также бывают fabricated overlays (фабрикованные оверлеи), которые создаются на лету, их можно создавать прям в рантайме (динамический оверлей ресурсов).

3. Обсудим, как вообще оверлеи накладываются на текущую таблицу ресурсов приложения -- что происходит под капотом. Что делает ОС, чтобы значения ресурсов бесшовно подменялись, какие компоненты системы за это отвечают.

4. Рассмотрим, какой функционал предлагает self-targeting overlay -- как раз тот самый кейс, когда обычное приложение может настроить, какие значения каких ресурсов будут заменены и на какие. Обсудим, какие преимущества и ограничения есть у такого подхода. Посмотрим, как такой подход может быть полезен при шифровании ресурсов приложения. Прям на примере разберем. Пример, кстати, возможно опубликую на гитхаб, поскольку в сети нет никакой внятной документации, объясняющей, как это сделать.

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

6. Бонус-chapter. Разберу технические детали найденных мною уязвимостей в Android Auto. Но пока жду решения Google по багам.

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

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

Что вас ждет:
1. Kotlin Compiler: За кулисами
- Краткий разбор архитектуры компилятора: от AST до генерации байткода.
- Как плагины вмешиваются в этапы компиляции и меняют код.
2. Создаем свой Kotlin Compiler Plugin
- Как написать свой плагин.
- Разберем основные методы и базу необходимую для создания плагина.
3. Пишем свой Kotlin Compiler Plugin самостоятельно
🛠 Напишем свой плагин KCP
💻 Готовый код на GitHub: Участники заберут шаблоны для своих проектов.

Максимум действия и минимум теории!

Деловая игра на понимание бизнес-команды при переговорах о разработке.

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

Мы сосредоточимся на следующем:
1. Понять кто участвует в переговорах, чего хочет, как с ним/с ней разговаривать.
2. Что важно для меня и что важно для членов бизнес-команды в разработке и переговорах.
3. Как работать со "странными" требованиями и как аргументировать мою позицию как эксперта каждому члену команды со стороны бизнеса.
4. Как быстро и адекватно реагировать на предлагаемые изменения

Что такое CI/CD и как он работает? Какие отечественные инструменты вам помогут? Пайплайны, артефакты, релизы - пишем код, чтобы не делать работу руками. Релизим в RuStore нажатием кнопки!

ОС Аврора – полностью российская мобильная операционная система с упором на защищенность от внешних угроз. Хоть она и позиционируется как ОС для корпоративного и госсектора, она имеет хороший потенциал для использования в качестве основного мобильного устройства. В ней есть всё необходимое для повседневного использования, но пока что очень мало приложений. И для мобильных разработчиков с других платформ это уникальная возможность занять пустующие ниши своими приложениями!

На данный момент основной стек разработки под Аврору – это Qt/QML 5.6 и C++. И хотя помимо базового стека доступна также разработка на фреймворке Flutter, мой воркшоп будет посвящен разработке приложения на Qt/QML.

На мастер-классе я расскажу основные моменты по установке и настройке SDK, а затем мы перейдём к самой интересной части – написанию мобильного приложения. В формате воркшопа я покажу, как:
– создать новый проект и какие есть системы сборки под Аврору;
– организовать минимальную архитектуру будущего приложения;
– сверстать несколько простых экранов для отображения данных;
– загрузить данные с удалённого сервера, обработать и показать их пользователю;
– локально сохранять и загружать пользовательские данные;
– собрать, подписать, установить и запустить приложение на устройстве или в эмуляторе.

Долгие годы во всех проектах Туту мы использовали Cocoapods как основной менеджер зависимостей. Однако наша цель как Core-команды — давать инженерам из продуктовых команд возможность беспрепятственно развивать и улучшать наши продукты, и с Cocoapods это стало проблемой. Становится больше фреймворков, дистрибуция которых осуществляется только через SPM, с некоторыми мы столкнулись лично. Сам проект Cocoapods вошел в режим поддержки, этап активного развития завершен. Тем временем Apple активно развивает SPM, на него-то мы и решили переехать.

Нам удалось перевезти все наши вспомогательные фреймворки и 4 публикуемых в стор приложения за 3 месяца и убрать все блокеры, которые были у нас на Cocoapods. А бонусом мы получили снижение размера наших приложений на 30-50%, ускорение запуска приложений на 40%. Кроме того переезд прошел практически бесшовно для всех iOS-разработчиков компании.

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

1. Как всё начиналось:
Погрузимся в историю процессов мобильного тестирования в нашей компании. Какие подходы мы использовали раньше и с какими вызовами столкнулись.

2. Почему пришло время меняться:
Что заставило нас пересмотреть существующие процессы? Реальные кейсы, которые показали, что старые методы больше не работают.

3. Исследование рынка: что предлагает мир тестирования?
Обзор инструментов и решений, доступных на рынке. Какие из них мы рассматривали и почему многие не подошли под наши задачи.

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

5. Ошибки, которые нас научили:
Как мы "наломали копий" в процессе поиска идеального решения. Практические уроки, которые могут быть полезны каждому.

6. Финал: как мы начали экономить без потери качества:
К чему мы пришли в итоге? Как нам удалось оптимизировать процессы тестирования, сократить затраты и при этом повысить эффективность.

LLM обладают огромным потенциалом, но текущий подход к их использованию сталкивается с существенными вызовами: высокая стоимость вычислений, уязвимости при передаче бизнес-данных сторонним компаниям и т. д.
Современные устройства Apple с интеграцией технологий Apple Neural Engine (ANE), Metal Performance Shaders и Core ML, способны эффективно запускать LLM локально, решая проблемы, приватности и безопасности данных, закладывая фундамент для будущих возможностей локальных ИИ агентов. Это может привести к снижению серверных расходов и разработке бизнес-приложений нового типа, например, обработка изображений, распознавание данных и многое другое.

Внедрение ИИ-решений в приложения становится трендом. Многие компании разработали и представили собственные LLM в виде AI-ассистентов и помощников, как в веб, так и встраиваемом в IDE решениях.
Рассмотрим практические примеры использования различных готовых сетей при разработке KMP-приложения. Обсудим, какие подводные камни могут встретиться в работе и как применять такие инструменты корректно и безопасно. Также посмотрим, как подготовить свое решение на основе открытой LLM.

В процессе разработки новых функций и модификации существующих мы часто сталкиваемся с ограничениями текущих API, что подталкивает нас к необходимости создания более гибких и универсальных решений.
В своем докладе я продемонстрирую этот процесс на примере супераппа Yandex Go, где мы пришли к использованию BDUI, а также расскажу о нашем опыте в стартап-сервисе Межгород.
Сделаю анализ трейдоффов между нативными решениями, ad hoc BDUI подходами и сложными системными решениями, такими как DivKit.

В докладе я расскажу:
• Как разработчик может менять процессы и почему софт-скиллы важны не меньше технических навыков.
• Как через маленькие изменения можно прийти к большим улучшениям: кейс про стандартизацию UIKit и выстраивание взаимодействия в команде.
• Как мы превратили фрустрацию в драйв: что делать, если никто не хочет менять процессы, а работать в хаосе уже невозможно?
• Ошибки на пути изменений: сопротивление команды, сложности в коммуникации и как их преодолевать.
• Как правильно презентовать идеи и внедрять их в команду так, чтобы это не вызывало отторжения.
• Почему навыки убеждения и адаптации важны даже в технических ролях и как их развивать.