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.
Crittercism is dropping free support of FOSS apps, so I'm dropping
it. Unfortunatly integration isn't as clean: so far at least I haven't
figured out how to make it possible for others to build the 'd' variant,
which includes Crashlytics, without their having a Fabric API key.
cleanup, iterating over built-in data rather than my hard-coded VARIANTS
and BUILDS arrays, which now go away. Renamed obj- and libs- directories
to better fit the variables the system provides.
Add BuildConfig boolean that's true when a gradle property is passed in
from the fdroid metadata/build file. Test when putting together upgrade
state and omit app info when it's true, same as if from Play store.
F-droid build system modifies git-controlled files so no build will ever
be clean. So look for a -P property and if that's set don't use the
--dirty flag when capturing the git revision. Requires a change to the
fdroid metadata to pass that property.
Name file and set internal constant sent to server to use same git rev
string so that the script will correctly identify whether the version I
have is the latest it has available. Fixes server offering to replace
with what I already have.
replace symlink silliness ant required with gradle commands to sign
debug builds with the checked-in (local file) debug keystore. Make
it possible for an environment variable to override in case somebody
wants to use his own.
Build different jni code (into different obj and libs directories) for
the different release/debug and xw4/xw4dbg combinations. This works when
only one build is done, but when doing two some later task tries to put
both multiple same-named libraries into the .apk and so fails. I still
think it's worth adding this to keep from using the wrong binary, but
that needs to be fixed.
cleanNDK just nukes all the directories. Easier than invoking build-ndk
clean...
