Beiträge von San Blarnoi

Zitat

Das sind jetzt 90x90 statt 94x94. Macht das was?

Das ist eine Frage des Anspruches; ich kann den Hintergrund erklären, bewerten dürft ihr den Sachverhalt dann selber:
Die genannten Größen sind Googles Vorgaben;
Die Darstellung an den verschiedenen Stellen (Launcher, Einstellugen/Apps etc) wird von diesen Größen ausgehen und zu kleine Icons entsprechend vergrößern;
dazu wird wahrscheinlich nicht der superduper HiTech Algorithmus verwendet, sondern einer der schnell fertig wird
Die Folge der Nichtbeachtung kann also Unschärfe in der Darstellung des Icons sein, während vielleicht alle anderen Icons drum herum gestochen scharf dargestellt werden.
Bei 90 -> 96 wird man das vermutlich mit bloßem Auge eher nicht sehen, Mi3 und M7 zB verwenden jedoch xxhdpi (144x144), und da wird man den Unterschied dann wohl erkennen.

Zur Auswahl der Icons: Fleissig, fleissig

Da die App ja von der Community für die Community sein soll, ist es nicht primär relevant, ob mir das Icon gefällt, ich würde den Kandidaten in die App übernehmen, der euch am besten gefällt.
Mir ganz persönlich gefällt das flache Design mit den frischen Farben besser.

Vielleicht sollte in diesem speziellen Fall auch beachtet werden, welche Icon sich besser in den Stil der MIUI Apps einfügt (daher die Frage nach der Transparenz, die ja dann die abgerundeten Ecken erzeugen würde)

Zitat

Entschuldigung, mit großem I und Leerzeichen "MI 2SC"

OK, hab ich korrigiert.

Zitat

Wie gefällt das Icon?

Finde ich auch gut, ist aussagekräftiger als das andere; der Hintergrund (alles außerhalb des silbernen Rahmens) wird dann noch transparent gemacht?

Die benötigten Größen habe ich ja oben schon genannt

An die werten Mitleser: das blaue oder das schwarze Icon?

olrb:

Zitat

Wäre sowas als icon in Ordnung? Ist recht schlicht.

Also mir gefällts - selber gemacht?
Was meinen die anderen?

Zitat

Bei diesem sind auch jede Woche die Updates über die standart MIUI Updater App via OTA
verfügbar. Vielleicht hilft es diese Rom mal genauer anzugucken um eventuell was ab zu gucken?

Wie ich es verstanden habe, funktioniert der Updater im deutschen ROM ebenfalls, jedoch nur mit dem Server in China.
<edit>
Die deutschen ROMs könnten da wohl ebenfalls gehosted werden, das würde jedoch für erhebliche Verzögerungen bei unseren Updates sorgen.
Der Updater verschickt übrigens bei jeder Update-Suche u.a. deine Telefon-ID und deine IMEI unverschlüsselt nach China - willst du den jetzt immer noch benutzen?

Der Updater ist closed source und die Antworten des Servers kommen in einem undokumentierten Binärformat, der ist also nicht ohne weiteres so anpassbar, das er die Updates vonmiui-germany.de bezieht.
</edit>

SamSoul
Das Logo wäre auch OK, allerdings verwendest du da das Foren-Logo, das du vermutlich nicht selber gemacht hast?
Da bräuchten wir dann also nach wie vor das Einverständnis des Urhebers

"Mi2SC": genau so ,also mit kleinem "i" und ohne Leerzeichen?
Bei mir steht "MI 3W", daher die Frage.

Zitat

Würde helfen, wenn man das betroffene Gerät angibt.

Steht in seiner Überschrift und in seinem Profil

Aktueller Stand der Dinge:

Nachdem wir mit "Plan A" offenbar nicht weiter kommen, habe ich die App auf "Plan B" umgestellt:
- das Update wird als "update.zip" heruntergeladen (und dazu eine .info Datei erstellt)
- nach dem Download kann die App ins Recovery booten, wo der Benutzer dann das update.zip mit wenigen Handgriffen "manuell" installiert
- bei jedem Start prüft die App, ob eine .info Datei existiert, ob die zur update.zip passt und benennt die udate.zip entsprechend um, damit die verschiedenen Updates sich nicht gegenseitig überschreiben und so die Möglichkeit bestehen bleibt, zur Not die Vorgängerversion wieder zu installieren

Das Ermitteln der aktuellen Version habe ich mittlerweile ohne Mithilfe des Seitenbetreibers implementiert; das funktioniert, solange das Benennungschema der Downloads nicht geändert wird.

Beim Start der App wird automatisch gesucht, für manuelles erneutes Suchen (etwas weil das Gerät beim Start noch nicht online war) wurde ein entsprechender Button ergänzt.

Wenn hier jemand die App verwenden möchte, der KEIN Mi3 verwendet, dann darf er hier gerne die Zeichenfolge nennen, die er unter Systemeinstellungen/Über das Telefon/Modellnummer findet; wenn sich das zugehörige Gerät auf der Downloadseite wieder findet, werde ich dann Support dafür in der App ergänzen.
(Mi3 Besitzer dürfen sich natürlich auch gerne melden, damit ich abschätzen kann, wie groß das Interesse an der App ist)

Falls sich jemand mit einem Icon für die App beteiligen möchte (ich bin kein Künstler): optimal wären .png in den Größen
- 144x144 (xxhdpi)
- 96x96 (xhdpi)
- 72x72 (hdpi)
- 48x48 (mdpi)
- ldpi können wir uns wohl sparen

Den aktuellen Stand seht ihr im Anhang.
BTW: vor einer Veröffentlichung bräuchte ich dann noch das Einverständnis des Urhebers vom "MIUI Germany" Logo (das im Updater verwendet wird) - der wird hier vermutlich mitlesen?

Um das auch endlich mal von meiner Liste streichen zu können:
Android verwendet ja die im Betreff genannten Ordner auf dem externen Speicher, um Apps (und Benutzern) eine einfache Möglichkeit zu bieten, akustische Feedbacks zu ergänzen.

Mein Mi3 zeigt die dort gelagerten Dateien jedoch nicht in der Auswahl an.
Muss ich da noch was einstellen?
Ist das seitens MIUI so beabsichtigt? (warum?)
Kann jemand eine App empfehlen, mit der die dort abgelegten Dateien wieder verwendbar werden?

Nachtrag: bevor das Mecker gibt - den hier [Mi-3 Frage] Klingelton welche Ordner? hab ich natürlich gesehen, aber wenn ich für eine solche Aktion erst die Einstellungen meines Musik-Players ändern muss, dann kann man das kaum als benutzerfreundlich bezeichnen, daher die erneute Frage, vielleicht gibt es ja mittlerweile eine "ordentliche" Lösung

Lösung: Ordner /sdcard/MIUI/ringtone anlegen, Sounds dort hineinkopieren (mindestens .flac, .ogg, .mp3 werden unterstützt), diese Sounds sind anschließend als Klingelton/Benachrichtigung/Alarm auswählbar

Zitat

Update auf 4.7.4 via Update App.
Probleme mir der Musikwiedergabe mit Pistons.

Mit meinen Beats funktioniert die Musik problemlos - aber: wenn ich die Kopfhörer anstecke, dann poppt ein Menü auf, in dem in der letzten Version noch ausgewählt werden konnte, ob das ein Kopfhörer oder ein MiKey ist; jetzt kommt da irgendwas chinesisches, und egal was ich auswähle, die Musi spielt (wie es auch sein sollte).

Ist da eine Übersetzung verloren gegangen?

Nachtrag: die komplette MiKey App (V1.6.1) ist in chinesisch gehalten, wahrscheinlich hängen diese beiden Dinge direkt zusammen.

Zitat von ARIELs

Der Auslöseton beim Foto machen ist kaum zu hören bei 4.7.4. Bei 4.6.20 war alles normal. Von 4.6.20 auf 4.7.4 per Update App, MI3.
Google und MIUI scheinen nicht die besten Freunde zu sein...

Hm, bei mir hört er sich normal an (6.20 -> 6.27 -> 7.4 per Update App)

Mquadrat:

Zitat

function: verify_file() //Welche sonst?

Da hätte ich folgende Einwände:

1. In Zeile 74 steht ein LOGI(), wenn die Funktion bis dort ausgeführt worden wäre, dann würden wir das im Log sehen;
vorher bricht sie ab, wenn
- die Datei nicht geöffnet werden kann (dann wäre der Vorgang schon vorher abgebrochen worden)
- die Datei kleiner als FOOTER_SIZE ist, der seek() also fehlschlägt (da die Datei > 6 Bytes ist, müsste sie defekt sein)
- das Lesen des Datenblocks (footer) aus der Datei fehlschlägt (defekte Datei)
- der vermutete Footer kein Footer ist (dann würde der Test auch beim Updater bzw. manueller Installation aus dem Recovery fehlschlagen)
Also alles Gründe, die bei einer funktionierenden .zip (und ohne Hardware-Defekte) nicht auftreten können.

2. Weder "Verifying update package…" noch "I:verify_file returned 1" kommen im recovery-master irgendwo vor, was wohl bedeutet, das der fehlschlagende Test in einem externen Binary stattfindet.

3. Der einzige Aufruf der genannten Funktion findet anscheinend in einem Testprogramm statt (verifier_test.c, Funktion main())

@andy25:

Zitat

Alle MI-Geräte bist auf das HongMi 1 erwarten Testkeys

Genau, solange man die erprobten/üblichen Wege der Installation verwendet;
nachdem das recovery von Googles Original abgeleitet ist, wäre es nicht denkbar, das der Autoinstall-Code mangels Bedarf nie an MIUI angepasst wurde und darum keine Ahnung von den "Testkeys" hat?

Zitat

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?

Zitat

Aufgabe: Hash-Algorithmus finden, verstehen, anpassen.

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

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.

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.

...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.

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?

Das hier:

Caused by: java.lang.NullPointerException
	at java.lang.String.<init>(String.java:141)
	at com.android.updater.tasks.c.a(BaseChecker.java:221)
	at com.android.updater.tasks.c.a(BaseChecker.java:185)
	at com.android.updater.tasks.c.a(BaseChecker.java:101)
	at com.android.updater.tasks.c.a(BaseChecker.java:80)
	at com.android.updater.tasks.UpdateChecker.pt(UpdateChecker.java:153)
	at com.android.updater.S.doInBackground(UpdaterBackgroundService.java:763)
	at com.android.updater.S.doInBackground(UpdaterBackgroundService.java:759)

bekomme ich zusammen mit "updater wurde beendet" gefühlt jedesmal, wenn ich das Mi3 online schalte.

Nachdem der Absturz mit einem String-Problem zu tun hat dachte ich, das könnte vielleicht mit euren Übersetzungen zu tun haben.

Derzeit läuft bei mir die .7.4, mit der .6.27, und der .6.20 war das aber auch schon so.

Zitat

Interesse besteht.

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

Zitat

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.

Zitat

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.

So, endlich Zeit für einen neuen Test gehabt:
scheint jetzt tatsächlich besser zu sein, ich hatte im Testzeitraum (einige Minuten) nur 2 oder 3 Aussetzer ganz links unten.

Interessant: Vergleichstest mit einem Stift ergab überhaupt keine Aussetzer, liegt dann wohl an meinen Fingern
(allerdings hatte ich schon ziemlich viele Smartphones und sowas ist mir bislang noch niemals aufgefallen)
Egal, wenn es so bleibt, dann kann ich damit leben.

Danke nochmal an alle Helfer

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

... dann muss man sich halt selber einen basteln

Vorhin hatte ich ein Stündchen Zeit, dabei ist das hier herausgekommen:
[Blockierte Grafik: 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

Zitat

mach einfach mal ne Kalibrierung,

Schreck in der Abendstunde...
1. Versuch: Failed, please retry
2. Versuch: Success - aber anschließendes Test Touchscreen ließ den Screen praktisch gar nicht mehr reagieren
Also mit viel Mühe versucht, erneut in die Kalibration zu gelangen (blöd, wenn man den Button nicht drücken kann), nochmal kalibriert, und diesmal funktionierte das Linien malen soweit wieder normal.
Ob es jetzt besser ist als vorher muss ich noch verifizieren, wollte erstmal Feedback geben.


Was hätte ich machen können, wenn der Screen nach 2. tatsächlich nicht mehr reagiert hätte?
Full reset? Oder wegschmeissen?