editieren der build.prop

  • 75 Antworten
  • Neuester Beitrag
Diskutiere editieren der build.prop im Root / Hacking / Modding für Samsung Galaxy Note im Bereich Samsung Galaxy Note (N7000) Forum.
M

meier2009

Dauergast
Was willst denn da warum ändern?

Gesendet von meinem GT-N7000 mit Tapatalk 2
 
frank_m

frank_m

Ehrenmitglied
Wie ich hier auch schon öfter beschrieben habe: Die build.prop benötigt spezifische Dateirechte. Wenn man sie auf einem PC zwischenspeichert, gehen die verloren. Die Datei zurückzuschieben reicht also nicht, man muss danach noch die Rechte wieder korrigieren, bevor man das Gerät rebootet.

Der ursprüngliche Beitrag von 20:52 Uhr wurde um 21:05 Uhr ergänzt:

Und was soll der Unsinn mit dem Crossposting? Versucht es doch gar nicht erst, ich finde es ja doch und fasse die Threads zusammen.
 
R

raymann

Erfahrenes Mitglied
Dadurch hätte ich dann eine andere DeviceID?
 
The-Error

The-Error

Neues Mitglied
nicht unbedingt. wenn du titanium backup drauf hattest und ein backup auf der ext SD ist, kannst die orginale wieder herstellen
 
R

raymann

Erfahrenes Mitglied
Ja aber ich hätt vorerst für eine kurze Zeit eine andere DeviceID?
 
The-Error

The-Error

Neues Mitglied
versteh dein problem nicht?
 
R

raymann

Erfahrenes Mitglied
Na das ich einfach nur wissen will wie ich meine DeviceID ändere, da hast du mir die Anleitunge gepostet, jetzt wollte ich einfach nur wissen ob ich, wenn ich nach dieser Anleitunjg vorgehe dann eine andere DeviceID habe?!
 
M

meier2009

Dauergast
Tb , linke Taste, runter scrollen, android id verwalten, zufällige id generieren



Gesendet von meinem GT-N7000 mit Tapatalk 2
 
Zuletzt bearbeitet:
R

raymann

Erfahrenes Mitglied
Danke aber mir geht's um die Device id nicht die Android id

Gesendet von meinem GT-N7000 mit der Android-Hilfe.de App
 
T

tilmsch

Neues Mitglied
Hallo,
ich habe auf meinem neuen Note gestern root-Rechte geholt und wollte anschliessend mit "LCD Density Modder" die Bildschirmaufloesung optimieren. Nach dem Reboot blieb das Note im Bootbildschirm haengen. Habe dann vom Recoverymenue einen Reset auf Werkseinstellungen gemacht. Das hat allerdings nichts gebracht. Ich war so schlau, vorher keinerlei Daten (ProductionCode/ IMEI,...) zu notieren (bin halte Anfaenger und habe erst gehandelt und dann gelesen...)
Meine Fragen:
- gibt es Moeglichkeiten, um ohne Firmwareflashen das Geraet zu retten?
- falls nicht, wie kann ich die richtige Firmware identifizieren, ohne die o.g. Daten zu haben?

Vorab Danke fuer Eure Hilfe!
Til
 
frank_m

frank_m

Ehrenmitglied
War der USB Debug Modus an zum Zeitpunkt der Modifikation? Dann könntest du evtl. über ADB im Recovery Modus Zugriff auf die build.prop erhalten. Aber auch das ist nicht trivial. Deshalb kümmern wir uns darum erst, wenn die Voraussetzungen definitiv erfüllt sind.

Wenn es über das Recovery nicht geht, dann hilft nur Flashen. Dafür müssen wir aber mindestens den ProductCode des Gerätes wissen.
 
T

tilmsch

