Added a wrapper function since for compatibility with the jni's encoding
the flags matter and need to be the same everywhere. Or at least there
should be no chance of their getting changed.
As a first step, use mine and android's and assert results are the
same. Note using built-in Base64 class requires moving the min android
version from 7 to 8.
Copy config file into the right place, turn it on for debug builds, and
fix compile-time complaints by adding -keep clauses. Resulting builds
seem to work (after a few minutes in emulator only) except that net
status icon taps crash at first (eventually recovering somehow) likely
because of problems with base64 en/decoding which goes through jni.
Get rid of black background of center icon, instead running the green or
red all the way to the middle. For better contrast make the green and
red darker and the non-active arrows white.
The debug-only settings for disabling individual conn types weren't
kept in sync with which types were enabled, and that set of types was
lost on rotation. Fixed (including keeping the disableds across rotations.)
I'm seeing assertions when a game gets into a state I don't fully
understand: host receives messages that need a channelNo assigned but
the game's full. With luck they're duplicates and can be ignored,
because that's all I can do.
Since it's now possible to add a name for an SMS contact added manually,
don't assuming a missing name means it was added manually. Just leave
blank if not provided.
I made these changes a while ago then stashed them. They worked when I
needed them then, and seem to work now, but I haven't verified now so
don't trust 'em too far. :-)
Crittercism is dropping free support of FOSS apps, so I'm dropping
it. Unfortunatly integration isn't as clean: so far at least I haven't
figured out how to make it possible for others to build the 'd' variant,
which includes Crashlytics, without their having a Fabric API key.
Resetting it on every ACK etc meant it happened forever at the most
frequent interval, at least on devices that have both sides of a game,
which is my usual test setup.
In game config, when the play game button's hit and the changes pending don't
"matter" (require reset), apply them. The motiviation is to allow
setting the "disableds" and immediately launching a game via the button,
but I think it's the right thing to do anyway. Needs testing.
Deal with occasional droppage of SMS data messages by running a
timer (via AlarmManager) with backoff that resends any pending moves for
games connected via SMS. Successful receipt of SMS data resets the backoff.
When Android client is backgrounded with a game playing (BoardActivity
on top) then brought to front again it fails to reconnect to relay
because it didn't disconnect and the relay thinks it's still there. The
right fix is in making the java code do the right thing (complete
disconnect), but it seems harmless to just honor the reconnect in this
case. Doesn't even cause leaks, per valgrind.
cleanup, iterating over built-in data rather than my hard-coded VARIANTS
and BUILDS arrays, which now go away. Renamed obj- and libs- directories
to better fit the variables the system provides.
Add DEBUG-builds-only UI at the bottom of GameConfig for turning on the
comms feature dropping outgoing or incoming messages. The idea's to use
this to reproduce and fix stalls. There's a noticable slowdown opening
the GameConfig fragment, but it should all be no-op in a release build.
Add BuildConfig boolean that's true when a gradle property is passed in
from the fdroid metadata/build file. Test when putting together upgrade
state and omit app info when it's true, same as if from Play store.
F-droid build system modifies git-controlled files so no build will ever
be clean. So look for a -P property and if that's set don't use the
--dirty flag when capturing the git revision. Requires a change to the
fdroid metadata to pass that property.
Years back what I read said you opened and closed the database around
every query. Now I'm reading differently, that the OS will close it for
you on app shutdown and that it's ok to just leave it open. Trying
that after a few minutes on one device looks ok. Will need to test the
heck out of it, especially on older OS versions, before ship.
Play store reports crashes but stack crawl doesn't tell me where
from. So try catching the exception and on debug builds logging what
dialog is responsible.
