-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
App update notification #1608
Conversation
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Due to different signatures you already have to reisntall the app if you want to use the fdroid version.
How comes? As long as the package name and signing key does not change nothing needs to be re installed.
I agree. Although it should be enabled by default. |
That's true, but I'd like to get back to one version.
flavorDimensions "apkSource"
productFlavors {
github {
dimension "apkSource"
applicationIdSuffix ".github"
}
fdroid {
dimension "apkSource"
applicationIdSuffix ".fdroid"
}
} This means, we now have four different builds: None of them matches our release build because these new have suffixes. This means an upgrade is not possible. |
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. |
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. |
Hey @TobiGr, @theScrabi I agree - A single version will be a better approach; I'll look into replacing the flavor with signature check. |
@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 :) |
@theScrabi Just to be clear, we'll be going with the signature check method as suggested by @TobiGr, right? And not with different builds. |
Yes the signature check method. |
@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? |
@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 :) |
Thanks @TobiGr! @theScrabi Can you confirm both the keys? On the website I only see one - |
@krtkush Thanks, I was just about to test it. |
There was a problem hiding this 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.
Done. I really hope it is actually done this time 😛 |
@krtkush Looks good to merge. Thanks for changing the code that often! |
Done. |
…wPipe into 1520_app_update_notif
Hey @theScrabi, I was wondering why the latest release not have this feature included? |
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. |
Ohkay. I wasn't aware of this. Good luck with your semester. |
if (!mPrefs.getBoolean(app.getString(R.string.update_app_key), true) | ||
|| !isGithubApk()) { | ||
this.cancel(true); | ||
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Added feature described in #1520 and #1531.
Currently it is a very basic version. Will further build on this feature in the future.