So... That was interesting. Apparently there are some bits of Android O's background process limitations that are still buggy. In the time the previous build was out there, the few Android 8 users that enabled reporting of crashes (yes, if you do this I will see them and start fixing) were seeing multiple crashes a day related to O issues (not my code). Back to API 25 for now.

For the uninitiated, this doesn't mean the APK doesn't work on O, it just means a little less metadata in the APK and doesn't impact usage even a little.

For all zero of you wondering... The occasional crash being addressed in 3.1.18 is happening in this bit of code.

Bundle extras = intent.getExtras();
if (null != extras) {
if (extras.containsKey("GraphicalWidget")) {
int[] appWidgetIds = extras.getIntArray("GraphicalWidget");
if (null != appWidgetIds) {
graphicalWidgetsActive = appWidgetIds.length;
scheduleNextTick();
}

} else if (extras.containsKey("SepticycleWidget")) {
int[] appWidgetIds = extras.getIntArray("SepticycleWidget");
if (null != appWidgetIds) {
septicycleWidgetsActive = appWidgetIds.length;
scheduleNextTick();
}

} else if (extras.containsKey("CheckpointWidget")) {
int[] appWidgetIds = extras.getIntArray("CheckpointWidget");
if (null != appWidgetIds) {
checkpointWidgetsActive = appWidgetIds.length;
scheduleNextTick();
}
}

Mind that the three checks for appWidgetIds are what I hope will address the problem, despite the fact that the system should never randomly be losing the array passed. ...but those were literally the only places where an NPE could possibly occur. This should kill off the absolute last crash bug.

Version 3.1.17 has been pushed to the Play Store

Bugfixes: "Phase 1 Ending" properly relabeled as "Phase 2 Ending".

Updates: September 26th anomaly events added to schedule, August 26th events removed.

Feature enhancement: Since people were having trouble finding it, the XM Anomaly Detector can now be launched from the Configuration app for the widgets.

Post has attachment
Spotted the one remaining bug, where Phase 2 was referred to as Phase 1. No biggie, I'll get it tomorrow.

Meanwhile...
Photo

I see it. I have to fix a caching value. Expect a new release before the bars close.

There's something quite absurd in how Android tracks CPU utilization and power consumption.

The Anomaly Detector sits around doing literally nothing most of the time, using what's supposed to be a bog-normal Handler.postDelayed mechanism that simply sets up a little timer that comes back and runs the update function at the top of each second. Now that I've converted just about all the graphics to a very small number of graphical elements so it's only having to draw about seven things, it's certainly not burning CPU stacking bitmaps anymore. But still, I look at GSAM and it's reporting that the detector is using a ludicrous amount of CPU time... nearly nine out of every ten seconds is supposedly being spent running the detector.

Except just to be certain it's an accounting problem and not a coding problem, I just stuck in a couple of functions. The first triggers the moment the recurring timer goes off, and it makes a note of System.currentTimeMillis(). The second triggers after the detector has done all it's (rather simple) calculations and makes another note about the time, substracts the second from the first and puts this in the logs...

08-17 23:30:18.048 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.
08-17 23:30:19.023 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 9ms.
08-17 23:30:20.010 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 2ms.
08-17 23:30:21.026 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 4ms.
08-17 23:30:22.040 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 2ms.
08-17 23:30:23.007 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 0ms.
08-17 23:30:24.028 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.
08-17 23:30:25.021 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.
08-17 23:30:26.015 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 0ms.
08-17 23:30:27.012 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.
08-17 23:30:28.007 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 2ms.
08-17 23:30:29.034 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 2ms.
08-17 23:30:30.011 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.
08-17 23:30:31.046 2877-2877/surrealestates.septiclockwidget D/AnomalyDetector: Done in 1ms.

Something is very amiss here, but at least it's not my code.

Hokay... A few more bits of code (namely the sideloading detector, the time traveller detector, and the idiot detector) have been ported in, a few routines got reshuffled so that the anomaly detector does a full screen update when one changes the faction setting (there was a delay on the clock bits before), and I think this is an RC!

Note that there are a number of units during the anomaly where the text labels will say something different for the first five seconds or last five seconds. Hopefully this will make what's going on a little clearer. Also, the bizarre "red mode" that was happening when normal (faction-colored) units ended has been sorted. Only "gold mode" should transition to "red mode" now.

Okay... I've converted all the text to basically, stickers, created a "massive" 4-dimensional array of what stickers are shown when, and I'm almost ready for an RC build.

I will probably email the maintainer of GSAM about the weird accounting issue, since I know other people are going to see that and freak out. It's definitely not using that much power. I've been watching the log window all day, and other than the occasional wobble when the phone is doing other things, each run has completed in under 2ms. That should be 0.2% power, not the absurdly high figure being reported. Android's own accounting mechanisms show the thing using only 2% (which is more than fine).

Release 3.1.3beta has been pushed to the Play Store!

Okay, so elegant coding is out, lots-and-lots-of-images is in! It turns out that while it might have been space-efficient to have a bunch of white images and simply apply a tint to them, this really chewed through battery power. I also consolidated a few pieces of imagery, and the result is that battery consumption is back to "hardly noticeable" levels.

"Testopolis" anomalies will continue to take place at 2am, 8am, 2pm, and 8pm each day as long as I'm beating on this code, although tomorrow I will very likely be kicking a new (and final) build to the production channel. There'll be a set of test anomalies built into the thing to take place exactly one week before the actual anomaly event, so that everyone has a chance to take a look at what's going to appear and when.

Heads up!

There will be a beta release tomorrow which will probably happen around noon. I have the anomaly detector mostly working now, and I'm mainly just refining what it says when and some of the blinky bits.

In case you'd like to familiarize yourself with what happens when, expect that it will go into "test/demo mode" where it pretends there's an anomaly at 2pm and at 8pm. (Note that this means it'll start doing stuff at 1pm and 7pm because I figured a one-hour warning window was probably a good idea).
Wait while more posts are being loaded