I either remove it or add the 64-bit abi. Since it's only there to run
in the emulator let's just leave it in for DEBUG builds. If I need to
run a release build in the emulator I can add it back.
When I started opening a lot of games at the same time hit a race
condition that synchronized fixes. Duh. Since two similiarly used
variables with the same name confused me, changed that too.
Add a third processor type to the .so, and fix first compile-time
warnings and then a few dumb bugs based on assumptions about ptr sizes.
Works to play networked games and browse wordlists, but is not
extensively tested and needs to be before release.
Looking for a common but not-yet-reproducible situation where the
gamelock gets stuck preventing a game from being opened, usually related
to a move arriving. One thing that looked wrong is it seemed possible to
have the refcount drop to 0 then get increased again, causing somebody
to thing he has a lock when it's actually unlocked. So assert to try to
catch that case (and synchronize to make it much harder.)
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.
It's crashing all the time and involves a system that only exists in
debug builds. So I should understand the root cause, but other stuff
needs to get done first.
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.
I can't reproduce this, but while testing recovery from DatagramSocket
recreation in RelayService got enough to know that somehow a timer's
procptr's not set. So test before calling, and log instead of crashing.
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.
