SHIFT6MQ.SOS.3.6.G.20220225

Status
Für weitere Antworten geschlossen.

Ingo Scheler

Alpha Tester
Beta Tester
26 Juni 2020
55
Das hätte ich (leider...) schöner nicht schreiben können:

[...] Die automatische Helligkeitssteuerung scheint sich nicht verändert zu haben. Funktioniert immer noch nur so meh. Gerade in dunklen Umgebungen muss ich doch sehr oft nach unten korrigieren [...]

Das ist beim mir leider von Anfang an so ( -> Juli 2020): Selbst bei absoluter Dunkelheit regelt die Automatik nie unter 43% drunter, was dann natürlich VIEL zu hell ist. Wenn man das dann manuell auf 0% oder auch was mehr korrigiert, tritt null Lerneffekt auf. Das nervt schon.
 

amartinz

ShiftOS Developer
Original poster
ShiftOS Developer
SHIFT Staff
19 März 2018
1.296
27
Wolfsberg, Austria
Das hätte ich (leider...) schöner nicht schreiben können:

[...] Die automatische Helligkeitssteuerung scheint sich nicht verändert zu haben. Funktioniert immer noch nur so meh. Gerade in dunklen Umgebungen muss ich doch sehr oft nach unten korrigieren [...]

Das ist beim mir leider von Anfang an so ( -> Juli 2020): Selbst bei absoluter Dunkelheit regelt die Automatik nie unter 43% drunter, was dann natürlich VIEL zu hell ist. Wenn man das dann manuell auf 0% oder auch was mehr korrigiert, tritt null Lerneffekt auf. Das nervt schon.
Ich lass es für die nächste OTA nochmal ganz genau durchtesten und neue Werte ermitteln.
 

Dinkleberg

Beta Tester
9 Februar 2021
8
Göppingen
Bin jetzt seit Veröffentlichung auf dieser Version. Soweit läuft eigentlich alles gut.
Kann auf jeden Fall das Problem mit der Helligkeit bestätigen, im gerade imDunkeln muss oft geregelt werden.
Leider habe ich in dieser Version wieder öfters zufällige Neustarts. Kann es leider nicht genau eingrenzen woran es liegt, da es weder regelmäßig auftritt, noch bei einer genauen Tätigkeit. Bug report (den aus dem Entwicklermenu) kann ich gerne per PN schicken. Aktuell fällt es mir stärker auf, habe gerade alle ein bis zwei Tage einen Neustart. Deswegen auch erst jetzt den Beitrag
 

amartinz

ShiftOS Developer
Original poster
ShiftOS Developer
SHIFT Staff
19 März 2018
1.296
27
Wolfsberg, Austria
Bin jetzt seit Veröffentlichung auf dieser Version. Soweit läuft eigentlich alles gut.
Kann auf jeden Fall das Problem mit der Helligkeit bestätigen, im gerade imDunkeln muss oft geregelt werden.
Leider habe ich in dieser Version wieder öfters zufällige Neustarts. Kann es leider nicht genau eingrenzen woran es liegt, da es weder regelmäßig auftritt, noch bei einer genauen Tätigkeit. Bug report (den aus dem Entwicklermenu) kann ich gerne per PN schicken. Aktuell fällt es mir stärker auf, habe gerade alle ein bis zwei Tage einen Neustart. Deswegen auch erst jetzt den Beitrag
Sind das Soft Reboots (vom laufenden System direkt zur Bootanimation) oder Hard Reboots (Gerät startet sich komplett neu, inklusive "SHIFT - powered by Android" Bildschirm)?
Wenn es Soft Reboots sind, bitte direkt danach einen Fehlerbericht aufnehmen und an mich schicken :)

Letztens gab es Probleme mit der Google Telefon App, würde mich wundern, ob das diesesmal auch der Fall ist.
Da konnte das Problem durch deinstalleren der Updates der Google Telefon App / konfigurieren der Einstellungen / neu aktualisieren bei den Betroffenen behoben werden.
 

Dinkleberg

