When a stream reader and writer are out of sync it often shows up as
trying to read off the end of the stream (firing an assert.) It's useful
to know where that's coming from on android where there's usually no
stack trace in the jin world. So pass __func__ in using macros, and log
before asserting. Crude but quick and already useful.
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.
When a word's been formed as part of the current turn, but not yet
committed, allow long-tap to trigger an offer to look it up online same
as for already-committed words. Allows checking the legality of
potential plays AND figuring WTF the hint feature just suggested.
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.)
I'm seeing my simultaneous access assert fail, so might as well break
fix it the foolproof way. It's background threads only that are calling
this stuff on Android so blocking them shouldn't hurt.
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.
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)
I got bitten when creating a new variant leaving the permission out of
the manifest but using a config flag to claim it was there. Better to
have just one place to configure that. So check for presence in the
manifest and, for now, assert that that matches the isBanned flag. Soon
the isBanned flag can be removed.
Some people will decide to leave SMS comms in while I look for an
alternative. Maybe. Don't show them the same alert every time they open
the game. In the process removed what seemed to be a duplicate ivar.
There's no one way to launch an SMS app with a ready-to-send
invitation. So try the two that work on our two phone/app combinations,
iterating until startActivity() succeeds. The code's set up to have new
recipes added easily.
Lots of work dealing with banned permissions (SEND_SMS and
RECEIVE_SMS). First, if they're banned and NBSProxy is installed, just
use it as if the permissions had been granted. When it's not there,
explain at various points where users will otherwise be confused: when
they try to invite using data sms, or when they open a game that already
uses it.)
It's an error to use an env with the wrong thread, but it IS possible
for more than one thread to be associated with the same env. So don't
assert to the contrary.
Seeing the occasional crash and trying to plug leaks that might be
contributing. I think I fixed the Gameptr.finalize() assertions I've
been seeing forever but the thread match assertion remains. Logs will
help catch that.
Didn't think it was required, but once the app started getting messages
in the background it stoped working or crashed. Changes are minimal
because this service isn't responsible for receiving messages: it
doesn't have the long-lived threads of the BT and Relay services.
Lots of threads call the smsproto code now so the existing check was
failing. Replace it with one that ensures that only one thread at a time
is running the code. Debug-builds only.
What I've been calling SMS is now "data sms" (or "nbs", in
code). There's a new way of inviting, called "User Sms" or somesuch,
that launches the user's SMS app with a URL and phone number, much like
email (save that no addressing is required by the inviter.) This new way
won't be involved in the ban on SMS permissions. (But play by NBS is
still awesome and will stay where it can.)
Get rid of the single sender thread and the complexity of querying
individual queues for their state (and the slowdown that happened when
successful writes had to wait for those to devices that weren't
responding). Instead each PacketAccumulator does its own waiting with
timeouts and backoffs, wakes itself when appropriate, and periodically
sends if it can make a connection. Now when there are a bunch of
messages ready they'll get sent pretty quickly once connections to the
remote device start to be successful.
A device where the OS isn't servicing enqueueWork() requests won't write
back to sockets it accept()s, causing the sender's writer to block
forever. So give it 30 seconds then kill the socket.
Add support for the old protocol, and define to use it. After the next
release has been adopted and everybody can read the new protocol another
release will turn it on.
Fix race condition that would have cleared all messages including those
added after a send began. In the process, move to storing outbound
messages individually rather than concatenated in their stream format.
Set a boolean every time app's upgraded, and clear it on first launch of
MainActivity. In between, if we try to launch the BTService but the OS
doesn't schedule it, post a notification asking user to launch the app.
Lots of changes. Old BT proto is no longer compatible. New one
batches messages per device and sends all on a single connection.
The queue (now a single buffer) is now a static global and the thread
that services it doesn't die (but gloms onto whatever Service instance
is most recent.) Code to pack and unpack the protocol can probably be
reused for wifi-direct or any other pass-through transport.
I'm seeing an assertion failure in cleanup that could be explained by
the cleanup happening when initGame() has been called but no subsequent
jni method that would have added the env to the map. So let's add it
immediately so that can't happen.
JNIThread is somehow sticking around sometimes and holding the lock for
a game so that that game can never be opened again. On the theory that
there's some place retain() was called but not release(), use the thing
in try-with-resources wherever possible. Which is pretty much
everywhere.
Also added age to the lock-holder report being uploaded.
I'm seeing something permanently lock a game so it can't be opened. So
add code to report the stack of the owner to Crashlytics when opening
fails 3 times in a row. It's stubbed out for non-debug builds.
I didn't like having to re-open a game to archive it after
rematching, so now there's a checkbox that lets you archive it after
either rematching OR just using OK to dismiss the alert. Also fixed
rematch of a solo game causing new game to be created in Archive
group if that's where the source game was.
squash me
Got tired of the space the forground-service notification icons were
taking. So now BT sends and receives are done via static threads and
onHandleWork(). The send thread times itself out quickly. The receive
thread doesn't yet. We'll see how long the OS lets it run and what
needs to be done to deal with that.
It's useful when testing to have the remote device play without human
interaction. So add an option, and UI to trigger it, for the players
created remotely in response to an invitation to be robots. There are
guards in place to catch the feature slipping into a release build.
Eliminate the writer thread, since onHandleWork() is already getting
called on a thread and can process the outbound queue itself. And get
rid of reader thread needing to wait for an instance of the RelayService
to be available to process a packet (which was taking 5-10 seconds all
the time): just post received packets via an enqueueWork() call using
the app context that's always available.
GameListItem was clearing its summary when kicking off a replacement
load. Instead keep the old around in case somebody wants it (e.g. to
figure out what menus to enable) until the reload finishes.
Also add logging of how long loading takes. I think a cache might be
called for.
Darned thing was dropping packets, failing to connect games built in
response to invitations, and otherwise misbehaving. First was due to not
resheduling when exited with outbound packets in queue; second to not
overriding relayNoConnProc() (due to signature change.) Though it still
happens occasionally.... Also added timestamps to track how long it
takes a packet to be sent and ACK'd.
Not sure why I was doing this, but it's not worth the
trouble (e.g. stopping updates of other data to fix an android bug
sending too many reregistration messages.) So now just use the first
element of arrays, replacing what's there instead of prepending. Ideally
those columns would not be arrays, but that's a harder change.
