На этой неделе с вами: Ефременков Александр @iamironz. Android GDE в России. Делаю безопасность в Yandex.Taxi, веду androiddev.apptractor.ru.

План на неделю:

1. Кто такой, чем знаменит, прочие оффтопы

2. Системное программирование под Android (introduction)

3. Фрагментация платформы и её проблемы для системной разработки

4. Платформа Android и её внутренности (рантайм, компиляторы, билд система)

5. Нативная разработка под Android (JNI, отладка, языки)

6. Кто такие GDE и с чем их едят

7. Подкастинг, звук и технические нюансы

Такие дела. Ну и конечно каждый пункт выше можно прокликать, туда в саб-треды и буду писать.

И да, про безопасность, OWASP и прочие вещи писать не буду, поговорим про более общие аспекты платформы и то, как с ней работать

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

В связи с чем приходится достаточно часто и глубоко ходить в платформу, как в рантайм, так и в кернел, включая всякие специфичные для Android подсистемы (о них поговорим отдельно в четверг)

До прихода в Android (7 лет назад) занимался писанием бэкендов на Java и всяких наколенных штук на C

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

А что с C - то и сейчас так же пишу на нём, но достаточно редко, чаще беру кресты, но без особых извращений

У каждого понятие извращений, естественно, сдвинуто в одну из сторон. В моём понимании иногда даже классы бывает 100 раз подумаешь писать или нет классы, т.е. ограничиваю себя move-semantics, STL библиотекой ну и поддержкой исключений. И везде есть нюансы, о которых в пятницу.

Что же про pet-проекты: их много, начиная от собственных реализаций stack/register-based виртуализаций, инструментов анализа Android байт-кода, до библиотек хранения данных и набросков игр

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

Ещё я с недавних пор GDE - Google Developer Expert, программа, которая позволяет мне нести свет в массы неокрепших умов, а иногда и в окрепших, о ней мы поговорим субботним днём

Кстати по поводу того, что из моих pet-проектов увидело свет: github.com/yandextaxitech…
это полностью совместимая реализация SharedPreferences.java интерфейса из android.jar, которая написана с нуля и добавляет своих особенностей для кастомизации хранения k/v записей

data loss безусловно, есть, как и во всех библиотеках для хранения чего ни было, но он достаточно низок, проверено в продах

Ещё, если кто не знает, на правах рекламы, я с ребятами веду подкаст про Android разработку: androiddev.apptractor.ru

С недавних пор мы начали экспериментировать как раз с выпусками, которые рассказывают, как погрузиться в Android платформу и правильно заткнуть нос, чтобы не захлебнуться

То есть как устроен рантайм, как происходит компиляция (.class -> .dex, JIT/AOT), инструменты для отладки, безопасность и т.п.

Так же, иногда рассказываю на конференциях что к чему в платформе. В этом году есть шанс, что сгребу все знания головы в кучу о том, что знаю про нативную отладку, санитайзеры и мифы и легенды о NDK разработке под Android в 2019.

Завтра поговорим как живётся в мире разработки системного софта (встраивания в платформу, инструменты безопасности, софт для отладки рантаймов). Там есть много чего рассказать, т.к. существует достаточно сильная энтропия при наличия великолепных самсунгов, хуавеев, мейзу и сони.

И да, я не из Badoo и вакансию писал не я :)

Итак, сегодня мы поговорим за системное программирование и что это вообще такое, зачем оно нужно и какая в этом есть своя, не передаваемая романтика

Как все знают, в программировании есть два основных столпа - это application software и system software

Если с application всё понятно (это те самые программы, которые пишут 90% разработчиков) - кнопки, экраны, жесоны бегают по сети, то с system не совсем очевидно сразу о чём именно речь

Если совсем вкратце, то system слой, это тот самый middleware для отрисовки кнопок, для отправки жесонов и весь менеджмент экранов, которыми вы пользуетесь

То есть стандартная библиотека в Android (android.jar + нативный его слой + libc) таковой и является, если говорить в разрезе сетевого стека, отрисовки графики и предоставления абстракции в виде экрана для компоновок элементов

А есть второй вид middleware, который к самой платформе напрямую не относится и поставляется сбоку - к примеру, средства отладки, мониторинга, защиты, драйвера. Всё это так или иначе реализовывает и эксплуатирует слои более низкие, чем прикладные программы

Если говорить совсем грубо, то в Android примерно следующие слои: android.jar -> runtime -> libc -> kernel