Beta Tester
9 Februar 2021
8
Göppingen
Puh, so genau habe ich da jetzt nicht geachtet. Werde aber bei den nächsten Neustarts darauf achten. (Vom Gefühl waren es eher Soft Reboots) Ich kann dir trotzdem einfach mal meine beiden Fehlerberichte schicken.
Gibt es für die Google-Telefonapp eine Anleitung, wie man die deinstalliert und neueinrichtet?
 

danielp

SHIFT Friend
Alpha Tester
Alpha Tester
22 September 2019
2.792
Deinstallieren kannst du sie nicht ohne weiteres aber die Daten zurücksetzen bzw die Updates dafür deinstallieren!

Lies mal hier. Da steht einiges zum letzten Problem!

Um Updates zu deinstallieren sollte es in den System Einstellungen bei der jeweiligen App oben rechts die Möglichkeit geben die Updates zu deinstallieren.
 
  • Like
Reaktionen: Dinkleberg

trainman261

Beta Tester
12 September 2020
249
Also je mehr ich darüber nachdenke und je länge es läuft, desto mehr frage ich mir, ob die Google-Telefonapp vielleicht irgendeine API aufruft, was die anderen Telefonapps nicht/weniger aufrufen, und es ein Problem bei der Implementierung der API gibt. Folgende Beobachtungen/Feststellungen, die mich zu dieser Aussage führen:
  • Wie öfters festgestellt, ersetzt man die Telefonapp mit z.B. Simple Dialer, ist das Problem "gelöst". Ich sage gelöst in Anführungsstrichen, weil die Integrierung in die Telefonservices nicht ganz 100%ig ist, gerade bei verpassten Anrufen. Vielleicht funktionieren andere Telefonapps da besser, das habe ich bisher noch nicht ausprobiert.
  • Die Telefonapp taucht nicht als der Verursacher des erhöhten Akkuverbrauchs auf - zumindest bei mir nicht. Ich lese auch zwischen den Zeilen raus, dass es bei Anderen hier genauso ist.
  • Eine einzelne App sollte nicht in der Lage sein, das gesamte System zum Absturz zu bringen. Das gilt insbesondere für Android (habe selber schonmal Android App-Programmierung gemacht), sowie auch für andere Betriebssysteme.
  • Ich hatte das Problem, der Akkuverbrauch hatte angefangen, sich zu erhöhen, das Handy wurde langsamer, aber es erfolgte noch kein Neustart. Da hatte ich die Telefonapp komplett deaktiviert. Wenn es die App war, die rumgesponnen hätte, wäre das Handy wieder schneller geworden, und der Akkuverbrauch wäre zurückgegangen. Das war aber nicht der Fall. Es wurde allerdings auch nicht mehr schlimmer. Es war dann ein paar Tagen später genauso langsam und genauso akkufressend wie wo ich die Telefonapp komplett deaktiviert hatte. Nicht besser, nicht schlimmer.
  • Auf meinem Diensthandy (Gigaset GS4) habe ich auch die Google Telefonapp, auch auf Android 10, und da habe ich kein einziges Mal solche Probleme gehabt. Dasselbe gilt für meine Kollegen soweit ich weiß.
Also ja, Umschalten auf einen anderen Dialer hilft, aber man sollte man das auf der Betriebssystemseite nochmal genauer anschauen.
 

amartinz

ShiftOS Developer
Original poster
ShiftOS Developer
SHIFT Staff
19 März 2018
1.296
27
Wolfsberg, Austria
Also ja, Umschalten auf einen anderen Dialer hilft, aber man sollte man das auf der Betriebssystemseite nochmal genauer anschauen.

Ich habe 5 Fehlerberichten von verschiedenen Leuten mit dem selben Phänomen: Google Dialer will sich als Call Screening App festlegen, wird aber beendet und der Service bindet sofort erneut. Das passiert im Millisekunden-Intervall, die DeathMonitor reihen sich damit auf, bis sie den Reference Table vom SystemServer sprengen und der sich verabschiedet und somit einen Soft Reboot verursacht.

Code:
03-15 23:09:58.222  1000 12239 12239 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-15 23:09:58.222  1000 12239 12239 F DEBUG   : Build fingerprint: 'SHIFT/axolotl/axolotl:10/QKQ1.201126.002/20220225:user/release-keys'
03-15 23:09:58.222  1000 12239 12239 F DEBUG   : Revision: '0'
03-15 23:09:58.222  1000 12239 12239 F DEBUG   : ABI: 'arm64'
03-15 23:09:58.223  1000 12239 12239 F DEBUG   : Timestamp: 2022-03-15 23:09:58+0100
03-15 23:09:58.223  1000 12239 12239 F DEBUG   : pid: 1469, tid: 2191, name: Binder:1469_6  >>> system_server <<<
03-15 23:09:58.223  1000 12239 12239 F DEBUG   : uid: 1000
03-15 23:09:58.223  1000 12239 12239 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
03-15 23:09:58.223  1000 12239 12239 F DEBUG   : Abort message: 'JNI ERROR (app bug): global reference table overflow (max=51200)global reference table dump:
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :   Last 10 entries (of 51200):
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51199: 0x1355fd20 com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51198: 0x1355dd90 android.app.LoadedApk$ServiceDispatcher$DeathMonitor
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51197: 0x1355d778 com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51196: 0x1f8eb7b0 android.database.ContentObserver$Transport
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51195: 0x13545c50 com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51194: 0x1355baa8 android.app.LoadedApk$ServiceDispatcher$DeathMonitor
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51193: 0x135436a8 com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51192: 0x1f8e7eb0 android.database.ContentObserver$Transport
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51191: 0x132eb5e0 com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     51190: 0x135419d8 android.app.LoadedApk$ServiceDispatcher$DeathMonitor
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :   Summary:
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :     43949 of android.app.LoadedApk$ServiceDispatcher$DeathMonitor (43949 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :      3695 of com.android.server.notification.NotificationManagerService$StatusBarNotificationHolder (3695 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       751 of com.android.server.am.ContentProviderConnection (751 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       361 of java.lang.Class (274 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       335 of com.android.internal.os.BinderDeathDispatcher$RecipientsInfo (335 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       287 of java.nio.DirectByteBuffer (287 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       261 of com.android.server.am.PendingIntentRecord (261 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       243 of com.android.server.telecom.callfiltering.CallScreeningServiceFilter$CallScreeningAdapter (243 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       233 of android.os.RemoteCallbackList$Callback (233 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       176 of android.os.ResultReceiver$MyResultReceiver (176 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :       133 of com.android.server.am.ServiceRecord (133 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        66 of android.database.ContentObserver$Transport (66 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        61 of com.android.server.am.ActivityManagerService$AppDeathRecipient (61 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        61 of com.android.server.display.DisplayManagerService$CallbackRecord (61 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        50 of com.android.server.ConnectivityService$NetworkRequestInfo (50 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        47 of com.android.server.TelephonyRegistry$TelephonyRegistryDeathRecipient (47 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        31 of android.os.Binder (31 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        28 of com.android.server.job.JobServiceContext$JobCallback (28 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        14 of com.android.server.wm.Session (7 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        14 of android.content.pm.BaseParceledListSlice$1 (14 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        13 of com.android.server.wm.ActivityRecord$Token (13 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        12 of java.lang.ref.WeakReference (12 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        10 of com.android.server.wm.WindowState$DeathRecipient (10 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :        10 of com.android.server.inputmethod.InputMethodManagerService$ClientDeathRecipient (10 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         9 of com.android.server.accessibility.AccessibilityManagerService$RemoteAccessibilityConnection (9 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         8 of com.android.server.appop.AppOpsService$ModeCallback (8 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         8 of com.android.server.input.InputManagerService$InputDevicesChangedListenerRecord (8 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         7 of com.android.server.GraphicsStatsService$ActiveBuffer (7 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         6 of com.android.server.appop.AppOpsService$ClientState (3 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         6 of com.android.server.notification.ManagedServices$ManagedServiceInfo (5 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         6 of com.android.server.telecom.VideoProviderProxy$1 (6 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         6 of com.android.server.telecom.VideoProviderProxy$VideoCallListenerBinder (6 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         6 of com.android.server.media.MediaSessionRecord$ControllerStub (6 unique instances)
03-15 23:09:58.223  1000 12239 12239 F DEBUG   :         5 of com.android.server.wm.PinnedStackController$PinnedStackListenerDeathHandler (1

Das probiere ich gerade zu lösen.
 

eTaurus

Beta Tester
18 Februar 2020
11
Bei mir löst ein Update des Google Dialer reproduzierbar einen soft reboot aus. Ansonsten habe ich keine Probleme mit häufigen spontanen reboots.
 

Ozzy

Alpha Tester
Beta Tester
21 Oktober 2020
217
Bei mir löst ein Update des Google Dialer reproduzierbar einen soft reboot aus. Ansonsten habe ich keine Probleme mit häufigen spontanen reboots.
Das habe ich auch schon einige Male erlebt. Leider hat sich mein Handy jedes Mal geweigert, einen Fehlerbericht aufzunehmen. Also es ist einfach nichts passiert.
 

amartinz

ShiftOS Developer
Original poster
ShiftOS Developer
SHIFT Staff
19 März 2018
1.296
27
Wolfsberg, Austria
Das habe ich auch schon einige Male erlebt. Leider hat sich mein Handy jedes Mal geweigert, einen Fehlerbericht aufzunehmen. Also es ist einfach nichts passiert.
In den letzten Beta-Versionen war das Fehlerbericht aufnehmen kaputt 😅

Und danke für das Feedback wegen dem Dialer, also stimmt meine Vermutung wohl (leider).
 

Ozzy

Alpha Tester
Beta Tester
21 Oktober 2020
217
In den letzten Beta-Versionen war das Fehlerbericht aufnehmen kaputt 😅

Und danke für das Feedback wegen dem Dialer, also stimmt meine Vermutung wohl (leider).
Ich glaube, ich habe immer vergessen, dass zu posten, weil ich erst noch den Fehlerbericht haben wollte. Und dann habe ich es vergessen. Allerdings habe ich auch mal extra nur den Dialer geupdatet und dann ist es nicht passiert.
🤷‍♂️
 

Dinkleberg

Beta Tester
9 Februar 2021
8
Göppingen
Kleines Update: Habe die Updates der Telefonapp deinstalliert und gleich wieder installiert und alle Benutzerdaten gelöscht. Bis jetzt hatte ich keinen Neustart mehr. Hoffe ich mal, dass es ne Weile so bleibt
 

frecherzwerg

Alpha Tester
Beta Tester
1 Juli 2020
290
Wenn ich das Handy abends ausschalte und morgen wieder einschalte, ist das dann wie ein Neustart oder ist das definitiv was anderes?
 
  • Wow
Reaktionen: danielp

Oliver500

Member
6 März 2022
34
Hallo zusammen,

ich habe ebenfalls Probleme das inkrementelle Update von der Version SHIFT6MQ.SOS.3.5.G.20211124 auf die Version SHIFT6MQ.SOS.3.6.G.20220225 durchzuführen. Die Updater-App zeigt einen "Installationsfehler" in der Benachrichtigungsleiste. Der Versuch, es manuell über die Updater-App zu installieren, führt zum selben Ergebnis. Nun habe ich allerdings auch beide "Versuche" in der Updater-App stehen, jeweils mit Button "Installieren". Wie kann man denn die Daten der Updater-App zurücksetzen? Kann ich alternativ auch versuchen, das FULL-OTA der Version 3.6 zu installieren, ohne irgendwelche Apps, App-Daten oder Systemeinstellungen der 3.5 zu verlieren? Die Meldung zur Installation der Version 3.6 vom 20220225 zeigt auch noch die falsche Version, und zwar 3.5:
 

Anhänge

  • Screenshot_20220402-212722_Updater.png
    Screenshot_20220402-212722_Updater.png
    170,1 KB · Aufrufe: 3

danielp

SHIFT Friend
Alpha Tester
Alpha Tester
22 September 2019
2.792
Inkrementelle Updates funktionieren nicht bei gerooteten Geräten. Wie sollte es auch? Wenn man die Ausgangsbasis ändert auf der die inkrementellen Änderungen aufbauen kann es nicht mehr klappen.

Bei inkrementellen wie vollen Updates geht nichts verloren.

Die System App heißt Updater. Einfach die Daten der App löschen und alles ist zurückgesetzt.
 

Oliver500

Member
6 März 2022
34
Ok, die Updater-App hab ich zurückgesetzt, das hat schonmal geklappt. Gut zu wissen, dass mein bei Root ein FULL-OTA braucht - dann sei es drum. Aber nochmal eine ganz dumme Frage: Ich finde hier kein Release-FULL-OTA der 3.6.G Gibt es die (noch?) nicht bzw. überhaupt nicht, sodass ich auf 3.5.G bleiben muss, oder bin ich jetzt völlig auf dem Holzweg? :unsure:

EDIT: Hat sich erledigt, ist dort nur nicht verlinkt - aber im ersten Post. Auch hier gilt mal wieder: Wer Lesen kann ist klar im Vorteil.
 
  • Like
Reaktionen: Webbi1264 und danielp

crizz

Alpha Tester
Beta Tester
30 Juli 2020
5
Hallo,
bei mir funktioniert seit diesem Update das Abdunkeln und Sperren vom Display bei Telefonaten wenn man es sich an das Ohr hält nicht mehr. Der Proximity Sensor zeigt in der Shift Support App immer 5 cm an.
Ist das ein bekannter Bug oder kann das jemand bestätigen?
 

danielp

SHIFT Friend
Alpha Tester
Alpha Tester
22 September 2019
2.792
Glaube nicht das es mit dem Update zu tun hat. Funktioniert bei mir seit jeher zuverlässig. Das ist aber nicht bei jedem so.

Es wäre interessant ob der Sensor vielleicht durch irgendetwas blockiert ist. Er befindet sich oben rechts neben dem Ohrmuschellautsprecher.

Wie schaut es direkt nach einem Neustart aus?
 
  • Like
Reaktionen: Webbi1264

crizz

Alpha Tester
Beta Tester
30 Juli 2020
5
Mir kommts auch komisch vor, aber er hat bis zu den Update funktioniert. Danach ist es mir das erste Mal aufgefallen.

Ich habe es erst vorhin zuerlegt und gereinigt. Der Sensor wird durch nichts blockiert. Auch ein Neustart ändert nichts.
Normalerweise sieht man den Proximity Sensor leicht rot blinken, aber er bleibt finster.

Was für Gründe hat es bei anderen wo er nicht zuverlässig funktioniert?
 

danielp

SHIFT Friend
Alpha Tester
Alpha Tester
22 September 2019
2.792
Die Gründe kann ich leider nicht nennen!

Kann natürlich immer sein das der Sensor defekt ist! Vor allem wenn du sagt er leuchtet nicht mehr. Wobei ich jetzt bei kein Leuchten sehe.

Vielleicht ist es dann am Besten den Support zu kontaktieren.
 

jefla

Beta Tester
31 Oktober 2019
152
Hi @crizz, ja das war m.E. hier im Forum schon Thema. Der Näherungssensor zeigt stets 5.0 cm an. Sobald Du Dich dem Sensor auf unter ca. 5 cm näherst, sollte er auf 0.0 cm wechseln. Dies bedeutet, dass er funktioniert.
 

danielp

SHIFT Friend
Alpha Tester
Alpha Tester
22 September 2019
2.792
Ich denke @crizz meint das er auch 5 cm anzeigt wenn er nahe dran ist!? Falls nicht ist das natürlich ein guter Punkt!
 
  • Like
Reaktionen: jefla

crizz

Alpha Tester
Beta Tester
30 Juli 2020
5
Mhhh ja dann werde ich mal den Support anschreiben. Danke!
Nein, er wechselt leider auch nicht direkt auf 0.0.
 
  • Wow
Reaktionen: jefla

amartinz

ShiftOS Developer
Original poster
ShiftOS Developer
SHIFT Staff
19 März 2018
1.296
27
Wolfsberg, Austria
Status
Für weitere Antworten geschlossen.