Ask for consent before checking for updates

[TobiGr]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

Ask for consent before enabling auto update check.

NewPipe is contacting its servers without asking for the users' consent. This is categorized as "tracking" by F-Droid (see #10785).

This PR disables checking for updates by default and adds a dialog asking for the user's consent to automatically check for updates if the app version is eligible for them. After upgrading to a version containing this commit the user is asked directly on the first app start. On fresh installs however, showing it on the first app start contributes to a bad onboarding an welcoming experience. Therefore, the dialog is shown at the second app start.

To Do

• Implement settings migration triggering the consent check on update
• Refactor the App.isFirstRun to be set inside App and read only (**should the variable be static?**)
• Provide testing APK which does not rely on release signature check to ask for consent
• Do testing

Before/After Screenshots/Screen Record

Fixes the following issue(s)

• Closes Disable update checker for F-Droid #10785

APK testing

Install this release APK for testing, singed by my dev key:
NewPipe-check-consent.zip

Due diligence

• I read the contribution guidelines.

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[AudricV]

If the user closes the app when it gets the dialog and reopens it, does the dialog appear again? From what I understood of the code changes in this PR, it doesn't seem to be the case.

Code looks good to me, even if the placement of the alert dialog code in the update settings fragment seems a bit weird to me.

[TobiGr]

Code looks good to me, even if the placement of the alert dialog code in the update settings fragment seems a bit weird to me.

I put it there because the dialog is working with the setting to keep that stuff in one place. For that reason, I did not put it into the MainFragment. If you want me to move it there, I'll do it.

[AudricV]

I put it there because the dialog is working with the setting to keep that stuff in one place. For that reason, I did not put it into the MainFragment. If you want me to move it there, I'll do it.

That's fine, anyway, when this will be "compostified" in the future, it will be probably placed in the right place :)

Do you think that the first run code migration should be reverted? I don't think that's necessary, but do what you think is the best :)

The rest of the changes looks good to me except this comment (a small optimization). Thank you for your efforts!

[TobiGr]

Do you think that the first run code migration should be reverted? I don't think that's necessary, but do what you think is the best :)

The migration is not necessary anymore because wasUserAskedForConsen() is checked on app start

[AudricV]

The migration is not necessary anymore because wasUserAskedForConsen() is checked on app start

I meant the refactoring of the first run code, sorry for the confusion.

[Stypox]

Code looks good :-)

[TobiGr]

I meant the refactoring of the first run code, sorry for the confusion.

Will do that tomorrow

[TobiGr]

@AudricV I just looked at the code again. Now that we have the isFirstRun() check in the MainAcitivity again, the refactor is needed. I'd therefore keep it as it is and would squash the commits if you are ok with that.

[Stypox]

Here an APK for you to test: NewPipe updatechecker.zip
This is the expected behavior:

• The first time the app is opened, no update check is run, and no consent is asked (this is to avoid a bad onboarding and welcoming experience)
• The second time, no update check is run, but the user is asked for consent
• If the user accepted to check for updates, from the third time onwards, the app will check for updates, otherwise it will never do so

_{The APK is signed with @Stypox keys. The fingerprint for which to check for updates has been set to f3c6b6ddf4f4c9e2fa5c5e65799dc388d17eae626acfa6e29f571b3520883b75, i.e. the fingerprint of my key. The version code of the APK is that of 0.26.0 (995) instead of 0.26.1 (996) so that version checks show a notification. The package name is org.schabi.newpipe.updatechecker.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[Stypox]

Thank you! I pushed two more commits to improve the checks a bit more (previously the default value when geting update_app_key was true, which would have resulted in update checks running without consent)