Android *

Приложения на вашем телефоне могут обнаружить VPN через SOCKS5 на localhost и слить IP-адрес сервера. Рабочий профиль (Island, Insular, Shelter) скрывает VPN от ConnectivityManager, но не от tun0, маршрутов и локальных портов. Так родился open-souce Anubis, который решает проблему иначе - автоматически отключает приложения через pm disable-user при смене состояния VPN. Мёртвое приложение не может ничего детектить, потому что его не существует.

Скилл для Claude Code, который знает Material Design 3 лучше, чем вы: 30+ компонентов с Compose-маппингами, генерация тем из seed-цвета, адаптивная навигация и аудит готового приложения по 10 категориям — от цветовых токенов до accessibility. Compose-first, Flutter вторичный, веб в maintenance mode. 454 звезды за 4 дня.

Несколько недель назад я описал на Хабре идею «честного российского мессенджера» с открытым кодом и прозрачным compliance. Та статья была про «зачем». Эта — про «как получилось». Web-клиент и Android-приложение полностью переписаны и работают в production, серверная часть развёрнута и обслуживает реальные подключения. iOS пока не трогали. Ниже — разбор архитектуры, решения, которые мы приняли, грабли, на которые наступили, и открытый набор людей в проект.

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

Это не субъективный опыт — строгая разделенная архитектура повышает гибкость, переиспользуемость и тестируемость кода. BLoC сам по себе — паттерн с отличной дисциплиной потока данных и строгим отделением бизнес‑логики от UI, но стоит немного расслабиться, и он разрастается до god объекта.

Цель этой статьи — продемонстрировать, как вынесение бизнес логики в use-cases может помочь вернуть контроль над ViewModel слоем. Это не попытка навязать единственный вариант реализации, а материал про технический компромисс, подтвержденный цифрами и опытом.

Когда я впервые всерьёз сел писать AGSL под Android, ощущение было очень странное. С одной стороны - современный графический конвейер, RuntimeShader, RenderEffect, красивые эффекты и весь этот техно-киберпанк. С другой - шейдерный код живёт внутри строковых литералов, uniform-ы приходится объявлять и привязывать вручную, а отладка периодически начинается с философского вопроса: «в какой именно строке я сейчас всё сломал?»

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

Собственно, так и появился RedByteFX. Я сделал его не только ради собственного удобства. Мне хотелось решить ещё одну задачу: сделать AGSL более массовой и понятной технологией для Android-разработчиков. Потому что в нативном виде AGSL мощный, но психологически для многих выглядит как «не трогай, это на Новый год». А мне хотелось, чтобы к шейдерам можно было подойти без дрожи в коленях и без ощущения, что сейчас придётся разговаривать с господином ПЖ на древнем пацакском наречии.

В новом дайджесте пружинная анимация и Kotlin без «воды, будущее Android-приложений с AppFunctions и путь к сингулярности, лампа с цифровым джинном, как Gemma 4 меняет правила игры, ошейники для коров, замена List, Remote Compose и многое другое. Заходите!

Сегодня наше правительство издаёт циркуляры, по которым программы из жизненно важного для среднего гражданина списка должны стучать “куда надо” о том, что у гражданина есть VPN.

Всё это - произвол в чистой форме, а потому мы можем и должны этому сопротивляться.

Гражданское сопротивление, гражданское неповиновение - вот то, что мы противопоставим этому произволу.

Они хотят сделать стукачей из установленных на наших смартфонах программ?

Мы ответим им тем, что отправим стукачей в цифровой ГУЛАГ. Изолируем эти мерзкие сущности из нашего мира!

Данная статья - инструкция о том, как установить и настроить песочницу Insular/Island. О том, как выселить всех стукачей на отдельный остров и заставить их работать там в изоляции. Без права переписки.

Каждое Android-приложение, которое хранит данные на устройстве, рано или поздно сталкивается с базой данных. Встроенная SQLite — надёжное решение, но работа с ней через SQLiteOpenHelper требует написания SQL-запросов вручную, преобразования курсоров в объекты и постоянного контроля за закрытием соединений. Это отнимает время и довольно часто вызывает ошибки.