С системными компонентами мы делаем или какие-то свои слои (скажем, свой рантайм) или эксплуатируем текущие (для написания отладки ГЦ в рантайме, мы используем его "api" для получения информации о жизненном цикле сборки мусора)

"api" в скобках, потому что это не совсем api и его приходится порой выкорячивать самыми витиеватвми путями (+ та самая фрагментация устройств)

Или, к примеру, взять свою реализацию android.jar, которая, скажем, портируется до уровня ядра. Написать в целом не сложно, таким образом можно обеспечить переносимый слой между всеми версиями Android (и не только, если рантайм туда тоже вкорячен)

Это очень похоже на то, как мы носим с собой sqlite и не используем платформенный, ну об этом в среду

А теперь тонкости: если говорить про использование "api" Android рантайма, скажем, для того чтобы ловить всякие события, то это постоянная возня с нативными экспортами в libdvm или libart. Они, конечно не документированы и заманглены, что вносит особый шик всему процессу

В стандартной библиотеке тоже есть свои подводные камни в виде hidden нотаций на публичные методы, запреты к приватному api в рантайме, добавленные с 28 api (обходится выставлением нулевого бита приватности)

С libc всё более менее неплохо, т.к. api ядра является действительно api (спасибо Линусу) и не ломает всё кардинально по желанию левой пятки ноги. Исключения составляют только переходы в 64 разрядные системные вызовы, но тут уже так много проблем

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

Ну и конечно у каждого есть своя цена - в стандартной библиотеке мы работаем на 99% с Java, что приятно. В рантайме у нас нет выбора и всё линкуется с применением C++ специфичных STL вещей и структур, а в syscall api надо уметь делать ASM вставки для, разных платформ

Благо, для syscall api есть пример в виде bionic, который показывает как это делать. Для рантайма есть сорцы libdvm/libart и проблем тут только одна: вендоры. Для стандартной библиотеки аналогично рантайму

К слову, в разработке системных софтин есть один психологический нюанс: в большинстве случаев это не видимо для конечного пользователя, что тоже может быть барьером для людей

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

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

Но для меня есть очень весомый плюс: понимание работы системы на достаточном уровне, чтобы решать более высокоуровневые проблемы без нужды штудировать интернеты/стековерфлоу. Становишься более автономным.

Такс, сегодня поговорим как раз о той злосчастной фрагментации

Тут в Android в системщине полнейший цирк с корнями. Все помнят тот самый jrebel, который не выдержал частой смены api платформы + компиляторов + количества кодогенераторов?

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

То есть всегда, при выходе новой версии Android делать дополнительный ресёрч, что то, что ты напилил - не отломалось

Ну и в большинстве случаев, конечно, всё работает (если заранее написал достаточное количество фоллбеков)

Скажем в Android Q полностью избавлилсь от Zygote форков в традиционном его виде, заменив его некоторым "unspecialized app process", который конечно же ломает жизненный цикл создания процесса

Слева - до, справа - после pic.twitter.com/CApRevbdG0

Таким образом те, кто разрабатывал, скажем, инструменты для работы со spawn'ами процессов (отладчики, инструменты типа xposed, magisk) для подмены состояний в загруженном процессе - пострадали, т.к. приходится искать новые схемы, как в форке процесса подсовывать нужные данные

Ещё один пример, скажем со Scoped Storage: там вообще всё переписали на логические разделы, динамически монтируемые в каждый процесс, что усложнило жизнь всё тем же ребятам из прошлого поста т.к. в каждому процессу генерится своя песочница

Ну и традиционно о слоях: к примеру в android.jar в последнее время всё плохо с обратной совместимостью из-за всеми известного gray-list и попыток сделать security manager (уже давно опционален в Java) для доступа куда не надо

Так же в стандартной библиотеке есть небольшая проблема вендор-специфичного творчества, которое легко фиксится написанием достаточного количества разных стратегий через if(isXiaomi)

В рантаймах всё неоднозначно: если в libdvm (dalvik vm) во всех версиях Android до 4.4, нативные экспорты были достаточно неизменными, то с libart (ART runtime) каждую новую версию часть api просто отрывают

Плюс вендоры, как со стандартной библиотекой, хотят сделать всё уникально, приходится линковаться через ветки фоллбеков

