phonelab / cm-shamu.manifest Goto Github PK

frameworks/base/core/java/edu/buffalo/cse/phonelab/json/ is missing in the develop branch. It looks like it may have been added individually to each of the logging branches.

Can someone add this and make sure any other logging infrastructure is where it needs to be?

Some people (myself included) have been experiencing a complete data loss on their device after having their data work fine for 36-48 hours. This is a very troubling bug that I'm currently looking into a solution for.

@gurupras: This happened after rebooting, and I encountered it twice in a row. Here's the stack trace:

2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: java.lang.RuntimeException: Unable to start receiver edu.buffalo.cse.phonelab.conductor.receivers.StartReceiver: java.lang.NullPointerException: Attempt to get length of null array
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.app.ActivityThread.handleReceiver(ActivityThread.java:2766)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.app.ActivityThread.-wrap14(ActivityThread.java)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1440)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:102)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.os.Looper.loop(Looper.java:148)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:5461)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: Caused by: java.lang.NullPointerException: Attempt to get length of null array
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at edu.buffalo.cse.phonelab.conductor.receivers.StartReceiver$LogLastKmsg.logPstoreFiles(StartReceiver.java:54)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at edu.buffalo.cse.phonelab.conductor.receivers.StartReceiver$LogLastKmsg.run(StartReceiver.java:45)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at edu.buffalo.cse.phonelab.conductor.receivers.StartReceiver.onReceive(StartReceiver.java:26)
2016-08-21 22:04:42.073.73999995 3130 3130 E AndroidRuntime: at android.app.ActivityThread.handleReceiver(ActivityThread.java:2759)

The default logcat format in LogcatTask.java is "trace", shouldn't it be "tracetime"?

Apparently "trace" is not a recognized format by logcat command.

I had previously disabled this option so that every apk (including) prebuilt ones) is pre-optimized in compilation stage to avoid the "Updating apps # out of #" message. And with that we manged to just fit the system image (1.9G) to the partition (2G).

It is disable by somebody. Any particular reasons?@saintsantos

Now that the tracetime format has been added to logcat, can we make this the default format?

The max headphone volume of the Nexus 6 is too low, which is very noticeable when connecting the device to external speakers, e.g. car stereo. This can be fixed by changing the RX1 and RX2 digital volume settings in device/moto/shamu/mixer_paths.xml.

Jinghao - I've fixed this and tested it in my car and the new volume levels are reasonable. Can I go ahead and push this?

I discovered SELinux is blocking kmsgd from running. In Lollipop, we were able to get away without creating a domain and policy for kmsgd, but it looks like we aren't now.

Here is a snippet from dmesg:

[ 5.569108] type=1400 audit(2439641.239:5): avc: denied { syslog } for pid=390 comm="kmsgd" capability=34 scontext=u:r:kmsgd:s0 tcontext=u:r:kmsgd:s0 tclass=capability2 permissive=0
[ 5.569390] init: Service 'kmsgd' (pid 390) exited with status 255
[ 5.569410] init: Service 'kmsgd' (pid 390) killing any children in process group
[ 5.584574] type=1400 audit(2439641.239:6): avc: denied { sys_admin } for pid=390 comm="kmsgd" capability=21 scontext=u:r:kmsgd:s0 tcontext=u:r:kmsgd:s0 tclass=capability permissive=0

After fixing these, the following occurs:

[ 10.918196] init: Starting service 'kmsgd'...
[ 10.926122] type=1400 audit(1471311434.029:8): avc: denied { syslog_mod } for pid=915 comm="kmsgd" scontext=u:r:kmsgd:s0 tcontext=u:r:kernel:s0 tclass=system permissive=0
[ 10.926992] init: Service 'kmsgd' (pid 915) exited with status 255
[ 10.927013] init: Service 'kmsgd' (pid 915) killing any children in process group

I found this running a modified system while working on porting the tracing infrastructure. However, I also verified the finding on Guru's device that I believe was running the latest.

I think the right fix is to modify device/moto/shamu/sepolicy/, which I have done and tested. Jinghao - I can push the fix to either develop or a new branch; you may want to look it over as I'm not an SELinux expert by any means.

Don't know if it's easy to enable it on mashmallow. If it takes more than an hour, just don't bother.

Open the dialer and dial a number. The phone will reboot when make a phone call.

/proc/last_kmsg is very useful information to obtain to understand reboot reasons and find rare bugs in stock sources as well as experiments.

We should add functionality to the conductor to log this on startup.

Solution
The conductor repo has a branch last_kmsg which enables these changes.
This branch is up-to-date with [email protected]/develop. The version numbers are the same as they are on [email protected]/develop. I can bump these up if needed.

Unfortunately, this branch also contains tracing changes. If this change is approved, I will separate these out and create a new branch containing only changes required to run log /proc/last_kmsg.

Issue

While testing the kmsgd SELinux changes, I discovered that kmsgd stops producing output, even though there are more messages being logged to the kernel system log. This is due to another reader (logd) reading from /proc/kmsg.

Since 5.1.1_r3, a new logd feature was added that reads messages from /proc/kmsg and adds them to a new kernel (virtual) log buffer available through logcat. While we disabled most logd logging by setting TARGET_USES_LOGD := false, the logd process still runs due to init.rc. It appears that /proc/kmsg cannot handle multiple readers. As a test, I disabled logd and kmsgd continues to log output as expected. As soon as I run adb shell cat /proc/kmsg, it stops.

Potential Fixes

Disable logd Kernel Logging

They've added a build property -- logd.klogd -- that we can set to turn this off in logd. This doesn't stop logd from running, but it should stop it from interfering with kmsgd. However, we would still have the issue if any other processes read from /proc/kmsg.

Disable logd

Removing logd from init.rc would also stop it from interfering with kmsgd, but we would need to muck with the build and/or init.rc.

Read From /dev/kmsg Instead

The documentation for /dev/kmsg says that it supports multiple readers. The change is a little more involved since the data is formatted differently, but it's not hard. This is probably the best solution since reading from /proc/kmsg is a bit brittle because of the multiple reader issue.

Switch to logd

This may where we're headed in the medium term, but for now it's probably best to push an easy short-term fix so we get the logs.

OTAed from 4.0.5. Gets stuck at CM boot animation. Can not do adb logcat either (error message is : read: unexpected length.)