dgets / cpurecord Goto Github PK

For some reason, when trying to process the information for the final core, all values are returned as 0, or NaN, by the time it is displayed. Perhaps the problem is that this phone is actually bears one of those weird processors with an odd number of cores? I doubt that's it, so there is probably a logic error somewhere causing the wrong data to be polled. A one-off error...

Code where the error appears follows:

        for (int cntr2 = 0; cntr2 < 4; cntr2++) {
            idle = deviceStats[cntr2][0]; iowait = deviceStats[cntr2][1];
            irq = deviceStats[cntr2][2]; softirq = deviceStats[cntr2][3];

            /*for (int statline : deviceStats[cntr2]) {
                idle = statline[0];
                iowait = statline[1];
                irq = statline[2];
                softirq = statline[3];*/

                total = (idle + iowait + irq + softirq) / 100;  //percentage work
                if (debugging >= GENERAL) {
                    Toast.makeText(appShit, "total: " + total +
                            "\nidle: " + idle + "\niowait: " + iowait +
                            "\nirq: " + irq + "\nsoftirq: " + softirq,
                            Toast.LENGTH_SHORT).show();
                }

                try {
                    statsBox.append("\nCore: " + cntr2 + "\n\tIdle: " +
                            ((float)idle / total) + "%\tIO Wait: " + ((float)iowait / total));
                    statsBox.append("%\n\tIRQ: " + ((float)irq / total) + "%\t\tSoft IRQ: " +
                            ((float)softirq / total) + "%\n\n");
                } catch (Exception e) {
                    Toast.makeText(appShit, "cntr: " + cntr2 + ": " + e.getMessage(), Toast.LENGTH_SHORT).show();
                }
            //}
        }

Told ya that code got uglified...

Keep javadoc current.

Luckily, I had all of the VMs on my computer down, for backup purposes, for awhile here. If it wasn't for that, and not having the USB cable to connect my 'droid to the computer, I might not have noticed how other architectures, and/or /proc layouts, are making the app hang. For instance, I switched from my LG G6 (four coar AArch64 rev. 1 -- physical device), to an emulated Nexus 5X (api 26), and now I can't even get the stats box to populate. Need to track down where things like this might be coming from and add cases to deal.

In conjunction with issue #6, it would greatly improve the usefulness of this application to save other relevant activity logs. Of course these should be time- & date- stamped, in order to correlate with the processor stats, at any given point in the history. For instance, being able to know when the device went into a locked/blank/off screen mode, would be very useful for cases such as the one that gave me the idea to develop this app. Other system changes, such as application opened, charging status, and LAN/4g networking status changes, are all stats that could, and should, be logged as well. In the original context for this app, such changes could be exceedingly useful to crossref with processor usage at, due to the fact that malware could be using those changes as triggers to activate.

Hell, we could go all the way and log PIDs, I suppose. Maybe options for different levels/stats to log would be a good idea, as well. Actually, I'm sure it would, I just don't want to heap too terribly much work into this one enhancement issue.

It might be a good idea to look at the structures of CPUDetails and CPURecord, and see how much common methodology there is going to be in the implementation of BattDetails and BattRecord. Superclasses would save some time and make things a lot easier to maintain.

For some reason, when the line int[][] cpuStats = new int[MAX_COARS][4]; is left in CPUProbe.displayInfo(), the 'Show debug info' button stops being responsive, same as when I was having other crashes buried in the CPU* classes. Not sure why in the hell this initialization is crashing things; I've commented out every other line utilizing it (all assignments), and it does, indeed, appear to be the declaration that is hosing things. Funny, I've been doing crap like this since grade school, and I could swear that I'm following the exact template found at Programiz.com and a half a million other places.

Different objects to be instantiated (ie CPUDetails) need to have fields, and constructors, set up properly, in order to take advantage of OO for maintainability. Right now it's pretty nasty; been doing it the quick & easy way in order to handle initial debugging.

Which reminds me; learning unit testing in a fashion applicable for 'droid development is probably a damn good idea. I know it would've saved some serious effort in the last several attempts at debugging.

Need to figure out how to format the float values for percentage of time spent in each mode. They should be rounded to 2 decimal places or so, allowing tabs that can be correctly inserted to keep things in a nice attractive view. The other option is, of course, to put a more organized layout type into use in the display.

When the Loop checkbox is set, and a tone playing, unsetting the checkbox without first stopping playing the tone will cause the tone to stop playing. At this point the button text will switch to 'Play', indicating that the tone is completed, but the activated toggle bar stays lit.

Obviously this event is not planned for properly. Easiest way to fix it would be disabling the checkbox while the tone is actively playing.

These methods are looking like they're going to be pretty helpful in awhile here.

When stats are populated in the TextBox, no matter how I do the math, it seems like they're always displayed as integers with a .0 static decimal value. The behavior that I was looking for was displaying a float with a 2 digit-to-the-right-of-the-decimal precision.

Pretty self-explanatory. Need to figure out how I'm going to implement a simple bar graph for history comparisons of CPU usage, and whatever else I may end up including in later versions.

Implement battery probing routines; it's another great way to keep an eye on the device, and whether or not malicious code may be active when things are dark.

I had another idea for something to add in. It runs pretty much along the same lines, as far as purpose is concerned. This particular feature would be devoted to watching the battery discharge rate, however. It would monitor the status, taking into account the discharge rate over a period of time, the display status, cpu status, and other major energy burns, and basically provide a means to see if something is gobbling up the juice too fast. Metrics for detecting whether or not something of the sort is going on, after sketchy activities, (ie adding packages, etc) could comparatively provide an interesting method for analysis.

In addition to just leaving things actively logging on the display, saving statistics to a log will greatly increase the handiness of this application. Not to mention the fact that it could be cross referenced with time- & date-stamps to other information from the system.