Ну а с libc всё достаточно хорошо: её не переписывают почём зря (есть теория, что там никто ничего не понимает, т.к. там всё покрыто 3этажными макросами и вложенными в друг друга switch блоками по паре тысяч строк с 80х, я не шучу) и api ядра тоже не очень-то и меняется

Правда, кто в libc андроида смотрел - тот в цирке не смеётся. Исторически, в андроид заехал openbsd libc со смесью netbsd (последний очень ядрёный). Ну и с 80 годов там мало что поменялось, разве что всякие хаки сбоку для сборки именно в Android, чтобы можно было собирать апстрим

А gnu libc не хотели брать из-за тогда ещё больших его размеров - 2mb против 10. Ничего не напоминает? Conversion to Dalvik format failed: Unable to execute dex: method ID not in [0, 0xffff]: 65536

Ещё gnu libc, как оказалось, просто был чуть-чуть менее производителен. Ну ок, сэкономили, какой ценой - ценой дичайшего количества месива в коде на стыках из-за того, что разрабам Android libc хтчется собирать из апстрима open/netbsd с полпинка, просто делая fetch

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

ART рантайм к слову написан менее убого, туда вроде бы наняли адекватных крестовиков, при просмотре кода которых рука сама не хочет заткнуть нос. Dalvik же это какой-то тихий ужас, писали его примерно таких же взглядов люди, что и bsd libc

Кстати, привед иос-богам, думаете у вас там в платформе всё внутри ок? Могу огорчить, предлагаю сходить и глянуть былое наследние, гуглеры заботливо выложили большую часть кода апстримов, которая на 332% уехала и к вам

А вот отдать честь отцам надо: strncmp, wsprintf и прочие "классно-назваемые" api тянутся десятилетиями

Ну и в ядре, как я уже говорил, всё ок, syscall api достаточно мало меняется, но после внедрения широких архитектур (64) надо фоллбечиться

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

Так вот, фрагментация. Xiaomi, Samsung, Sony, Meizu... У них почти у всех, конечно же, пройден CTS, но! Когда ты системщик, тебе эти кайфы не понять, т.к. у тебя всё замкнуто на приватные api, без каких либо гарантий на совместимость.

Давайте придумаем сами себе задачу: померим, сколько проходит по бранче JIT code cache, и вывести в лог.

Так вот, libdvm всё тривиально: вешаемся на события JIT с нужным id компиляции через dlsym на соответствующую callback функцию и готово

На libart всё неоднозначно, т.к. JIT mode опционален и может не быть вообще в рантайме, смотря как скомпилял вендор. А так же мог это api зам заиспольовать. И тут dlsym уже покрывается различными хаками. В зависимости от вендора мы ищем экспорты, релевантные, скажем через frida.

И чтобы таких проблем избежать, в системном софте стараются как можно меньше притягивать со стороны и реализовывать/бандлить всё в себя

Скажем, если бы в Android был портируемый рантайм (понятно, что мы жертвуем размерами), то было бы больше поле для полётов (понятно, что появились бы другие проблемы), а всякие внешние сервисы (типа пушей, метрик) реализовывались как модуль ядра.

И такой портируемый рантайм уже существует. Иосники, заткните уши и нос, называется он "Multi-OS Engine" от RnD из Intel.

Он позволяет сделать AOT бинарь, который бандилт помимо скомпилированного apk ещё и весь ART рантайм. Штука не новая, с года 13-14, опциональна в libgdx (кто знает про геймдев) и достаточно стабильна. Вторая, после robovm (который к слову до сих пор саппортит коммьюнити)

Так вот, подобные тулы просто прорастают напрямую в libc/libstdc++ и дальше уже крутят свои абстракции.

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

А сегодня обсудим, что там вообще внутри у Android рантаймов (JIT, AOT, PGO и прочие кейворды)

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

Как всё наверное знают, до 5.0 в рантайме был только JIT/interpreter mode. С 5.0 добавили AOT, но и отключили некоторое количество JIT оптимизаций, впоследствии вернув всё обратно в 23 (M)

Хотя во многих источниках пишут, что JIT mode вернули в 24 (N), исходный код говорит об обратном pic.twitter.com/XiYRwW20Kv

Но теперь JIT mode стал опциональным и как я рассказывал вчера, вендоры его могут просто напросто исключить из фазы компиляции pic.twitter.com/sf8eiLrP9n

А схема работы с M (23) такая:

С отправкой профилей всё весело: из-за той самой фрагментации, профиль под конкретные cpu arch строится тоже вендоро-специфичный и конечно же анализируется в облаке, дабы не поломать багами какого-либо MTK все Snapdragon на той же cpu arch

