I have a couple of Xiaomi Pocophones F1. I have set up one of them with the most recent LineageOS (rooted the device, edited a lot of system settings, installed and configured some apps) and would like to distribute the OS as an image to other devices of the same model. Is there a way?
I tried NANDroid from the TWRP recovery with PIN (secure startup) disabled before creating the backup as well as on the target device. Unfortunately, the result ist not bootable. I restored Boot, System, and Data partition.
Am I doing something wrong? Are there other ways (aside from professional MDM)?
EDIT: Sorry for the double-posting in the Pocophone sub-forum. I figured that it is not really a Pocophone-limited question.
The only way you will pull that off is compiling the rom yourself with the changes you want.
Never flash a nandroid from another device as they copy devixe spicific files.
I see. I was afraid that was the case and it makes sense.
Out of curiosity: could you come up with some example of those files from the top of your head?
pegnose said:
I see. I was afraid that was the case and it makes sense.
Out of curiosity: could you come up with some example of those files from the top of your head?
Click to expand...
Click to collapse
The main one is the efs fields hich contains the imei as well as another fields used to identify the device from other.
Ah, of course. Thank you again!
PS: You look a little like Batman.
Related
Hi,
I know Android is based on Linux and I have good knowledge when it comes to Linux. I also have a good understanding when it comes to Android right from the first devices...flashing roms etc. Still I am just using it on a user level and I am just guessing from those experiences what basic elements are and how Android is structured.
For once I would like to know how a typical Android phone is partitioned?
First there is the boot-element. I can flash ROMs all I want and it stays the same (in my case LG Animation). I guess this is a separate partition where a little bootloader like GRUB is located? Or is this located in the system-partition? Maybe the file boot.img? What is this? Some Mini-Linux?
Then there is for example the ClockWorkMod Recovery. Where is it located? It isn't deleted when I flash new ROMs. Is it on a separate partition? And what is it? Some Mini-Linux you can boot into?
Then there is the OS-Partition I can see when I install a file-explorer app in Android. I am guessing the OS itself (is this Linux or Android?) resides in /system, the user data resides in /data. Can somebody explain the main folders in this partition and what they contain?
Then there are elements like the Baseband or the RIL. Where are they located? Are they on a separate partition? Are they a Mini-Linux themselves and why aren't they changed when I flash a ROM?
In summary: I would like to understand Android better. Maybe you can answer some of my questions above or know some articles describing exactly what I want to know. I used Google and the forum search but found nothing really useful.
Cheers,
sb
Nobody got anything?
Not sure if this helps, it applies to most (if not all) Android devices:
http://androidforums.com/evo-4g-all-things-root/278898-android-partitions-kernels-explained.html
Thanks! This helped a lot. I head a similar view in my head but nothing really confirmed. There are more links to read in your link...which I will do
Hi.
Last time I flashed a new firmware I made a backup of the phone. The problem was that I couldn't get it back after flashing.
So, my question is:
How on earth do I make a backup of everything before flashing. And how do I restore it afterwords.
Thanks in advance
Pemell
Hi pemell,
How did you generate the backup? Yesterday I generated a full backup of my Lumia 800 and the command that I executed was the following:
sudo dd if=/dev/sdX of=~/fulldump
This generated the fulldump file (16GB).
David Ortega.
I'd suggest that you back up in two ways: First in Zune and then via the DD. I would suggest that you create a separate backup of each partition in order to make reflashing easier.
davortsan - I didn't update by cab sending so aren't that familiar with these commands. I guess of course I could find out by some testing and reading.
chrisKringel - two partitions? are there two partitions? If the phone had a memorycard I would get where you're going.
kind of strange there are no step by step guide of how to backup pre flashing and restore afterwords. I'm too much of a noob to write it myself.
pemell said:
chrisKringel - two partitions? are there two partitions? If the phone had a memorycard I would get where you're going.
Click to expand...
Click to collapse
Let's take a computer for example. When you open up explorer on said computer you see multiple HDD-icons. One for the system, one for Music and Pictures and one for games. This doesn't necessarily mean that this computer has 3 physical HDDs as you can split up a storage device into multiple logical partitions. The computer can easily have only one physical drive.
Same thing goes for our Lumias. They have (as far as I know) only one NAND chip that stores all the data. But this chip is split up into 9 logical partitions, containing the bootloader, serialnumber, mac etc. (head over to the Development Section, a few of the early posts discuss the partitions). When you have a Linux at your hands you can use the DD command to dump every single partition. Of course you should only touch the 9th partition later but better safe than sorry. In order to backup with Linux you have to either run the full dump command from above. When you want to reflash the fulldump every single partitions gets reset to the state from when you created the backup. I never tried this but I would not advise to reflash all partitions. I'd rather advise you to create a single backup of each partition. Charge your phone and enter QUALCOMM mode. Plug it into your Linux and run the commands
Code:
dd if=/dev/sdX1 of=backup1.bin
Code:
dd if=/dev/sdX2 of=backup2.bin
... repeat for every number until the following ...
Code:
dd if=/dev/sdX9 of=backup9.bin
X refers to the mount point where your device is connected. You can use fdisk -l to get the right letter. When you need to restore your device you need only partition 9, but better safe than sorry You never know, these additional backups might come in handy sometime...
What do you intend to do? Do you want to have your Apps back after you flashed your phone?
Thanks Chris, a perfect post!
I know that most of the information on the phone comes from the cloud, but some doesn't. For exemple I use the call history a lot and I would like to keep all of my sms+mms. Reinstalling all the apps is, of course, something i would prefer not to do at every update (even though they don't come that often).
I'll look into the information you posted and see what I can come up with. / Pemell
pemell said:
Thanks Chris, a perfect post!
I know that most of the information on the phone comes from the cloud, but some doesn't. For exemple I use the call history a lot and I would like to keep all of my sms+mms. Reinstalling all the apps is, of course, something i would prefer not to do at every update (even though they don't come that often).
I'll look into the information you posted and see what I can come up with. / Pemell
Click to expand...
Click to collapse
Keeping the specified data like messages, settings and call history during a reflash is not easily possible. When you reflash (or flash) your phone all the data gets wiped and completely new data is written to the phone. There are some homebrew solutions for texts in the WP7 Dev & Hacking boards that might work, depending on your current ROM. Another thing is that the flash you do when using the methods described in this board is different from a flash in a Nokia Care Point. The official flashing flashes in a certain way that the first boot writes all the phone data in the registry, like the WP activation key and some other serials. This won't happen when you write the file in Qualcomm mode. This could cause problems when you try to restore a backup from Zune. I'm not really sure about this, though.
Another thing to note is that some ROMs are not updateable through Zune, on these ROMs you have to do a manual update or a new flash to get up to date.
I would suggest that you wait a few weeks if you can. Maybe Microsoft will announce a cloud backup for text messages when the introduce WP8. A official backup would be the safest way.
Thanks Chris, a good advice.
We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
ttttttttttttttttt said:
We are a large urban school district located in southern California that will be soon be distributing approximately 11,000 android tablets to our first grade classrooms. The biggest challenge we’ve had with this project so far is coming up with a way to quickly and reliably clone the devices with all the apps and settings. The approach we’ve been attempting to take is the same as how we would handle PC’s by creating a master image that then gets copied to all the other devices.
Our first attempt at doing this was by using adb backup/restore. This process was less than ideal as it didn’t copy all the settings/preferences that we wanted and still required a lot of manual configuration to get the devices in to our ideal state. The bigger problem we had here was that sometimes it would just hang during the restore. Most of the time it did work but we’ve run in to this restore problem enough that we need something more reliable.
So our current cloning method is using Clockworkmod Recovery. Basically we flash CWM on to the device, make our backup, copy that backup to the destination devices and restore it with CWM. Seems to work great. And it copies everything on the devices so there’s virtually no manual configuration that needs to be done.
However there’s a few caveats with this process. At first we found that it was also cloning the MAC address which of course caused havoc on our wireless network. Through a whole lot of trial and error I found that if I delete /data/nvram/RestoreFlag from the data backup tar the MAC address no longer gets cloned. Thought we were good, but…
The next problem we found when attempting to enroll the devices in to our MDM system. They end up replacing each other because they all show the same UDID and GUID. The MDM app is installed in the backup image but we are waiting until after it is restored to complete the enrollment. I’m not sure if the UDID and GUID is something specific to the MDM or if that’s a global Android thing.
So does anyone know if there something else I can delete from the backup to prevent this? This also raises the question, are there any other items in a CWM backup that should not be copied between devices? Or is there a better method we could use to clones the devices?
The device we are currently using is a Lenovo A1000 (MTK MT8317). After creating the backup I’ve been removing the system and cache tars entirely and only the file mentioned above from within the data tar. So the only parts that get restored are data and boot. Any suggestions are welcome.
Click to expand...
Click to collapse
You can try use adb from Android SDK but this method needs root
We did initially try adb but it was inconsistent during the restore phase. Sometimes it would just stop in the middle and never complete. Didn’t try it on a rooted device. So maybe that would have helped…
Anyhow I found the solution to my immediate problem. Figured out what our MDM vendor refers to as the UDID is really the Android_ID. So by deleting that row from the settings database in our master backup image it’ll generate a new one the first time the OS starts after restoring with CWM.
I’m still a little concerned we’re going to find other issues cause by this cloning method later on but I guess we’ll just have to roll with the punches as they come.
In case someone else ever needs to clone devices like this and in the interest of sharing here’s the basic steps we’re following.
1.) Setup the master device as you like with all the apps and settings.
2.) Install Clockworkmod Recovery on to the master device
3.) Boot into CWM Recovery
4.) Mount /data and connect to adb
5.) Delete /data/nvram/RestoreFlag (this step prevents duplication of MAC address)
6.) Using sqlite open the database (this prevents duplication of Android_ID): \data\data\com.android.providers.settings\databases\settings.db
execute: delete from secure where name='android_id';
7.) unmount /data
8.) Create a backup
9.) Boot the device back in to normal mode and copy the clockworkmod folder to your computer. This the backup image you’ll restore on the other devices.
10.) [OPTIONAL] I deleted the system and cache backup files from this folder and also removed them from the nandroid file. There didn’t seem to be anything in these we cared about so removing those speeds up the restore process.
Once you have the backup image here’s how to restore it on the other devices:
1.) Install CWM Recovery
2.) Copy the clockworkmod folder from your computer on to the device
3.) Boot in to CWM Recovery
4.) Restore the backup
5.) Reboot the device back in to normal mode
6.) [OPTIONAL] Complete MDM enrollment
Sorry for the thread grave dig, but thanks for posting info on how to do this. I have attempted cloning in the past and ran into similar issues. My question - is this process the same for Android Lollipop 5.0/5.1? I have some Lenovo K3 Notes I'd like to deploy and cloning would save a lot of time.
Haven’t had the need to do any devices running 5.x versions so can’t say for sure. I would imagine a similar process would work.
But I will provide a bit of an update. Our initial deployment of 11,000 Lenovo A1000 devices have been out in the field since February/March of 2014 and no trouble has come to light using this cloning method. These devices run 4.1.2
Sometime around May 2014 we did another round that was about 300 Lenovo A3000 devices. Don’t have one of these handy and I don’t remember the exact Android version but it was 4.x something.
Then starting in October 2014 we put out another 9000 or so Lenovo A3500 devices. These run 4.4.2
All around so far so good.
For the A3000 and A3500 there were two changes to the process. For step 5 in creating the backup I had to clear the entire nvram directory instead of just the one file. I don’t remember what exactly but there was something undesirable getting copied over. The result of clearing this directory is the first boot after the restore takes a little longer as each app runs through the “update” process at startup. The second change was I could not get CWM to backup and restore to/from the internal memory so instead did it from a micro-sd card. This ended up speeding up the restore process since we didn’t have to copy the backup to each device and instead just moved the sd card with the files already there.
this should be pinned in android dev
also sorry for grave digging? except this should be a maintained topic. why isnt this an ongoing thread?
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
oxiroxt said:
Hello,
I'm willing to try and build a custom rom, but I've been diving through the site for a few days and I still don't get it. I believe I do have the required background to do this: programming, linux, etc. and I have wide experience as a phone user, etc. It's just that either I'm not reading what I need or the way I want it. The problem, I believe, is that all I find are guides telling me to install this and those tools and then open this and that and voila! you got your rom. But they're not explaining WHAT exactly goes into those roms, or what is expected to go there, what's the purpose of those contents, etc., and I can't really catch with that. I feel at a loss and hate wasting my time turning around for nothing.
1. I don't understand the difference between a flashable rom and one that is meant to be installed through recovery, although I can see they're different. Do they both models contain the same kind of data? Is there any restriction to what one model can contain over the other one? If so, how would I convert from one to the other? But please, don't tell me to use this or that tool. I just need the theory behind it. Something of sorts like: "You need to extract this or that from this tarball, then mount this image, then the directory tree there goes in that directory over the other model of rom"
2. update-binary: Okay I guess this is run when installing from recovery, and this takes care of installing the rom, right?wrong?. Is this a per-rom thing, per-device thing? generic? If it's per-rom, how to generate it? do I need to compile something? Is there any generic source code that can be used as a start?
3. Although I have a basic understanding of how the Linux directory tree works, I know Android works on top of a heavily modified Linux. So can you explain briefly how the directory tree works? For instance, I believe /data/data is where Android apps install to, in /system/bin or xbin I can find busybox binaries/symlinks if present. /dev and /proc look the same as in Linux. I don't know about /sys. Also how are both rom models deployed to this tree? What is basically being copied?
4. If I were to compile a kernel, where do I find the Android kernel sources? or is it just a generic Linux kernel? where can i get a basic config for the device? Last time I checked my device hadn't /proc/config.gz but maybe I could get it from another rom with it enabled or something. What toolchain and where to get it? Oh and if you know of a native arm version of gcc or whatsnot, I'd prefer that. Setting up IDEs or toolchains is a nightmare. I don't like crosscompiling. But crosscompiling or not, a directory with all needed binaries without needing to set up system variables nor other stuff, would be amazing.
I surely have a lot more questions that I can't get from the back of my mind now, and I'll have yet more as you explain. But the point of my questions was mainly trying to explain the degree of the loss I'm at, so you can assist me better.
If it looks like a foolish petition, well, that's because I'm quite stubborn and can't catch things that don't go my way. I really need to understand the basics before I can move into actually doing something. I want to build a rom for the right reasons(to me). It's not just about packing a set of apps or themes with it, but about learning and doing other stuff like trying to fix things that are not supposed to work for the device in that Android version, etc.
If you can't help, congrats for reading through here anyways But any help is greatly appreciated :good:
Click to expand...
Click to collapse
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
synesthete said:
I am not terribly knowledgeable about all of this, but I will take a crack at it. Others can feel free to correct me.
1. "Flashing" is usually done through the recovery from a zip with an update script inside. That script is in a language called "edify". Read more about Edify Here and Here.
The only other common way that I know of installing a ROM is through fastboot in the bootloader, but that is normally only used with official factory images. Also, I think Samsung ROMs are often flashed with a proprietary program called Odin.
2. I think that the update-binary is standard across all recent devices. I think it is just an interpreter for the Edify scripting language. Old versions of android used a somewhat different scripting language and required a different file. You can probably pull the binary out of another recent zip and use that. The main thing you have to worry about is the update script (instructions for what the zip does) and the folder structure of the zip.
3. I am not confident to explain much here, but the apps and their data are stored in different places. User apps are stored in /data/app with app data stored in /data/data, I think. System apps are installed in /system/app. There is more files stored on the "sdcard" partition which can be internal or external, depending on the device.
4. Kernel sources are usually provided in the source code from whatever repo you are using. Different ROMs use different bases. Here is some info about grabbing the AOSP kernel sources with git: http://source.android.com/source/building-kernels.html
Many of the more popular ROMS have specific build instructions on their individual github pages (Cyanogen, Paranoid Android, etc), so you might what to look at those, too. Also, depending on the individual devices, there might be proprietary binaries sourced from the device or hardware manufacturers for things like camera drivers, graphics chips, etc.
If you want a walk through of the basic build process google has a tutorial. The last time I checked there seemed to be some outdated info, but it might give you a general idea of the build process. http://source.android.com/source/initializing.html
Hopefully someone more knowledgeable can give you more info, but that is all I got
Click to expand...
Click to collapse
OMG Finally some light! THANK YOU, THANK YOU, THANK YOU for all the info. I didn't get much right now, I'll need to read through your post a few times before I get it all, haha. I'll be sure to check the links too. Thank you!
Greetings everybody,
I recently bought an outdated (and somewhat uncommon) tablet: namely Kobo’s Arc 7. It doesn’t support any custom ROM (nor is it supported by any recovery images AFAICS), and Kobo appears to be notorious for is lack of technical support, total absence of documentation and general disregard towards customers.
I rooted the OS (Android 4.2.something), didn’t make any backup and... deleted every Google Play app I could find (with a vengeance). I didn’t realize (until it was too late) that the Google Play Services *also* handle OS-critical parts, such as the main launcher or the Settings app.
Long story short, I now find myself with an OS that boots onto an empty screen: you can only see the clock and the battery icon at the top, and the three back/home/switcher icons at the bottom. Pulling the dropdown widget at the top just leaves you with a dark empty frame; I have now way of launching any app, nor accessing the Settings, nor (re)installing what’s missing.
The other boot modes I have access to are: fastboot (but as long as I don’t find a compatible ROM image, that’s nearly worthless) and adb sideload (for updates only, but the only update.zip I could find is for an older model). I can also access the device via MTP (no "mass storage" though, and I don’t have the ability to change that setting), but full ADB isn’t available, only the "sideload"/update thingy that hasn’t worked with anything I could throw at it.
The only resources I could find are:
This guide on XDA, mostly dealing with other models
This source code repo (that I’m not sure how to use)
This unofficial recovery image (which doesn’t seem legit, the device-specific files are empty)
Other than this missing GUI, the system appears to be intact, so I don’t want to flash the whole thing and risk losing drivers and hardware-specific mods, which I then won’t be able to replace in the absence of a ROM image. So, is there any way I could access a shell or fix the GUI (or at least backup the drivers, partition map and unreplaceable stuff) with what I’m working with ? Or should I buy/borrow another identical tablet to get a full nandroid backup? (which is kinda uneasy here)
Thanks for any pointers!
If it was a regular computer, I’d happily switch to a tty, ssh then chroot into it or boot onto another OS on an external drive... But these locked-down, binary-only, GUI-only devices just plain suck.
That tablet is junk. At this point, just throw it away.
ubigred said:
That tablet is junk. At this point, just throw it away.
Click to expand...
Click to collapse
Hi,
could you elaborate? (Like, how far away ? )
Yes
Give it to me! :laugh:
I can upload a nandroid backup
I have a nandroid backup, if you want? I can upload to mega or mediafire. :angel: