change application id #34
Comments
thestinger
changed the title
|
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 |
This is not possible as far as I know because it would violate a security constraint (apps cannot see each other's data).
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.
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. |
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.
It's not another app's package name. There are no official builds of Chromium. It's intentionally a filler name.
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 |
|
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. |
|
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. |
|
It sounds like |
|
The |
I think this might just be an issue with the build that I did because I reused the previous build date. |
|
Not working as expected. Maybe the old application has to be left around for it to work. I don't know. |
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.
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. |
That's what I am trying to do and what the issue is about. It seems
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. |
|
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 |
|
Or, maybe I won't take that approach. I don't know. Too much time wasted on this already though. |
|
What kind of data loss do we expect anyway? |
|
Everything. |
|
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. |
|
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 ~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)); |
|
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 |
|
Not sure if that's required for correctness. |
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. |
|
The original-package feature was fixed in Android 11. However, it has at least one limitation preventing it from being used for Chromium. |
|
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. |
|
This is fully completed. |
This is trickier than it seems because losing the data on existing installs wouldn't be desirable.
The text was updated successfully, but these errors were encountered: