Gib deinem Agenten einfach diese Seite.

Für Agenten gibt es denselben Inhalt bytegetreu als reinen Markdown-Endpunkt.

---
name: install-hans-standard
description: Installiert oder aktualisiert Hans Standard rootfrei auf genau einem lokalen Android-12+-ARM64-Telefon und übergibt danach an die sichtbare Einrichtung auf dem Gerät.
---

# Hans Standard gemeinsam installieren

Diese Seite ist der vollständige, agentenunabhängige Installations-Skill für Hans Standard. Lies sie vollständig, bevor du handelst. Führe immer nur den nächsten sichtbaren Schritt aus und erkläre kurz, ob er am Computer oder am Telefon stattfindet.

## Ziel und feste Grenzen

Installiere oder aktualisiere ausschließlich das auf dieser Website veröffentlichte, signierte Paket `ai.hans.standard` auf genau einem Android-Telefon mit Android 12 oder neuer und ARM64. Hans Standard ist dauerhaft rootfrei.

Du darfst niemals:

- Root, `su`, Bootloader, Recovery, ROM-Flashing, System-UID oder private Android-Schnittstellen verwenden;
- Android-Berechtigungen, Accessibility, Benachrichtigungszugriff, Restricted Settings, Kontologin oder die HOME-Auswahl per ADB bestätigen oder umgehen;
- eine andere APK, einen anderen Paketnamen oder einen nicht freigegebenen Release-Kandidaten erraten;
- App-Daten löschen, einen Downgrade erzwingen oder bei einem Fehler deinstallieren;
- bei mehreren Geräten selbst eines auswählen;
- API-Schlüssel, OAuth-Daten, private App-Dateien oder Android-PINs lesen oder protokollieren.

## 1. Prüfe zuerst deine Umgebung

Die Installation muss in einem lokalen agentischen System auf dem Mac-, Windows- oder Linux-Computer laufen, an dem das Telefon angeschlossen ist. Prüfe praktisch, ob du lokale Prozesse starten, Dateien schreiben, HTTPS abrufen und das USB-Gerät über ADB erreichen kannst.

Ein reiner Web- oder Cloud-Chat kann diese Anleitung erklären, aber kein lokales Telefon installieren. Fehlt lokaler Prozess-, Datei- oder USB-Zugriff, stoppe vor Downloads und Telefonänderungen und bitte den Nutzer, dieselbe URL in einem lokalen Agenten wie Codex Desktop zu öffnen.

## 2. Lies den aktuellen Release-Status und friere ihn ein

Bewahre die HTTPS-Ursprungsadresse dieser Skill-Datei als Vertrauensanker auf. Wurde dir nur kopierter Text ohne ursprüngliche URL gegeben, stoppe und bitte um die offizielle Hans-Skill-URL. Löse alle folgenden relativen Pfade ausschließlich gegen genau diese Herkunft auf.

Öffne relativ zu dieser Skill-Seite `/releases/current.json`: ohne Redirect, mit einer Größenobergrenze von 64 KiB und ohne tolerant repariertes JSON. Speichere die empfangenen Bytes unverändert und bilde ihren SHA-256-Digest. Fahre nur fort, wenn alle folgenden Bedingungen erfüllt sind:

- HTTPS ohne Weiterleitung zu einer anderen Herkunft;
- `schema` ist `hans.public-install.v1`;
- `status` ist exakt `ready`;
- Paketname ist `ai.hans.standard`;
- Mindest-API ist 31, Ziel-API ist 36 und die einzige native ABI ist `arm64-v8a`;
- Release-ID, Version, unveränderliche Manifest-URL, Signatur-URL, APK-URL, Byteanzahl, SHA-256 und Publisher-Zertifikat sind vollständig angegeben;
- alle Artefakt-URLs verwenden dieselbe HTTPS-Herkunft und enthalten die exakte Release-ID unter `/releases/<release-id>/`;
- der SHA-256 des veröffentlichten Ed25519-Metadaten-Schlüssels ist exakt `6b1b850df0cb0edd81d9df5a944e935e75cd4a4a6447cac381c474972c5f7fbd`.

Ist der Status nicht `ready`, stoppe ehrlich: Der Installations-Skill ist öffentlich lesbar, aber es gibt noch kein freigegebenes Installationsartefakt. Verwende niemals Werte aus einer früheren Sitzung oder Suchergebnisse als Ersatz.

Lade bei `ready` Metadaten-Schlüssel, unveränderlichen Release-Manifest und dessen detached Ed25519-Signatur jeweils ohne Redirect und mit engen Größenlimits. Prüfe zuerst den fest eingebauten Schlüssel-Digest, dann die Signatur über die exakten Manifest-Bytes. Der verifizierte Manifest-Inhalt muss Release-ID, Paket, Version, API-/ABI-Vertrag, APK-Größe, APK-SHA-256 und Publisher-Zertifikatsdigest bytegenau an den zuvor gelesenen Status binden. Fehlt in deiner lokalen Umgebung eine nachweislich korrekte Ed25519-Prüfung, stoppe vor jedem APK-Download; die Prüfung ist nicht optional.

