Профиль хорошо разделяет данные и пакеты, но плохо подходит для полного сокрытия факта изоляции. Android реализует work profile как отдельного пользователя: UID вычисляется как 100000 * userId + appId, данные лежат отдельно, а системные API знают текущий user/profile. RKNHardering проверяет это явно.
Официальные источники: AOSP Work profiles и AOSP Private space.
Стабильные native-сигналы:
ISOLATION_PROFILE — общий профильный контекст;ISOLATION_CLONE — характерные clone-user диапазоны, включая MIUI-подобные ID;ISOLATION_SECONDARY_USER — любой userId > 0;ISOLATION_WORK_PROFILE — managed/profile owner признаки.β-слой добавляет beta.user_profile, beta.foreground_user, sandbox process/filesystem/namespace identity и fscrypt identity. По отдельности они обычно review, но профиль плюс независимое сетевое расхождение может сформировать β-кворум.
Shelter и Insular используют официальный managed profile. Они могут:
Но сеть и ядро устройства остаются общими, а userId видим. Поэтому профиль полезен для конкретного package-visibility сценария, но не заменяет kernel/Binder hide.
Наиболее чистый сценарий без root: RKNHardering остаётся в основном пользователе, VPN вынесен на внешний роутер. Профиль тогда вообще не нужен и не создаёт isolation-сигнал.
Если RKNHardering запущен в work profile, а VPN только в owner profile, приложение может получить прямой путь и не видеть VPN-пакет. Цена — явный userId > 0, work-profile состояние и возможное расхождение сетевых политик. Рассматривайте это как эксперимент, не как гарантированный pass.
Private Space — отдельный private profile. Когда пространство заблокировано, профиль остановлен и приложения скрыты; когда разблокировано, это обычная отдельная копия приложения в другом user context. Запустить проверку внутри заблокированного пространства невозможно, а после разблокировки профильная идентичность остаётся.
Private Space хорошо скрывает приложения от повседневного package enumeration, но не меняет TUN/system network модели автоматически. Если VPN работает в основном профиле на уровне всего устройства, приложение в Private Space может всё равно видеть общие сетевые признаки.
Xiaomi/MIUI, Samsung Dual Messenger, Huawei PrivateSpace и другие OEM-реализации используют разные user/profile модели. В текущем native-коде RKNHardering отдельно распознаются clone-диапазоны вроде user 999 и 950–959. Переименование ярлыка или package alias это не меняет.
adb shell pm list users
adb shell am get-current-user
adb shell cmd package list packages -U | grep com.notcvnt.rknhardering
adb shell dumpsys user
dumpsys user может содержать личные сведения об аккаунтах/профилях; не публикуйте полный вывод без очистки. Для конкретного пользователя:
adb shell cmd package list packages --user 0 | grep com.notcvnt.rknhardering
Замените 0 на ID из pm list users только для чтения. Установка/удаление профиля может уничтожить его данные.
Root не делает профиль невидимым сам по себе. Он помогает правильно применить VPNHide к UID каждой копии приложения.
VPNHide upstream разрешает package names в UID через packages.list/pm list packages -U; современные версии должны учитывать user/appId. VPNHide Next заявляет полноценную поддержку рабочих профилей. После сохранения целей проверьте, что в kernel control list присутствует UID именно той копии RKNHardering, которую вы запускаете.
Пример чтения UID:
adb shell cmd package list packages -U --user 0 | grep com.notcvnt.rknhardering
adb shell cmd package list packages -U --user 10 | grep com.notcvnt.rknhardering
Не копируйте UID вручную между перезагрузками/переустановками без повторной проверки. AppId обычно стабилен, но profile/user часть отличается.
Если framework-хук использует только appId, он может примениться ко всем профилям; если backend использует полный UID, каждую копию нужно добавить отдельно. Сверяйтесь с README конкретной версии и её диагностикой.
Root-hiding модуль также должен выполнять unmount для UID/profile копии, а не только для owner instance. Иначе основное приложение выглядит чисто, а work-profile копия видит /data/adb/mount следы.
Это минимизирует локальные и isolation признаки. Остаются server-side GeoIP/CDN/DNS/RTT.
Может убрать package visibility и локальный VpnService из owner context, но поведение OEM различается. Снимите dumpsys connectivity в обоих профилях и проверьте egress.
Профиль сам становится сигналом. Применимо только для исследования чувствительности ISOLATION_* и β-кворума.
System Framework.Это покрывает локальную сеть, но ISOLATION_* остаётся правдивым. Не пытайтесь ломать UserManager глобально: это может нарушить launcher, package manager и политики устройства.
Удаление work profile/Private Space стирает приложения, ключи, аккаунты и локальные файлы внутри профиля. Перед удалением экспортируйте нужные данные через штатные механизмы. Shelter/Insular имеют собственные инструкции teardown — следуйте им, а не удаляйте DPC принудительно.
Не создавайте/удаляйте системных пользователей командами pm create-user/pm remove-user на основном устройстве без резервной копии. В этой инструкции команды ограничены чтением состояния.