I have a few questions related to smartphones. Searched and couldn't find anything like I was looking for.
I am vary familiar with PC's and would like to compare in my mind where things reside on a smartphone.
On a smartphone, where does the operating system reside? Is it in the ROM(I know is Read-only-memory)? Or is the ROM similar to the BIOS on a PC and contains the basic instructions to interact with the between software and hardware?
Just having a little problem comparing what is where.
i think its in ROM memory, but there is additonal memory for system/internal apps too.
In my XPlay I have 512mb+400mb.
There isn't anyth like bios but u can flash recovery
From what I know, everything is stored in NAND flash. There is a boot partition which contains the kernel, and a system partition which contains the OS (firmware) itself. Those essentially double as ROM. Technically it's not read-only memory but its contents won't change unless you root your phone and change them yourself.
Also, I don't think an embedded system such as a smartphone would benefit much from having a full-blown BIOS. Hardware initialization, I believe, is done during the boot sequence, not prior to it. Look up "Board support package".
If someone knows more about this subject, feel free to correct me and provide additional information.
I'm quite interested in embedded systems myself, but only have had the opportunity to work with simple microcontrollers.
So basically everything inside is more like a solid state hard drive? Just partitioned for different tasks? I figured the rom was not really a rom. Usually you have to build an interface and cut traces on the board in order to flash a rom.
Are we able to browse the rom? Like with root explorer? Or is that partition "hidden"?
Also, what are the caches for. I am familiar with caches like in ie. But the davlik seems to be persistent. Thanks for the answers so far guys.
Usually when you load a new os, the cache is usually wiped. But with phones, a step is to wipe the caches. Confusing when trying to grasp with the knowledge I have of older electronics. Lol I just called pc's old.
I wish there was some guide already making the comparison but Google can't find it!
Yes, you can browse those partitions in Root Explorer. It will allow you to mount even the /system partition r/w so you can modify the contents.
As for the caches, I'm not sure what exactly gets stored on the /cache partition, but the reason you have to wipe/format it when you flash a new ROM, is because it's separate from the /system partition. That's probably what you meant by "persistent".
It's actually convenient when you think about it. If you want to flash an update of the ROM you are currently using, you probably don't want the cache to be wiped as well. On the other hand, sometimes you may want to wipe just the cache. Same goes for the /data partition, when you are doing a factory reset, for example.
I would also assume that since /system partition normally isn't written to, and /cache and /data are, keeping them separate helps in case the filesystem gets corrupted.
Now you are confusing me.
/system is a folder. Not a partition. It may be in a folder but it is not a partition afaik. There is a root partition which is basically everything you see when you open file explorer that includes the system folder, then any other partitions are mounted under /mnt. Those include /asec /obb /sdcard and /secure. (using what I see in my kf for this example)
So when we flash the "rom" we are really only flashing one partition of a rom that has several partitions. That would be the basic partition containing the system files? We are not flashing the entire rom. Does that sound correct?
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
DeVelox said:
In Linux partitions are mounted under directories. So /cache, /data and /system are really just mount points for those partitions. It's understandable that this would confuse you if you haven't had experience with Linux. Windows handles partitions somewhat differently.
When you flash a ROM, you are actually flashing only the system partition. Kernel is flashed to the boot partition, and others (cache, data, sdcard, etc.) are used by the system itself.
Click to expand...
Click to collapse
Yes i have a little knowledge, albeit very little, of Linux. But if it is an actual partition it will also show under /mnt after you mount it, correct? That is how you tell if it is an actual partition. I do realize that the others partitions like /sdcard are being automatically mounted. And you can browse them through the /sdcard folder or /mnt/scard.
/cache is no where under /mnt or any subs of any partitions that are mounted so that tells me the /cache folder that shows under root is actually only a folder. Well there is a cache subdirectory underone of the partitions under /mnt but the contents are different than the contents of the cache folder running off of root.
Sorry bout all of the questions. I have done a lot to my phone and kf. I just like to know what it's being affected when when I do what I am doing. And why I am doing what I am doing.
Like i said before, the term rom confused me as when i was flashing roms on other devices I was having to build a hardware interface and cut traces on the board, sometimes install jumpers across traces. All of that to flash "roms". This was on xboxes and satellite receivers mainly.
No, /mnt is just a directory like any other. In fact, it is rarely used for mounting purposes in modern Linux distributions.
When you open /cache, /data or /system in Root Explorer, please check the "x MB used, y MB free" line at the top. You will notice that it shows different values for each of those directories. That should be enough to convince you that they are indeed partitions, and not ordinary directories.
You will also notice that, for example, /etc shows the same used/free info as /system. That is because /etc is actually a symlink to /system/etc.
You should read up more on Linux, or just take my word for it.
P.S. If you have Terminal Emulator app installed, try the "df -h" command. It will list all the partitions, their mount points, and used/free space info. Mind you, only entries starting with "/dev/block" are actual partitions, tmpfs is something else.
I see said the blind man. I also found this as an example of the partitions on my kf.
Scrolling down I see all of the active partitions.
http://kindlefirenews.org/expand-app-storage-on-the-kindle-fire/
Thanks for the explanations. But I will say that ROM it's a misnomer!
Open a console on your android and type "df".
You will see the partitions.
I have used the adb shell to mount my system partition as RW (mount -o remount,rw /system) but it appears to revert to RO. I can't tell exactly why.
I wish to move app updates to /system.
I have used CF Auto Root to root the device.
I installed Titanium Backup Pro.
I have set the app mode to AUTO/indirect as recommended for Samsung devices.
I select Integrate updates to system ROM (or similar, I don't have the screen in front of me). As soon as I do this, the /system partition is remounted as read only (cat /proc/mounts | grep system)
TB just seems to hang. The Gmail base.apk has been copied to /system/apps and the com.google.android.gm-1 folder has been removed from /data/app.
If I don't mount /system as RW the same thing happens.
If I manually copy the app data from /data/app to /system/app and set the permissions the app still fails to function.
Does anyone have any ideas why this is happening?
EDIT:
I cannot load apks via adb - I am told I have a RO file system, even though I can clearly see the /system partition is mounted.
This was driving me up a tree the last few days. I've dealt with Link2SD on quirky devices before, but this one forced me to understand just how Link2SD implemented the mount script, and hooray, I got it.
Now basically, I'm assuming you already know what Link2SD is for, and I'm also assuming that your S-ON device is already rooted and you have a custom recovery partition to the likes of TeamWin or CWM installed and functioning. For my device, I have a recently rooted HTC Desire 510 acquired from FreedomPop.
With the help of DiskInfo, I determined that this device supports ext4, so that's the filesystem I'm using.
____________________
So, What's the magic file anyway? (or, How does Link2SD Work?)
Link2SD has to mount the second SD partition rather early to make sure the files on it are accessible before Android starts looking for the apps. It does this by replacing an existing binary file with its mount script. Don't worry though, before replacing it, it renames the binary file and calls it at the end of the script. The file is:
/system/bin/debuggerd
That's it, and if you want to use Link2SD on your S-ON device (without resorting to quick-reboot every other boot, which on my device at least was spitting an error for every moved app or directory), you'll need to manually do the steps Link2SD would normally do automatically. You'll need to gather some info and other preparation. I'll provide a sample script (which came from my Proscan tablet), which you must edit to match your device information before flashing.
Here's the sample script. Save as "debuggerd" :
Code:
#!/system/bin/sh
#added by link2sd
LOG=/data/link2sd-debuggerd.log
echo "$(date) mounting..." > $LOG
sleep 2
mount -t ext4 -o rw /dev/block/vold/179:2 /data/sdext2 1>>$LOG 2>>$LOG
mount -t ext4 -o rw /dev/block/mmcblk0p2 /data/sdext2 1>>$LOG 2>>$LOG
mount >> $LOG
echo "$(date) mount finished" >> $LOG
echo debuggerd.bin launched >> $LOG
exec /system/bin/debuggerd.bin
You'll notice two mount lines, these are the ones in need of edit. What you'll need to find out:
* The 2nd SD partition type. If you did the partitioning, you should already know this one. As I already mentioned, I used ext4.
* The block number of the second SD partition. I like DiskInfo for that one. The script might be okay for your device, or it might not depending on how storage is set up. The desire was mmcblk1p2.
* The vold id of the second SD partition. Vold is the standard method of managing partition mounts in Android, so is Link2SD's preferred mount method. The block number line is only included as a backup in case the mount by vold id fails. If Link2SD is already installed (and it should be) and the mount script (supposedly) created, it will have already mounted the second partition, so you should be able to go into terminal and type
mount | grep sdext2
to retrieve this number. 179:2 is typical, but my desire was something like 179:58. Best to look it up.
Make the necessary edits, then save the file somewhere accessible to your recovery, such as the root of the sd card (first partition).
Double check the mount info in the script.
____________________
The manual install.
Now for the fun part. Reboot into your custom recovery.
Make sure /system and the sd card are mounted.
Enter the file manager.
Navigate to /system/bin.
Rename debuggerd to debuggerd.bin .
..This is to match the last (exec) line in the script, and what makes the mount stage a seamless insertion into the boot process.
Navigate to where you saved the replacement debuggerd script. Select Copy.
Navigate back to /system/bin and Paste. Confirm if necessary.
Once the custom debuggerd script is copied, you'll need to make sure it's executable. Run chmod on it, something like 755 will be fine. Confirm if necessary.
You also need to make sure the mount directory exists. Navigate to /data , if it doesn't already exist, make a directory called sdext2 .
That should be it. Reboot into the system. If everything is correct, you should boot normally with the second SD partition already mounted before the apps are loaded. I have so far been running Link2SD on the Desire for about a week, and have not run into any *unusual* problems.
____________________
Disclaimer.
This method was successful for me. Your mileage may vary. Editing the system partition always has some inherent risk. What you do to your device is on you; I will not be held responsible for a boot-loop, bricking the device, random interplanetary calls, or any other damages incurred, physical, monetary, or otherwise following your reading of this post. Proceed at your own risk.
---
Sent from my HTCONE using XDA Free mobile app
Having revisited this thread, I noticed I forgot a step, now fixed.
I still use this phone. A couple small glitches have developed over time which may be related to using a cheap sd card, but, basically I have an app with a bad id, it's disabled anyway so I just ignore it on boot (the I'm feeling lucky button). Also, if there is a glitch that prevents a proper shutdown, the second partition may get corrupted. It is impossible to boot with the card unmounted without causing a bunch of other app related issues, so the only way to deal with it cleanly is shut down, remove the card, and fix it on another computer (preferably linux), then reinsert the card before booting the device back up.
Also, after another week, "app data" on the card stopped working right: existing moves caused errors and new moves failed, so I just moved all app data back to internal. Again, this may be just related to using a cheap card, and it was around the same time the bad id occurred, so I'm sure there's some unresolved corruption that just plain isn't getting fixed without a factory reset. It's getting about time to do that, so if I can score a new card and some time to set it up, I'll post how it goes. Apps themselves, dolvik, and libraries continue to work on the sd card without issue on most apps.
This is a very annoying issue but I have not found any thread about it.
I'm trying to upgrade my external/removable sdcard for an android 6 device.
The new sdcard gets mounted to /mnt/media_rw/XXXX-XXXX (i.e. not 0123-4567), so no app works as files can't be found.
The linux way (ln) wont work. Simply creating /mnt/media/0123-4567 causes bad bootloop on my device. This suggests that FolderMount app or Magisk modules such as fbind are a bad idea. selinux is enforcing.
It appears that Android assigns different mount points are to different sdcards and the first sdcard always gets 0123-4567. It that's right, Android probably stores sdcards' identifiers so as to know which mount point to use at boot time. So, deleting the identifiers database would probably mean that the next card inserted would get 0123-4567 as mount point.
I have looked at the data of com.android.externalstorage, but there is nothing there. I don't see other obvious candidate apps.
Where is this ext sdcard data stored?
I was wrong. Android sets mount points matching sdcard uuid
How to change vfat partition UUID?
How do I change the UUID of a vfat partition? For ext2 / ext3 / ext4, this is done with a simple: tune2fs -U <new-uuid> /dev/<partition> Is there a similar command for vfat partitions?
superuser.com
Hello, i have a Redmi note 9S which shipped with Android 10 out of box.. i'm using Dynamic System Updates (DSU) with unlocked bootloader to try custom roms and decided to modify some custom GSI to manually root it and customize some apps (modifications directly to system partition) but noticed that system partition can't be mounted as rw and gives error "wrong fs type, bad option,.." i can only mount it as ro.
I knew that this happens because ext4 partition formatted with EXT4_FEATURE_RO_COMPACT_SHARED_BLOCKS (so called ext4 dedup) and this prevent it from being mounted as rw, trying to extend system.img with fallocate and resize ext4 file system with resize2fs and then use "e2fsck -E unshare_blocks" seems to work but the phone can't boot and trying to create a new rw system.img also fail as device doesn't boot, also i noticed that GSI versions with "vndklite" can be mounted as rw but same thing, it fail to boot when flashed with DSU and the device reboot again to the main OS..
So i have two questions here:
1) is that happens because the device refuse to boot system partition without EXT4_FEATURE_RO_COMPACT_SHARED_BLOCKS as it's already shipped with Android 10 and support this out of box or this happens because of DSU and will boot if flashed with fastboot?
2) and most importantly how can i modify system.img and then apply EXT4_FEATURE_RO_COMPACT_SHARED_BLOCKS (apply shared blocks feature on the file system) like what custom roms developers do so i can boot a modded system partition?
Any help would be appreciated.. Thanks!
same question, did you find answer?