Project

General

Profile

upgrading without flashing - unzipping on to a live system

Added by robin p about 9 years ago

I wondered recently what would happen if I upgraded replicant by downloading the update, and unzipping on to a live system, rather than booting into recovery/clockworkmod and "flashing" the zip across. I figured this is what synaptic, yum and so on do on desktop/server installations of Debian, Opensuse, etc,. so why not on replicant? Does anyone have any ideas, has anybody tried it? Is there any obvious reason why it couldn't work?

On a similar note, I see Cyanogen Mod has cmupdater, which allows live updates via an app with a GUI.

What would it take to use this to upgrade Replicant?

Cheers,

r


Replies (3)

RE: upgrading without flashing - unzipping on to a live system - Added by Paul Kocialkowski about 9 years ago

I don't really see the point of doing this. There are many technical reasons why this wouldn't work. First off because /system is mounted read-only.

What would it take to use this to upgrade Replicant?

I'm not sure their application is free software. If it is, then you're welcome to adapt it for Replicant, even though I'm not sure it's really needed.

RE: upgrading without flashing - unzipping on to a live system - Added by robin p about 9 years ago

Paul Kocialkowski wrote:

I don't really see the point of doing this. There are many technical reasons why this wouldn't work. First off because /system is mounted read-only.

I'm sure you don't see the point, but as the GPL states, you are free to use the software for any purpose, so it's not strictly relevant whether you see it or not. Anyway, getting back to the software, and sticking to non-inflammatory methods: the idea of upgrading in place, without flashing, appeals because I can. Lots of other operating systems do so, it is anachronistic and frankly clumsy to use the method we have. Also, it's quicker, doesn't need a reboot, hence less downtime.

Yes, /system is mounted read-only, but that can be changed by invoking mount with the remount option. I'm sure you're aware of this already.

I'd be intrigued to know the other technical reasons, may we be party to them?

What would it take to use this to upgrade Replicant?

I'm not sure their application is free software. If it is, then you're welcome to adapt it for Replicant, even though I'm not sure it's really needed.

It is free software, it's in their github repository:
https://github.com/CyanogenMod/android_packages_apps_CMUpdater

I'm dissecting the server API at the moment.

RE: upgrading without flashing - unzipping on to a live system - Added by Paul Kocialkowski about 9 years ago

I'm sure you don't see the point, but as the GPL states, you are free to use the software for any purpose, so it's not strictly relevant whether you see it or not.

Well, that's right indeed! My point is not that you shouldn't try it, rather that I have no personal interest in that, nor do I see any technical advantage, so I'm not going to invest my time helping you figure out the details of this.

Lots of other operating systems do so, it is anachronistic and frankly clumsy to use the method we have. Also, it's quicker, doesn't need a reboot, hence less downtime.

Android images are built as a whole and there is no packaging system that allows to keep track of the revision of each component. Also, you would need to restart dalvik, surfaceflinger and friends after updating the system and reboot if there were changes in the kernel, so I don't see significantly less downtime there. Again, there is no system that keeps track on what needs to be restarted after updating certain parts. This is not part of Android's technical philosophy. I reckon this is a nice thing on GNU/Linux, but it's just not a good fit for Android.

Yes, /system is mounted read-only, but that can be changed by invoking mount with the remount option. I'm sure you're aware of this already.

Of course.

It is free software, it's in their github repository:
I'm dissecting the server API at the moment.

I'd be interested in knowing what exactly the server must provide to see if it would be realistic to set it up.

    (1-3/3)