[Xposed General] paul.miner:
I recently had a problem with my battery draining that I eventually tracked down to a problem with either Xposed or an Xposed module, and an overly large "powerManager" database. I figured I would detail the steps I took to find the problem in case someone else runs into something similar.

Background: I'm on a rooted Note 5 (Sprint), with Xposed framework 3.0 alpha 4, version 75 (custom build by wanam / 20151008). My active modules: BootManager, Disable Clear Defaults Dialog, Network Speed Indicator, SNAPPREFS, SpotifySkip, Wanam Xposed, YouTube AdAway, and YouTube Background Playback.

When I first noticed the problem, I used OS Monitor to see if something was using CPU. A process listed as "Android System" (with the process name "system_server") was constantly using 10-25% CPU. Rebooting had no effect -- it would be back using CPU as soon as I booted, and never stopped. Unlike other Android System processes, the process name wasn't a path to a binary, and I couldn't figure out what system_server was (though I later learned that it was "/system/bin/app_process64_xposed").

First I went to a terminal, su'ed to root, and looked for the process:

busybox ps -ef | busybox grep system_server

I could see that the process nnnn was still using a lot of CPU. Next, I drilled down to the thread level:

busybox ps -efT | busybox grep nnnn

From here, I could see one thread tttt in particular was using all the CPU, named something like "Thread-225", nothing too helpful. So my next task was to try to get an idea of what it was doing. Being that I have no experience with Android/Linux debugging, I took the blunt approach of killing the thread/process to create a tombstone (I read somewhere to send the signal twice, don't know why):

kill -6 tttt
kill -6 tttt

At this point, the phone rebooted (not surprising), but after it came back up, I found a new tombstone file in /data/tombstones. Looking at the backtrace of the thread I killed, I saw this:

backtrace:
#00 pc 000000000005eca4 /system/lib64/libc.so (pread64+8)
#01 pc 000000000005e5b0 /system/lib64/libsqlite.so
#02 pc 000000000001de44 /system/lib64/libsqlite.so
#03 pc 0000000000050bb0 /system/lib64/libsqlite.so
#04 pc 0000000000050df8 /system/lib64/libsqlite.so
#05 pc 0000000000050e5c /system/lib64/libsqlite.so
#06 pc 0000000000050ef4 /system/lib64/libsqlite.so
#07 pc 0000000000050fec /system/lib64/libsqlite.so
#08 pc 0000000000079734 /system/lib64/libsqlite.so
#09 pc 000000000007f404 /system/lib64/libsqlite.so (sqlite3_step+652)
#10 pc 00000000000c5088 /system/lib64/libandroid_runtime.so
#11 pc 00000000000c5164 /system/lib64/libandroid_runtime.so
#12 pc 000000000010dec4 /data/dalvik-cache/arm64/system@framework@boot.oat

So unless I caught it at an unusual time, my guess was that it was spending a lot of time doing database access. But on what? I went back to the terminal, found the process pppp again, and used lsof to see what files were open:

busybox lsof | busybox grep pppp

This was where I learned that the process was Xposed because lsof listed the path to the binary. I don't have the output of this command anymore, but among all the pipes and sockets were a variety of files in the /data/system folder, so I filtered it further:

busybox lsof | busybox grep pppp | busybox grep data

There were quite a few database files open, such as category.db, enterprise.db, etc. I was guessing there was either corruption, or an oversized database that took an excessive amount of time to query. The latter seemed easier to check for, so I sorted by size. One database in particular stood out: /data/system/powerManager was about 50MB, and the last-update timestamp was constantly changing. I created a subfolder and moved powerManager and powerManager-journal there, then rebooted. Opening up OS Monitor showed that CPU usage was back to nil. The powerManager database was not recreated, but it didn't seem to be causing a problem. I could probably put a blank database there, but I haven't felt the need to.

So that's how I tracked down my little power consumption problem. I still don't know what module (or if it was the framework) that triggered the issue, or even what the powerManager database is used by, but my battery usage is greatly improved. Hope this is of help to someone.