Для тех, кто не слышал: Cloud Profile позволяет собирать профиль локально и отправлять его на Google Play для последующей рассылке при первой установке

Так, на девайсах большого количества юзеров крутятся разные сценарии, создаётся более широкий профиль, который впоследствии докачиваются при установке, позволяя исполнять горячий код сразу после установки. Краудфандинг "тормозящей джавы" наяву!

Давайте обсудим то, как ART рантайм продюсит код

dex2oat - та самая утилита, которая строит пути исполнения и предоставляет оптимизированный код. Никакого .odex файла на выходе он не делает, этот формат релевантен только для преинсталенного в систему софта. На выходе есть 3 файла: .odex, .vdex, .art

.odex содержит всё исполняемое, что dex2oat смог скомпилять, т.е. это тот самый дополняемый JIT профилем код, который впоследствии исполняется, если текущая ветка была заранее скомпиирована

.vdex содержит весь набор .dex файлов (просто мерджит их в один) + выносит лайаут классов, констант и первично загружающихся класслоадером классов в начало, предварительно верифицировав весь набор данных и кода для запуска

.art делает примерно тоже самое для оптимизации запуска, но вынося всю метадату в отдельный файл (появился позже, разработчики впоследствии разделили bootstrap метадату и оставили в .vdex только верифицированный код)

Так же, есть 4 режима запуска dex2oat: verify, quicken, speed, speed-profile

verify - используется для, как уже понятно из названия, для верификации кода. Использует при OTA апдейтах, скажем, при апдейте приложения посредством системного package manager

quicken - запускает в себе verify и оптимизирует короткие инструкции в более длинные (например делает длинными из просто const_string в const-string/jumbo). Этот режим используется для всех не предустановленных приложений.

speed - запускает verify и делает полный AOT прогон всех методов кода. Используется для предустановленных приложений, не использует PGO для исполнения кода.

speed-profile - ну и как уже понятно из названия, делает тоже самое что и speed, но с профилем. Тот самый режим, когда вы ставите устройство на зарядку или же ваш телефон хорошо заряжен. Он гоняет профиль, пока не зайдёт во все бранчи и не прогреет их, опираясь на прошлый профиль

Примерно так работают стадии рантайма. Если что-то кому-то хотелось уточнить - буду рад обсудить. А вечером обсудим компиляции уже исходного кода.

Прежде чем рассказать за компиляцию, ещё хотел дополнить, что Android позволяет запускать чисто JVM байт-код. Запускается через app_process ( android.googlesource.com/platform/frame…), в системные библиотеки встроен целый libopenjdk, что забавно. Просто интересный факт.

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

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

Чтобы сделать свой java-класс (нужно, к примеру, для .aar библиотек, т.к. все внутренности там в .jar) - можно воспользоваться инструментами типа objectweb.asm или javassist (первый поприятнее)

Для Android всё уже похуже. Есть dexlib из smali/baksmali библиотеки. Но он слегка убог в плане api, на мой взгляд. dexmaker не умеет в генерацию методов без прототипа кода (т.е с abstract, interface, native модификаторами)

Но есть отличный dex2jar reader/writer, который построен на таком же visitor api, как и objectweb.asm, что очень удобно для построения унифицированных кодогенераторов как в .aar библиотеках, так и в .apk проектах.

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

Если кратко - то, нужно для создания средств отладки, мониторинга, защиты, драйверов

Чем скажете это лучше того же APT - тем, что нету зависимости на язык, вообще. Только на тип байт-кода. Т.е. не придётся мучаться с kapt и прочими вещами. Второе - не ломается инкрементальность, т.к. source граф перекомпилировать не приходится.

В dex2jar к слову хорошее покрытие тестами и можно посмотреть, как генерить код.

Но для этого нужен специальный скилл, конечно. Сорцкод компилять из APT попроще будет. Для вникания, предлагаю зачитать через smali нужный вам прототип и накидать из него кусок на dex2jar-writer, и его же так же прогнать через smali, убедившись в идентичности.

Ну и так же с java-байткодами, только через procyon-decompiler в режиме с нотациями и генерить через objectweb.asm

На сегодня всё. Завтра говорим про нативную разработку в Android в целом, их языки и подводные грабли.

А сейчас обсудим то, как живётся в нативной разработке в 2019. И живётся ли вообще.

Сперва поговорим о том, как всё с тулингом. Тулинг уже хромает не так сильно, как скажем, пару лет назад. К примеру инспекции уже иногда прокликиваются, но если часть кода за пределами директории проекта, подключена через cmake src-dir, то начинается свистопляска

Жёлтые плашки, что код мол не принадлежит проекту, давай-ка синканём всё (и так бесконечно). Если наворачивать макросы на этапе компиляции, кто увидит он их только после первой компиляции соответственно

Поэтому я предпочитаю всё таки пользоваться vim, для текстового редактора, который забирает ~4gb и слегка отказывается работать - это многовато

Про нативный api Android - это вам конечно не развесистый android.jar с набором утилит на все случаи жизни (да-да, после нативного кода без использования буста это правда глоток воздуха)

Референс для Android специфичного api достаточно скудный. Для понимания: есть sensor api, но до сих пор нету gps api (а тут ещё в новом Scoped Storage Android Q хотят заставить файловый дескриптор через Java слой пробрасывать, т.к. ndk api тоже не осилили)

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

С boost тоже всё достаточно неплохо, жить можно, вкомпилять в 2019 с текущим тулчейном проблем особых нету

Стандарт тоже можно поднять вплоть до C++ 17

С последними версиями билд тулов поддерживается даже cmake 3.10.2, не совсем свежий, но и не предыдущий мамонт 3.6.0. В 3.10.2 есть в общем-то почти вся экзотика, которую можно представить, если вы извращаетесь с билдом.

Но сразу скажу - cmake крайне упоротая билд система с точки зрения dsl. Разработана была в мед промышленности, не знаю как помягче, но медики не очень умеют в человечность в коде. Если хотите начать писать всерьёз - советую почитать референс с самого начала, от корки до корки

gradle к слову поддерживает нативный билд, всё никак не дойдут руки попробовать скрестить это с android плагином, т.к. пару сотен строк кода на cmake dsl эквивалентны по понятности сотне строк на bash

Так вот, про языки. Kotlin/Native под Android пока очень слабо, т.к. нету поддержки LLVM бэкенда для x86 и из-за этого соответственно пускать по эмуляторам и Intel нельзя

С языками типа Rust в общем-то всё ок, компиляется всё через LLVM, но есть нюанс: нужно городить все стадии компиляции самому (rustc, кормить ndk тулчейн, подкладывать бинарники в нужные директории).

Для Rust надо написать unsafe nomangle функции и в общем-то они будут работать ок, осталось только понять парадигму языка

Ну и кажется чисто крестовикам или vim или clion. Студия пока очень слаба.

Для Go всё примерно тоже самое, подкидывем тулчейн для компиляции и наворачиваем скрипты для копирования скомпиленых библиотек

А вообще, рекомендую именно C++ т.к. дял него по-умолчанию есть все инструменты отладки, такие как gdb, нативный трассировщик в студии и в целом понимание нативной разработки, я считаю, следует прочувствовать через кресты

Ну и на последок: изучите то, как работает move семантика, шаблоны, STL и весь фундамент в C++, он очень поможет в будущем для поиска проблем

Кстати, rust уже добавлен для сборки в тулах android.googlesource.com/toolchain/rust…

Такс, а сегодня про GDE: что это такое, зачем им не/становиться, какая польза и что для этого надо.

GDE - Google Developer Expert, программа Google, подтверждающая экспертные знания в одной или нескольких технологий от Google. Соответственно, накладывающая обязанности иметь определённый багаж знаний, который необходимо постоянно актуализировать, для донесения его в массы

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

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

Часто слышу:
-"О, круто, тоже хочу стать, ездить на Google IO и чтобы на странице экспертов светиться"

Но всё не совсем так: конечно, GDE тебе даёт бенефиты, но и чтобы их получить - надо постоянно поддерживать коммьюнити всякими апдейтами

Я сам не долго в этой тусовке, смотрю со стороны как это работает уже продолжительное время и могу сказать, что это дольше про "давать" чем "брать"

Штука в том, что поездку на Google IO ещё надо заслужить и промоутить достаточно, чтобы быть в приоритете (логично, какой он GDE, если сидит и потчевает на лаврах)

Как становятся: прежде чем им стать, надо убедиться что текущий, постоянный импакт происходит с постоянной периодичностью

После чего надо связаться с ближайшим по рукопожатию GDE от тебя или, если повезло, DevRel'ом и задать ему соответствующий наводящий вопрос

Ежели вы подходите, то вам обязательно перезвонят и обсудят то, "какие ваши доказательства" путём проведения секций на английском языке

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

В таким случае вам выдадут трусы и крестик, пригласят во всякие приватные чаты и вам надо действовать с удалённой силой, как вы действовали до

Вся активность трекается вами, занося в специальную тулу все подробности об активностях (слава богу гитхабы и стековерфлоу трекаются автоматом)

Ежегодные конференции DevFest становятся для вас домом родным, рекомендую начинать знакомиться с GDG (Google Developer Group) городов, которые покрываются этой конфой

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

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

Что на счёт бенефитов: постоянная, прямая связь с командами Google, влияние на процессы разработки, что очень неплохо, когда релизят закрытые альфы и на них можно влиять

Так же общение с другими GDE позволяет масштабировать связи горизонтально, эксперты из разных стран имеют разный опыт

Плюс, как уже говорилось, неплохой бенефит - поездки на Google IO, GDE/Android Summit в роли участника

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

Такс, сегодня мой последний день тут и очередная оффтопная тема про подкасты

В общем, возможно кто-то знает, или нет, но у нас есть подксат androiddev.apptractor.ru, в котором мы обсуждаем все аспекты Android разработки в совершенно разнообразных областях, призывая в выпуски топовых ребят из России и ближайшего зарубежья

Так вот для этого нам надо какая-то площадка для вещания, чтобы всё это броадкастить в народ по интернету, да и ещё в режиме реального времени

Из-за того, что команда дико распределённая и спикеры приходят к нам как из России, так и из Британии, Сингапура, США - возникает необходимость в low latency VoIP телефонии

Такое решение у нас есть, и называется оно mumble. Оно полностью Open Source, так же self-hosted, что позволяет поставить на такую машинку, чтобы распределение трафика и задержки были минимальными

Сам бекенд стоит как раз на US West машинке, для равномерного latency, т.к. в ту точку трафик ходит примерно одинаково

Вначале мы ходили в скайп, но потом эта затея привела к мысли, что качества звука очень посредственное, а наколенная модификация кодека Opus - SILK не то чтобы отдаёт качественный звук при высоком распределении команды

В mumble клиенте, конечно, интерфейс не для людей, но он очень гибок в настройке размера пакетов, битрейта, буферов и в целом позволяет хорошо затюниться, когда много специфики

Далее как вещаем: для этого у меня есть сложная схема виртуальных in/out девайсов (soundflower драйвер), которые я комбинирую вместе посредством утилиты Hijack Audio (очень гибкая тула для ввода\вывода всего)

Hijack Audio - это просто чудо какое-то, когда надо смикшировать, пробросить и записать какой-то эфир, чтобы попутно не сойти с ума.

То то есть сама запись происходит локально на моей хост-машине. Какие входы: mumble (голоса участников), аудио-подложка, микрофон (мой голос), выходы: запись в файл, бродкаст в виртуальный аудио-драйвер

Бродкаст тула - butt (broadcast using this tool), она захватывает виртуальный аудио-драйвер и кастит вывод в icecast ноду. Icecast - тоже опенсорснутая тула для бродкаста всего и вся.

Плюс на icecast ноде так же есть грязный бэкап, который пишется на случай, если всё пропадает. Такое уже было пару раз (слава богу что не с эфиром, а с просто записью), так что лучше бэкап чем "простите, выпуска не будет"

Ну и icecast нас висит на том же региноне, планирую перекатить кюда-то в Россиию.

В итоге задержка всего трафика от реальнго времени примерно 5 секунд, что позволяет собирать в чатике вопросы в режиме реального времени и отвечать на них

Кстати, ссылка на чат, если кто не знал: t.me/androiddevpodc…

Это всё о меня. Спасибо, за то что читали и задавали вопросы! Надеюсь, было интересно. Если вам интересно о том, что я пишу - прошу пожаловать ко мне в твиттер @iamironz всем пока!

И с вами снова @igrekde для небольшой рекламной паузы перед следующим гостем.

Badoo ищет Android-разработчика! Нужны Java (Kotlin как плюс), знание паттернов проектирования и английский, очень пригодится инициатива и вовлеченность. Работа в Москве, командировки в Лондон. 🇷🇺�bit.ly/AndroidDevBadoogLNN

И еще не стесняйтесь подписываться на твиттер @produnderhood – там тоже интересно и полезно для разработчика.