Repository navigation
de CONTRIBUTING
Languages: English | العربية | Čeština | Deutsch | Español | فارسی | Français | हिन्दी | Bahasa Indonesia | Italiano | 日本語 | 한국어 | Nederlands | Polski | Português | Русский | Svenska | ไทย | Türkçe | Tiếng Việt | 中文
Danke fürs Mithelfen! VDBackup soll leicht sein, um dazu beizutragen. Dieser Leitfaden erklärt dir, wo die Dinge liegen und die wenigen Konventionen, die wir befolgen.
VDBackup ist ein KernelSU/APatch/Magisk-WebUI-Modul: Shell-Skripte + eine vanilla-JS-WebUI + statische Binärdateien pro ABI. Für die Kernfunktionen ist keine App erforderlich. Siehe ARCHITECTURE.md und docs/FILE-STRUCTURE.md.
Es ist der offene, root-native Nachfolger von Swift Backup, Neo-Backup und Android-DataBackup - die Vereinigung ihrer Funktionen unter AGPLv3, mit Import vorhandener Neo-Backup- und Android-DataBackup-Backups, damit Leute migrieren können.
KI-Assistenten und -Agenten sind hier erstklassige Mitwirkende, kein nachträglicher Einfall.
- Das Projekt ist maschinenlesbar aufgebaut: jedes
helper.sh-Verb gibt ein einzelnes JSON-Objekt aus, die Engine ist reine POSIX-Shell, und das Dateilayout ist in docs/FILE-STRUCTURE.md dokumentiert. - Ein Agent kann jeden Inhalt und jede Aktion des Moduls headless über diese JSON-API verwalten - die vollständige Steuerungsfläche, Verben und Sicherheitsleitplanken stehen in docs/AI-AGENTS.md.
- KI-unterstützte Patches werden zu denselben Bedingungen geprüft und akzeptiert wie alle anderen - nach Korrektheit, Klarheit und den Konventionen unten, nicht danach, wer (oder was) sie geschrieben hat.
- Wenn du VDBackup von einem Agenten aus steuerst, nutze die JSON-Ausgabe von
helper.shals Vertrag; scrape nicht die WebUI. - Gleicher Maßstab für alle: echte Funktionen werden nie geschwächt, Geheimnisse und Gerätedaten landen nie im Repo (siehe die strikte .gitignore), und verändernde Aktionen bleiben bestätigt und protokolliert.
- Du brauchst ein gerootetes Gerät/einen Emulator (KernelSU, APatch oder Magisk) zum Testen.
- Baue das flashbare Zip:
cd module && zip -r9 ../VD-Backup-dev.zip .und flashe es dann. - Die WebUI ist
module/webroot/(öffne sie aus dem Root-Manager). Das Backend istmodule/helper.sh(Dispatcher) undmodule/worker.sh(abgekoppelte Engine). - Native Binärdateien liegen in
module/bin/<abi>/und werden von der CI erzeugt (.github/scripts/build_bin.sh); normalerweise baust du sie nicht von Hand neu.
-
Jede Quelldatei (
.sh,.js,.css,.html,.svg,.yml) beginnt mit dem Projekt-Banner-Header (kopiere ihn aus einer beliebigen vorhandenen Datei). Keine Ausnahmen. - Code und Kommentare auf Englisch. Halte Kommentare minimal und nur dort, wo nötig.
-
Kein Geviert- oder Halbgeviertstrich; verwende immer einen einfachen Bindestrich
-. - Die WebUI ist vanilla JS (ein
scripts.js); keine Frameworks. Sprich mit Root nur über denhelper(verb, args)-Wrapper und maskiere jeden interpolierten Wert. - Schwäche nie eine echte Funktion (z.B. Erhalt von SELinux/uid/gid/Modi).
- Verändernde Aktionen (Restore, Delete) müssen eine Bestätigung verlangen und ein Audit-Log schreiben.
- UI-Strings liegen in
module/webroot/lang/. Englisch ist der kanonische Fallback (en.js+en.json); die anderen 20 Sprachen sind<code>.json. - Um einen String hinzuzufügen oder zu ändern: bearbeite
en.jsunden.json, dann aktualisiere jede<code>.json. Ein sichtbares Label zu berühren bedeutet, alle Sprachdateien und alleREADME.<code>.mdzu aktualisieren. - Übersetzungen sind reines JSON - ein großartiger erster Beitrag. Siehe die Sprachliste in
module/webroot/i18n.js.
- Halte PRs fokussiert. Beschreibe was und warum.
- Zeichne deine Commits ab (DCO):
git commit -s(fügtSigned-off-by:hinzu). - Die CI muss grün bleiben. Sei freundlich in Reviews - siehe CODE_OF_CONDUCT.md.
Halte Ausschau nach den Labels good first issue und help wanted. Übersetzungen, Docs, neue
rclone-Ziel-Presets und WebUI-Feinschliff sind alle großartige Ausgangspunkte.