Move connection options READ_PHONE_STATE check from ConnViaViewLayout to
GameConfigDelegate and give it a rationale. Preferences stuff can't do
permissions because it can't override onRequestPermissionsResult (base
activity is of wrong class). Should fix that at some point, either by
moving to preference fragments or with a dummy activity to go over the
top.
Explicit "ask again" and "skip" buttons in alert showing rationale;
check/ask for permission before sending invitation via SMS; warn each
time SMS-enabled game is opened without permission but allow it to stay
open and if necessary send an invitation.
An edge case, but: doing "new from" on a game without any connection
types crashed because of an assertion in comms that assumed
addr_setType() was being called on zero-initialized flags, which
shouldn't have been a requirement. Pulled that as well as java code that
added RELAY-type connectivity to any game that had none. If a game has
none, leave it that way.
Add new static method that takes a request, rationale and Action, offers
the rationale if required and then, if user hasn't cancelled, asks for
permission. Eventually the Action is issued with either POSITIVE or
NEGATIVE. Use this to ask for STORAGE when downloading upgrades and
moving wordlists to the downloads area.
You need PHONE permission to start and play an SMS game but not to have
started it in response to an invitation. But to rematch you need it. So
ask, including offering a rationale that differs depending on whether
there's a way for the game to communicate once SMS is removed.
They were hacks for debugging SMS early on, probably infrequently
seen. Instead post messages. BUT: they aren't being received because of
how listeners get cleared in onPause(). Needs to be fixed, but there's
no harm in having them dangle for now.
Remove strings that no longer exist in English, add missing "other"
quantities in Japanese (taking a guess from context that it's ok to use
generic counters), and in a couple of languages fix typos in format
specifiers that would have caused crashes.
Let's make it easier to add to the set of available BT devices from the
place where the user sees the need. TODO: update the descriptive text,
but not this release since it'll break existing localizations.
On launching SMS invite dialog, ask for READ_CONTACTS permission. Where
it's needed, though, is for the user-invisible process of translating
phone numbers to names (not launching the Contacts app via an
Intent). This just seems like the best place to ask since the user's
thinking about contacts and phone numbers.
Add post-open test for SMS and then ask for SMS permission, giving
rationale if the OS says I should. Meant adding a new interface for
rationales and wiring that in. It's a bit spaghetti and I may think of a
cleaner way later.
When opening a game that sends via SMS, check if it has permission and
offer to remove the config if it doesn't, removing a similar check from
pre-opening code. (Here it'll catch e.g. games opened from the
GameConfig process.) Sends/receives without SMS permission are already
caught by existing catch{} blocks, so there's no crash.
rewrite perms23 class to use Builder pattern, making it easier to pass
more than one required permission. Use that (with hard-coded set for
now) to check and ask for permissions a game needs to communicate. Offer
to remove the comms methods the user doesn't want to permit (but that's
not implemented yet.)
Add UI, minor thanks to recent refactoring, to allow invitations via
wifi direct. Uses a mapping of all currently known device mac addresses
to names, with only the latter shown to users. Works well, though
something I changed seems to have causes devices to start losing track
of their connections to each other.
Got to the point where I have an open socket for the packet I want to
send! Lots of changes to how discovery works seem to have improved
reliability though I'm still unimpressed. Much to learn.
better strings, and explain when pref changed that user must restart for
it to take effect. Actually restarting from inside prefs delegate is
hard enough I'm not doing it for what should be advanced users.
When a device is a tablet and not a first-time install, put up an offer
to enable dual-pane mode. Change confirm-alerts to include
do-not-show-again box, and use that. Add menu item, hidden when not in
dual-pane mode, to turn it back off. Exit app after posting a
notification and a toast on changing that preference so it'll take
effect.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
