reproducible issue when installing --> uid issue --> settings not persistant

[slajeune]

I still have the following issue when installing froyo-x86. No matter
what I do, the settings do not stay persistent and this is the reason
for it: everytime I reboot, I get a message like:

System package com.android.xxxx: uid changed from 1000 to 10001; old
data removed

As we can see, we are going in circles here. Everytime we boot, it
removes the old data (and thus, our settings) and continues on with a
'clean' boot.

To reproduce it:

Partition a drive as such:

/dev/sda1 --> 2 gigs
/dev/sda2 --> xx Gigs for /data

- compile a usb image
- boot from a usb image and install onto a hard (/dev/sda1)
- boot from the harddrive making sure that DATA=/dev/sda1
- at the main screen, remove the android hints widget and the google
search bar
- reboot the tablet by using the menu item reboot
- at the boot screen, make sure to again set DATA=/dev/sda1
- notice that both widgets are back on the screen
- open a terminal window and navigate to /data/system
- view file uiderrors.txt, notice that every single time you boot, it
detects a uid change

This is the issue to fix, in my mind, to allow people to really start
playing with the froyo install.

If anybody has any hints what to look for in order to fix this, please
update this thread.

Cheers,
Stephane.

[slajeune]

Slight follow up to my post. It seems that on every boot, Android
detects that the data doesn't match the uid/gid of the apps stored in /
system/app. Specifically this part of the code found in
PackageManagerService.java:

if ((parseFlags&PackageParser.PARSE_IS_SYSTEM) !=
0) {
// If this is a system app, we can at least
delete its
// current data so the application will still
work.
if (mInstaller != null) {
int ret =
mInstaller.remove(pkgName);

if (ret >= 0) {
// Old data gone!
String msg = "System package " +
pkg.packageName
+ " has changed from uid: "
+ mOutPermissions[1] + " to "
+ pkg.applicationInfo.uid + ";
old data erased";
reportSettingsProblem(Log.WARN, msg);
recovered = true;

// And now re-install the app.
ret = mInstaller.install(pkgName,
pkg.applicationInfo.uid,
pkg.applicationInfo.uid);


If I try to work around the line where it removes the package, it just
fails miserably (i.e. force closures on all apps).

Not sure I can be of much assistance to this.

One fix in the past was to run a script to try and synchronize the
packages uid/gid but we need to mount /system read-write for that.

One part that I feel is critical, we NEED to be able to mount /system
as read/write. Currently, even if installed on the hard disk, /system
is mounted from the squashfs system.sfs. Even if I place a system.img
instead of system.sfs, I still cannot remount rw (mount -o rw,remount /
system doesn't complain but doesn't remount the file system read
write!).

Cheers,
Stephane.

[slajeune]

This is the actual log that we see in uiderrors.txt:

2010-11-04 16:25: System package com.android.providers.telephony has
changed from uid: 1000 to 1001; old data erased
2010-11-04 16:25: System package com.svox.pico has changed from uid:
1000 to 10000; old data erased
2010-11-04 16:25: System package com.android.contacts has changed from
uid: 1000 to 10001; old data erased
2010-11-04 16:25: System package com.android.soundrecorder has changed
from uid: 1000 to 10002; old data erased
2010-11-04 16:25: System package com.android.provision has changed
from uid: 1000 to 10003; old data erased
2010-11-04 16:25: System package com.android.quicksearchbox has
changed from uid: 1000 to 10004; old data erased
2010-11-04 16:25: System package com.android.defcontainer has changed
from uid: 1000 to 10005; old data erased
2010-11-04 16:25: System package com.example.android.snake has changed
from uid: 1000 to 10006; old data erased
2010-11-04 16:25: System package com.android.magicsmoke has changed
from uid: 1000 to 10007; old data erased
2010-11-04 16:25: System package com.android.bluetooth has changed
from uid: 1000 to 10008; old data erased
2010-11-04 16:25: System package com.android.music has changed from
uid: 1000 to 10009; old data erased
2010-11-04 16:25: System package com.cooliris.media has changed from
uid: 1000 to 10010; old data erased
2010-11-04 16:25: System package com.android.providers.calendar has
changed from uid: 1000 to 10011; old data erased
2010-11-04 16:25: System package com.android.protips has changed from
uid: 1000 to 10012; old data erased
2010-11-04 16:25: System package com.android.calendar has changed from
uid: 1000 to 10013; old data erased
2010-11-04 16:25: System package com.android.phone has changed from
uid: 1000 to 1001; old data erased
2010-11-04 16:25: System package com.android.browser has changed from
uid: 1000 to 10014; old data erased
2010-11-04 16:25: System package com.android.providers.contacts has
changed from uid: 1000 to 10001; old data erased
2010-11-04 16:25: System package com.android.providers.downloads has
changed from uid: 1000 to 10015; old data erased
2010-11-04 16:25: System package com.example.android.notepad has
changed from uid: 1000 to 10016; old data erased
2010-11-04 16:25: System package com.android.providers.userdictionary
has changed from uid: 1000 to 10001; old data erased
2010-11-04 16:25: System package com.android.launcher has changed from
uid: 1000 to 10017; old data erased
2010-11-04 16:25: System package com.android.camera has changed from
uid: 1000 to 10018; old data erased
2010-11-04 16:25: System package com.android.deskclock has changed
from uid: 1000 to 10019; old data erased
2010-11-04 16:25: System package com.android.inputmethod.pinyin has
changed from uid: 1000 to 10001; old data erased
2010-11-04 16:25: System package org.connectbot has changed from uid:
1000 to 10020; old data erased
2010-11-04 16:25: System package com.android.globaltime has changed
from uid: 1000 to 10021; old data erased
2010-11-04 16:25: System package com.android.providers.applications
has changed from uid: 1000 to 10001; old data erased
2010-11-04 16:25: System package com.android.wallpaper has changed
from uid: 1000 to 10022; old data erased
2010-11-04 16:25: System package org.openintents.filemanager has
changed from uid: 1000 to 10023; old data erased
2010-11-04 16:25: System package com.android.spare_parts has changed
from uid: 1000 to 10024; old data erased
2010-11-04 16:25: System package com.android.wallpaper.livepicker has
changed from uid: 1000 to 10025; old data erased
2010-11-04 16:25: System package com.android.certinstaller has changed
from uid: 1000 to 10026; old data erased
2010-11-04 16:25: System package com.android.mms has changed from uid:
1000 to 10027; old data erased
2010-11-04 16:25: System package com.example.android.rssreader has
changed from uid: 1000 to 10028; old data erased
2010-11-04 16:25: System package android.tts has changed from uid:
1000 to 10029; old data erased
2010-11-04 16:25: System package com.android.speechrecorder has
changed from uid: 1000 to 10030; old data erased
2010-11-04 16:25: System package com.android.email has changed from
uid: 1000 to 10031; old data erased
2010-11-04 16:25: System package net.toload.main has changed from uid:
1000 to 10032; old data erased
2010-11-04 16:25: System package com.android.development has changed
from uid: 1000 to 10033; old data erased
2010-11-04 16:25: System package com.example.android.jetboy has
changed from uid: 1000 to 10034; old data erased
2010-11-04 16:25: System package com.android.musicvis has changed from
uid: 1000 to 10035; old data erased
2010-11-04 16:25: System package com.android.packageinstaller has
changed from uid: 1000 to 10036; old data erased
2010-11-04 16:25: System package com.android.term has changed from
uid: 1000 to 10037; old data erased
2010-11-04 16:25: System package com.android.inputmethod.latin has
changed from uid: 1000 to 10038; old data erased
2010-11-04 16:25: System package com.android.calculator2 has changed
from uid: 1000 to 10039; old data erased
2010-11-04 16:25: System package com.android.providers.drm has changed
from uid: 1000 to 10015; old data erased
2010-11-04 16:25: System package com.example.android.lunarlander has
changed from uid: 1000 to 10040; old data erased
2010-11-04 16:25: System package com.android.htmlviewer has changed
from uid: 1000 to 10041; old data erased
2010-11-04 16:25: System package com.android.providers.media has
changed from uid: 1000 to 10015; old data erased

A script called fix_permissions.sh would synchronize everything in /
system/app with the packages.xml in /data/system and would also ensure
that all apps have proper permissions. However, we need rw on /
system...

Cheers,
Stephane.

[Chih-Wei Huang]

2010/11/5 slajeune <stephane....@gmail.com>:

> I still have the following issue when installing froyo-x86.  No matter
> what I do, the settings do not stay persistent and this is the reason
> for it: everytime I reboot, I get a message like:
>
> System package com.android.xxxx: uid changed from 1000 to 10001; old
> data removed
>
> As we can see, we are going in circles here.  Everytime we boot, it
> removes the old data (and thus, our settings) and continues on with a
> 'clean' boot.
>
> To reproduce it:

Ok, I tried the procedure you suggested.
Nothing wrong in my test.
All changes are saved, including the widget in the desktop.

> Partition a drive as such:
>
> /dev/sda1 --> 2 gigs
> /dev/sda2 --> xx Gigs for /data
>
> - compile a usb image
> - boot from a usb image and install onto a hard (/dev/sda1)
> - boot from the harddrive making sure that DATA=/dev/sda1

Hmm? sda1 or sda2?

> - at the main screen, remove the android hints widget and the google
> search bar
> - reboot the tablet by using the menu item reboot
> - at the boot screen, make sure to again set DATA=/dev/sda1
> - notice that both widgets are back on the screen
> - open a terminal window and navigate to /data/system
> - view file uiderrors.txt, notice that every single time you boot, it
> detects a uid change

No, I didn't see such a change.

> This is the issue to fix, in my mind, to allow people to really start
> playing with the froyo install.

Don't claim this is an issue of froyo-x86.
I'm definitely sure this is your own issue.

> If anybody has any hints what to look for in order to fix this, please
> update this thread.

To be helpful, how to you get your froyo-x86 image?
Do you build it yourself, or use the prebuilt image from
our website? Please try the both.

Have you tried other version like donut-x86?

Try to erase everything in your machine,
or change another machine.

Try any possible alternative way to
find the differences.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[slajeune]

Hi Chih-Wei,

this is my own built image. Outside of a wifi driver and an
additional touchscreen driver, this is a stock froyo-x86 build tree.
The only thing that I can think of is the signing of the apks. Are
you using your own dev cert for signing the apk? Where in the build
tree can I put mine and which scripts need to be modified?

On Nov 4, 10:20 pm, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> 2010/11/5 slajeune <stephane.lajeune...@gmail.com>:

>
> > I still have the following issue when installing froyo-x86.  No matter
> > what I do, the settings do not stay persistent and this is the reason
> > for it: everytime I reboot, I get a message like:
>
> > System package com.android.xxxx: uid changed from 1000 to 10001; old
> > data removed
>
> > As we can see, we are going in circles here.  Everytime we boot, it
> > removes the old data (and thus, our settings) and continues on with a
> > 'clean' boot.
>
> > To reproduce it:
>
> Ok, I tried the procedure you suggested.
> Nothing wrong in my test.
> All changes are saved, including the widget in the desktop.
>
> > Partition a drive as such:
>
> > /dev/sda1 --> 2 gigs
> > /dev/sda2 --> xx Gigs for /data
>
> > - compile a usb image
> > - boot from a usb image and install onto a hard (/dev/sda1)
> > - boot from the harddrive making sure that DATA=/dev/sda1
>
> Hmm? sda1 or sda2?

Android is installed on /dev/sda1. /dev/sda2 is used for DATA, sorry
the lines above are wrong..

> > - at the main screen, remove the android hints widget and the google
> > search bar
> > - reboot the tablet by using the menu item reboot
> > - at the boot screen, make sure to again set DATA=/dev/sda1
> > - notice that both widgets are back on the screen
> > - open a terminal window and navigate to /data/system
> > - view file uiderrors.txt, notice that every single time you boot, it
> > detects a uid change
>
> No, I didn't see such a change.
>
> > This is the issue to fix, in my mind, to allow people to really start
> > playing with the froyo install.
>
> Don't claim this is an issue of froyo-x86.
> I'm definitely sure this is your own issue.

Probably. But I seem to recall another user with the same issue.

> > If anybody has any hints what to look for in order to fix this, please
> > update this thread.
>
> To be helpful, how to you get your froyo-x86 image?
> Do you build it yourself, or use the prebuilt image from
> our website? Please try the both.
>
> Have you tried other version like donut-x86?

No, I'm not interested in donut-x86

> Try to erase everything in your machine,
> or change another machine.

I format the drives between each install

[slajeune]

See the thread about froyo x86 and wlan0 permissions error.

Same thing as me. So, out of the box, we are doing something
different / wrong while building our images. My current theory
revolves around have debug keys instead of real keys for signing apks.

I have an image built that I will test when I get home.

Cheers,
Stephane.

On Nov 4, 10:20 pm, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> 2010/11/5 slajeune <stephane.lajeune...@gmail.com>:
>

[slajeune]

Ok, this is confirmed. This has to do with the signing of the APKs.
You need to generate your own keys BEFORE building the image. If you
don't generate your own keys, you will get errors on every reboot.
Here is how to generate your keys:

build/target/product/security

Delete all keys that are there. Then, generate your own WITHOUT
setting any password for them (you can change anything between the
quotes '' below):

$PATH_TO_SRC/development/tools/make_key testkey '/C=US/ST=California/
L=Orange/O=Big Corp/OU=Big Corp/CN=Big Corp/
emailAddress=andr...@bigcorp.com'
$PATH_TO_SRC/development/tools/make_key release '/C=US/ST=California/
L=Orange/O=Big Corp/OU=Big Corp/CN=Big Corp/
emailAddress=andr...@bigcorp.com'
$PATH_TO_SRC/development/tools/make_key platform '/C=US/ST=California/
L=Orange/O=Big Corp/OU=Big Corp/CN=Big Corp/
emailAddress=andr...@bigcorp.com'
$PATH_TO_SRC/development/tools/make_key shared '/C=US/ST=California/
L=Orange/O=Big Corp/OU=Big Corp/CN=Big Corp/
emailAddress=andr...@bigcorp.com'
$PATH_TO_SRC/development/tools/make_key media '/C=US/ST=California/
L=Orange/O=Big Corp/OU=Big Corp/CN=Big Corp/
emailAddress=andr...@bigcorp.com'

Once this is done, you can install the image and the data will stay
persistant.

The only thing missing right now is the sdcard issue. Once this is
resolved, this will be pretty solid!

Cheers,
Stephane.

[Chih-Wei Huang]

Hmm, interesting finding.
But I think you have messed up something
to get such a problem.
Even the document of AOSP didn't say
you need to generate your keys before build the images.
(http://source.android.com/source/download.html)

I suggest you create a fresh tree (Android-x86 or even AOSP)
and try again.

2010/11/6 slajeune <stephane....@gmail.com>:

[slajeune]

Actually,

it's part of their porting guide:

http://source.android.com/porting/release_keys.html

Cheers,
Stephane.

On Nov 6, 12:09 am, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> Hmm, interesting finding.
> But I think you have messed up something
> to get such a problem.
> Even the document of AOSP didn't say
> you need to generate your keys before build the images.
> (http://source.android.com/source/download.html)
>
> I suggest you create a fresh tree (Android-x86 or even AOSP)
> and try again.
>

> 2010/11/6 slajeune <stephane.lajeune...@gmail.com>:

[Chih-Wei Huang]

Thank you for the info.
But it does't explain why you got your problem.

Which build did you create? eng, user or userdebug?

2010/11/7 slajeune <stephane....@gmail.com>:

> Actually,
>
> it's part of their porting guide:
>
> http://source.android.com/porting/release_keys.html
>

--

[slajeune]

Hi

I used eng build. I still belive that it should be best practice to
generate our own keys as suggested by google.

Cheers
Stephane.

On Nov 8, 1:33 am, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> Thank you for the info.
> But it does't explain why you got your problem.
>
> Which build did you create? eng, user or userdebug?
>

> 2010/11/7 slajeune <stephane.lajeune...@gmail.com>:

[slajeune]

Actually,

yes it does explain what caused my problem. I am trying to compile a
release version. A release version needs a release key. By default,
there is no release key in AOSP. If it doesn't find a release key, it
uses the testkey, which is not a valid key. This is what caused my
issue. When I recreated all keys as per the link above, it solved my
issue completely.

Cheers,
Stephane.

On Nov 7, 8:33 pm, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
> Thank you for the info.
> But it does't explain why you got your problem.
>
> Which build did you create? eng, user or userdebug?
>

> 2010/11/7 slajeune <stephane.lajeune...@gmail.com>: