Das Samsung Galaxy Tab S2 ist auch 4 Jahre nach Erscheinen noch ein tolles Gerät: 9,7 Zoll Super-AMOLED-Display mit einer Auflösung von 2048 × 1536 Pixel, 3 GB Hauptspeicher und eine Qualcomm Snapdragon 652 als CPU - und das alles bei einem Gesamtgewicht von 389 g.
Leider hat die Tatsache, daß Samung mit dem Galaxy Tab S2 eines der leichtesten und dünnsten Tablets bauen wollte einen gravierenden Nachteil: mit zunehmendem Alter fängt das Tablet vor allem bei verminderter Akku-Ladung an, im laufenden Betrieb neu zu starten.
Das Problem scheint im Zusammenspiel zwischen Akku und CPU zu liegen und verschiedene Beiträge auf XDA (s.o.) berichten, daß die Geräte auch nach einer erfolgreichen Reparatur meist nach kurzer Zeit wieder ein ähnliches Fehlerbild zeigen.
Als brauchbarer Weg zur Verhinderung der Neustarts hat sich eine Limitierung der Taktfrequenz erwiesen: mit einer App wie SmartPack-Kernel Manager (Google Play) oder Kernel Adiutor (F-Droid) werden die CPU-Parameter so gesetzt, daß die “großen Kerne” nicht mehr bis höchstmöglichen Taktfrequenz von 1804800 getaktet werden, sondern bereits bei einem niedrigeren Wert Schluß ist.
Da zum Setzen der CPU-Frequenz zwangsweise root-Rechte erforderlich sind, kann mit Hilfe von Magisk auch komplett auf eine App verzichtet und stattdessen ein Boot Script im Verzeichnis “/data/adb/service.d” verwendet werden:
#!/system/bin/sh
# 2020-09-07 athul/initial
echo '4:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '5:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '6:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '7:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '1' > /sys/devices/system/cpu/cpu4/online
echo '1382400' > /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq
echo '1' > /sys/devices/system/cpu/cpu5/online
echo '1382400' > /sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq
echo '1' > /sys/devices/system/cpu/cpu6/online
echo '1382400' > /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq
echo '1' > /sys/devices/system/cpu/cpu7/online
echo '1382400' > /sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq
Der Erfolg kann (zu Testzwecken) ebenfalls mit Hilfe eines weiteren Skripts überprüft werden:
#!/system/bin/sh
# 2020-09-07 athul/initial
echo "available frequencies:"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_available_frequencies
echo "scaling_max_freq:"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq
echo "cpu_max_freq"
cat /sys/module/msm_performance/parameters/cpu_max_freq
echo "scaling_available_governors"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_available_governors
Das Skript zeigt, daß die gesetzten Werten übernommen wurden:
available frequencies:
400000 883200 940800 998400 1056000 1113600 1190400 1248000 1305600 1382400 1612800 1747200 1804800
scaling_max_freq:
1382400
1382400
cpu_max_freq
0:4294967295 1:4294967295 2:4294967295 3:4294967295 4:1382400 5:1382400 6:1382400 7:1382400
scaling_available_governors
interactive ondemand userspace powersave performance
Sofern die Werte für einige Kerne nicht angzeigt werden, liegt dies daran, daß diese aktuell zwecks Strom sparen abgeschaltet sind.
Auch wenn der Markt für Android Tablets auf den ersten Blick nach halbwegs Ausahl aussieht - spätestens beim Blick auf die Sicherheitsupdates kommt der Gedanke, daß es um diese nicht nur gefühlt nochmals eine ganze Ecke schlechter bestellt ist als bei Smartphones.