[QA] Add content provider to handle settings in QA variant

[jesmrec]

Summary

Adds a ContentProvider to the qa variant that allows to handle the shared preferences with testing purposes.

The ContentProvider overrides the call function that receives three parameters:

method : name of the method that will execute the action. In this case, only one method set_boolean since it's intended (for the moment) for boolean preferences
arg: the name of the preference
extras: value of the preference (in this case, true or false)

How it works

1. Build the branch with qa variant to get an apk.
2. Plug on a device/emu and install the apk
3. With an adb command, the content provider is called with the proper arguments

F. ex:

to enable the show_disabled_spaces preference:

adb shell content call --uri content://com.owncloud.android.test.preferences --method set_boolean --arg show_disabled_spaces --extra value:b:true

to disable the show_hidden_files preference:

adb shell content call --uri content://com.owncloud.android.test.preferences --method set_boolean --arg show_hidden_files --extra value:b:false

Security

In order to assure that this implementation is only available in the qa variant, the following checks have been performed:

1. Check that Manifest is OK

Firstly, a Manifest for every variant is generated:

./gradlew clean
./gradlew :owncloudApp:processQaReleaseMainManifest
./gradlew :owncloudApp:processOriginalReleaseMainManifest

Then, inspect them:

grep -n "TestPreferencesProvider" owncloudApp/build/intermediates/merged_manifest/qaRelease/processQaReleaseMainManifest/AndroidManifest.xml

Result: 81: android:name="com.owncloud.android.test.TestPreferencesProvider"

That means, the qa manifest contains the TestPreferencesProvider class.

Let's check in the original:

grep -n "TestPreferencesProvider" owncloudApp/build/intermediates/merged_manifest/originalRelease/processOriginalReleaseMainManifest/AndroidManifest.xml 

That returns no results, so the original manifest does not contain the TestPreferencesProvider class

2. Check if the compilings contain the TestPreferencesProvider class

Execute the following commands

./gradlew clean -> clean up directory
./gradlew :owncloudApp:compileOriginalReleaseKotlin -> compile the originalRelease variant
find owncloudApp/build/tmp/kotlin-classes/originalRelease -iname '*TestPreferencesProvider*' -> tries to find the TestPreferencesProvider inside of it. It shouldn't find anything.

./gradlew clean -> clean up again
./gradlew :owncloudApp:compileQaReleaseKotlin -> compile the qaRelease variant
find owncloudApp/build/tmp/kotlin-classes/qaRelease -iname '*TestPreferencesProvider*' -> it should return owncloudApp/build/tmp/kotlin-classes/qaRelease/com/owncloud/android/test/TestPreferencesProvider.class

3. Check the presence of TestPreferencesProvider in the artifacts

Build a signed apk with both original and qa variant, and execute over both of them:

$ANDROID_HOME/cmdline-tools/latest/bin/apkanalyzer dex packages owncloud.apk | grep -i testpreferencesprovider

(set the right apk name in the command fot every case)

That command list the code files inside the apk. The TestPreferencesProvider class should be listed only in the apk that was built with the qa variant.

Those checks show that the originalXXX variants will never include the TestPreferencesProvider and the qa Manifest.

(open to other ideas)

App:

• Add changelog files for the fixed issues in folder changelog/unreleased. More info here
• Add feature to Release Notes in ReleaseNotesViewModel.kt creating a new ReleaseNote() with String resources (if required)

---

QA

[joragua]

Some comments @jesmrec!

[joragua]

No newline at end of file

[jesmrec]

👍 Added

[joragua]

Would it be possible to create a variable for set_boolean (similar to prefsName)?

[jesmrec]

yep, since the name of the method is static, i'll add it as a companion string, and same for the prefs_name. What do you think?

[joragua]

Nice! 💯 Is prefsName also a static value? We could move both values to the companion object

[joragua]

What would happen if context, arg or extras were null? Would it be possible to use a safe calls (?.) for these arguments? 🤔

[jesmrec]

it shouldn't, or the call to the provider will fail. Anyway, let's do some control over its nullability

[joragua]

I would write this method on a single line for clarity (just my personal opinion) 🙌🏻

[jesmrec]

sure, no problem 👍