Google предложил библиотеку Room, которая является оберткой над SQLite и реализует паттерн ORM (Object-Relational Mapping). В этой статье мы на конкретном примере сравним, как выглядят операции добавления и чтения данных на чистом SQLite и на Room. Вы увидите, почему Room избавляет от «шаблонного кода» и делает работу с БД простой и безопасной.

Знакомо, правда? Мечтаешь создать невозможное: уникальное, новое, то, чего ещё нет на рынке. И при этом чтобы это было твоё «детище», твой продукт, которым ты будешь гордиться и который станет по-настоящему стоящим и полезным для мира.

Думаешь, анализируешь, ищешь вариант, генерируешь идеи… Но всё не то. И каждый раз сталкиваешься с тем, что это уже кто-то реализовал. Да ещё и так круто, что подступиться страшно.

В этой статье я расскажу о проектировании мобильного приложения "Balance" по методу колеса жизненного баланса — от выбора идеи до кликабельных прототипов и тестирования.

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

Недавно Apple подтвердила стратегическое партнерство с Google для интеграции ИИ Gemini в свои устройства.  Сегодня мы их опередим и поднимем свою LLM в Android-смартфоне. С блэкджеком и WebUI.

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

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

Меня зовут Станислав, я Test-инженер в KODE, в этой статье разберу, как использовать Proxyman Scripts не как вспомогательную фичу, а как инструмент автоматизации тестирования.

Привет, хабровчане! С вами снова Евгений Иванов, QA-lead в компании Fix Price. В этот раз поделюсь с Вами опытом внедрения автоматизации для гибридного мобильного приложения на Android. 

У этого решения есть свои плюсы и минусы, и мы продолжаем работать над его развитием. Но уже сейчас понятно: оно приносит реальную пользу команде во время регрессионных и предрелизных прогонов. Расскажу подробнее, как мы собрали связку Playwright + Appium + WebdriverIO и что из этого вышло.

Технологии Backend-Driven UI уже давно используются во многих компаниях, включая Альфа-Банк. Существует множество реализаций этого подхода, и недавно Google представил собственное решение — Remote Compose.

Remote Compose выглядит очень перспективной технологией. Фреймворк активно развивается и поддерживается командой Google. Однако на момент написания статьи технология всё ещё находится в alpha-версии, поэтому использовать её на проде пока рано. 

Но я изучил этот фреймворк и хочу поделиться своим опытом, а когда Remote Compose выйдет в бета-версию вы будете знать, как с ним работать

В статье разберём:

•  общую концепцию Remote Compose,
•  чем он отличается от классического BDUI,
•  какие интересные технические решения используются внутри,
•  несколько практических примеров использования.

Вскоре после нахождения шпионского модуля в Max я обнаружил критическую уязвимость во всех известных VLESS клиентах.

Эта уязвимость позволяет обходить per-app split tunneling и приватные пространства (Knox/Shelter/Island/etc) и гарантированно обнаруживать выходной ip прокси, который вы используете.

При этом один из клиентов уязвим настолько, что позволяет дампить ваши конфиги и, в худшем случае, расшифровать весь ваш трафик.

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

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

Привет! Давайте разберёмся, что там накатили в новом мажоре Room. На момент написания актуальная версия — 3.0.0-alpha03, а стабильный релиз обещают где‑то к лету.

Если вдруг выпали из контекста: Room — это повсеместно используемая ORM‑обёртка над SQLite ранее только для Android, с недавнего времени и для Kotlin Multiplatform.

И у неё вышел 3 мажор! Подробнее внутри.

В новом выпуске выпуск приложений в App Store без Mac и Android Service своей мечты, узкие места в производительности Android-приложений и как Swift работает с памятью, Android SDK на Swift, кризис в RuStore и путь к тёмной стороне, захват категории Cast to TV в Google Play, галлюцинации LLM и многое другое. Заходите!

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

Мы разобрали 6 популярных PFM-инструментов (Personal Finance Management), чтобы посмотреть, как именно — на уровне архитектуры и UX — они заставляют пользователя «резать косты» и брать бюджет под контроль.

