command: find . -name '*.jp*g' -o -name '*.png' | xargs exiftool -all=
Did this because fdroid is complaining about metadata and I can't see
any obvious changes in the appearance of the app, but it's not
well-considered. Back this out if there are problems.
I think there's a rare race condition here. Assuming it results from a
bad network state rather than two sends coming too quickly, respond to
not having a connection by killing the thread so the next send will
retry.
Failure to immediately get a lock for a rowID in an intent meant that
other intent processing kicked in, and might have done the wrong
thing. So now if there's a rowid in it we try nothing else. And we use
the GameLock callback mechanism to deal with the case where it's
temporarily unavailable, as it will be when an incoming move is being
dispatched to it.
(DEBUG only) I'm seeing deadlocks in a non-reproducible way and need to
get at the source. This should log the stacks of long-held locks, and
notify via Toast (when possible) when it occurs.
No point in worrying about whether a thread exists without emptying its
queue. Instead have a thread start when something's added to the queue
and exit when it's been empty for a while. Only trick is the need to
remember the phone number[s] on behalf of which a retry's necessary
because jni code is waiting to see if combining can be done.
Should not show the new you-can-lookup-uncommitted-words hint for
already-played words, so needed to be able to tell difference between
the two. Now you can -- and on the gtk side I draw them differently
because I can.
Scrolling's needed in some cases, and you can't easily put a ListView
inside a ScrollView. So replace the ListView with a LinearLayout whose
contents I manage manually, and wrap the whole layout in a ScrollView.
Just keep a thread for each
phone we're sending to or receiving from, and pass them packets and
other things to send or (incoming case) process. So far the threads
don't die, but they will soon once there's nothing in their queues. Just
need to be sure there's no racing there.
This is to work around the frequent failure of the OS to pass enqeued work
into the service within a reasonable amount of time (I expect seconds, but see
delays of minutes or even hours.)
Theory is that the store's buggy site is presenting its
banned-permissions interface because it's detecting a Receiver that
requires SMS_RECEIVE permission even though the permissions themselves
aren't there any more.
Fix longstanding bug triggered by something as simple as putting device
into and out of airplane mode. Once the class-variable socket was
created it was never replaced. Now respond to exceptions that mean it's
useless and set it to null so existing logic will recreate it.
When enqueuing Intents for any of the three services, cache the
Intent. When onHandleWork() is called, remove the equivalent cached
intent. Then periodically check for intents that have been stored for
more than 60 seconds, and post a Notification alerting user to
stall. The user will likely have noticed that messages aren't flowing,
so this will simply explain the problem. Includes an "email author"
button.
Move some work into superclass where instrumentation can be added to
greater effect. And remove from BTService an earlier attempt (at stall
detection.)
toward tracking down relay stalls, log a bit more in resend process and
add UI to support an option where there's no reliance on
polling (i.e. FCM only)
