Android *

Я инженер ОВиК, и меня достало каждый день гуглить перевод кгс/см² в бары. Универсальные конвертеры не знают про Гкал/ч и кгс/м², а инженерные калькуляторы — платные или с рекламой. Написал своё Android-приложение на Python/Kivy: 10 категорий, 60 единиц измерения (включая все инженерные), 5 калькуляторов (скорость в трубе, тепловая мощность с гликолями, расширительный бак по СП 60.13330, потери на клапане, площадь изоляции). Работает полностью офлайн, бесплатно, без рекламы. Рассказываю как сделал, с какими граблями столкнулся и как выложил в RuStore.

Меня зовут Вячеслав, и я — «процессуальный хирург».
Сейчас адвокат. Из них 20 лет я провел по ту сторону баррикад — работал следователем, помощником прокурора и прокурором.

Моя работа в суде — не красивые речи, а поиск багов. Я берусь за дела, где система дала сбой: следствие допустило ошибку, суд закрыл глаза. Я провожу аудит материалов, нахожу фатальное нарушение (баг в процедуре) и «ломаю» приговор. Я не работаю ради процесса — я либо вижу техническую возможность отмены, либо честно говорю клиенту: «Тут WontFix».

Год назад я понял, что мне нужен инструмент, который работает так же бескомпромиссно, как я сам. Мне нужен был цифровой ассистент...

Давайте представим типичную ситуацию для разработчика: вы делаете фичу, код проходит ревью, тесты «зеленые». На первый взгляд все хорошо, вы отправляете её в релиз. А потом на проде обнаруживается визуальный баг: текст наехал на текст, цвет оказался не тот, отступ съехал. Бывало такое?

В чем проблема – ведь тесты были пройдены успешно? Дело в том, что юнит-тесты проверяют только логику. Им все равно на то, как выглядит экран.

А screenshot-тесты нужно писать вручную в большом количестве. В классическом подходе мы прописываем каждый тест, но что если у вас 50 экранов по 5 состояний на каждый? Так как же быть, если не хочется писать 250 тестов вручную, а проверку сделать нужно?

Привет я Федотов Михаил, технический лидер по Android разработке в Альфа-банке. Сегодня хочу поговорить про performance (ускорение) unit тестов.

Я работаю на проекте Android приложения Альфа-банка для физических лиц. Для нашего большого проекта это время — больная тема, так как у нас около 800 модулей и большая часть кода полностью покрыта unit тестами (за некоторыми исключениями, например, view классы). Сейчас у нас почти 6000 spec (тест-классов) в которых 37 000 тест-кейсов.

Общее время прогона всех тестов на CI превышало 3 часа. Локально все тесты прогнать вообще было утопией, так как вероятнее всего сборка просто падала от нехватки оперативной памяти.

Сейчас все тесты проекта мы научились прогонять за честные 12 минут и я расскажу что для этого потребовалось.

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

Аккаунт не волк - в лес не убежит
Знал бы  где сломают - подложил емайл
Второго фактора бояться - на Госуслуги не ходить
Век живи, век учись, а МАКС поставишь

(и мое любимое!)
Готовь сани летом, а второй фактор и третий способ сегодня

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

Разбираться во внутренностях AirDrop - это как препарировать фокус иллюзиониста: на сцене всё бесшовно, а за кулисами - вспотевшие инженеры пытаются заставить два разных радиомодуля не конфликтовать за общую антенну. Прочитав этот текст, вы поймете, как Apple фактически создала свой стек протоколов на базе стандартного железа, почему Bluetooth Low Energy - это «швейцар», а Wi-Fi - «грузчик», и как индустрия наконец-то пришла к единому стандарту передачи данных, который не заставляет владельцев Android чувствовать себя лишними на этом празднике жизни.

В прошлой части мы загрузили своё мобильное ядро, вывели "Hello world" в UART и нарисовали квадратик на экране.

В этой части я покажу, как улучшилось ядро за это время: поддержка новых устройств (запуск и отладка в QEMU и Raspberry Pi 5), разбиение на модули, и, наконец, полноценный менеджер памяти. В этом нам очень поможет система типов Rust.

В этом выпуске модульная архитектура и уменьшение зависаний, переходы между общими элементами и продажа рефакторинга, слежка за акулами, жестокая реальность App Store, придуманные ГОСТы ChatGPT и многое другое. Заходите!

Хаотичные события в Android (навигация, тосты, запросы) часто превращаются в источник багов и нечитаемого кода. В этой статье вы узнаете, как использовать sealed-интерфейсы Kotlin для создания полной, типобезопасной модели экрана, где состояния и события управляются отдельно и предсказуемо. Вы научитесь превращать одноразовые побочные эффекты в строго контролируемый поток команд, получите compile-time гарантии, избавитесь от багов с поворотом экрана и сможете легко тестировать любые события UI. Рассмотренный подход не только защищает от ошибок, но и кардинально упрощает масштабирование логики. Вы сможете добавлять новые события без риска сломать существующую функциональность, а ваш UI-слой станет чистым и декларативным. При этом всё, что нужно для внедрения - это понимание базовых принципов Flow и ViewModel.

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

Dagger/Hilt генерирует DI‑классы, Room генерирует DAO и сущности, Moshi генерирует JSON и т.д. Это экономит тонны времени. Но долгие годы для Kotlin‑проектов приходилось использовать KAPT — Kotlin Annotation Processing, прослойку для совместимости с Java‑аннотациями.

KAPT работал, но имел свои минусы. Он генерирует Java‑стабы из Kotlin‑кода и прогоняет стандартный Java Annotation Processor. Эта махинация замедляет компиляцию: сначала компилятор Kotlin должен переварить ваши исходники в промежуточные Java‑классы, потом снова всё это компилировать. Плюс, KAPT порой криво понимал Kotlin фичи, потому что мыслил категориями Java.

И вот появился Kotlin Symbol Processing (KSP). Это библиотека, которая позволяет писать процессоры напрямую для Kotlin. Обещают до 2х ускорения сборки по сравнению с KAPT, полную поддержку всех фич языка и мультиплатформенность.

Троян Mamont продолжает вести свою вредоносную деятельность, направленную на пользователей Android-смартфонов.

В ходе отслеживания активности семейств вредоносных программ для операционных систем Android эксперты отдела исследований киберугроз «Перспективного мониторинга» обнаружили вариацию вредоносного ПО Mamont с названием Фото(92).apk, датированную 2026 годом.

В ходе тщательного анализа этого образца была выявлена новая панель управления C&C — fensteadom[.]com.

Проблему SharedPreferences можно описать несколькими словами: ANR, блокировка перехода между экранами, явное нарушение стрик мода в Android SDK по работе в главном потоке.

В чем проблема с SharedPreferences и решит ли ее Datastore - узнаем в этой статье.

О том, как установить GrapheneOS без браузера через командную строку, используя ПК на Debian или его деривативах.

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

В прошлой статье мы запустили эмулятор и убедились, что Android Automotive OS (AAOS) — это не просто зеркало вашего телефона. Это самостоятельная экосистема. Но пока мы запускали только стандартные медиа-плееры, мы скользили по поверхности.

Настоящая магия начинается там, где софт встречается с «железом».

В телефоне у вас есть стандартный набор датчиков: GPS, акселерометр, гироскоп. В современном автомобиле таких датчиков тысячи: от давления в шинах и температуры масла до угла поворота руля и статуса каждой двери. Как Android-разработчику получить доступ к этому океану данных? Не будем же мы тянуть провода к OBDII разъему?

Конечно, нет. Для этого Google построила мощный мост, по которому мы сегодня и пройдемся. Добро пожаловать в мир Car API и VHAL.

VK Видео — один из крупнейших видеосервисов в России. В декабре 2025 года его ежемесячная аудитория достигла 81,5 млн пользователей. А в первую неделю января 2026 года среднесуточная аудитория VK Видео превысила 42 млн человек (без учёта просмотров на Smart TV и встраиваемых плееров, по данным Mediascope). 

Часть аудитории пользуется сервисом на устройствах Android. Для работы с видео на Android у VK есть единое решение — SDK OneVideo Player. Оно основано на библиотеке Media3 и содержит много улучшений и доработок в части проигрывания видео. Одна из таких оптимизаций — адаптация видео под viewport.

Меня зовут Егор Баженов. Я Android-разработчик в команде видеоплатформы VK. В этой статье я расскажу, как мы внедрили адаптацию под viewport в нашу библиотекуи каких результатов это позволило достичь.

В начале было приложение. И было это приложение для цифровой подписи. Работало оно просто: подписываешь документы на смартфоне, не думая о каких-либо дополнительных токенах. Все упаковано в телефон — и сертификаты, и библиотеки. Процесс знакомый: авторизовался, загрузил файл, подписал.

Но вот однажды пользователи стали жаловаться, что не могут найти ранее подписанные документы. Бывало, пользователь подписал файл, долго к нему не возвращался, а спустя время уже не смог его отыскать. Переустановил приложение или авторизовался с другого устройства, и все файлы как в воду канули. 

Меня зовут Георгий Левченко, я Android-разработчик в ПСБ. Начал я искать источник бед пользовательских. Оказалось, виной всему было то, что все файлы хранились в кэш-директории приложения. Понял я: чтобы файлы не пропадали, им нужен менеджмент для файлов. Отыскался у Android для таких целей готовый инструмент — Storage Access Framework (SAF), он служит для доступа к файлам через стандартный интерфейс без управления разрешениями вручную. Поведаю под катом, как я решал с его помощью эту задачу. 

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

Пользователи Android в этом споре чаще всего начинают оперировать фактами, характеристиками, доказывать, что их POCO X6 Ultra (я только что выдумал этот телефон) лучше последнего iPhone 17 Pro Max, а стоит в два раза дешевле. Но для типичного фаната яблочной продукции это вообще не аргумент, он мыслит другими категориями.

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

Маленькая предыстория - в тот момент большой канадский гигант SIP телефонии решил выпустить первый телефон под Андроидом, но, не просто выпустить под AOSP, а так, что бы все гугловые сервисы были доступны. Это требовало пройти полное тестирование по GTS (Google Test Suite). Проект разрабатывался израильской командой канадского вендора и командой нашей компании, которая имела давние связи с канадцами.

Приём сертификационных заявок, на прохождение GTS заканчивался в начале ноября, а летом, хитрая израильская команда, предложила нашему архитектору, поменяться задачками - баш-на-баш. Архитектор проведя поверхностный анализ, не нашёл подвоха и... согласился,... как потом оказалось - зря, стоило анализ провести получше.

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

Тогда подключили мою "команду спасателей" - меня и моего разработчика (Вовка, ты крут).

Задача на словах звучала просто (как всегда):

Недавно я перешёл в новую команду и столкнулся с классической задачей — рефакторингом сложной продуктовой фичи. Путь от диагностики проблемы до «продажи» решения был тернист... и нереально интересен. Всеми знаниями, что из него вынес, делюсь в этой статье.

Текст будет полезен не только разработчикам продуктовых команд. Участникам core-команд расскажу про общие принципы рефакторинга, а менеджерам помогу понять, чем отличается зрелое предложение о рефакторинге от обычного «хочу всё переписать».