search

kiwix / kiwix-android

Kiwix for Android
https://android.kiwix.org
GNU General Public License v3.0
827 stars 444 forks source link

When side-loading the APK on Android, Google Play Store recognizes the app and tries to upgrade it. #3933

Closed GlennLasher closed 6 days ago

GlennLasher commented 2 weeks ago

As someone who needs to side-load content on Android, I need to use the side-loaded app, because the version that is in the Google Play Store does not support side-loaded content, as required by a Google Play Store policy.

Description

When side-loading the app, the Google Play Store is able to identify the side-loaded app as if it were downloaded via the App Store. As such, it will attempt to upgrade the app, and when it succeeds in doing so, it breaks the ability to view side-loaded content.

Expected behavior

The side-loaded version of the app should not be recognized by the Google Play Store. Being unrecognized, the Google Play Store should not attempt to upgrade it.

Steps to reproduce the behavior: Install any version of the side-loaded APK except for the newest revision. Open it. Click the + button. Find the path to your side-loaded content. View it.

Go to the Google Play store. Touch the profile button. Touch "Manage apps and Device". Touch Manage. Touch "Updates available." Scroll through the list and find that Kiwix is on it. Update it.

Go back to Kiwix. Attempt to access the side-loaded content. Fail to do so.

Environment

kelson42 commented 2 weeks ago

@GlennLasher Thank you for your quality issue. This is a known issue/limitation. @MohitMaliFtechiz Would it be easy to have an other appid for the APK, at least as long as we don't have reintroduce the ability to sideload ZIM in the PS version? What kind of side effect should we expect? @benoit74 @Popolechien We discussed this last week, had we found any reason not to do that (I don't remember clearly our conclusions).

benoit74 commented 2 weeks ago

As far as I remember, we didn't came to any conclusion other that:

Popolechien commented 2 weeks ago

My notes only say "Open a ticket so they could get separate App IDs". So I guess that part of the job is done 😀

Jaifroid commented 2 weeks ago
  • impact of having two app IDs is at most very unclear for now and must be very carefully assessed, since this is a change which is going to be painful for users

FWIW, for the Microsoft Store app, I very definitely need two different app IDs: one for the version installed from the Store and another for the version installable from GitHub. Partly this is dictated by the need to sign the GitHub version with the Kiwix code-signing certificate, whereas MS signs the app in the Store. The result is that users can install both apps. But I never had a complaint, and no-one has expressed confusion about it. If they're smart enough to sideload, they know what they're doing!

If there are two different IDs, then that should keep settings and scoped storage separate for each app...

kelson42 commented 2 weeks ago

@MohitMaliDeveloper Could that fix be done easily?

MohitMaliFtechiz commented 2 weeks ago

@kelson42, @Jaifroid, @Popolechien, @benoit74 We had an issue like this https://github.com/kiwix/kiwix-android/issues/3839 and we have this type of problem until we will not use the different packageName for the website APK, and we have a last option to resolve this problem as @Jaifroid mentioned in his last comment. We need to use the different packageName for the website and nightly APKs so that playStore does not recognize these apps and does not show them in the update list.

@MohitMaliFtechiz Would it be easy to have an other appid for the APK, at least as long as we don't have reintroduce the ability to sideload ZIM in the PS version? What kind of side effect should we expect?

But before doing this, we need to know the drawbacks of this. After changing the packageName for debug and nightly the previous user can not update their existing app since the packageName will be different for these new apps so it will install the new app instead of updating the existing app. This means the previous data of the user can not be available in these versions of apps(e.g. notes, history, and the bookmark can be exported from the previous app and imported into the new version. But there is no option available for exporting the history and notes).

@MohitMaliDeveloper Could that fix be done easily?

@kelson42 Yes, it won't take too long to be done. We just need to create a variant for website and nightly APK and need to refactor the CI to upload these APKs.

Jaifroid commented 2 weeks ago

After changing the packageName for debug and nightly the previous user cannot update their existing app since the packageName will be different for these new apps so it will install the new app instead of updating the existing app.

Maybe t's just a case of educating users that they won't be able to access their scoped storage and settings from the sideloaded version (and vice versa)?

kelson42 commented 2 weeks ago

@kelson42 Yes, it won't take too long to be done. We just need to create a variant for website and nightly APK and need to refactor the CI to upload these APKs.

We don't want a new variant, we just want the APK for download.kiwix.org to have an other packagename. What is the current packagename?

MohitMaliFtechiz commented 2 weeks ago

Sorry for not being so clear here, I meant we need a productFlavors here https://developer.android.com/build/build-variants#change-app-id. The current packageName is org.kiwix.kiwixmobile.

kelson42 commented 2 weeks ago

@MohitMaliFtechiz Then lets go for it in next minor milestone.

kelson42 commented 1 week ago

@MohitMaliFtechiz Have finaly moved to current milestone with appid "org.kiwix.kiwixmobile.standalone".

benoit74 commented 6 days ago

Where is the impact assessment of having two distinct appId? Are we sure we don't need a distinct appId for nightly as well?

MohitMaliFtechiz commented 5 days ago

@benoit74 A different appId is required for the website and nightly APK to prevent updates from showing on playStore https://github.com/kiwix/kiwix-android/issues/3839#issuecomment-2109434402, and we have now a different appId for nightly as well.

benoit74 commented 5 days ago

I agree that we need at least 2 appId. I wonder if we should have 3. With https://github.com/kiwix/kiwix-android/pull/3951, appId is identical for the website version and the nightly as far as I've understood.

As far as I know, we have 3 stuff published: a "release" (playstore version), a "nightly" and a "standalone" (website version). Sharing the same appId between "nightly" and "standalone" is something which has not been discussed and might prove to be a good or a bad idea. It should be argued from my PoV

But since we have no idea about what are the downsides of having 2 appid, it is difficult to decide if there is a problem to have 3.

Jaifroid commented 5 days ago

But since we have no idea about what are the downsides of having 2 appid, it is difficult to decide if there is a problem to have 3.

We know what the downside is of having a single ID for all apps. We know that, conceptually, an appID is a unique identifier for an app, ensuring that there is no conflict between same-named apps in the Store so long as they have different IDs. We also know that the app-scoped storage used is unique to the appID, not to the name of the app. So we can conclude that the effect of having a different ID is to isolate the apps, and any downloads stored in app-scoped storage, completely from each other. This is a desired effect. The only clash could come about in terms of which app is used for opening a file shared from another app, if Kiwix has that functionality. However, Android manages that by allowing the user to choose which app to use.

Regarding whether to have three IDs, this seems less crucial. As the Play Store won't automatically update the APK or the nightly versions, the main effect of sharing the ID between each is that an installation of one will overwrite the installation of the other. They will both use the same app-scoped storage, and this doesn't get erased across installs (in my experience to date). This might be beneficial for developers who want to test nightly on a set of already downloaded archives, and for users who want to have the very latest version of the app for a specific feature without having to wait for an official release. It could also represent a drawback if developers wish to test the nightly app on a physical device without affecting their main app. Swings and roundabouts.