change application id about vanadium HOT 24 CLOSED

If I had to solve this problem as a one-time issue, I would probably backup the app data, rename the package name within it, and restore it. I am not sure though whether this has ever been possible (I remember so) or whether it's still possible.

That's what I am trying to do and what the issue is about. It seems original-package is supposed to offer that for system packages (i.e. preserving and then transferring over the previous data) but I can't get it to work.

I would follow whatever trick/strategy Android/Google are already using for this purpose. My point was more that rowing against the way application data is segregated will not be worth the effort.

I'm not rowing against the way that application data is segregated. I'm trying to rename the applicationId of a system app while preserving the application data rather than having it automatically deleted as part of the OS upgrade as would usually happen. I'm trying to use what appears to be the standard approach for this. I don't have the time to pursue this any further so the applicationId is going to need to be left as is for the time being unless someone wants to help me with it.

from vanadium.

From which package name to which package name?

If you are using the Chromium package name then it has to be done regardless, as you're not shipping Chromium technically speaking.

from vanadium.

From org.chromium.chrome to org.grapheneos.vanadium, but it will have to be done in a way that doesn't lose existing data on the installs. It doesn't have to be done but it would be nice to have a proper Vanadium package name. It's also currently signed with the device release key as part of the build which could become an annoyance later on. This issue is really about figuring out how to do these kinds of migrations in a generic way with AOSP.

from vanadium.

it will have to be done in a way that doesn't lose existing data on the installs

