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.
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.