Убирался в комнате, наткнулся на старый Xiaomi 11T в ящике — 8 ГБ ОЗУ, Dimensity 1200, лежит без дела. Решил превратить его в персональный AI-сервер: поднял OpenClaw через Termux, подключил бесплатную модель через OpenRouter и теперь у меня в Telegram отвечает свой AI-ассистент. Бесплатно. Четыре способа установки, борьба с Android за живучесть процесса и подробный раздел про безопасность.

Кратко расскажу о себе и о том, зачем возникла необходимость в подобном. Я более десяти лет пишу приложения под Android, около 5 лет под IOS, и сейчас переношу свои наработки под десктопы. Приложения мои предназначены для сисадминов, это SSH клиент, сетевые сканеры и тд. В общем, самое сложное — не сам интерфейс, а то, что под капотом. Когда я лишь начинал, я думал, что остановлюсь на платформе Android и стал пилить все на Java. Но затем осознал свою ошибку и исправил ее. На данный момент все мои приложения состоят из двух частей: общего для всех систем ядра на С++ и платформозависимого интерфейса, написанного на Java/Swift/C++ в зависимости от системы.

Оговорюсь сразу, эта статья будет лишь своего рода вступлением. Я покажу, как работать с объектно‑ориентированным кодом на C++ в Java оболочке (в JNI нам доступен экспорт С функций). Инициализировать объект, делать из него вызовы, удалять, при этом имея аналогичный класс в оболочке, будто бы наш код был написан на Java. Задача эта не слишком сложная, но прежде чем опытные прогеры закрыли эту статью, я оговорюсь, что в следующей части мы уже будем работать с каллбэками — вызовами Java листенеров из нашего С++ кода, а вот это уже задача совсем нетривиальная, требующая понимания работы JNI и Dalvik. Но обо всем по порядку.

Итак, у нас есть некий CPP класс и Java оболочка. Через JNI мы можем вызывать только С‑функции, то есть не объектный код. Так как же нам работать с ООП? Главная проблема — не столько вызовы, сколько хранение адреса объекта нативного класса. Лично для себя я нашел решение — хранить его в Java классе, как long. То есть, у нас получается приблизительно такой код:

Мы с братом создали Sova AI (https://ayconic.io/sova), ИИ агента на Андроиде, который оперирует приложениями и выполняет ваши хотелки таски на телефоне. Это первый ассистент, которому не нужны ADB, USB, PC, root и т.д., просто самое обычно приложение, которое устанавливается на Андроид (пока IOS в разработке) и всегда с вами, куда бы вы не пошли (звучит страшно? 😁).

Зачем еще один ИИ ассистент?

Потому что он единственный в своем роде, все остальные “mobile-use” требуют подключения к PC, и это конечно неудобно и не интересно. Если уже есть PC, то лучше уже на нем и выполнять различные задачи, зачем тогда телефон мучать? Computer-use, browser-use вполне себе прекрасно работают на PC.

Нам хотелось ассистента, который всегда будет на телефоне, а не когда мы с кабелем USB возле компа, ассистента который будет делать на телефоне все, что может делать пользователь, а не еще один умный браузер (привет Perplexity) который будет требовать API чтобы что-то сделать, или кастрированный Gemini assistant который только и твердит что он ИИ модель и не может ничего. Они в большинстве просто бесполезны, как и все чатботы которые всего лишь чатботы, но почему-то называются AI assistant для маркетинга.

Что оно умеет

Как и computer‑use он делает клики, скроллы, открывает приложения, и симулирует любые действия пользователя. Под капотом — работа с Accessibility API Андроида, используем tree экрана и скриншоты. Только на скриншотах мало что сделаешь, модели не очень хорошо с ними работают, оптимизируют картинки каждый по своему и так далее. Поэтому мы сделали определенную комбинацию того и другого, с экономией токенов, чтобы пользователи не продавали себя в рабство из‑за одного заказа еды. Также его можно сделать асситентом по умолчанию и оно будет реагировать на ваши голосовые команды и делать что захотите, без этого всего «Я ИИ модель и ничего не могу делать, хнык‑хнык».