Use low-level NFC, a combination of emulated card and reader mode, to
work around Google's removal of "beaming" support from Android 10. App
emulates a card by declaring support in its AndroidManifest. When a game
is open that has data to send, it goes periodically into read mode. If
two devices are touched while one is in read mode and the other isn't,
they handshake and open a connection that should last until they're
separated. The devices loop, sending messages back and forth with or
without data (as available.)
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.
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.)
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 modified existing translated strings, adding the new clause. Not doing
that would cause the existing strings to be stripped because they'd no
longer have the matching set of format specifiers.
Once built for SDK 26 the old GCM support code crashes as it's calling
startService() from background. Duh! Will have to bring in Firebase's
replacement at some point. For now if I'm to release it has to be
without GCM.
It's a pain to have to change code to run in Genymotion, and to have
upgrade not testable using Genymotion. Consider verting this change
before next release.
Notifications don't work on Oreo without this change, which includes a
new Support Library in order to get NotificationChannel and creates and
uses that as docs describe. Requires that MinSDK be raised from 8 to 14,
which may lock some users out. It *should* be possible not to do this in
the fdroid variant since their app store doesn't requires SDK 26, but
I'll look at that later.
For some reason my laptop wouldn't build without this change. No idea
what happened to the newer version I was using or if the change
works (beyond compiling). Should be easy to find the change later if
it's a problem.
This seems to fix that app, when built by me where GCM_SENDER_ID's set
in the environment, being a battery hog. Apparently google's code
doesn't handle being passed the wrong senderID very well.
In Dbg version only (with enabling boolean moved to BuildConfig.)
Currently crashes when first used, and recipient can't always connect to
relay until app rebooted. And of course there are still open questions
like how to populate the list -- how user learns the deviceID of an
opponent.
As a first step, use mine and android's and assert results are the
same. Note using built-in Base64 class requires moving the min android
version from 7 to 8.
Copy config file into the right place, turn it on for debug builds, and
fix compile-time complaints by adding -keep clauses. Resulting builds
seem to work (after a few minutes in emulator only) except that net
status icon taps crash at first (eventually recovering somehow) likely
because of problems with base64 en/decoding which goes through jni.
