[Nexus 10 Android Development] InsaneScientist:
First off, thank you for keeping these old devices going!!

I installed the most recent 17.1 build on our ancient N10 last night, and it seems to work well, albeit a bit laggy as guidol mentioned. It is however, fairly old, so laggy isn't too much of a surprise.

That being said, I connected a shell over ADB and noticed that the system_server process has 1 CPU core pegged at 100% constantly (with a priority of 18 and a nice value of -2, so it's definitely not sharing time on that core either).

I imagine this is not intended... anyone have any idea what this thing does or where I should start digging to figure out what's causing it?

I imagine having the second core available would help a bit with the speed of the system. :)

Edit: digging through some of the android documentation, looks like it's a java process with a ton of things running inside it. This could get complicated to debug... hrmmm...

Update2: I installed the last build of 16. As mentioned by others, it's much snappier. I don't see system_service pegging the CPU on this build. I'll try to get time to reload 17.1 and check the logs (looks like I can filter logcat by PID?). Unfortunately, the amount of time I have with this device is somewhat limited because it's supposed to go to my dad as a kindle device. Will see how much debug info I can get out of it in the next day before it goes away!

Side note: I also saw the failures trying to install 16 with twrp 3.4.0. Rolled back to 3.3.1 and it worked just fine.

Update 3: Ran a clean install (formatted all partitions, adb push the .zip, install only the os - no gapps). Same problem. logcat doesn't show anything particularly useful - nothing spewing to indicate that it's repeatedly trying to do something. htop shows that it's a thread eating CPU, not the top level process (not too much of a surprise given the description of what it does)... Currently somewhat blocked by permissions... need root access

Update 4: Looks like it's the sensor service, and that thread is actually running with realtime priority, which explains why it's making an insane mess of system performance.

First line of top -H -p $(pidof system_server) :

TID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ THREAD PROCESS
447 system RT -8 2.0G 171M 112M R 100 15.5 4:19.01 SensorService system_server

I ran a thread dump of that process - this is the output for that thread (there's way too much total to paste everything).

"SensorService" prio=10 tid=41 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x13840ed0 self=0x7c87a600
| sysTid=447 nice=-8 cgrp=default sched=1073741825/10 handle=0x7ad50230
| state=R schedstat=( 410629489625 13894126 1119 ) utm=8168 stm=32894 core=0 HZ=100
| stack=0x7ac55000-0x7ac57000 stackSize=1008KB
| held mutexes=
native: #00 pc 00097674 /apex/com.android.runtime/lib/bionic/libc.so (__ppoll+20)
native: #01 pc 00065b97 /apex/com.android.runtime/lib/bionic/libc.so (poll+54)
native: #02 pc 00002343 /system/lib/sensors.manta.so (sensors_poll_context_t::pollEvents(sensors_event_t*, int)+206)
native: #03 pc 0000124f /system/vendor/lib/hw/sensors.exynos5.so (sensor_device_poll(sensors_poll_device_t*, sensors_event_t*, int)+14)
native: #04 pc 00005ab9 /system/vendor/lib/hw/android.hardware.sensors@1.0-impl.so (android::hardware::sensors::V1_0::implementation::Sensors::poll(int, std::__1::function<void (android::hardware::sensors::V1_0::Result, android::hardware::hidl_vec<android::hardware::sensors::V1_0::Event> const&, android::hardware::hidl_vec<android::hardware::sensors::V1_0::SensorInfo> const&)>)+112)
native: #05 pc 00010a25 /system/lib/android.hardware.sensors@1.0.so (android::hardware::sensors::V1_0::BsSensors::poll(int, std::__1::function<void (android::hardware::sensors::V1_0::Result, android::hardware::hidl_vec<android::hardware::sensors::V1_0::Event> const&, android::hardware::hidl_vec<android::hardware::sensors::V1_0::SensorInfo> const&)>)+104)
native: #06 pc 00010cc7 /system/lib/libsensorservice.so (android::SensorServiceUtil::SensorsWrapperV1_0::poll(int, std::__1::function<void (android::hardware::sensors::V1_0::Result, android::hardware::hidl_vec<android::hardware::sensors::V1_0::Event> const&, android::hardware::hidl_vec<android::hardware::sensors::V1_0::SensorInfo> const&)>)+70)
native: #07 pc 0000f6e5 /system/lib/libsensorservice.so (android::SensorDevice::pollHal(sensors_event_t*, unsigned int)+80)
native: #08 pc 00019219 /system/lib/libsensorservice.so (android::SensorService::threadLoop()+584)
native: #09 pc 00019773 /system/lib/libsensorservice.so (non-virtual thunk to android::SensorService::threadLoop()+4)
native: #10 pc 0000d84f /system/lib/libutils.so (android::Thread::_threadLoop(void*)+186)
native: #11 pc 0007fac5 /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+84)
native: #12 pc 000a78b7 /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+20)
native: #13 pc 00060027 /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30)
(no managed stack frames)

Unfortunately, I think this is probably about as far as I go... I'm a linux dev, but not an android one (yet), so I have no idea what anything in there is supposed to look like or how to figure out what sensor is failing or whatever. :(

Hope some of that helps!