edge-revanced

Imported from rushiforai/revanced-archive (examplepatches/AriesAlex/edge-revanced/AGENTS.md). Install upstream with npx skills add rushiforai/revanced-archive --skill edge-revanced. Copyright stays with the author.

Инструкции для работы с Edge ReVanced

Этот репозиторий содержит ReVanced-патчи и runtime-расширение для Microsoft Edge Canary на Android. Патчи на Kotlin меняют bytecode/resources APK, Java-код в extensions/edge/mobile добавляет runtime-поведение, а scripts/ воспроизводимо готовит DevTools frontend, собирает .rvp и применяет его к исходному APK.

Источники истины и границы

• Каноническая реализация патчей находится в patches/src/main/kotlin/app/revanced/patches/edge/EdgePatches.kt; не дублируй выбор методов и точек инъекции в скриптах или extension-коде.
• Runtime-логику держи в extensions/edge/mobile только когда она действительно должна выполняться внутри приложения. Статически разрешимые изменения оставляй в ReVanced-патчах.
• scripts/devtools-mobile.js — мобильная надстройка над собранным Chromium DevTools frontend. Не редактируй сгенерированное содержимое local/; меняй исходный скрипт и пересобирай архив через штатный pipeline.
• local/ содержит скачанные инструменты, исходные APK, результаты декомпиляции и другие воспроизводимые локальные артефакты. Эта папка не является исходным кодом и остается ignored.
• Signing identity официальных сборок хранится вне Git: локально как ignored edge-mod.keystore, а в CI — как repository secret EDGE_MOD_KEYSTORE_BASE64. Не заменяй и не генерируй ключ заново: без исходного ключа следующая сборка не обновит уже установленный мод.
• scripts/bootstrap.ps1 получает зафиксированный commit официального ReVanced Gradle plugin в ignored-папку local/revanced-patches-gradle-plugin, которая подключена через Gradle composite build. Не копируй его код в tracked source и не обновляй pin без отдельной проверки сборки.
• scripts/edge-canary.ts и .github/workflows/release.yml образуют автоматический release pipeline: дешёвая проверка версии предшествует скачиванию APK, а источник принимается только после проверки package name, ARM64 ABI и закреплённой подписи Microsoft.

Исследование и переносимость патчей

• Перед изменением сначала воспроизведи поведение на реальном APK и найди фактический code path через JADX/Ghidra, smali, resource table или runtime-инструментацию. Названия обфусцированных классов сами по себе не являются доказательством.
• Для новых версий Edge предпочитай устойчивые fingerprints: сигнатуры, стабильные Chromium/Microsoft типы, строки, resource references, характерные вызовы и opcode-последовательности. Обфусцированное имя класса или метода используй только вместе с проверяемыми структурными условиями.
• Каждый fingerprint обязан fail-fast при нуле или неоднозначном числе совпадений. Не применяй патч к «похожему» месту молча и не скрывай несовместимость fallback-веткой.
• В resource-патчах отделяй обязательные смысловые anchors от необязательных продуктовых секций: Microsoft может удалить целую группу preferences или один из дублирующих layout-вариантов между соседними версиями. Требуй минимум один однозначно найденный ресурс, проверяй структуру каждого найденного варианта и меняй только пересечение реально существующих optional-элементов; не фиксируй точное количество вариантов без доказанного контракта.
• В multidex APK сырые упоминания descriptor и строк используй только для отбора DEX-кандидатов: они могут повторяться в DEX со ссылками на класс. Уникальность класса или метода подтверждай по фактическому объявлению в дизассемблированном bytecode.
• Не привязывай Chromium-класс к номеру classesN.dex: даже между соседними сборками Edge объявление J.N переезжает между DEX. Находи класс по descriptor и проверяй ровно одно фактическое объявление.
• Совпадение набора методов J.N и подмена WHOLE_HASH не доказывают совместимость нового libchrome.so со старым Java-слоем. Multiplex selector IDs и native-to-Java callbacks меняются независимо от сигнатур J.N; трансплантат обязан включать согласованный с native-библиотекой сгенерированный JNI glue и проходить реальный cold-start flow.
• При замене файлов внутри APK сохраняй ZIP compression method каждого donor entry. Chromium открывает resources.pak и часть snapshot-assets через file descriptor; случайное deflate-сжатие формально целого файла ломает загрузку runtime.
• Перед добавлением временного DEX-регистра вычисляй число parameter и local registers. Переиспользуй существующий local register; расширяй register file только у метода без locals и явно восстанавливай все сдвинутые v-aliases параметров, которые читает старое тело. После этого проверяй фактический метод через apkanalyzer/dexdump на обеих поддерживаемых формах.
• После bytecode-инъекции с ветвлениями проверяй фактически собранный DEX через dexdump: каждая цель перехода должна указывать на допустимую инструкцию, а move-result* обязана непосредственно следовать за соответствующим invoke-* и не может быть branch target. В текущем patcher не передавай snippets с внутренними labels через обычный addInstructions — они могут собраться в формально валидный APK с неверными смещениями.
• Не меняй padding, clipping или layout TabListRecyclerView во время его ItemAnimator и не прерывай оригинальный callback завершения раскладки: незавершённая continuation оставляет clip-outline карточек в промежуточном состоянии. Смещение однорядного списка делай внешней transform-анимацией, не инвалидирующей child layout.
• После обновления Edge сначала проверь применение каждого патча к новой версии, затем тот же пользовательский сценарий на настоящем ARM64-устройстве. Успешная перепаковка APK не доказывает корректность runtime-поведения.
• x86_64 AVD с ARM-трансляцией не является контрольным стендом для Chromium Edge. Для финальной проверки используй физический ARM64-телефон либо чистый ARM64 AVD.
• Пользовательские строки добавляй на русском и английском, когда обе локали реально нужны. Устойчивые технические названия вроде DevTools можно не переводить.

