[ROM][5.1.1] CyanogenMod 12.1 Beta für das Gigaset QV1030

Ich hab oben gerade ein paar Screenshots hinzugefügt. Ein Reboot bringt nichts. Möglich ist natürlich auch, dass die aktualisierten GApps hier Probleme machen, aber das wäre doch ein sehr merkwürdiger Zufall.

Außerdem verstehe ich nicht, was dagegen spräche einfache eine DPI von 297 zu setzen? Über das adb shell command oder die build.prop doch überhaupt kein Problem und es sieht top aus:

Screenshot_2015-11-15-16-38-25.png

Es Cyanogenmod als Auswahl-Option beizubringen sollte doch durchaus ebenfalls machbar sein.

Ich beiße jetzt einfach mal in den sauren Apfel und lösche meine Google Launcher Einstellungen ... aber es ist schwer vorstellbar, dass dieses Verhalten nicht mit den aktuellen DPI-Probleme zusammenhängen soll.

Nutzt du evtl. Xposed und GEL Settings um das native Verhalten zu überschreiben? Hier ist nur der vanilla Google Launcher installiert.

EDIT: Launcher Daten löschen hat nichts gebracht außer Arbeit. Weiterhin ein 7x7 Grid.

Die vorherige CM build hatte hier keinerlei Probleme verursacht, App Drawer und Home-Screen Icons waren gleich groß und der Google Launcher hat ein sinnvolles Grid von 5x6 bzw. 5x6 verwendet.
 
Zuletzt bearbeitet:
Weil alle Apps mit den sechs Standard-densitys umgehen müssen: Supporting Multiple Screens, aber alles andere zu Darstellungsfehlern führen kann, weswegen ich am liebsten eine dieser Einstellungen nutzen würde.
Wenn ich bspw. 320dpi fix setzten würde, könnte natürlich weiterhin über das Auswahlmenü in CM eine andere Dichte gewählt werden.
Das hilft dir mit deinem Problem natürlich nicht. Nur die DPI sind, meiner Meinung nach, der einzige Ansatzpunkt. Denn wenn wirklich das Aspect Ratio durcheinander wäre, würde das gesamte Interface verzerrt werde.
Übrigens habe ich mich bei den DPI verguck, da wir ja 2560*1600 haben und nicht 2560*1440 hat das QV1030 302 dpi.
 
320dpi sind und waren ja auch überhaupt kein Problem. Problem ist halt nur, dass der Google Launcher kein passendes Grid zu dieser-DPI wählt und dass sie als Auswahl in den Einstellungen fehlt. Irgendwo scheint also beide eine Information zu fehlen die unabhängig von der gesetzten DPI ist ...

... Mhhh. Heureka ...

... und diese Information ist schlicht der fehlende ro.sf.lcd_density Eintrag in der build.prop!

Setzt man ihn, stimmt wieder alles. Der Google Launcher wählt das korrekte Grid und Cyanogenmod zeigt auch höhere dpi-Einstellungen zur Auswahl.

Warum frühere builds der fehlende Eintrag nicht gestört hat weiß der Himmel. Gibt's sonst noch ein config-file, in dem er hinterlegt ist?
[doublepost=1447605413,1447604336][/doublepost]Um's nochmal kurz zu machen:

@weltraumpapst86 und alle anderen, die Probleme mit den DPI-Einstellungen der neuen build haben, einfach

ro.sf.lcd_density=320

an die build.prop anfügen und schon gibt's keine Probleme mit Google Launcher, Play Store und Cyanogenmod Display Settings mehr.

Mit 320 in der build.prop sollte man auch keine Probleme mit der App-Kompatibilität (zumindest im Play Store) mehr haben, selbst wenn man genauer passende 300 in den Einstellungen wählt.

Screenshot_2015-11-15-17-32-10.png

Kann mal jemand, der noch auf einer älteren CM-Version ist schauen, ob der ro.sf.lcd_density dort wirklich gefehlt hat? Kann ich mir irgendwie kaum vorstellen.
[doublepost=1447605539][/doublepost]Übrigens nochmal ein fettes Lob an @Spartaner25. Außer diesem leicht zu behebenden Problemchen habe ich bisher keine Probleme festgestellt. Keine Grafik-Fehler, kein Stottern, kein Freezen. Mal sehen, wie sich die neue build im Dauertest schlägt, ich muss jetzt jedenfalls erstmal meinen Google Launcher neu einrichten ... *seufz*
[doublepost=1447606168][/doublepost]Ah, shit. Ich hätt's nicht sagen sollen.

Chrome und Firefox funktionieren bei mir derzeit überhaupt nicht, so sehen alle Seiten aus:

Screenshot_2015-11-15-17-43-07.png
Schwarz und ohne Tabs in Chrome ...

Screenshot_2015-11-15-17-44-09.png
und ein Traum in weiß in Firefox. Sehen tut man nichts.

Ist das bei euch anders?
 
Wir können dazu ja mal ein bisschen in den Quellcode tauchen:
Also die Density Settings finden hier statt: android_package_apps_Settings.
Wie unschwer zu erkennen ist, wird dort das Array der verfügbaren DPIs eingestellt, auf Basis der Methode getDefaultDensity.
Diese Methode finden wir in der gleichen Datei an anderer Stelle, und zwar auf Zeile 278.
Unter Annahme das der try-Block fehlschlägt (Die Methode ist etwas.. speziell) wird die Variable DENSITY_DEVICE ausgelesen, die mittels der Methode getDeviceDensity aus der DisplayMetrics.java aufgerufen, wo dann eben die ro.sf.lcd_density ausgelesen wird.
Soweit so gut, wie du schon sagtest, wenn ro.sf.lcd_density gesetzt ist, löst sich das Problem von allein.
 
Hier die passende logcat zum Chrome/Firefox Bug:

Code:
D/NvOsDebugPrintf(14060): ERROR: can't start nvcgcserver. Compilation is impossible.
D/NvOsDebugPrintf(13746): Compiler process exits, cleaning up.
D/NvOsDebugPrintf(13746): CompilerClientThread: error readingresult binary size
D/NvOsDebugPrintf(13746): CompilerThreadParent: compilation FAILED, killing compiler process
E/chromium(13746): [ERROR:shader_manager.cc(130)] Shader translator allowed/produced an invalid shader unless the driver
is buggy:
E/chromium(13746): --Log from shader translator--
E/chromium(13746):
E/chromium(13746): --original-shader--
E/chromium(13746): precision highp float;
E/chromium(13746): attribute vec2 a_position;
E/chromium(13746): attribute vec2 a_texcoord;
E/chromium(13746): uniform vec4 src_subrect;
E/chromium(13746): varying vec2 v_texcoord;
E/chromium(13746): void main() {
E/chromium(13746):   gl_Position = vec4(a_position, 0.0, 1.0);
E/chromium(13746):   vec2 texcoord = src_subrect.xy + a_texcoord * src_subrect.zw;
E/chromium(13746):   v_texcoord = texcoord;
E/chromium(13746): }
E/chromium(13746):
E/chromium(13746): --translated-shader--
E/chromium(13746): attribute highp vec2 a_position;
E/chromium(13746): attribute highp vec2 a_texcoord;
E/chromium(13746): uniform highp vec4 src_subrect;
E/chromium(13746): varying highp vec2 v_texcoord;
E/chromium(13746): void main(){
E/chromium(13746): (gl_Position = vec4(a_position, 0.0, 1.0));
E/chromium(13746): highp vec2 texcoord = (src_subrect.xy + (a_texcoord * src_subrect.zw));
E/chromium(13746): (v_texcoord = texcoord);
E/chromium(13746): }
E/chromium(13746):
E/chromium(13746): --info-log--
E/chromium(13746): Error reading result binary size from compiler process
E/chromium(13746):
E/chromium(12277): [ERROR:gl_helper.cc(891)] Error reading result binary size from compiler process
E/chromium(12277):
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6874)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUseProgram: program not linked
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(8208)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_V
ALUE : glVertexAttribPointer: index out of range
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(4905)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_V
ALUE : glEnableVertexAttribArray: index out of range
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(8208)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_V
ALUE : glVertexAttribPointer: index out of range
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(4905)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_V
ALUE : glEnableVertexAttribArray: index out of range
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform1i: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform4fv: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform2fv: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform2fv: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform2fv: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(6527)] [.CmdBufferImageTransportFactory-0x9d2f3e00]GL ERROR :GL_INVALID_O
PERATION : glUniform4fv: no program in use
E/chromium(13746): [ERROR:gles2_cmd_decoder.cc(7084)] [.CmdBufferImageTransportFactory-0x9d2f3e00]RENDER WARNING: Drawin
g with no current shader program.
D/SyncController(12277): Enabling sync
D/DelegatedPKCS11Manager(12277): initialize
I/cr.BindingManager(12277): Moderate binding enabled: maxSize=20 lowReduceRatio=0.250000 highReduceRatio=0.500000
V/NFC     (12277): this device does not have NFC support
I/MinidumpUploadService(12277): Attempting to upload accumulated crash dumps.
I/Icing   ( 3990): Usage reports 3 indexed 0 rejected 0 imm upload false
E/cr.Icing(12277): Failed to clear legacy corpus. Status Code: 8 Message: No CorpusConfig for history of com.android.chr
ome
D/NvOsDebugPrintf(14089): ERROR: can't start nvcgcserver. Compilation is impossible.
D/NvOsDebugPrintf(13746): Compiler process exits, cleaning up.
D/NvOsDebugPrintf(13746): CompilerClientThread: error readingresult binary size
D/NvOsDebugPrintf(13746): CompilerThreadParent: compilation FAILED, killing compiler process
E/chromium(13746): [ERROR:shader_manager.cc(130)] Shader translator allowed/produced an invalid shader unless the driver
is buggy:
E/chromium(13746): --Log from shader translator--
E/chromium(13746):
E/chromium(13746): --original-shader--
E/chromium(13746): #version 100
E/chromium(13746): uniform mediump vec4 urtAdjustment_Stage0;
E/chromium(13746): attribute highp vec2 inPosition;
E/chromium(13746): attribute mediump vec4 inCircleEdge;
E/chromium(13746): varying mediump vec4 vCircleEdge_Stage0;
E/chromium(13746): void main() {// Primitive Processor CircleEdge
E/chromium(13746): vCircleEdge_Stage0 = inCircleEdge;vec2 pos2 = inPosition;gl_Position = vec4(pos2.x * urtAdjustment_St
age0.x + urtAdjustment_Stage0.y, pos2.y * urtAdjustment_Stage0.z + urtAdjustment_Stage0.w, 0, 1);gl_PointSize = 1.0;}
E/chromium(13746): --translated-shader--
E/chromium(13746): uniform mediump vec4 urtAdjustment_Stage0;
E/chromium(13746): attribute highp vec2 inPosition;
E/chromium(13746): attribute mediump vec4 inCircleEdge;
E/chromium(13746): varying mediump vec4 vCircleEdge_Stage0;
E/chromium(13746): void main(){
E/chromium(13746): (vCircleEdge_Stage0 = inCircleEdge);
E/chromium(13746): highp vec2 pos2 = inPosition;
E/chromium(13746): (gl_Position = vec4(((pos2.x * urtAdjustment_Stage0.x) + urtAdjustment_Stage0.y), ((pos2.y * urtAdjus
tment_Stage0.z) + urtAdjustment_Stage0.w), 0, 1));
E/chromium(13746): (gl_PointSize = 1.0);
E/chromium(13746): }
E/chromium(13746):
E/chromium(13746): --info-log--
E/chromium(13746): Error reading result binary size from compiler process
E/chromium(13746):
D/NvOsDebugPrintf(14092): ERROR: can't start nvcgcserver. Compilation is impossible.
D/NvOsDebugPrintf(13746): Compiler process exits, cleaning up.
D/NvOsDebugPrintf(13746): CompilerClientThread: error readingresult binary size
D/NvOsDebugPrintf(13746): CompilerThreadParent: compilation FAILED, killing compiler process
E/chromium(13746): [ERROR:shader_manager.cc(130)] Shader translator allowed/produced an invalid shader unless the driver
is buggy:

Die neuen blobs laufen wohl nicht, wie sie sollen. Schade. So ist die ROM leider nicht zu gebrauchen. :-(
 
Oh oh, das ist gar nicht gut.
Ich hatte die Hoffnung das es nur am fehlenden nvcgcserver liegt, aber da ist noch viel mehr im argen, verdammt.
Ich habe die Version mal wieder rausgenommen, sorry Leute!
Und insbesondere freibooter bei dir möchte ich mich entschuldigen, dass du jetzt auch das Problem hast :sad:.
 
  • Danke
Reaktionen: Achtern und freibooter
Hab die neue ROM auch drauf und kann bisher folgendes berichten:
Bei der Eingabe des WLAN Passwortes war das Tablet eingefroren, nach den Neustart gab es dann aber keine Probleme. Boat Browser for Tablet läuft bisher fehlerfrei (siehe Foto). Und weil freibooter wegen Firefox gefragt hat, bei mir stürzt der ständig ab, siehe Fotos. Hab auch mal ein logcat erstellt.
 

Anhänge

  • Boat Browser for Tablet.png
    Boat Browser for Tablet.png
    111 KB · Aufrufe: 239
  • FireFox_1.png
    FireFox_1.png
    46,4 KB · Aufrufe: 208
  • FireFox_2.png
    FireFox_2.png
    10,7 KB · Aufrufe: 222
  • FireFox_3.png
    FireFox_3.png
    56,9 KB · Aufrufe: 211
  • logcat.zip
    56,4 KB · Aufrufe: 116
Zuletzt bearbeitet:
Kein Grund dich zu entschuldigen @Spartaner25 , ich bin froh, dass ich bei der Fehlersuche behilflich sein konnte und ein Downgrade tut ja nicht weh. Hoffentlich dauert es nicht zu lange bis zur nächsten build, sag einfach bescheid, wie wir dich weiter unterstützen können.
 
@freibooter. In meiner build.prop cm Version 5.02. vom 17.04. habe ich diesen Eintrag gefunden. ro.sf.override_null_lcd_density. Das Tablet läuft mit einer Auflösung von 2560×1504 und 320 dpi (laut ES Taskmanager)
 
Welche Version ist die momentan stabilste die am wenigsten einschränkungen mit bringt? Habe momentan eine sehr alte Version (eine der ersten) drauf und möchte mal wieder updaten da das Tab ständig abstürzt. Danke für die schnelle Hilfe ;-)
 
andre333 schrieb:
Welche Version ist die momentan stabilste die am wenigsten einschränkungen mit bringt?
Das Build vom 16.9. läuft bei mir (YMMV) bis auf gelegentliche Freezes (mit denen AFAIK aber ALLE CM-Versionen auf diesem Gerät zu kämpfen hatten/haben) stabil.
 
Spartaner25 schrieb:
Ich habe die Version mal wieder rausgenommen
Nur gut das ich die gleich geladen hatte:D
Also ich werde die Version erst einmal drauf lassen, das all meine Apps die ich bisher genutzt hatte laufen. Wenn gewünscht kann ich aber gerne noch ein paar andere testen... falls Interesse besteht einfach bescheid geben.
 
Zwar etwas Offtopic, aber fühlt sich euer Tablet während dem Ladevorgang auch komisch an?

Sprich, lade ich das Gerät und fahre mit den Fingerkuppen über die Rückseite, fühlt es sich an, als würde es irgendwie vibrieren. Kabel raus, passt es wieder.
Habe jetzt verschiedene Kabel und Netzteile getestet. Meiner Freundin ist das auch schon aufgefallen.

Gruß
 
Zuletzt bearbeitet:
das ist ein harmloser Berührstrom, liegt daran das das Schaltnetzteil nicht galvanisch getrennt ist und nur Schutz-isoliert ist (Schutzklasse II)...und durch die Kapazitive Kopplung im Netzteil wird eben am Ausgang eine schwache Oberwelle mit daraufgelegt, welche auch mal über 100V haben kann - also wenn man mit nem Multimeter mal die Gehäuserückseite des Tablets gegen Erde misst kann da schon einiges zusammenkommen.
Diese Spannung bricht aber beim Berühren so stark zusammen, das im Endeffekt nur unter 0.1mA fließen - was uns Menschen nicht wirklich stört, aber man merkt es in form von dem gribbeln.
auch ein MacBook Air, oder einige Smartphones und Notebooks mit Metallrückseite weißen dieses Phänomen auf.


Wem das nicht gefällt muss ein Netzteil suchen der Schutzklasse I, also mit Vollwertigen Schuko-Stecker wo auch der Schutzleiter mit abgegriffen wird. da wird diese durch Kapazitive Kopplung fehl-induzierte Spannung mit abgeleitet.
 
  • Danke
Reaktionen: SpicyShakshuka7, stroke, Achtern und 6 andere
Ich brauche Versuchskaninchen!
Nach dem Desaster vom letzten Mal, habe ich diese Version jetzt auch selber mal gründlicher getestet und keine grösseren Probleme gefunden.
Dennoch möchte ich euch darum bitte, die Version im Moment nur dann zu installieren, wenn ihr einerseits mit einem Roll-Back auf die vorherige Version keine Probleme habt und wenn ihr mir brauchbare Fehlermeldungen liefern könnt (Wie es zum Beispiel freibooter und tarjan getan haben. Danke dafür Leute :thumbsup:).
Zur Version selber:
- Neuer Kernel mit Bugfix
- Binaries vom Note 7
-"DPI-Fix" (DPI sind per build.prop auf 320 eingestellt, aber in den Einstellungen modifizierbar)
Wenn ihr mir beim Bughunting helfen wollt, würde ich euch bitten, folgende Elemente genauer unter die Lupe zu nehmen:
- DRM (sprich Widergabe von DRM geschütztem Material)
- Kamera (Hier sind noch die alten libs vom QV1030 vorhanden)
- Grafik Performance & Akkulaufzeit (Hier reicht auch ein grobes "ähnlich wie vorher", ich möchte nur inkompatible Libs ausschließen)
Download:
cm-12.1-20151119-UNOFFICIAL-fg6q.zip

Und wer sich noch dafür interessiert, wo der Fehler lag:
Zwei Dateien fehlten. Einmal der nvcgserver (ersichtlich aus den Logs) und das set_hwui_parameters.sh Skript, was einige Parameter zur Grafikbeschleunigung auf 2D-Oberflächen wie der GUI festlegt (Wie die Tabs in Chrome). Das Skript ist übrigens in der system.prop aufgegangen, da unser Bildschirm immer die gleiche Auflösung hat, und wir daher nicht immer beim Neustart die Parameter auf Basis der Auflösung ändern müssen.
 
  • Danke
Reaktionen: freeztyler, meta666, Overmind123 und 11 andere
neuer Kernel und Grafik-Tweaks...ist damit eine art "neurer Treiber" gemeint? weil einige Games wie z.B. X-Com und auch World of Tanks bereiten ja diese bösen Texturen-Flicker probleme, wodurch das spiel selber nicht mehr nutzbar ist, das ist aber auch nicht sofort, sondern manchmal erst bei bestimmten szenen :(
 
Zuletzt bearbeitet:
Wenn du es so ausdrücken willst, könnte man auch schlicht "neue Treiber" sagen :winki:.
Ich kann ja mal etwas weiter ausholen. Das QV1030 nutzt ja einen Tegra 4 Chip als SOC der CPU wie GPU beinhaltet. Für die GPU brauchen wir, genau wie bei jedem anderen System auch so etwas wie "Treiber". In diesem Falle müssen die Treiber eben für Android passend sein und daher EGL unterstützen. Das Problem dabei ist, dass die originalen Treiber von Gigaset mittlerweile an die zwei Jahre alt sind und vielerlei Tweaks, Hacks und Flags brauchten um zu funktionieren. Die EGL-Blobs (sprich die "Treiber") habe ich schon früher durch die des TF701t (welches auch einen tegra 4 Chipsatz hat) ersetzt, da ohne sie Lollipop nicht funktionierte. Diese Blobs sind aber auch nicht mehr die jüngsten und ich hatte in letzter Zeit immer mal wieder das Problem, einen Blob vom QV patchen zu müssen, damit er wieder funktioniert (Was weder einfach für mich noch transparent für euch ist).
Daher hatte ich schon länger das Ziel möglichst viele dieser Blobs durch die des Note 7 zu ersetzten, da jenes mittlerweile die Version Androidversion 5.1 offiziell unterstütz. Idealerweise wollte ich alle ersetzten um Inkompatibilitäten zwischen den Blobs zu vermeiden, was mir auch (fast) gelungen ist (Der Rest steckt im Ordner "prebuilts" in der Githubrepo). Unter anderem die EGL-Blobs sind die aktuellen vom Note 7.
Daher ja, es gibt neue "Treiber".
Meine Quelle für die neuen Blobs ist übrigens xda-developers.
Und wenn ihr die Blobs aus dieser zip mittels ./extract-files in den vendor Ordner importiert, könnt ihr auch wieder ein Rom auf dem aktuellen Stand für euch selbst bauen, wenn gewünscht.
 
  • Danke
Reaktionen: wolder und SSX
Ahh, ok. Naja mit dem Linux gedöhnse kenne ich mich nicht wirklich aus :( bin eher für die Hardware da :D

Da werd ich mal nen full backup von meinem system machen, danach deine neuste kreation draufziehen und mal schauen ob es was gebracht hat was diese grafik-bugs angeht... Am ende hat es was mit der unterstützten direct3d oder opengl api selber zutun, wo der tegra4 einfach zu alt für ist um für aktuelle games herhalten zu können
 
Mpf, jetzt hab ich mich extra vor den Rechner gequält um ein log via logcat zu machen und jetzt funktioniert wieder alles ... jetzt weiß ich nicht, ob mich darüber ärgern oder freuen soll.

@Spartaner25 Vielen Dank für die neue Build, da kann ich trotz der Probleme der letzten natürlich nicht widerstehen. Installation lief problemlos und der erste Eindruck ist positiv.

Im Vergleich zur letzten Version mit den alten Blobs vom 30.09. sind die Artefakte (schwarze Balken und Flächen) z.B. in Google Now und im Play Store verschwunden!

Chrome und Firefox funktionieren stabil und ohne Lags und Freezes.

Als aufwändigstes 3D Spiel hab ich gerade mal Hitman Sniper (aus dem 10 cent Deal) getestet, auch hier gab's keine Probleme - das lief allerdings auch mit der alten Version. @all , bei welchen 3D Spielen gab's denn zuletzt Probleme?

Bisher keine permanenten Freezes oder katastrophalen Abstürze.


Erster beobachteter Bug bisher:

Grafische Oberfläche ist abgestürzt, das System lief aber weiter. Power-Knopf schaltete zwischen schwarzem Screen mit Hintergrundbeleuchtung und deaktiviertem Screen um und flackerte gelegentlich sehr kurz bei dem vergeblichen Versuch wieder etwas auf dem Screen anzuzeigen. Bis der Rechner einsatzbereit, das Tablet angeschlossen und logcat gestartet war ging plötzlich wieder alles als hätte es nie ein Problem gegeben. Ähnliches habe ich auch mit früheren builds beobachten können
 
Ist es denn auch möglich direkt übers tablet die logfiles auszulesen? Ich meine - gerootet ist es ja, da sollte es doch auch so irgendwie möglich sein?


An games geht momentan sogar weniger als mit der stock rom :(
X-com stürtzt z. B. Direkt beim starten ab, Star Horizon schmiert beim übergang vom spielemenü ins eigentliche spiel ab, world of tanks stürzt in der panzergarage ab wenn man ein paar mal zwischen den panzern switcht und sich den forschungsbaum anschaut,...
Was mir noch aufgefallen ist - vibration funktioniert nicht, miracast fehlt noch, oder?



Du siehst, ich hätte reichlich logfiles die ich erstellen könnte... Ich such mal eben nach einer root app, die diese logcat files auslesen kann
 
Zuletzt bearbeitet:

Ähnliche Themen

S
Antworten
0
Aufrufe
733
satlink
S
H
Antworten
3
Aufrufe
2.990
wolder
wolder
N
  • Netzonline
Antworten
3
Aufrufe
7.930
wolder
wolder
Zurück
Oben Unten