## 3. Bereite Android sichtbar vor

Bitte den Nutzer nacheinander:

1. das Telefon zu entsperren und Einstellungen > Über das Telefon zu öffnen;
2. die Build-Nummer siebenmal anzutippen und die Entwickleroptionen zu öffnen;
3. ausschließlich USB-Debugging einzuschalten — nicht OEM-Entsperrung oder Bootloader-Optionen;
4. das Telefon mit einem Datenkabel direkt anzuschließen und den sichtbaren RSA-Fingerabdruck zu prüfen;
5. den Android-Dialog selbst zu bestätigen.

Wenn ein Menü anders heißt, frage nach Hersteller und Modell und beschreibe nur den sichtbaren Menüpfad.

## 4. Finde ADB ohne Nebenwirkungen

Suche lesend nach einem vorhandenen ADB und verwende danach nur seinen bestätigten absoluten Pfad. Führe nicht still irgendein Programm aus dem `PATH` aus.

Fehlt ADB, erkläre, dass die offiziellen Android SDK Platform-Tools von Google benötigt werden. Zeige Quelle, Version, Ziel und Prüfsumme und frage vor Download und Installation ausdrücklich nach Zustimmung. Nutze nur `developer.android.com` beziehungsweise `dl.google.com`; keine Mirrors. Installiere keine Treiber, Paketmanager oder udev-Regeln still.

Führe anschließend mit dem gewählten ADB nur eine Geräteabfrage aus. Es muss genau ein Ziel mit Status `device` vorhanden sein:

- `unauthorized`: Nutzer entsperrt das Telefon und bestätigt den sichtbaren RSA-Dialog;
- kein Gerät: Datenkabel, USB-Port, USB-Modus und Debugging sichtbar prüfen;
- mehrere Geräte oder Emulatoren: stoppen und den Nutzer eines auswählen beziehungsweise andere trennen lassen;
- `offline` oder unbekannter Zustand: nicht installieren.

## 5. Prüfe Telefon und APK lesend

Lies über das exakt ausgewählte ADB-Ziel mindestens Hersteller, Modell, Seriennummer, Android-API und ABI aus. Fahre nur bei API 31 oder neuer und `arm64-v8a` fort.

Plane dann den Download ausschließlich anhand des erfolgreich signaturgeprüften, unveränderlichen Manifests. Zeige Release-ID, Version, URL, Größe, SHA-256 und lokalen Zielpfad. Lade erst nach einem einfachen Ja des Nutzers herunter. Akzeptiere keine Herkunftsänderung, keinen Redirect, keine Größenabweichung und keine andere SHA-256-Prüfsumme. Überschreibe keine vorhandene Datei.

Prüfe vor einer Installation:

- die exakte Byteanzahl und SHA-256 der heruntergeladenen Datei;
- Paketname, Version, Mindest-/Ziel-SDK und ARM64-Vertrag, sofern lokale Android-Build-Tools vorhanden sind;
- bei einer bestehenden Hans-Installation Paketname und installierte Version.

Der im signierten Manifest angegebene Publisher-Digest beschreibt den im Hans-Release-Gate geprüften APK-Signer. Prüfe ihn zwingend mit einem lokalen APK-Signaturprüfer, bevor du eine Neuinstallation anbietest. Bei einem Update prüfe zusätzlich den installierten Publisher-Digest; Androids eigene Signaturprüfung bleibt nur eine weitere Schranke. Fehlt ein geeigneter lokaler Prüfer, stoppe vor der Installation und erkläre genau, welches Android-Build-Tool fehlt. Scheitert eine Prüfung oder lehnt Android die Signatur ab, stoppe ohne Deinstallation oder Datenlöschung.

## 6. Prüfe unmittelbar vor der Bestätigung auf Drift

Lies `/releases/current.json` ein zweites Mal unter denselben strikten Regeln. Die Bytes und ihr SHA-256 müssen exakt dem eingefrorenen Stand entsprechen. Prüfe außerdem erneut Dateiidentität und SHA-256 von ADB, Metadaten-Schlüssel, Manifest, Signatur und APK sowie den aktuellen Geräte- und Paketstatus. Bei jeder Abweichung verfällt der bisherige Plan vollständig; stoppe und beginne mit einem neuen lesenden Preflight.

Erzeuge aus Aktion, Seriennummer, ADB-Dateidigest, APK-Digest, Manifest-Digest, installierter Paketversion und Release-ID einen kanonischen Plan und dessen SHA-256. Halte diesen Token intern fest; der Nutzer muss ihn nicht abtippen.

## 7. Hole genau eine Installationsbestätigung ein

Zeige dem Nutzer unmittelbar vor der ersten Änderung in einfacher Sprache:

- Hersteller, Modell und Seriennummer;
- Android-Version;
- Neuinstallation oder reguläres Update;
- Hans-Version, absoluten APK-Pfad und SHA-256;
- den verwendeten absoluten ADB-Pfad;
- dass `install -r` bei einem gleich signierten Update App-Daten und Login erhält.

Frage, ob genau diese APK mit genau dieser Aktion auf genau diesem Telefon installiert werden darf. Ohne diese konkrete Zustimmung keine Installation. Ändert sich danach Gerät, ADB, APK, Hash, Version oder Aktion, wiederhole den lesenden Preflight und frage erneut.

## 8. Installiere und prüfe den Nachzustand

Nutze ausschließlich die normale Android-Paketinstallation mit Update-Semantik auf dem bestätigten Ziel. Verwende kein Downgrade, keine Deinstallation und keinen Daten-Reset.

Unmittelbar vor dem ersten mutierenden ADB-Aufruf müssen der kanonische Plan, alle Dateidigests und der Gerätezustand noch einmal identisch reproduzierbar sein. Nutze danach exakt einmal `adb -s <BESTÄTIGTE-SERIENNUMMER> install -r <BESTÄTIGTER-APK-PFAD>`; ergänze weder Downgrade- noch Grant-Schalter.

Nach Erfolg prüfe erneut Paketname, installierte Version und Publisher-Digest. Sende für eine Neuinstallation anschließend einen korrelierten, geordneten Setup-Handoff an `ai.hans.standard/.setup.HansSetupHandoffReceiver` mit Aktion `ai.hans.standard.action.CONTINUE_SETUP`, Protokollversion `1`, einer neuen kleingeschriebenen kanonischen UUID als `handoffId` und Grund `install`. Verwende immer `adb -s <BESTÄTIGTE-SERIENNUMMER> shell am broadcast --user current --include-stopped-packages` und die explizite Komponente; kein impliziter Broadcast.

Akzeptiere die Quittung nur, wenn genau eine Zeile `Broadcast completed: result=..., data="..."` vorliegt und die Daten das Schema `hans.setup-handoff.ack.v1`, Protokoll `1`, dieselbe UUID, denselben Grund, einen erlaubten Status und einen SHA-256 über die fünf mit Zeilenumbruch verbundenen Felder Schema, Protokoll, UUID, Grund und Status enthalten. Positive Status benötigen Resultcode `-1`; negative Status `0`. Nur ein positiver, digest-geprüfter und exakt gebundener Status bedeutet `accepted` mit `ackValidated=true`. Jede fehlende, doppelte, fremde oder ungültige Quittung ist `manual_required`, niemals Erfolg.

Erst nach validierter Quittung starte sichtbar `ai.hans.standard/.LauncherActivity` mit dem öffentlichen HOME-Intent. Setze Hans nicht per ADB als HOME-App und erteile keine Android-Berechtigung per Shell.

Melde getrennt:

1. vom Computer verifiziert: Gerät, exakte APK, Installation und Paketversion;
2. vom Telefon noch zu bestätigen: Login, HOME-Auswahl und Android-Berechtigungen;
3. nicht geprüft oder nicht aktiviert: alles, wofür kein frischer wirksamer Nachweis vorliegt.

## 9. Übergib an Hans auf dem Telefon

Hans übernimmt danach sichtbar die Anmeldung und das turn-basierte Geräte-Setup. Der Nutzer bestätigt jeden Android-Dialog selbst. Ab Android 13 kann Android für Accessibility oder Benachrichtigungszugriff zusätzlich „Eingeschränkte Einstellungen zulassen“ in der App-Info verlangen; öffne höchstens die öffentliche App-Info, aber tippe oder bestätige diese Wahl nie selbst.

Wenn Hans bereits installiert ist und nur aktualisiert wurde, bleiben App-Daten und Codex-Login erhalten. Wenn die Einrichtung nicht automatisch erscheint, bitte den Nutzer, Hans einmal normal zu öffnen und unter „Einrichtung & Gedächtnis“ auf „Setup starten“ zu tippen. Installiere deswegen nicht erneut.

## Reparatur- und Stoppregeln

- Bei einem Installationsfehler bleibt der aktuelle Paketstand unangetastet; keine automatische Wiederholung oder Deinstallation.
- Bei niedrigerer angebotener Version keinen Downgrade erzwingen.
- Bei Signaturkonflikt, unbekanntem Paketstatus, mehreren Geräten oder geänderten Artefaktdaten stoppen und neu vorprüfen.
- Eine spätere Reparatur ist höchstens ein erneut bestätigtes `install -r` derselben oder einer höheren, versiegelten Version.
- Behaupte niemals Rootzugriff oder eine Android-Fähigkeit, die Hans nicht frisch als wirksam bestätigt hat.

Am Ende fasse knapp zusammen, was wirklich verifiziert wurde und welcher eine sichtbare Schritt jetzt auf dem Telefon folgt.