Сборка и проверка

• Для подготовки зависимостей и DevTools frontend используй .\scripts\bootstrap.ps1.
• Для проверки ABI и сборки .rvp используй .\scripts\build.ps1. По умолчанию скрипты используют все доступные процессоры; ограничивай -CpuCount только по явной ситуативной причине.
• Для полного результата из текущих исходников используй .\scripts\patch.ps1 -Apk '<path-to-edge.apk>'. Для применения уже собранного bundle используй -Rvp '<path-to-bundle.rvp>': этот режим не должен запускать Gradle или повторно получать DevTools frontend. Параметры и требования к SDK сверяй с актуальным README.md и самим скриптом.
• После изменения Kotlin/Java/DevTools-кода минимум собери .rvp, примени все выбранные патчи к поддерживаемому APK и проверь отсутствие failed patches. Для пользовательского поведения установи APK через adb install -r и повтори точный измененный сценарий на устройстве.
• Не считай успешную Gradle-сборку, установку APK или запуск браузера отдельным доказательством исправления UX. Проверяй именно измененный flow и, для визуальных изменений, фиксируй реальный портретный и альбомный render.
• Изменения tab switcher обязательно проверяй покадрово как минимум на переходе 3→2 с закрытием нижней левой карточки, на первом входе после am force-stop и на быстрых повторных закрытиях. Карточки должны оставаться полностью отрисованными после завершения каждой animation phase.

Код и саморевью

• Главный приоритет — чистый, простой и сильный итоговый код в контексте всей кодовой базы. Минимальность означает отсутствие лишнего кода, состояний, абстракций и неверных слоев, а не минимальное число строк в patch.
• Не добавляй speculative fallback, backward-compatibility ветки, reflection или runtime-check'и «на всякий случай». Сначала докажи, что они нужны реальным контрактом Edge или совместимостью версий.
• Не оставляй временные логи, диагностические hooks, закомментированные эксперименты, неиспользуемые imports/methods/files и следы промежуточной гипотезы.
• После каждого смыслового изменения пересмотри diff как строгий ревьюер: проверь точки инъекции, регистры и control flow smali, границы Kotlin/Java/JavaScript, cleanup временных артефактов и отсутствие unrelated изменений.
• «"Работает" недостаточно. После того как довел до рабочего состояния, убедись, что решение встроено в код красиво и без временных подпорок. Если по пути пришлось оставить костыль или фоллбэк, потом обязательно добейся его удаления, даже если для этого надо явно попросить пользователя сделать связанное изменение.»

Git и секреты

• Перед изменениями и delivery проверяй git status --short; не откатывай и не включай чужие или unrelated правки.
• Репозиторий публичный: не коммить и не пушь .env, credentials, signing keys, tokens и любые другие секреты. Секреты официального CI хранятся только в GitHub Actions Secrets, локальные — только в ignored-файлах вне истории.
• Никогда не печатай значения секретов в логах, diff-отчетах, ответах, issues или pull request. Перед delivery проверяй tracked-файлы и историю на случайно попавшие credentials.
• Не создавай .bak, .old и timestamp-бэкапы в репозитории. При реальной необходимости используй временную директорию вне рабочей копии.

Долговременные правила

• Если пользователь в ходе работы даёт новые устойчивые правила по стилю кода, структуре или процессу, то их надо кратко и по делу сразу добавлять в этот файл AGENTS.md, если это реально полезно будущим агентам.
• Правила в AGENTS.md добавлять только если пользователь явно просит сохранить что-то универсальное и долговременное; не заносить туда ситуативные договорённости текущей задачи.
• Пользователь явно просил автоматически закреплять в этом файле новые подтверждённые проектные грабли и способы их предотвращения. Добавляй только переиспользуемый инвариант, а не хронологию ошибки или детали текущего релиза.