verhindern der CPU Untertaktung im Standby (ScreenOff)

[Fallaxia]

Hi Leute,

kennt jemand eine Möglichkeit Android davon abzuhalten im Standby, also wenn der Bildschirm abgeschaltet wird, die CPU Taktfrequenz abzusenken?

Ich habe einige Apps die komplexe Aufgaben auf dem Tablet berechnen und dafür schonmal 60 Minuten pro Aufgabe brauchen können.

Die App sammelt umfangreiche Daten von einem Messgerät und komprimiert diese dann um sie per UMTS/LTE zum Server hochzuladen. Das Komprimieren dauert halt die meiste Zeit.

Die Messgeräte stehen in der Umwelt, also draussen, somit habe ich sonst keine Stromquellen in der Nähe.
Dies nur so als Erklärung.

Der Bildschirm verbraucht hierbei unnötig Strom und ich schleppe einen externen Akku quasi nur für die sinnlose Beleuchtung des Displays mit. Gibt es eine Möglichkeit das Display auszuschalten ohne dabei die CPU zu untertakten und die App damit quasi einzufrieren?

Die Tabs sind gerootet bzw. können es werden wenn das nötig ist.

Grüße,

Fallaxia

 

[h4rd]

Moin,
ich habe auch lange gesucht und bin mit "Screen Standby" sehr zufrieden.
Man kann es sogar automatisch mit definierten Apps starten lassen.

Damit das Display aber wirklich ausgeht, braucht "Screen Standby" root!

Viel Spass damit

 

[Fallaxia]

Root ist kein Problem, werde ich unbedingt gleich probieren. Besten Dank h4rd!

 

[HamHeRo]

Moin,

natürlich kann man mit Screen Standby und Konsorten die von Dir beschriebenen Probleme kaschieren. Die Ursache liegt doch aber wohl eher woanders, nämlich in den Apps selbst.

Die Apps, die die Daten von Messstationen auslesen, werden ja wohl extra für den Einsatzzwecke entwickelt worden sein, insofern würde ich bei den Ursachen ansetzen.

1. Warum werden die Daten überhaupt von unterwegs verschickt ? Wenn man mit einem Tablet Messstationen in der Wallachei abklappern muss, dann wird es sich ja wohl kaum um eine Echtzeitübertragung handeln, schon gar nicht wenn da vorher eine Stunde rumkomprimiert wird. Wieso sammelt die App nicht die Daten und speichert sie lokal und die Daten werden später versendet, sobald man wieder einen Stromanschluss und evtl. auch WLAN zur Verfügung hat ?
2. Die Apps können ja während der Berechnung einen Wake-Lock setzen, damit das Gerät eben nicht in den Standby geht.
3. Während dessen können die Apps natürlich auch die Bildschirmhelligkeit selbst auf 0 setzen, auch ohne Root und externe Tools.
4. Bis zu 60 Minuten für die Komprimierung von Daten ? Warum werden die Daten überhaupt selbst komprimiert? Die Datenübertragung wird ja wohl kaum nativ über UMTS/LTE erfolgen, sondern wohl eher über TCP und dort wird sicherlich ein entsprechenden Protokoll verwendet (FTP, HTTP etc.). Warum wird also eine proprietäre Komprimierung verwendet, statt das was es z.B. schon längst gibt (HTTP unterstützt u.B. gzip kompression) ? Don't reinvent the wheel.
5. Wenn die Komprimierung unbedingt selbst programmiert werden soll, dann implementiert man solche rechenintensive Aufgaben natürlich nicht in JAVA, sondern nativ in C. Dafür gibt es für Android das NDK. Die vorhandene HTTP Implementierung unter Android macht das schließlich auch.

 

[MaverickM]

1. Warum werden die Daten überhaupt von unterwegs verschickt ? Wenn man mit einem Tablet Messstationen in der Wallachei abklappern muss, dann wird es sich ja wohl kaum um eine Echtzeitübertragung handeln, schon gar nicht wenn da vorher eine Stunde rumkomprimiert wird. Wieso sammelt die App nicht die Daten und speichert sie lokal und die Daten werden später versendet, sobald man wieder einen Stromanschluss und evtl. auch WLAN zur Verfügung hat ?
2. Die Apps können ja während der Berechnung einen Wake-Lock setzen, damit das Gerät eben nicht in den Standby geht.
3. Während dessen können die Apps natürlich auch die Bildschirmhelligkeit selbst auf 0 setzen, auch ohne Root und externe Tools.
4. Bis zu 60 Minuten für die Komprimierung von Daten ? Warum werden die Daten überhaupt selbst komprimiert? Die Datenübertragung wird ja wohl kaum nativ über UMTS/LTE erfolgen, sondern wohl eher über TCP und dort wird sicherlich ein entsprechenden Protokoll verwendet (FTP, HTTP etc.). Warum wird also eine proprietäre Komprimierung verwendet, statt das was es z.B. schon längst gibt (HTTP unterstützt u.B. gzip kompression) ? Don't reinvent the wheel.
5. Wenn die Komprimierung unbedingt selbst programmiert werden soll, dann implementiert man solche rechenintensive Aufgaben natürlich nicht in JAVA, sondern nativ in C. Dafür gibt es für Android das NDK. Die vorhandene HTTP Implementierung unter Android macht das schließlich auch.

Unabhängig von der Fragestellung des TEs, alles sehr gute Fragen!

Ich würde für solche Zwecke auch kein Tablet sondern eine Raspberry PI oder eine Arduino Eigenbaulösung verwenden.