Did a bunch of stuff to inherit from JobIntentService and use enqueue(),
but doesn't work yet. OS is unable to bind, with this error:
09-21 17:20:51.678 3050 3050 W JobServiceContext: Time-out while trying to bind 2edee28 #u0a277/1111 org.eehouse.android.xw4dbg/org.eehouse.android.xw4.BTService, dropping.
Notifications don't work on Oreo without this change, which includes a
new Support Library in order to get NotificationChannel and creates and
uses that as docs describe. Requires that MinSDK be raised from 8 to 14,
which may lock some users out. It *should* be possible not to do this in
the fdroid variant since their app store doesn't requires SDK 26, but
I'll look at that later.
Some devices, including my Moto, are apparently calling server_do() more
than most. When the game's supposed to be asking the user to pick tiles
that resulted in stacked TilePickAlerts. The stack of these
sending (taken together) too many picked tiles to the game made it
crash. So modify server to have only one pending tile-pick request going
at a time. Because the server can't know when the user dismisses the
alert in Android and so won't post again, respond to the dismissal by
closing the game. Reopening will put it in a state where the tile picker
can get called again.
Logic error meant it was never sent. Now always send on receipt of a
well-formed invitation, even if e.g. the recipient's missing a wordlist
and the game can't be started immediately.
Had inadventently changed how NetLaunchInfo was transmitted, and crashed
on receiving from older builds. Fix to not crash, and then fix to send
and recieve in the old format.
So now all jni code uses a single dutil context, but also a single
mempool and jniutil instance instead of new instances of the latter two
per game and dict-iteration.
A number of jni calls were "stateless", which meant they allocated their
own vtmgr and mpool instances each time invoked. Instead invoke them
with the global jni closure and add to it vtmgr (already has mpool) and
use these instead of allocating/freeing each time. To make sure no race
conditions are introduced (mpool, though debug-only, is probably not
thread-safe), guard these new uses with an in-use flag. If that fires
I'll need a mutex or something.
Somehow I got a wordlist into a location different from what was
recorded in the DB table and since the delete command matched on
location as well as name it was never deleted (which meant the checksum
was never updated and so upgrading never seemed to succeed.) Removing
the match on location fixed that problem, and since I don't see any harm
in cacheing only one version of a wordlist will simply leave it that
way.
Did a bunch of cleanup as well.
