CyanogenMod 4.1.9x/4.2.x - Sammelthread

[florian]

Hallo ich habe zurzeit noch die steinalte Version 4.0.4 vom CyanogenMod auf meinem G1, da ich bisher keine Zeit hatte sie zu updaten. Dies will ich jetzt machen aber ich finde nirgend das RecoveryImage signed-dream_devphone_userdebug-ota-14721.zip Auf der HTC Seite sind keine Downloadlinks mehr.
Wäre schön wenn mir jemand helfen könnte.

 

[Kranki]

Wie sieht das eigentlich aus, kann man Apps problemlos durch einen Decompiler jagen, oder sind die Apps "verschlüsselt"?

Naja, sie sind nicht verschlüsselt, aber sie sind Dalvik-Bytecode - erstmal einen Decompiler haben. Bisher gibt es AXMLPrinter2.jar für XML-Dateien und Baksmali für den Programmcode. Letzteren kann man sogar ändern und mit Smali wieder zusammensetzen. Baksmali ist allerdings kein Decompiler sondern ein Disassembler, damit was anzufangen ist dann wieder ganz was anderes.

 

[Denowa]

Hallo ich habe zurzeit noch die steinalte Version 4.0.4 vom CyanogenMod auf meinem G1, da ich bisher keine Zeit hatte sie zu updaten. Dies will ich jetzt machen aber ich finde nirgend das RecoveryImage signed-dream_devphone_userdebug-ota-14721.zip Auf der HTC Seite sind keine Downloadlinks mehr.
Wäre schön wenn mir jemand helfen könnte.

Oooh man ... bitte Brille auf ...

Nimm das Fullupdate von Kranki ...

https://www.android-hilfe.de/forum/...1/cyanogenmod-full-updates-4-2-15-1.8791.html

 

[Kranki]

Hallo ich habe zurzeit noch die steinalte Version 4.0.4 vom CyanogenMod auf meinem G1, da ich bisher keine Zeit hatte sie zu updaten. Dies will ich jetzt machen aber ich finde nirgend das RecoveryImage signed-dream_devphone_userdebug-ota-14721.zip Auf der HTC Seite sind keine Downloadlinks mehr.
Wäre schön wenn mir jemand helfen könnte.

http://dl.dropbox.com/u/2992789/signed-dream_devphone_userdebug-ota-14721.zip

 

[dazw]

Naja, sie sind nicht verschlüsselt, aber sie sind Dalvik-Bytecode - erstmal einen Decompiler haben. Bisher gibt es AXMLPrinter2.jar für XML-Dateien und Baksmali für den Programmcode. Letzteren kann man sogar ändern und mit Smali wieder zusammensetzen. Baksmali ist allerdings kein Decompiler sondern ein Disassembler, damit was anzufangen ist dann wieder ganz was anderes.

Ich habe gerade mal ein wenig gegoogelt.
Mark Schönefeld hat auf einer Konferenz dieses Jahr eine Methode vorgestellt, um Dalvik-Bytecode in Java-Code umzuwandeln.

http://2009.confidence.org.pl/mater...choenefeld_reconstructing_confidence_2009.pdf

Sein fertiges Programm hat er "undx" gekannt und unter der GPL veröffentlich. Undx, a tool to reconstruct dalvik applications

Da ich gerade auf der Arbeit bin und kein Android-SDK hier habe, kann ich es leider nicht testen. Vielleicht komme ich heute Abend dazu, oder Du schaust es Dir mal an.

Die Handhabe ist recht einfach und "java -jar undx.jar classes.dex" sollte schon ein Ergebnis liefern. So jedenfalls in der Theorie

So könnte man den Wecker (oder ein anderes App mit Datumsstring) mal decompilen und sich den Code anschauen. Vielleicht hilft es ja

 

[Kranki]

So könnte man den Wecker (oder ein anderes App mit Datumsstring) mal decompilen und sich den Code anschauen. Vielleicht hilft es ja

Kann ich auch so, ich hab den Source vom Wecker ja. Was ich wissen möchte ist, wo java.text.DateFormatSymbols liegt und wie das funktioniert.

 

[dazw]

Kann ich auch so, ich hab den Source vom Wecker ja. Was ich wissen möchte ist, wo java.text.DateFormatSymbols liegt und wie das funktioniert.

In Java 6 liegt das im "rt.jar" im Pfad "java.txt.DateFormatSymbols".
Das gibt es btw auch erst seit Java 6

Laut der API besorgt man sich die Instanz über

public static final DateFormatSymbols getInstance(Locale locale);

wobei für unseren Fall "Locale" so instanziiert werden müsste: new Locale (Locale.GERMAN)

Locale kann natürlich auch übergeben, bzw global gehalten werden und dann dementsprechen rangezogen werden.
Musst mal schauen, wie der Konstruktor vom Wecker geht bzw was der sich beim Start so alles nachlädt.

 

[Kranki]

In Java 6 liegt das im "rt.jar" im Pfad "java.txt.DateFormatSymbols".
Das gibt es btw auch erst seit Java 6

Für den Kompiliervorgang des Android-Grundsystems ist laut Google Java 5 erforderlich, mit dem Ubuntu beiliegenden OpenJDK 6 hats auch gleich nicht geklappt. (Was ganz toll war, weil es für das neueste Ubuntu kein Java 5 mehr gibt, und ich langwierig manuell die Pakete der Vorversion suchen musste.)

Ich bin auch ziemlich sicher, dass im Wecker alles richtig läuft.
Das ist der Code, mit dem der String generiert wird, der anzeigt, wann der Wecker wiederholt wird:

/* short or long form? */
            DateFormatSymbols dfs = new DateFormatSymbols();
            String[] dayList = (dayCount > 1) ?
                                    dfs.getShortWeekdays() :
                                    dfs.getWeekdays();

            /* selected days */
            for (int i = 0; i < 7; i++) {
                if ((mDays & (1 << i)) != 0) {
                    ret.append(dayList[DAY_MAP[i]]);
                    dayCount -= 1;
                    if (dayCount > 0) ret.append(
                            context.getText(R.string.day_concat));
                }
            }

Laut Java API wird ohne Angabe einer bestimmten Locale die Standard-Locale benutzt, was die des Systems sein sollte. Sieht für mich richtig aus.
Ich bau da jetzt mal hardcoded auf deutsch, und guck, was passiert.

 

[dazw]

Für den Kompiliervorgang des Android-Grundsystems ist laut Google Java 5 erforderlich, mit dem Ubuntu beiliegenden OpenJDK 6 hats auch gleich nicht geklappt. (Was ganz toll war, weil es für das neueste Ubuntu kein Java 5 mehr gibt, und ich langwierig manuell die Pakete der Vorversion suchen musste.)

Ich bin auch ziemlich sicher, dass im Wecker alles richtig läuft.
Das ist der Code, mit dem der String generiert wird, der anzeigt, wann der Wecker wiederholt wird:

/* short or long form? */
            DateFormatSymbols dfs = new DateFormatSymbols();
            String[] dayList = (dayCount > 1) ?
                                    dfs.getShortWeekdays() :
                                    dfs.getWeekdays();

            /* selected days */
            for (int i = 0; i < 7; i++) {
                if ((mDays & (1 << i)) != 0) {
                    ret.append(dayList[DAY_MAP[i]]);
                    dayCount -= 1;
                    if (dayCount > 0) ret.append(
                            context.getText(R.string.day_concat));
                }
            }

Laut Java API wird ohne Angabe einer bestimmten Locale die Standard-Locale benutzt, was die des Systems sein sollte. Sieht für mich richtig aus.
Ich bau da jetzt mal hardcoded auf deutsch, und guck, was passiert.

