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