Wenn der mitgelieferte Updater nicht funktioniert...

... dann muss man sich halt selber einen basteln

Vorhin hatte ich ein Stündchen Zeit, dabei ist das hier herausgekommen:
[Blocked Image: https://drive.google.com/file/d/0Bw-uKAR6CDhHdnRXUExpZlR5TEU/edit?usp=sharing]
Hm, an dieser Stelle wollte ich eigentlich einen Screen einbetten, das scheint aber nicht zu funktionieren...

Müsst ihr bei Interesse also den Link manuell verfolgen.

Im ersten Absatz wird geprüft, ob Gerät/System/Onlinestatus für ein Update überhaupt geeignet ist.

Im zweiten Absatz käme der Seitenbetreiber ins Spiel, die App muss ja irgendwie herausfinden, welche Version aktuell auf der Seite zum Download angeboten wird.
Da das mit dem mitgelieferten Updater früher mal funktioniert hat, sollte die Infrastruktur dafür aber eigentlich bereits vorhanden sein und ich bräuchte nur eine Doku

Die App würde die entsprechende .zip Datei dann herunterladen (als update.zip) und in der minimalversion anschließend bei Klick auf entsprechenden Button ins revoery booten, wo mandann nur noch "install update.zip" auswählt und dann fertig ist.
Allerdings besteht noch die Chance, das auch dies automatisch erledigt werden kann, offenbar kann man Kommandos ans recovery übergeben (an alle? welche?), und wenn ich dazu eine Doku auftreiben kann, dann würde der Vorgang vereinfacht zu: man drückt den Knopf, das Gerät bootet, installiert und startet dann mit der neusten Version
Beim Auftreiben der (englischen) Dokus nehme ich gerne Hilfe an

Die fertige App würde ich hier selbstverständlich kostenlos zum Download bereitstellen.

Fragen also:
1. Besteht daran seitens der Mitleser überhaupt Interesse?
2. Besteht seitens des Forenbetreibers Interesse? Ohne den (bzw. die Bereitstellung der Versionsdaten) müsste ein Interpeter für die Downloadseite her, und das wäre mir im Moment zu aufwendig)
3. Als "normale" App werden beim Klick auf "reboot" root Rechte angefordert; da das sicher einige abgeschaltet haben, könnte das problematisch sein - bei meinem Test erschien eine entsprechende Box mit OK/Abbruch, bei OK passierte aber nix.
Daher wäre es vielleicht sinnvoll, die App nach Fertigstellung ins ROM aufzunehmen, wodurch bestimmt die Möglichkeit eröffnet wird, das sie automatisch root Rechte hat und den Anwender nicht belästigt.
In diesem Fall würde ich selbstverständlich den Sourcecode zur Verfügung stellen damit zweifelsfrei verifiziert werden kann, das mit der App alles seine Ordnung hat.

...und jetzt kommt ihr

Mit andy hatte ich letzte Tage schon wegen einer ähnlichen Thematik Kontakt, auf meinen Konzeptvorschlag hat er sich dann aber nicht mehr gemeldet - was immer das bedeuten mag

Gibt auch schon ein Update zum recovery: wenn unsere Version auf der von Android beruht (da habe ich gerade in den Source geschaut), dann kann die Installation des Update vollständig automatisiert werden

Damit wären wir dem vorinstallierten Updater dann funktional ebenbürtig - nur das unserer tatsächlich funktioniert

Quote

Interesse besteht.

Prima, ich hatte schon angefangen über Plan-B nachzudenken

Quote

Hier ist die Source vom Mi-Recovery

Danke, und ja, der ist unzweifelhaft von Googles Code "abgeleitet", d.h. wenn die Entwickler es nicht irgendwo im Detail verbockt haben, dann bekommen wir eine vollautomatische Installation hin.
Allerdings gehe ich davon aus, das der vorinstallierte Updater bei der Installation ebenfalls so vorgeht, daher bin ich recht zuversichtlich.

Quote

