Android *

LLM пока не может хорошо обращаться с Е2Е автотестами потому что для этого нужно провести целый комплекс мероприятий. Сложность возникает уже на этапе запуска такого автотеста. В отличии от юнит автотестов, Е2Е автотесты почти всегда PageObject и целый проект со своей архитектурой на базе Selenium Appium Espresso и тд.

Когда мы разрабатываем настольную операционную систему, очень легко попасть в архитектурную ловушку: начать строить систему вокруг одного типа приложений. Исторически так и происходило: Windows запускала Windows‑приложения, macOS запускала macOS‑приложения и Linux — Linux‑приложения. Но пользователь живет не в этом мире. Ему неважно, на каком языке написана программа, под какую платформу она создавалась и какая у нее экосистема. Он хочет, чтобы нужные приложения запускались у него быстро и максимально удобно.

Привет, Хабр! Меня зовут Илья Клементьев, я старший инженер-программист в отделe разработки сервисов настольной ОС в YADRO. Современные ОС постепенно двигаются в сторону универсальных хостов — то есть систем, которые способны запускать приложения из разных программных экосистем. В статье я расскажу, как можно запускать Android- и Windows-приложения внутри Linux, какие технологии для этого используются и как устроена многоуровневая архитектура системы с виртуальной машиной и контейнерами.

Эта статья — про то, что реально изменилось, и в каком порядке я бы рекомендовал это
трогать. Основано на диффе между (3.3.0) и (8.6.2).

Это статья от автора библиотеки, поэтому нейтральным разбор не будет. Но это и не рассказ про
конкретный проект — а разбор задач, на которых, на мой взгляд, Paging 3 начинает буксовать, и
того, как Paginator устроен, чтобы эти задачи
закрывать. KMP-библиотека пагинации для Android, iOS, JVM и Desktop. Ниже — почему она появилась
именно как отдельная библиотека, а не как fork или обёртка над Paging 3.

Меня зовут Максим, я Android-разработчик в команде дизайн-системы «БКС Мир инвестиций». В 2025 году у нас шёл большой редизайн: компонентная библиотека росла, команды подключали новые Compose компоненты, а вместе с этим быстро рос и объём UI-тестов.

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

Эта статья про то, как мы решили задачу через Kotlin IR Compiler Plugin. Снаружи решение выглядит почти незаметно: разработчик ставит одну аннотацию, а на этапе компиляции компонент автоматически получает стабильный testTag и тестовые semantics, собранные из его state. В результате у команды стало меньше бойлерплейта в компонентах, меньше риска рассинхронизации между state и тестами, а экранные UI-тесты получили более устойчивый контракт работы с дизайн-системой.

Я разрабатываю PWA для голосовой практики английского. Несколько раз пытался опубликовать его в RuStore через Trusted Web Activity (TWA) — Google-обёртку, которая упаковывает PWA в подписанный Android AAB. После четырёх отказов модерации я понял, что для моего класса приложений TWA в RuStore не работает, и за день переключился на Telegram Mini App.

Эта статья — не история стартапа, а разбор технических решений:

Привет, Хабр!

Ну вот вы ставите Яндекс Go, жмёте «Разрешить» на всё подряд — микрофон, контакты, местоположение. Такси же, надо. А потом выясняется, что приложение лезет в буфер обмена. 16 раз в разных местах кода. Зачем такси буфер обмена — я так и не понял.

Короче, я взял семь популярных Android-приложений и разобрал их по косточкам. SAST, реверс-инжиниринг, декомпиляция DEX, разбор манифестов, ковыряние в нативных библиотеках. Под раздачу попали: Яндекс Go, Карты, Музыка, Пэй, Телемост, Mir Pay и мессенджер МАКС (бывший ICQ New / VK Messenger).

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

<cut/>

Привет, Хабр! На связи команда UserGate uFactor и я, Иван Князев!

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

Друзья, я снова с подборкой программ! Поскольку работаю с графикой и перепробовал много редакторов, то хочу подсказать, чем заменить Photoshop. Нашел варианты и для обработки фотографий, и для серьезного дизайна. Каждый по праву можно назвать лучшим бесплатным аналогом Фотошопа на русском языке.

Рано или поздно каждый Android‑разработчик сталкивается с задачей «одно приложение — много сборок»: white‑label‑решения, региональные версии, отдельные сборки для разных магазинов приложений, демо для клиентов, внутренние окружения.

Встроенный механизм product flavors в Android Gradle Plugin отлично справляется со своей задачей — пока количество вариантов умещается в голове и в паре экранов build.gradle.kts.

В этой статье я разберу подход, при котором конфигурация flavors строится динамически: список вариантов и их параметры живут вне build.gradle.kts.

В новом дайджесте уход Тима Кука и ненависть к Gboard, диск выбора месяца в стиле Airbnb и анимация зачеркивания текста в SwiftUI, основы разработки приложений для iOS, приватность в обычной клавиатуре, Kotlin-агент широкого профиля KMP, атаки мобильных приложений глазами хакера, рост релизов в App Store и Google Play и многое другое. Заходите!

Написал полностью офлайновый голосовой ввод на русском для Android. Никаких серверов, подписок и привязок к аккаунтам. За распознавание отвечает открытая нейросеть GigaAM v3 от Сбера: модель зашита прямо в APK, работает без интернета и отлично расставляет знаки препинания.

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

Стек: GigaAM v3 + sherpa-onnx (NNAPI / CPU) + крошечный детектор речи Silero VAD. Требования: Android 13+, ARM64. Исходники открыты (MIT).

Говорят, для программирования на Си нужен стол, стул, мощный ПК и Linux. У меня другой стек: диван, планшет на Андроиде и Termux. Но иногда мой монитор помещается в карман — это смартфон.

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

Противостояние против индустрии

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

Привет. Полгода назад я выложил singbox-launcher — десктопный GUI для управления ядром sing-box. По фидбеку стало понятно: идея зашла, людям удобно собирать и отлаживать конфиги на ноутбуке, а потом переносить их на роутеры и другие сетевые устройства. Подробнее о десктопной версии я писал на Хабре.

Пару слов для тех, кто не в контексте. Есть небольшой класс кроссплатформенных сетевых ядер, которые умеют гибкую маршрутизацию трафика и поддерживают современный набор протоколов: WireGuard, VLESS, SOCKS5, Shadowsocks, Hysteria2, TUIC и так далее. Sing-box в этом списке — не самый раскрученный, но для меня он оказался наиболее интересным: быстрая эволюция, внимание к деталям, чистый код, живое общение мейнтейнеров с пользователями, классно организованный по логике конфиг.

Довольно быстро стали приходить запросы на Android-порт. Первое время казалось, что это будет прямое переиспользование десктопного кода. На практике сценарии потребления на мобильных оказались сильно другими: другой UX, другой lifecycle, Doze и background-лимиты, OEM-специфика, ограниченный экран, другие ожидания от автозапуска и обновлений. В итоге пришлось переписать практически всё с нуля.

Результат этой работы — LxBox, и сегодня я хочу рассказать, чем он отличается от существующих Android-клиентов и как устроен изнутри.

В прошлой статье я сравнивал Paginator с Paging 3 на кошачьем уровне: «вот простой фид, смотрите — три строки вместо тридцати». Это полезно для первого знакомства, но не отвечает на главный вопрос: а как оно себя поведёт, когда продукт начнёт требовать то, ради чего люди обычно и пишут свой велосипед поверх Paging 3?

В этой статье я беру мессенджер — потому что мессенджер это честный полигон. Там есть:

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

Дисклеймер: этот пост — про вайб-кодинг, поэтому в нём не будет приведено ни единой строки кода. Я просто показываю идею, не детали реализации. И немного мнения о вайбкодинге в целом — в конце публикации.