Du hast natürlich Recht, DateFormatSymbols gibt es schon länger. Ich habe mich verschaut, DateFormatSymbols.getInstance() ist mit 1.6 neu dazugekommen

Hast Du es mittlerweile getestet, ob es hardcoded auf deutsch funktioniert?
Wenn ja, dann ist es wirklich eine Systemvariable (ka, ob es die bei Linux in der Form gibt) bzw. die Java-Systemproperties liefern den falschen Wert.

Log im WeckerApp mal die user.language "System.getProperty("user.language");" während der Laufzeit.
Oder log alle Properties.

Ich weiß nicht genau, ob die 2. for-Schleife bei 1.5 funktioniert, deshalb zwei Lösungen

	public static void main(String args[]){
		Properties properties = System.getProperties();
		
		Object[] keyArray = properties.keySet().toArray();

		for(int i = 0; i < keyArray.length; i++){
			System.out.println(keyArray[i] + " : " + properties.getProperty((String) keyArray[i]));
		}
		
		for(Object key : keyArray){
			System.out.println(key + " : " + properties.getProperty((String) key));
		}
	}

 

[dazw]

@Kranki:

Wie sieht es aus an der Front?

 

[CMcRae]

kann mir einer mal sagen was dwang ist??? sowas wie cyanogen?? oder besser??

lese das ständig bei den themes forum im xda....

 

[brotbuexe]

Dwang: xda-developers
also schon "sowas" wie cyanogen.

 

[trautna]

Dwang, der nachfolger von cyanogen oder was??
Schon ehrfahrung damit gemacht??

 

[xxcrashxx2]

Hi

ich hab nen Riesenproblem.
Ich habe nach der Anleitung auf die cm-4.2.7.1-signed geupdatet und jetzt ist der Bildschirm dunkel und keine Taste geht mehr.

Kann mir einer helfen?? Plz help

cu

 

[dazw]

Hi

ich hab nen Riesenproblem.
Ich habe nach der Anleitung auf die cm-4.2.7.1-signed geupdatet und jetzt ist der Bildschirm dunkel und keine Taste geht mehr.

Kann mir einer helfen?? Plz help

cu

Was heißt, "keine Taste geht mehr"?
Geht das Gerät noch an, oder kannst Du es noch nicht mal mehr anschalten?

 

[xxcrashxx2]

Hi

ja an geht es, es kommt das große G1 Logo und dadrunter T-mobile. Dann kommt der Androidschriftzug und dann geht der weg und dann bleibt alles dunkel. Dann reagiert keine Taste mehr nur noch Akku raus nehmen bringt was

 

[dazw]

Mal mal nen Wipe und lösch den Dalvik-Cache.

 

[xxcrashxx2]

Hi

also im Menü zum Flashen (On + Home) habe ich gelöscht vorher.

den Dalvik-Cache./QUOTE]

kannst du mir das mal erklären?

cu

 

[dazw]

Hi

also im Menü zum Flashen (On + Home) habe ich gelöscht vorher.

den Dalvik-Cache.

kannst du mir das mal erklären?

cu

Welche Recovery hast Du drauf?
Im RA-Dream 1.4.0 hast Du die Möglichkeit neben einem Factory-Reset auch explizit den Dalvik-Cache im Handy und auf der SD zu löschen.
https://www.android-hilfe.de/forum/...covery-14-nov-2009-ra-dream-v1-5-2.10115.html

Der Dalvik-Cache beinhaltet die kompilierten Versionen Deiner installierten Apps. Wenn Deine SD nicht jungfräulich ist, kann es zu Problemen kommen, weil die Apps noch für die vorherige Version kompiliert wurden. (salopp gesprochen).

 

[xxcrashxx2]

Hi

erstmal danke für deine Infos. Problem ist ich habe den G1 gebraucht gekauft und ich weiß leider nicht was genau drauf ist. Kann man das irgendwie auslesen?

Kann man nicht das ganze Phone platt machen und alles neu einspielen?

cu