[android-developers] SharedUserId: Things that Cannot Change http://android-developers.blogspot.com/2011/06/things-that-cannot-change.html

2011-07-24 Thread Greg Giacovelli
Would SharedUserId be worth calling out. I currently don't have one set on 
any of my apps, but after playing around with the feature while trying to 
get a Test Project to run as the same user ...  I think it's not really 
possible to change the user_id with a live app without some big issues. The 
only way I can think to do it is to release an apk which changes all 
elements in /data/data/* to be opened with Context.MODE_WORLD_WRITEABLE and 
then later in another apk release, change the sharedUserId to the value 
desired. This sounds pretty bad. My theory is based on just very primitive 
tests of upgrading from a debug build with no sharedUserId to a debug build 
of the same package (cert) and realizing that any attempt to read anything 
in the /data/data/my_package either throws a SecurityException or 
FileNotFoundException (even when writing a new file). I think this should 
really be called out in the documentation, similar to how package name has 
big bold letters around it all the time that says (DO NOT CHANGE!) :)

However even with my idea of making a release with world writable files, I 
don't believe I would ever be able to create new files within 
/data/data/my_package. I am wondering that if the package name has to be 
unique anyways for the package manager, why they just didn't make the 
default user_id the package_name of the app. Then with the correct signing 
cert and agreed upon name you would be able to migrate to a userid if need 
be. 

... Or am I completely wrong?


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] SharedUserId: Things that Cannot Change http://android-developers.blogspot.com/2011/06/things-that-cannot-change.html

2011-07-24 Thread Nikolay Elenkov
On Mon, Jul 25, 2011 at 12:39 PM, Greg Giacovelli miyamo...@gmail.com wrote:
 Would SharedUserId be worth calling out. I currently don't have one set on
 any of my apps, but after playing around with the feature while trying to
 get a Test Project to run as the same user ...  I think it's not really
 possible to change the user_id with a live app without some big issues.

If sharedUserId was not set, and you set it afterwards, the UID of the
app changes. I think it's mentioned somewhere in the docs, but can't
seem to find the reference. So, basically, if you want to have two
(or more) apps with a shared UID, you have to design for this in
advance. E.g., release one app with sharedUserId=foo and the next
one with the same. There is an open issue though:

http://code.google.com/p/android/issues/detail?id=1227


 However even with my idea of making a release with world writable files, I
 don't believe I would ever be able to create new files within
 /data/data/my_package. I am wondering that if the package name has to be
 unique anyways for the package manager, why they just didn't make the
 default user_id the package_name of the app. Then with the correct signing
 cert and agreed upon name you would be able to migrate to a userid if need
 be.
 ... Or am I completely wrong?

Interesting proposition. It does seem that the system manages shared UIDs
differently from 'regular' ones, so maybe that's the reason this hasn't been
 (can't?) be done?

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en