This is not possible as far as I know because it would violate a security constraint (apps cannot see each other's data).

It doesn't have to be done

I think it's fair to not use another app's package name; if an user wants to install a vanilla Chromium build (available from plenty different parties) it may encounter issues.

It's also currently signed with the device release key as part of the build which could become an annoyance later on. This issue is really about figuring out how to do these kinds of migrations in a generic way with AOSP.

You would have to consider if an application changing package name is a feature worth to implement; there are no "handover" tokens for this type of renames, as far as I know.

from vanadium.

This is not possible as far as I know because it would violate a security constraint (apps cannot see each other's data).

I'm talking about an operating system component. Vanadium isn't shipped as a standalone app. I'm well aware that this obviously isn't something that a third party application could do.

I think it's fair to not use another app's package name; if an user wants to install a vanilla Chromium build (available from plenty different parties) it may encounter issues.

It's not another app's package name. There are no official builds of Chromium. It's intentionally a filler name.

You would have to consider if an application changing package name is a feature worth to implement; there are no "handover" tokens for this type of renames, as far as I know.

It's an OS component, and there's OS functionality for handling data migration during major upgrades.

I obviously can't just delete everyone's browser data in an upgrade. That's not an option, and this issue can be closed if it turns out there isn't a good way to do this kind of migration. It will just need to stay as org.chromium.chrome indefinitely.

from vanadium.

OS components don't work the same way as third party apps. If a system app is renamed, that means the previous installation is gone and so is the user data. That's not a serious option. The only way that the app id can be changed to org.grapheneos.vanadium as desired is if a data migration is implemented as part of the standard framework for doing that in the OS.

from vanadium.

Dealing with this kind of migration is also something that needs to be figured out in general, otherwise, the OS is permanently stuck with whatever apps it currently includes. It's why I'm quite careful to never include an app signed with a non-first-party key since it would be impossible to ever address any issues with it or deal with upstream development ending. It's still problematic because the standard approach is to sign apps with the OS release key but then if they become standalone projects it's desirable for them to be signed with their own key. Changing the key might not lose any data but it may result in inconsistent state without doing some kind of migration. These things need to be figured out. The OS needs to be able to change which apps are included, etc.

from vanadium.

It sounds like <original-package android:name="org.chromium.chrome"/> may accomplish this for system apps.

from vanadium.

The original-package feature appears to work, although it doesn't work quite the way I anticipated. It appears to continue using the old id on existing installs, but it understands the new name too. I need to do some more testing with this but it appears to provide what I needed in that it at least continues supporting old installs.

from vanadium.

It appears to continue using the old id on existing installs

I think this might just be an issue with the build that I did because I reused the previous build date.

from vanadium.

Not working as expected. Maybe the old application has to be left around for it to work. I don't know.

from vanadium.

Dealing with this kind of migration is also something that needs to be figured out in general, otherwise, the OS is permanently stuck with whatever apps it currently includes.

If I had to solve this problem as a one-time issue, I would probably backup the app data, rename the package name within it, and restore it. I am not sure though whether this has ever been possible (I remember so) or whether it's still possible.

OS components don't work the same way as third party apps. If a system app is renamed, that means the previous installation is gone and so is the user data.

I would follow whatever trick/strategy Android/Google are already using for this purpose. My point was more that rowing against the way application data is segregated will not be worth the effort.

from vanadium.

I couldn't figure this out in a reasonable amount of time so there will unfortunately be data loss as part of doing this renaming. This is justified by the fact that GrapheneOS is in a very early state (and is prominently marked as such) and lacks the development team needed for it to be sustainable. I tried my best to get the community to help with this over the past few weeks. I feel that doing this sooner rather than later is the best approach rather than hoping using original-package will ever be figured out. I also don't want to keep messing with this and rolling back / rebuilding. I'm shipping what I have now which is using org.grapheneos.vanadium. Sad, but that's the state of the project right now. Can't do everything the way I want.

from vanadium.

Or, maybe I won't take that approach. I don't know. Too much time wasted on this already though.

from vanadium.

What kind of data loss do we expect anyway?

from vanadium.

Everything.

from vanadium.

The simple solution is for people to step up and help with this as I've requested. I don't have the resources to continue developing / maintaining everything alone. People need to help.

from vanadium.

Seems like this upstream-change to PackageBuildService broke original-package:

+    /** Returns {@code true} if the package has been renamed. Otherwise, {@code false}. */
+    private static boolean isPackageRenamed(@NonNull PackageParser.Package pkg,
+            @Nullable String renamedPkgName) {
+        return pkg.mOriginalPackages != null && pkg.mOriginalPackages.contains(renamedPkgName);
     }
 
     /**
@@ -9979,7 +9917,7 @@
     @GuardedBy("mPackages")
     private @Nullable PackageSetting getOriginalPackageLocked(@NonNull PackageParser.Package pkg,
             @Nullable String renamedPkgName) {
-        if (pkg.mOriginalPackages == null || pkg.mOriginalPackages.contains(renamedPkgName)) {
+        if (!isPackageRenamed(pkg, renamedPkgName)) {
             return null;
         }

if (pkg.mOriginalPackages == null || pkg.mOriginalPackages.contains(renamedPkgName))

is not the same as

!isPackageRenamed(pkg, renamedPkgName)

~a || b != ~(a && b)

This is also filled upstream

Reverting the line seems to fix the issue in PQ3B.190801.002.2019.08.05.19

--- a/services/core/java/com/android/server/pm/PackageManagerService.java
+++ b/services/core/java/com/android/server/pm/PackageManagerService.java
@@ -10395,9 +10395,9 @@ public class PackageManagerService extends IPackageManager.Stub
     @GuardedBy("mPackages")
     private @Nullable PackageSetting getOriginalPackageLocked(@NonNull PackageParser.Package pkg,
             @Nullable String renamedPkgName) {
-        if (!isPackageRenamed(pkg, renamedPkgName)) {
-            return null;
-        }
+       if (pkg.mOriginalPackages == null || pkg.mOriginalPackages.contains(renamedPkgName)) {
+               return null;
+       }
         for (int i = pkg.mOriginalPackages.size() - 1; i >= 0; --i) {
             final PackageSetting originalPs =
                     mSettings.getPackageLPr(pkg.mOriginalPackages.get(i));

from vanadium.

They also mention making this change too:

diff --git a/services/core/java/com/android/server/pm/PackageManagerService.java b/services/core/java/com/android/server/pm/PackageManagerService.java
index 46f02259e74..a0d2b94971b 100644
--- a/services/core/java/com/android/server/pm/PackageManagerService.java
+++ b/services/core/java/com/android/server/pm/PackageManagerService.java
@@ -10184,7 +10184,7 @@ public class PackageManagerService extends IPackageManager.Stub
 
         if (newPkgSettingCreated) {
             if (originalPkgSetting != null) {
-                mSettings.addRenamedPackageLPw(pkg.packageName, originalPkgSetting.name);
+                mSettings.addRenamedPackageLPw(pkg.realPkgName, originalPkgSetting.name);
             }
             // THROWS: when we can't allocate a user id. add call to check if there's
             // enough space to ensure we won't throw; otherwise, don't modify state

from vanadium.

Not sure if that's required for correctness.

from vanadium.

This is also filed upstream

That issue requires sign-in to be viewed.

This feature looks like something OEMs use a lot too; I could only find this outdated blog post and a reference here in the official docs: https://developer.android.com/reference/kotlin/android/R.styleable#androidmanifestoriginalpackage

It seems to be a feature for your use case (renaming a system package), it would be surprising if it is currently broken for all OEMs.

from vanadium.

The original-package feature was fixed in Android 11. However, it has at least one limitation preventing it from being used for Chromium.

10-25 00:49:27.432  4437  4437 W System.err: java.lang.SecurityException: Failed to find provider org.chromium.chrome.browser for user 0; expected to find a valid ContentProvider for this authority
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.Parcel.createExceptionOrNull(Parcel.java:2373)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.Parcel.createException(Parcel.java:2357)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.Parcel.readException(Parcel.java:2340)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.Parcel.readException(Parcel.java:2282)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.IContentService$Stub$Proxy.notifyChange(IContentService.java:1261)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.ContentResolver.notifyChange(ContentResolver.java:2828)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.ContentResolver.notifyChange(ContentResolver.java:2817)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.ContentResolver.notifyChange(ContentResolver.java:2736)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.ContentResolver.notifyChange(ContentResolver.java:2706)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.content.ContentResolver.notifyChange(ContentResolver.java:2672)
10-25 00:49:27.432  4437  4437 W System.err: 	at org.chromium.chrome.browser.provider.ChromeBrowserProvider.m(chromium-TrichromeChrome6432.aab-stable-424011434:5)
10-25 00:49:27.432  4437  4437 W System.err: 	at org.chromium.chrome.browser.provider.ChromeBrowserProvider.onHistoryChanged(chromium-TrichromeChrome6432.aab-stable-424011434:1)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.MessageQueue.nativePollOnce(Native Method)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.MessageQueue.next(MessageQueue.java:335)
10-25 00:49:27.432  4437  4437 W System.err: 	at android.os.Looper.loop(Looper.java:183)
10-25 00:49:27.433  4437  4437 W System.err: 	at android.app.ActivityThread.main(ActivityThread.java:7656)
10-25 00:49:27.433  4437  4437 W System.err: 	at java.lang.reflect.Method.invoke(Native Method)
10-25 00:49:27.433  4437  4437 W System.err: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
10-25 00:49:27.433  4437  4437 W System.err: 	at com.android.internal.os.ExecInit.main(ExecInit.java:43)
10-25 00:49:27.433  4437  4437 W System.err: 	at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
10-25 00:49:27.433  4437  4437 W System.err: 	at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:399)
10-25 00:49:27.433  4437  4437 W System.err: Caused by: android.os.RemoteException: Remote stack trace:
10-25 00:49:27.433  4437  4437 W System.err: 	at com.android.server.content.ContentService.notifyChange(ContentService.java:430)
10-25 00:49:27.433  4437  4437 W System.err: 	at android.content.IContentService$Stub.onTransact(IContentService.java:503)
10-25 00:49:27.433  4437  4437 W System.err: 	at android.os.Binder.execTransactInternal(Binder.java:1154)
10-25 00:49:27.433  4437  4437 W System.err: 	at android.os.Binder.execTransact(Binder.java:1123)

from vanadium.

This seems to be an API level 26 (Android 8.0) feature according to https://readyandroid.wordpress.com/2019/12/31/java-lang-securityexception-failed-to-find-provider-for-user-0-expected-to-find-a-valid-contentprovider-for-this-authority/

Relevant documentation section is here: https://developer.android.com/about/versions/oreo/android-8.0-changes#ccn

I am absolutely in the dark on how to implement this, though.

from vanadium.

This is fully completed.

from vanadium.