Да, в далёком 2018г. я целых 24 часа работал на какой то фабрике в Подмосковье. Делающей салаты и другие полуфабрикаты. В каком то отделе, то ли контроля, то ли безопасности. В общем надо было смотреть в камеры видео наблюдения. Ну и вроде всё, сутки через трое. Хотел уйти с 5/2 на 1/3. Но я не согласился, слишком тяжело, слишком. Через 6 лет после тех суток я начну изучать Java и пробовать писать приложения на андроид. Третьим моим пет приложением будет Ch4IR.

Написанный на библиотеке LibVLC и в память о несложивщейся карьере в сесурити.

Он был настоящим RTSP рекордером: отображал 4 потока, писал 4 потока на флешку или usb диск, нарезал куски видео по 60 минут и автоматически удалял записи старше указанной даты. Он умел воспроизводить записи и перематывать их. Но всё изменилось, перед самой публикацией.

Когда я начал делать кредитный трекер, казалось, что финансовая математика — самая простая часть проекта. Формула аннуитета есть в любом учебнике, Excel справляется за пять минут.

Я ошибался.

Небольшой контекст: до этого я довольно долго не делал ничего для Android — работал в других областях, экосистема успела заметно измениться. Вернуться оказалось неожиданно приятно: Compose после нескольких лет XML-вёрстки ощущается как глоток свежего воздуха, KSP вместо KAPT работает заметно быстрее, а Room с Flow и корутинами — это уже совсем другой уровень удобства по сравнению с тем, что я помнил. Так что статья отчасти и про это: как выглядит возвращение в Android-разработку после перерыва.

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

Если коротко: пагинация — это когда вы не грузите 100 000 товаров из каталога одним запросом, а показываете их страницами по 20–50 штук и подгружаете следующую порцию, когда пользователь домотал до конца.

Звучит как задача на полдня. На практике — по-разному.

Я пишу мобильные приложения уже давно, и каждый раз, когда в новом проекте появлялась пагинация, рядом с ней через месяц-другой появлялся один и тот же набор багов и ad-hoc-решений. Флаги isLoadingNextPage, isLoadingPrevious, isRefreshing, isEmpty, hasError, hasNextPage. Попытки «просто заменить элемент без перезагрузки страницы». Восстановление позиции после убийства процесса. Прыжок на конкретную страницу по deeplink.

На Android есть Jetpack Paging 3, и его берут по умолчанию. Но как только вы выходите за рамки «загрузи следующие 20 элементов на скролле вниз» — начинается интересное. А если ваш проект — Kotlin Multiplatform, то Paging 3 вообще не ваш вариант: это Android-библиотека, она не едет на iOS.

Я расскажу про опенсорсную библиотеку Paginator, которую делаю последние несколько лет. Она работает одинаково на Android, JVM и iOS из одного commonMain, закрывает сложные сценарии из коробки — и даже на самой обычной ленте настраивается короче, чем Paging 3. Это не поход против Paging 3 и не попытка что-то кому-то доказать. Это просто описание того, что есть другой инструмент, и он делает то же самое компактнее.

Современные Android-приложения всё чаще работают с данными, утечка которых критична для пользователя: платёжной информацией, одноразовыми кодами, персональными сведениями и содержимым приватных экранов. При этом на практике защита таких интерфейсов нередко сводится только к запрету скриншотов или ограничению вывода изображения, хотя реальная проблема шире: злоумышленник может попытаться получить не снимок экрана, а его структурированное представление через механизмы специальных возможностей. В результате чувствительные данные становятся доступны для чтения, анализа и автоматизированного сопровождения действий пользователя. В статье рассматривается именно эта проблема и предлагается практический многослойный подход к защите чувствительных экранов в Android, который сочетает средства защищённого вывода, ограничение доступности данных в accessibility-дереве, очистку семантики интерфейса и дополнительные меры против побочных каналов утечки.