[Feature] Автообновление Pre-Release сборок & Обновление подписок через прокси

[Tsumugii-Kotobukii]

Описание фунции / Feature description

Предлагаю добавить две полезные функции для улучшения пользовательского опыта (UX) и стабильности работы приложения:

1. Автообновление Pre-Release: Добавить опцию автоматической проверки и установки обновлений для Dev/Pre-Release канала.
2. Обновление подписок через прокси: Возможность скачивать/обновлять URL подписки через уже активный прокси-сервер (из этой же или другой подписки), а не напрямую.

Сценарий использования / Use case

• Для автообновления: Многие используют Dev-ветку как основную, так как новые конфигурации Mihomo (YAML) требуют свежих версий ядра и ломаются на старых релизах. Постоянный ручной поиск и скачивание билдов с GitHub неудобны.
• Для прокси-обновления: Часто возникают проблемы с доступностью сервера подписки напрямую — будь то блокировка домена, целевого IP-адреса регуляторами или иные сетевые ограничения (непроходимость трафика к хостингу подписок). При этом сами прокси-серверы внутри клиента остаются рабочими. Функция обновления ссылки через активный прокси гарантирует стабильное получение конфигураций в обход любых сетевых аномалий.

Буду благодарен за фидбек, если что-то из этого технически сложно реализовать. Спасибо за FlClashX!

Операционная система / Target OS

• Android
• Windows
• MacOS
• Linux

[Tsumugii-Kotobukii]

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

Подскажите, пожалуйста, как именно под капотом работает функция «Контроль доступа» (Access Control) на Android?

Меня интересует, как она взаимодействует и не конфликтует ли с правилами exclude-package на уровне ядра? Например, я использую готовые списки обхода (вроде legiz-ru), где огромный перечень российских приложений прописан через exclude-package.

Правильно ли я понимаю логику:

1. Контроль доступа (в UI FlClash) работает на уровне Android VPN Service API (раздельное туннелирование) — то есть трафик исключенных здесь приложений вообще не попадает в TUN-интерфейс и ядро Mihomo его даже не видит?
2. exclude-package (в YAML конфиге) работает уже на уровне самого ядра Mihomo для того трафика, который прошел через TUN-интерфейс?

Вопрос по производительности и стабильности:
Если попытаться скормить этот огромный список (500+ приложений) не ядру, а напрямую в «Контроль доступа» самого FlClashX — способно ли приложение и сама система Android нормально это переварить? Не приведет ли обработка такой огромной таблицы маршрутизации через Android VpnService API к падению (crash) службы VPN, зависаниям при запуске или сильной нагрузке на процессор/аккумулятор?

Как правильнее поступить: имеет ли смысл разделять этот список, или для таких массивных баз (500+ аппов) однозначно лучше оставить всю фильтрацию пакетов на уровне ядра через exclude-package?

Буду очень благодарен за разъяснение!