Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App update notification #1608

Merged
merged 42 commits into from
Jan 23, 2019
Merged

App update notification #1608

merged 42 commits into from
Jan 23, 2019

Conversation

krtkush
Copy link
Contributor

@krtkush krtkush commented Aug 16, 2018

Added feature described in #1520 and #1531.

Currently it is a very basic version. Will further build on this feature in the future.

Copy link
Member

@TobiGr TobiGr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @krtkush!
Thanks for working on this.
Unfortunately, I think there are some details, which we need to discuss first. Apart from that, I've pointed some things out in the code which should be improved. But I recommend you to wait with fixes until we have finished our discussion.

My biggest concern about these changes are the additional build flavors. When someone installs NewPipe from F-Droid, he/she will always be forced to use this source to update the application.
Additionally, with this new config every user needs to uninstall the current version of the app.
Not only for this reason, but also as update notifications can be disturbing from time to time, I suggest to add a setting which handles the update options:

  • Enable / Disable search for new updates
  • Preferred download mirror (applies when F-Droid and GitHub versions are the same, see below).

To identify whether the app is from F-Droid or GitHub we need to check the app's signature. A guide how this can be achieved can be found here.

IMHO we should come back to one release apk using F-Droid's reproducible builds feature.

@@ -663,6 +664,9 @@ public void onPlaying() {
lockManager.acquireWifiAndCpu();

hideControls(DEFAULT_CONTROLS_DURATION, DEFAULT_CONTROLS_HIDE_TIME);

// Check for new version
new CheckForNewAppVersionTask().execute();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you run the check here, too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I remember the check was not being performed in the pop-up mode. Hence, I had to put it here. I'll check once again and make changes if needed.

@Override
protected void onPostExecute(String response) {

Log.i("Response--", response);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entry does not help us to find issues in the future. Please add some additional information or remove this log entry.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was not supposed to go into production. I'll remove it.

@TobiGr TobiGr mentioned this pull request Aug 16, 2018
@theScrabi
Copy link
Member

My biggest concern about these changes are the additional build flavors. When someone installs NewPipe from F-Droid, he/she will always be forced to use this source to update the application.

Due to different signatures you already have to reisntall the app if you want to use the fdroid version.

Additionally, with this new config every user needs to uninstall the current version of the app.

How comes? As long as the package name and signing key does not change nothing needs to be re installed.

Enable / Disable search for new updates

I agree. Although it should be enabled by default.

@TobiGr
Copy link
Member

TobiGr commented Aug 17, 2018

Due to different signatures you already have to reisntall the app if you want to use the fdroid version.

That's true, but I'd like to get back to one version.

How comes? As long as the package name and signing key does not change nothing needs to be re installed.

flavorDimensions "apkSource"
    productFlavors {
        github {
            dimension "apkSource"
            applicationIdSuffix ".github"

        }

        fdroid {
            dimension "apkSource"
            applicationIdSuffix ".fdroid"
        }
}

This means, we now have four different builds:
githubRelease
githubDebug
fdroidRelease
fdroidDebug

None of them matches our release build because these new have suffixes. This means an upgrade is not possible.

@theScrabi
Copy link
Member

But do we need the suffix?

I am with you though, I think trying to make the reproducible build work might not be a bad idea.

@TobiGr
Copy link
Member

TobiGr commented Aug 17, 2018

The current implementation uses the new build flavors to decide whether to check for an update. As mentioned above, there are other ways to do this (e.g. the signature). So if this is implemented in a different way, we won't need a suffix.

@krtkush
Copy link
Contributor Author

krtkush commented Aug 20, 2018

Hey @TobiGr, @theScrabi

I agree - A single version will be a better approach; I'll look into replacing the flavor with signature check.

@theScrabi
Copy link
Member

@krtkush @TobiGr so here are some updates. After the youtube amageddon that made us release v0.14.1 a few days ago, I had a conversation with the fdroid people about update speed.

It seems to be a complicated topic which seem to not get a widespread acceptance within their team. Therefore we should try and even deliver updates ourself even if its a version deploid by fdroid.

This on one hand makes things easier for us since we don't have to deploy two separate versions, and on the other hand we need to make NewPipe a reproducable build within fdroid.

@krtkush could you please try to fix the conflicts, and @TobiGr would you please review it after the changes are done.

I am willing to put this feature into the next version if it's possible :)

@krtkush
Copy link
Contributor Author

krtkush commented Sep 11, 2018

@theScrabi
Sure! I'll work on it this weekend.

Just to be clear, we'll be going with the signature check method as suggested by @TobiGr, right? And not with different builds.

@theScrabi
Copy link
Member

Yes the signature check method.

@krtkush
Copy link
Contributor Author

krtkush commented Sep 15, 2018

@TobiGr @theScrabi Does NewPipe use different KeyStores for the github and f-droid versions respectively?

I'll need the developer certificate signature of the KeyStore(s), as instructed in the linked article. Could either of you provide that?

@TobiGr
Copy link
Member

TobiGr commented Oct 4, 2018

@krtkush Sorry for the silence. We are all quite busy. If I am correct, you can find the fingerprint on @theScrabi's website: https://schabi.org If you need any further information about the signing key, please ask him :)

@krtkush
Copy link
Contributor Author

krtkush commented Oct 6, 2018

Thanks @TobiGr!

@theScrabi Can you confirm both the keys? On the website I only see one - SHA1: B0:2E:90:7C:1C:D6:FC:57:C3:35:F0:88:D0:8F:50:5F:94:E4:D2:15

@TobiGr
Copy link
Member

TobiGr commented Nov 23, 2018

@krtkush Thanks, I was just about to test it.

Copy link
Member

@theScrabi theScrabi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will block until issue with vectors is done.

@krtkush
Copy link
Contributor Author

krtkush commented Nov 25, 2018

Done. I really hope it is actually done this time 😛

TobiGr
TobiGr previously approved these changes Dec 3, 2018
@TobiGr
Copy link
Member

TobiGr commented Dec 3, 2018

@krtkush Looks good to merge. Thanks for changing the code that often!
@theScrabi Can you please remove your block?

theScrabi
theScrabi previously approved these changes Dec 15, 2018
@theScrabi
Copy link
Member

Done.

@krtkush krtkush dismissed stale reviews from theScrabi and TobiGr via 794c370 December 28, 2018 12:39
@krtkush
Copy link
Contributor Author

krtkush commented Jan 19, 2019

Hey @theScrabi, I was wondering why the latest release not have this feature included?

@theScrabi
Copy link
Member

I wanted to take care about pending features once my semester is over. However the sudden release came because of the full shutdown on Thursday.

@krtkush
Copy link
Contributor Author

krtkush commented Jan 20, 2019

full shutdown on Thursday

Ohkay. I wasn't aware of this.

Good luck with your semester.

Comment on lines +63 to +66
if (!mPrefs.getBoolean(app.getString(R.string.update_app_key), true)
|| !isGithubApk()) {
this.cancel(true);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking this before starting the task would be more efficient, at App#L108

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is 4 years old code, is this still the case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Stypox,

I apologize for my previous comment. I didn't realize that the code was 4 years old, and I see that it has now been deleted. I was going through the code to explore and understand the codebase, but I should have been more careful about commenting on old code.

I'll be more mindful of the age of code in the future and avoid commenting on old code unless I'm sure it's still relevant.

Thanks for your patience and understanding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants