Merge pull request #187 from brarcher/pre-v0.18.1

Update for v0.18.1

CHANGELOG.md

@@ -1,3 +1,15 @@
+## v0.18.1 (2018-01-24)
+
+Changes:
+- Workaround crash during install on some Android versions (likely Android 5 and below). (https://github.com/brarcher/loyalty-card-locker/pull/184)
+
+## v0.18 (2018-01-19)
+
+Changes:
+- Fix crash when importing certain types of corrupted CSV files. (https://github.com/brarcher/loyalty-card-locker/pull/177)
+- Fix importing backups directly from the file system. (https://github.com/brarcher/loyalty-card-locker/pull/180)
+- Fix importing backups from certain types of content providers. (https://github.com/brarcher/loyalty-card-locker/pull/179)
+
 ## v0.17 (2018-01-11)
 
 Changes:

CONTRIBUTING.md

@@ -0,0 +1,91 @@
+How to Submit Patches to the Loyalty Card Keychain Project
+===============================================================================
+https://github.com/brarcher/budget-watch
+
+This document is intended to act as a guide to help you contribute to the
+Loyalty Card Keychain project.  It is not perfect, and there will always be exceptions
+to the rules described here, but by following the instructions below you
+should have a much easier time getting your work merged with the upstream
+project.
+
+## Test Your Code
+
+There are four possible tests you can run to verify your code.  The first
+is unit tests, which check the basic functionality of the application, and
+can be run by gradle using:
+
+    # ./gradlew testReleaseUnitTest
+
+The second and third check for common problems using static analysis.
+These are the Android lint checker, run using:
+
+    # ./gradlew lintRelease
+
+and FindBugs, run using:
+
+    # ./gradlew findbugs
+
+The final check is by testing the application on a live device and verifying
+the basic functionality works as expected.
+
+## Make Sure Your Code is Tested
+
+The Loyalty Card Keychain code uses a fair number of unit tests to verify that
+the basic functionality is working. Submissions which add functionality
+or significantly change the existing code should include additional tests
+to verify the proper operation of the proposed changes.
+
+## Explain Your Work
+
+At the top of every patch you should include a description of the problem you
+are trying to solve, how you solved it, and why you chose the solution you
+implemented.  If you are submitting a bug fix, it is also incredibly helpful
+if you can describe/include a reproducer for the problem in the description as
+well as instructions on how to test for the bug and verify that it has been
+fixed.
+
+## Sign Your Work
+
+The sign-off is a simple line at the end of the patch description, which
+certifies that you wrote it or otherwise have the right to pass it on as an
+open-source patch.  The "Developer's Certificate of Origin" pledge is taken
+from the Linux Kernel and the rules are pretty simple:
+
+	Developer's Certificate of Origin 1.1
+
+	By making a contribution to this project, I certify that:
+
+	(a) The contribution was created in whole or in part by me and I
+	    have the right to submit it under the open source license
+	    indicated in the file; or
+
+	(b) The contribution is based upon previous work that, to the best
+	    of my knowledge, is covered under an appropriate open source
+	    license and I have the right under that license to submit that
+	    work with modifications, whether created in whole or in part
+	    by me, under the same open source license (unless I am
+	    permitted to submit under a different license), as indicated
+	    in the file; or
+
+	(c) The contribution was provided directly to me by some other
+	    person who certified (a), (b) or (c) and I have not modified
+	    it.
+
+	(d) I understand and agree that this project and the contribution
+	    are public and that a record of the contribution (including all
+	    personal information I submit with it, including my sign-off) is
+	    maintained indefinitely and may be redistributed consistent with
+	    this project or the open source license(s) involved.
+
+... then you just add a line to the bottom of your patch description, with
+your real name, saying:
+
+	Signed-off-by: Random J Developer <random@developer.example.org>
+
+## Submit Patch(es) for Review
+
+Finally, you will need to submit your patches so that they can be reviewed
+and potentially merged into the main Loyalty Card Keychain repository. The preferred
+way to do this is to submit a Pull Request to the Loyalty Card Keychain project.
+Changes need to apply cleanly onto the master branch and pass all
+unit tests and produce no errors during static analysis.

app/build.gradle

@@ -13,8 +13,8 @@ android {
         applicationId "protect.card_locker"
         minSdkVersion 17
         targetSdkVersion 27
-        versionCode 19
-        versionName "0.18"
+        versionCode 20
+        versionName "0.18.1"
     }
     buildTypes {
         release {

gradle.properties

@@ -15,4 +15,9 @@
 # When configured, Gradle will run in incubating parallel mode.
 # This option should only be used with decoupled projects. More details, visit
 # http://www.gradle.org/docs/current/userguide/multi_project_builds.html#sec:decoupled_projects
-# org.gradle.parallel=true
+# org.gradle.parallel=true
+
+# The aapt2 tool creates an APK which fails to install on Android 5 and below if it contains
+# a bug. Build tools 27.0.1 has a mitigation. Avoiding aapt2 also avoids hitting the bug.
+# See: https://issuetracker.google.com/issues/64434571
+android.enableAapt2=false