Can't Repro
Status Update
Comments
jl...@google.com <jl...@google.com>
sk...@gmail.com <sk...@gmail.com> #2
I have had this problem also. I released the free version of my application and
thought that I had set the sharedUserId in preparation for later releasing the paid
version of my application. I needed to be able to copy the database from the free
version to the paid version, so I set the sharedUserId. However I followed the
instructions for sharedUserLabel which says "The label must be set as a reference to
a string resource; it cannot be a raw string." and also set my sharedUserId as a
@string value. However it turns out that the sharedUserId must be a raw string (the
opposite of sharedUserLabel).
The problem is that my already released free application has the sharedUserId set to
a value which didn't work. I changed it to a raw string which now works to share the
database with the paid version. However I posted my update of the free application
with the sharedUserId set to the new raw string value to Android Market without
realizing that the application would no longer be able to access its own database.
When people upgraded to the new version, it would crash as soon as it tried to open
its database.
thought that I had set the sharedUserId in preparation for later releasing the paid
version of my application. I needed to be able to copy the database from the free
version to the paid version, so I set the sharedUserId. However I followed the
instructions for sharedUserLabel which says "The label must be set as a reference to
a string resource; it cannot be a raw string." and also set my sharedUserId as a
@string value. However it turns out that the sharedUserId must be a raw string (the
opposite of sharedUserLabel).
The problem is that my already released free application has the sharedUserId set to
a value which didn't work. I changed it to a raw string which now works to share the
database with the paid version. However I posted my update of the free application
with the sharedUserId set to the new raw string value to Android Market without
realizing that the application would no longer be able to access its own database.
When people upgraded to the new version, it would crash as soon as it tried to open
its database.
da...@gmail.com <da...@gmail.com> #3
I've run into this issue as well, was hoping that this might be moved out of the unreproducible state as I can't
add a sharedUserId to existing applications now.
add a sharedUserId to existing applications now.
an...@gmail.com <an...@gmail.com> #4
I confirm this is still a problem on 2.1.
And it is easy to reproduce. I can provide a sample application demonstrating the
problem. Let me know if you need it.
And it is easy to reproduce. I can provide a sample application demonstrating the
problem. Let me know if you need it.
an...@gmail.com <an...@gmail.com> #5
And this is defect, not enhancement: developer doesn't expect that adding
sharedUserId to an application would forbid this application from accessing *its* data.
sharedUserId to an application would forbid this application from accessing *its* data.
vi...@gmail.com <vi...@gmail.com> #6
I want the exact same thing to be dona as skyhigh1001. I have a free version with a
sharedUserId and now i want to access the database of the free version into the paid
version of the application. How do I achieve this can any 1 upload the source code or
any piece of code to make this happen. PLs guys help me out.
Andriy.Tsykholyas if u can put up your sample application it would be helpful.
Thanks in advance guys. Looking forward to your reply. :) Cheers
sharedUserId and now i want to access the database of the free version into the paid
version of the application. How do I achieve this can any 1 upload the source code or
any piece of code to make this happen. PLs guys help me out.
Andriy.Tsykholyas if u can put up your sample application it would be helpful.
Thanks in advance guys. Looking forward to your reply. :) Cheers
fo...@gmail.com <fo...@gmail.com> #7
I am having this same problem as vish.shal and skyhigh. The workaround I've used is
to implement a ContentProvider for accessing data from the free version.
ContentProviders make data from your app available to others, which is what an app
with a different uid is as far as the OS is concerned. For database access, you just
need to implement the query method, which is designed for returning a cursor over the
database.
to implement a ContentProvider for accessing data from the free version.
ContentProviders make data from your app available to others, which is what an app
with a different uid is as far as the OS is concerned. For database access, you just
need to implement the query method, which is designed for returning a cursor over the
database.
an...@gmail.com <an...@gmail.com> #8
Workaround with ContentProvider has at least two drawbacks:
1) interprocess communication results in performance penalty
2) what about sharing resources?
1) interprocess communication results in performance penalty
2) what about sharing resources?
fo...@gmail.com <fo...@gmail.com> #9
If you want both apps to be installed and active continuously, then 1) is a problem.
I'm envisioning a situation where the 2nd app replaces the first, so yes there is a
performance penalty but only during the upgrade process. No biggie.
Although if you want 2 components installed, you might be better off releasing a new
version of each with the manifest fixed and telling all your old users to reinstall.
You could implement an import procedure to make it easy.
In regards to sharing resources, the same logic would apply, although this:
http://developer.android.com/reference/android/content/ContentResolver.html#openAssetFileDescriptor
explains how to share resources. I would imagine performance would still be an issue.
I'm envisioning a situation where the 2nd app replaces the first, so yes there is a
performance penalty but only during the upgrade process. No biggie.
Although if you want 2 components installed, you might be better off releasing a new
version of each with the manifest fixed and telling all your old users to reinstall.
You could implement an import procedure to make it easy.
In regards to sharing resources, the same logic would apply, although this:
explains how to share resources. I would imagine performance would still be an issue.
ak...@gmail.com <ak...@gmail.com> #10
Anyone have a workaround for this problem once the app has been updated with the new sharedUserId? I made the mistake of doing this and the app started crashing. I removed the attribute and uploaded the update to the market but the problem persists. It seems like Android is not assigning it the same id it had before the sharedUserId was added (even though the latest version has the sharedUserId attribute removed). Anyone have a satisfactory solution to this problem?
Summary: Version 1 did not have sharedUserId. Version 2 had sharedUserId leading to force closes. Version 3 does not have sharedUserId but still force closes with the same error.
Summary: Version 1 did not have sharedUserId. Version 2 had sharedUserId leading to force closes. Version 3 does not have sharedUserId but still force closes with the same error.
va...@gmail.com <va...@gmail.com> #11
Steps to reproduce:
1) take any Android device/emulator
2) write a program without shareduserid set, which uses database (create database).
3) install it: adb install oldVersion.apk
3) modify the program by adding shareduserid, increment versionCode
4) try to upgrade old version by the new one (ex: adb install -r newVersion.apk)
5*) note that database is not accessible
6*) note logcat records:
01-14 18:03:20.969: DEBUG/PackageManager(62): Shared UserID ru.yandex.uid.shared (uid=10038): packages=[PackageSetting{44162c10
ru.yandex.mail/10038}, PackageSetting{440c2808 ru.yandex.mail/10038}]
01-14 18:03:20.969: INFO/PackageManager(62): Package ru.yandex.mail codePath changed from /data/app/ru.yandex.mail-2.apk to /dat
a/app/ru.yandex.mail-1.apk; Retaining data and using new
01-14 18:03:20.989: WARN/PackageManager(62): Package ru.yandex.mail shared user changed from <nothing> to ru.yandex.uid.shared;
replacing with new
01-14 18:03:21.019: ERROR/PackageManager(62): Package ru.yandex.mail has mismatched uid: 10040 on disk, 10038 in settings
Expected result: file permissions MUST be changed to correspond with newly created UID OR the app UID MUST be untouched.
1) take any Android device/emulator
2) write a program without shareduserid set, which uses database (create database).
3) install it: adb install oldVersion.apk
3) modify the program by adding shareduserid, increment versionCode
4) try to upgrade old version by the new one (ex: adb install -r newVersion.apk)
5*) note that database is not accessible
6*) note logcat records:
01-14 18:03:20.969: DEBUG/PackageManager(62): Shared UserID ru.yandex.uid.shared (uid=10038): packages=[PackageSetting{44162c10
ru.yandex.mail/10038}, PackageSetting{440c2808 ru.yandex.mail/10038}]
01-14 18:03:20.969: INFO/PackageManager(62): Package ru.yandex.mail codePath changed from /data/app/ru.yandex.mail-2.apk to /dat
a/app/ru.yandex.mail-1.apk; Retaining data and using new
01-14 18:03:20.989: WARN/PackageManager(62): Package ru.yandex.mail shared user changed from <nothing> to ru.yandex.uid.shared;
replacing with new
01-14 18:03:21.019: ERROR/PackageManager(62): Package ru.yandex.mail has mismatched uid: 10040 on disk, 10038 in settings
Expected result: file permissions MUST be changed to correspond with newly created UID OR the app UID MUST be untouched.
zh...@gmail.com <zh...@gmail.com> #13
I have had this problem also. And any one have perfect solution?
en...@gmail.com <en...@gmail.com> #14
I wrote this comment in issue 36924841 , but thought that I can write it here as well since I'm in dying need of an answer. Also, I hope that my post will strengthen everyone's will to find a solution to this issue when they see how many people agree that this is an issue that either needs to be resolved or needs a reliable work around solution.
I want appA on deviceA to write values to an SQLite database and appB on deviceB to read those values from that database.
I'm doing this for a Honours (Multimedia) project at the University of Pretoria in South Africa and do not plan to publish my app on the Market - I simply want to pass my degree :)
Will I be able to create new versions of my app by specifying the same UserID in each app's Manifest.xml file or should I attempt to make use of Content Providers and Content Resolvers?
In future I do want to create apps and publish them on the Market, so I too need this issue to be resolved or at least a reliable solution to be found. But I'm too new to Android to have discovered anything that will be of use, just yet :)
I want appA on deviceA to write values to an SQLite database and appB on deviceB to read those values from that database.
I'm doing this for a Honours (Multimedia) project at the University of Pretoria in South Africa and do not plan to publish my app on the Market - I simply want to pass my degree :)
Will I be able to create new versions of my app by specifying the same UserID in each app's Manifest.xml file or should I attempt to make use of Content Providers and Content Resolvers?
In future I do want to create apps and publish them on the Market, so I too need this issue to be resolved or at least a reliable solution to be found. But I'm too new to Android to have discovered anything that will be of use, just yet :)
mh...@gmail.com <mh...@gmail.com> #15
I am seeing this bug regardless of setting sharedUserId.
01-26 11:23:26.524: E/PackageManager(1595): Packagecom.mycompany.android.app has mismatched uid: 10102 on disk, 10014 in settings
We have never set the sharedUserId. The device underwent a upgrade to the latest version of Android (HTC Flyer) after which running the app or fresh install causes the various files in cache to be inaccessible since they are tied to the old UID. Since the pre-upgrade file system associates the UID for that package differently from the post-upgrade UID, the current application cannot do any file access which it may have had to do. This affects any webviews in the app (Admob uses webview to display ads), database open/access, sharedPreferences, etc.
Some have noted this happens when you transition an installed application from secured to unsecured. I have seen this happen simply by hitting the run application feature in Eclipse. One too may installs and the system applies a new UID to the package.
So far, the factory reset is the only known solution to fix this.
01-26 11:23:26.524: E/PackageManager(1595): Package
We have never set the sharedUserId. The device underwent a upgrade to the latest version of Android (HTC Flyer) after which running the app or fresh install causes the various files in cache to be inaccessible since they are tied to the old UID. Since the pre-upgrade file system associates the UID for that package differently from the post-upgrade UID, the current application cannot do any file access which it may have had to do. This affects any webviews in the app (Admob uses webview to display ads), database open/access, sharedPreferences, etc.
Some have noted this happens when you transition an installed application from secured to unsecured. I have seen this happen simply by hitting the run application feature in Eclipse. One too may installs and the system applies a new UID to the package.
So far, the factory reset is the only known solution to fix this.
er...@gmail.com <er...@gmail.com> #16
A factory reset inflicted this on me. Apparently Google/Android think it is acceptable to erase filesystems when their package installer fails to encrypt properly. If the battery dies while it is encrypting, for example, Android triggers an unstoppable factory reset on the next boot.
I had anticipated that this travesty of an operating system might destroy /data and /system somehow, and had backed them up to a squashfs. Recovering them was more trouble than expected because of this issue -- some UIDs had changed. FX, the file manager I normally use, could no longer gain root access and mentioned this issue. I had to install the terminal app with a file:/// URI from the browser (which is unable to list directories). Eventually I was able to extract /data and /system to an ext4 filesystem on my external SD card and rsync the factory defaults to oblivion.
I had anticipated that this travesty of an operating system might destroy /data and /system somehow, and had backed them up to a squashfs. Recovering them was more trouble than expected because of this issue -- some UIDs had changed. FX, the file manager I normally use, could no longer gain root access and mentioned this issue. I had to install the terminal app with a file:/// URI from the browser (which is unable to list directories). Eventually I was able to extract /data and /system to an ext4 filesystem on my external SD card and rsync the factory defaults to oblivion.
er...@gmail.com <er...@gmail.com> #17
Android also reintroduced this issue when it forgot how to read Kindle's dm-crypt filesystem on the SD card and I reinstalled it. Finding the UID that Android assigns is tricky. I was able to get Kindle running long enough before it crashed to dig its UID out of `ps`. With that I could chown all its data correctly.
sh...@gmail.com <sh...@gmail.com> #19
Just been hit hard by this. Was receiving countless reports of "Error 24" (nice work on the meaningful error reporting, Google) from people trying to update my app. Finally figured out it was this.
I've now somehow got to inform 10s of thousands of paying customers that they need to uninstall and reinstall the app.
I've now somehow got to inform 10s of thousands of paying customers that they need to uninstall and reinstall the app.
bo...@gmail.com <bo...@gmail.com> #20
Join the club -_- I also had to inform 37.000 users...
4p...@gmail.com <4p...@gmail.com> #21
...
ha...@gmail.com <ha...@gmail.com> #22
I have an app with a sharedUserId specified from start. Now I am considering removing the sharedUserId since it is not supported by Google Play. Yes, major f*ck up #2 by Google: http://code.google.com/p/marketbilling/issues/detail?id=90
Ok. So my app uses several SQLite databases. If I remove the sharedUserId, will my app get screwed like described above?
This bug gives me nightmares.
Ok. So my app uses several SQLite databases. If I remove the sharedUserId, will my app get screwed like described above?
This bug gives me nightmares.
xi...@gmail.com <xi...@gmail.com> #23
Would Google plan to solve this problem? or keep it open forever...
mk...@gmail.com <mk...@gmail.com> #24
It's been nearly 9 years guys. The status is "Won't Fix (Not reproducible)" - I would have higher hopes of Android developer team, since this bug has been starred 72 times (and probably affected hundreds if not thousands of developers). Unsubscribing from this, as getting those notifications just reminds me of this sad, very sad bug report. Not cool, Google Android team.
Description
sharedUserId="xxx" then Android upgrade works. However, after running it
sounds that the /data/data/<package_name>/ directory becomes in accessible
to the application.
It seems that Android upgrade will use a new userid if it
encountered "sharedUserId" changes in the manifest file. It assigned a new
uid for the application (see from /data/dalvik-cache) but the user data
directory is still belongs to old userid, but since the package name is
the same, thus new application will NO longerable to access its data
folder.
Suggestion: either does NOT allow direct upgrade, OR, internally, re-
assign files under OLD uid to the new uid (which is better).
Dana