Doku über die Infrastruktur werde ich dir die Tage zukommen lassen

OK.

Wäre das neu zu machen, dann wäre das hier mein Plan gewesen:
- App ermittelt Gerätenamen vom System (Beispiel: "MI 3W")
- App übermittelt diesen per URL an diese Seite, etwa "http://miui-germany.de/version.php?MI-3W"
- Server liefert aktuell bereitstehende Versionsnummer als Antwort ("4.6.27"), oder einen leeren String, falls das Gerät nicht supportet wird
- App vergleicht diesen Wert mit der vom System erfragten Versionsnummer
- App fordert ggf Download vom Server an, etwa "http://miui-germany.de/download.php?MI-3W"
- Server liefert die .zip als Antwort

So könnten wir das ganze leicht auf alle unterstützten Geräte ans Laufen bekommen, und es bräuchte kein Update, wenn neue Geräte hinzukommen.

Aber wenn ihr schon was fertiges habt, dann lass uns das erstmal anschauen, wäre ja weniger Arbeit für euch.

Zwischenbericht FirmwareUpdate App:

- die üblichen Tests sind alle implementiert
-- MIUI installiert
-- Device wird unterstützt
-- Gerät ist online (WLAN oder nach Bestätigung des Anwenders auch Funkturm)
-- Akku > 50% oder ladend
- Download funktioniert
-- derzeit mit der Plan-B Methode (download-v5.php?device=16)
-- Portrait, Screen-Lock
- Reboot ins Recovery funktioniert (root)
- Recovery erkennt, das ein Update installiert werden soll (laut Logfile)

Leider wird die Installation dann aber nicht durchgeführt...
Stattdessen erscheint das übliche Menü, im Hintergrund kann man das Android-Männchen zusammen mit einem Dreieck erkennen;
Jedoch werden keine Hinweise geliefert, warum die Installation fehlschlug, was vermutlich daran liegt:

"can't open /dev/tty0: No such file or directory"

Der relevante Ausschnitt aus dem Log:

...
I:Update location: /sdcard/MIUI-GER-MI-3W-4.7.4.zip
I:Saving locale "de_DE"
void ScreenRecoveryUI::draw_screenview_locked(screenview*): scr->child_count=0
virtual void ScreenRecoveryUI::StartGraphicMenu(const char*, int): menu id <menu_choose_language>
...

Im Source des MI-Recovery sind wir also hier:

static int really_install_package(const char *path, int* wipe_cache)
{
    ui_set_background(BACKGROUND_ICON_INSTALLING);		// 1
    ui_print("Finding update package...\n");			// 2
    ui_show_indeterminate_progress();
    LOGI("Update location: %s\n", path);			// 3




    if (ensure_path_mounted(path) != 0) {
        LOGE("Can't mount %s\n", path);				// 4
        return INSTALL_CORRUPT;
    }




    ui_print("Opening update package...\n");




	...

1: zeichnet wohl das Android-Männchen (nicht überprüft)
2: nirgends zu sehen (ui_print ist ein define für printf(), was wohl auf /dev/tty0 ausgeben möchte und damit obige Fehlermeldung verursacht)
3: Die Ausgabe im Log (LOGI ist ein define für fprintf(stdout) und stdout wird via freopen() aufs Logfile umgelenkt)
4: schlauerweise ist LOGE ein define für ui_print, siehe 2:

Mit anderen Worten kann ich ohne selber gebasteltes Recovery nicht herausfinden, was das Problem bei der Installation ist :-/
- das /sdcard nicht gemounted ist, halte ich nicht für wahrscheinlich, da ich ein "/sdcard/update.zip" manuell im Recovery installieren könnte
- das mit dem .zip etwas nicht stimmt ist ebenfalls unwahrscheinlich, denn via Updater verlief die Installation problemlos

Hier sind also die Flash-Erfahrenen Mitleser gefragt:
was könnte da schief gehen bzw. was kann ich tun um das Problem einzugrenzen?

...und noch ein Update...

Es scheint so zu sein, das "/sdcard" erst gemounted wird, wenn man im Recovery "install update.zip" wählt;
also habe ich meinen Code so erweitert, das die heruntergeladene Datei zunächst in die /cache Partition kopiert wird, die muss ja zugänglich sein, weil da auch die Kommandosequenz hinterlegt wird.

Tatsächlich ergibt sich daraus auch ein geändertes Log: (Zeilen beginnend mit "--" sind von mir als Kommentar eingefügt worden)

-- Datei liegt nicht mehr auf /sdcard, sondern auf /cache
I:Update location: /cache/u.zip
-- die nächsten 3 Zeilen sind neu und warten auf eine Interpretation
I:read key e=3 hash=20
I:1 key(s) loaded from /res/keys
I:verify_file returned 1
-- ab hier kommt wieder das, was immer im Log steht...
I:Saving locale "de_DE"
void ScreenRecoveryUI::draw_screenview_locked(screenview*): scr->child_count=0
virtual void ScreenRecoveryUI::StartGraphicMenu(const char*, int): menu id <menu_choose_language>

Kann das jemand erklären?

Ich wollte jetzt eigentlich nicht erst zum Kernel-Hacker werden müssen, um diese App fertigstellen zu können, insbesondere vor dem Hintergrund, dass sich das Interesse an einer Lösung hier im Forum ja doch stark in Grenzen hält.

Danke, aber Hilfe beim Programmieren brauche ich eigentlich nicht, eher Hilfe beim Interpretieren der Meldungen...
Ich hätte eigentlich gedacht, das hier viele Flash-Erfahrene unterwegs sind, die mit solchen Meldungen etwas anfangen können, oder gar welche, die vielleicht schon selber an irgendwelchen Custom-ROMs gebastelt haben, aber da habe ich mich wohl geirrt.

Danke für die Beiträge.
Das hat mich zu mehr Recherche motiviert und der Stand ist nun:

Wenn die Log-Ausgaben vom mi-revovery vollständig wären, dann würden sie wohl so aussehen:

Finding update package…
I:Update location: /cache/u.zip
Opening update package…
I:1 key(s) loaded from /res/keys
Verifying update package…
I:verify_file returned 1
E:signature verification failed
Installation aborted.

Die These wäre dann: bei manueller Installation im recovery, und offenbar auch bei Installation mittels "updater" wird demnach ein anderer Key verwendet als bei automatischer Installation via recovery.
Der der Sourcecode vom mi-recovery keine Anzeichen einer Option zum Bestimmen des Keys (oder zum Abschalten des verify) zeigt (genau so wenig wie eine Option zur Bestimmung des Installations-Ziels, also System1 oder System 2), sind wir mMn an dieser Stelle am Ende, es sei denn der Hersteller der ROMs könnte einen passenden Key zum Signieren des .zip verwenden (welcher auch immer das dann sein mag).

Mag jemand diese These widerlegen? Würde mich freuen

Mquadrat: jo, die "hash" Zeile kommt mir auch seltsam vor, keine Ahnung was die bedeuten könnte...
Tatsächlich kommt die nicht mal aus dem Recovery (zumindest nicht aus dem Stand, vom dem ich den Source habe), so das keinerlei Basis für eine Interpretation vorliegt.

Quote

3. Wird ein Hash berechnet. Das Ergebnis wird ausgegeben (Hash == 20)
4. Hier wird eine Datei geladen die erwartete (fixe???) Hashwerte enthält. (in dem Fall sollte der Hash == 3 (e(expected)=3) sein. Aber der Hash der Datei u.zip ergibt 20

Hm, wenn der Hash tatsächlich "falsch" wäre, warum lassen sich die .zip dann via Updater und manuell via recovery installieren?
Weil diese Prüfung dort nicht durchgeführt wird?

Quote

Aufgabe: Hash-Algorithmus finden, verstehen, anpassen.

Das wäre dann die Aufgabe des ROM-Erstellers, oder wie meinst du das jetzt?