Neues Mitglied
Hallo,
erst mal vielen Dank für die Antwort.
Ich habe jetzt mal weitergeforscht:
bekannt ist: csc-code (AT0), seriennummer des Geraets, SSN (N7000GSMH), Han (Gt-N7000ZBADBT), FCC-ID und IMEI. Kann man da irgendwie auf den ProductCode rueckschliessen? Oder kann das die Samsung-Hotline?
Ausserdem habe ich mit "adb get-seriealno" eine Seriennummer ausgeben lassen, die allerdings voellig anders ist, als die, die hinten im Gerät steht (ist das hex-Darstellung oder so?). Bedeutet letzteres, dass ich ggf. die Moeglichkeit habe, die buildt.prop auszulesen?

Til
 
Zuletzt bearbeitet:
S

spsnote

Neues Mitglied
Hallo,

Wahrscheinlich hat das Programm zum ändern der Dpi die Zugriffsrechte der build.prop verändert.
Das führt, warum auch immer, dazu das das Note beim booten hängen bleibt.
Ich hatte das bisher immer wenn ich vergessen hatte nach manuellen editieren die Rechte wieder auf rw-r--r-- zu setzen.
Im Normalfall sollte ein neuflashen der Firmware das Problem beheben.

Gesendet von meinem XT910 mit der Android-Hilfe.de App
 
fragi

fragi

Dauergast
Also wenn du den Produktcode hast, dann weißt du ja eigentlich, welche Firmware auf das Gerät gehört. Kommst du denn in den Download Modus? Dann solltest du eigentlich das passende Stock Rom via Odin flashen können. Das sollte nicht mal zu einem Datenverlust führen.

Korrigiert mich, falls ich Unfug rede ;)

Edit: Sehe gerade, dass da widersprüchliche Daten sind... Da steht ja einmal ATO und einmal DBT... So wie das für mich ausschaut, würde ich jetzt auf DBT tippen... Aber warte lieber auf weitere Kommentare.
 
T

tilmsch

Neues Mitglied
ich habe jetzt die build.prop runterladen koennen:
Code:
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=IML74K
ro.build.display.id=IML74K.XXLPY
ro.build.version.incremental=XXLPY
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0.3
ro.build.date=Fri May  4 04:23:15 KST 2012
ro.build.date.utc=1336072995
ro.build.type=user
ro.build.user=se.infra
ro.build.host=SEP-103
ro.build.tags=release-keys
ro.product.model=GT-N7000
ro.product.brand=samsung
ro.product.name=GT-N7000
ro.product.device=GT-N7000
ro.product.board=smdk4210
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=samsung
ro.product.locale.language=en
ro.product.locale.region=GB
ro.wifi.channels=
ro.board.platform=exynos4
# ro.build.product is obsolete; use ro.product.device
ro.build.product=GT-N7000
ro.tether.denied=false
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=GT-N7000-user 4.0.3 IML74K XXLPY release-keys
ro.build.fingerprint=samsung/GT-N7000/GT-N7000:4.0.3/IML74K/XXLPY:user/release-keys
ro.build.characteristics=phone
# Samsung Specific Properties
ro.build.PDA=N7000XXLPY
ro.build.hidden_ver=N7000XXLPY
ro.build.changelist=474507
# end build properties
#
# system.prop for smdk4210
#

rild.libpath=/system/lib/libsec-ril.so
rild.libargs=-d /dev/ttyS0
ro.sf.lcd_density=160

wifi.interface=wlan0
wifi.supplicant_scan_interval=15
#wlan.driver.apmode "unloaded"

media.enable-commonsource=true
persist.sys.storage_preload=1

#
#System property for qemu
#
ro.kernel.qemu=0

ro.lcd_min_brightness=40

#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.opengles.version=131072
ro.sf.lcd_density=160
ro.config.ringtone=S_Over_the_horizon.ogg
ro.config.notification_sound=S_Whistle.ogg
ro.config.alarm_alert=Good_Morning.ogg
ro.config.media_sound=Media_preview_Touch_the_light.ogg
hwui.render_dirty_regions=false
ro.com.google.clientidbase=android-samsung
ro.url.legal=http://www.google.com/intl/%s/mobile/android/basic/phone-legal.html
ro.url.legal.android_privacy=http://www.google.com/intl/%s/mobile/android/basic/privacy.html
ro.error.receiver.default=com.samsung.receiver.error
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=256m
ro.secdirenc=true
ro.secsddecryption=true
ro.secfulldirenc=true
keyguard.no_require_sim=true
dev.sfbootcomplete=0
dev.powersave_fps=0
ro.ril.hsxpa=1
ro.ril.gprsclass=10
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=4.0_r1
dalvik.vm.dexopt-flags=m=y
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
Ist damit folgende FS die richtige?
- IceCreamSandwich 4.0.3 LPY einteilig: https://www.hidrive.strato.com/lnk/lLOR4S8W
oder muss es wegen dem bootloop zwingend eine 3-teilige sein? welche waere das?

Diese SF kann ich doch mit Odin ohne Zaehlererhoehung flashen, oder?

Lese ich das in der build.prop richtig, dass ich ein britisches Geraet gekauft habe?? Hat mir Kies deswegen vor ein paar Tagen (als die Welt noch in Ordnung war) nur 4.0.3 statt 4.0.4 zum Update angeboten?
 
Zuletzt bearbeitet:
frank_m

frank_m

Ehrenmitglied
tilmsch schrieb:
bekannt ist: csc-code (AT0) [...] Han (Gt-N7000ZBADBT)
Das kann nicht sein, oder an dem Gerät wurden inoffizielle Eingriffe vorgenommen. CSC und ProductCode müssen zusammenpassen.

Vor allem muss eine passende Firmware geflasht werden. Alles andere ist sehr gefährlich. Also was genau sind nun deine Daten und wie hast du sie herausgefunden?
 
T

tilmsch

Neues Mitglied
Meine Daten:

auf der Verpackung (die beim Kauf bereits geoeffnet war) steht (u.a): HAN: GT-N7000ZBADBT,
das Geraet selber sagt mir im Recoverymode: csc-code: AT0
in der built.prop steht (siehe auch oben): ro.build.fingerprint=samsung/GT-N7000/GT-N7000:4.0.3/IML74K/XXLPY.

Wahrscheinlich stimmen eher die Daten im Geraet (csc, build.prop), es sei denn, mein rooten des Geraets mit "Superuser-3.1.3-arm-signed.zip" haette die Daten geaendert.
Kann das sein?
 
frank_m

frank_m

Ehrenmitglied
tilmsch schrieb:
auf der Verpackung (die beim Kauf bereits geoeffnet war) steht (u.a): HAN: GT-N7000ZBADBT,
das Geraet selber sagt mir im Recoverymode: csc-code: AT0
Das ist aber sehr merkwürdig. Den ProductCode des Gerätes hast du nie nachgesehen, oder?
Korrekt ist das jedenfalls definitiv nicht.

tilmsch schrieb:
in der built.prop steht (siehe auch oben): ro.build.fingerprint=samsung/GT-N7000/GT-N7000:4.0.3/IML74K/XXLPY.
Und da ist das Problem: Die LPY gabs sowohl für ATO als auch für DBT. Nur welche ist die richtige für dich? Siehe Kapitel EFS Backup und ProductCode in den FAQ, und dir ein Bild der möglichen Konsequenzen zu machen. Vor allem wird es kritisch, wenn vor dir tatsächlich schon jemand unsachgemäß an den Gerät herumgeflasht hat.
 
T

tilmsch

Neues Mitglied
spsnote schrieb:
Hallo,

Wahrscheinlich hat das Programm zum ändern der Dpi die Zugriffsrechte der build.prop verändert.
Das führt, warum auch immer, dazu das das Note beim booten hängen bleibt.
Ich hatte das bisher immer wenn ich vergessen hatte nach manuellen editieren die Rechte wieder auf rw-r--r-- zu setzen.
Im Normalfall sollte ein neuflashen der Firmware das Problem beheben.

Gesendet von meinem XT910 mit der Android-Hilfe.de App
meine build.prop ist voellig offen (rwxrwxrwx).
- kann das der Grund fuer den bootloop sein?
- wie kann ich aus dem bootloop die Rechte aendern?