Database Info

[Q&A] Ubuntu on the Transformer (eMMC install)

This thread is for help and support related to ubuntu on the eeepad transformer, all questions not related to development should be asked here, please be friendly and do not flame each other or I will request the thread be closed.
Download links are in the third post.
There is a wiki entry here that has a bit more detailed explanation. Please note though that as it is a wiki information
quoted in there may or may not be entirely accurite.
you will need to download an nvflashable rom, like prime.
Please read the README before attempting this. The readme is below as well as in the kit, YOU WILL LOSE DATA.
Download links are in the second post.
OLiFE for the ASUS transformer
------------------------------------------------------------------
(c) 2011 Steven Barker <[email protected]>
This package should have only been linked to from xda-developers
or rootzwiki if you got the links to this package from anywhere
but those sites please send an email to the above email
address with the subject: "unauthorised posts"
DISCLAIMER
------------------------------------------------------------------
Steven Barker (lilstevie) nor anybody will take any responsibility
for any damage, data loss, fire, death of a loved one, or loss of
data resulting from using this mod for your device. Using this mod
may void your warranty.
NVFLASH
------------------------------------------------------------------
nvflash is the intellectual property of nvidia, and remains the
property of nvidia. Any questions or queries regarding the usage
and licence of nvflash should be directed to nvidia.
abootimg
------------------------------------------------------------------
abootimg is by Gilles Grandou <[email protected]> and is
unmodified. The source is available from online at
http://gitorious.org/ac100/abootimg
usage
------------------------------------------------------------------
Usage has changed since the release of the last kit, please read
these instructions carefully, as the install method is a little
more complex, (but easier once you use it).
If you downloaded OLiFE.tar.gz you will need to inject the android
rom and ubuntu image. You can use any nvflashable rom with this.
I recommend that you use prime as that is the configuration that
I have tested myself, and the ROM that I support for use with this
device. You can download the ubuntu image from
http://lilstevie.geek.nz/ports/ubuntu.img.gz.
If you downloaded OLiFE-Prime-Edition.tar.gz you will not need to
download the ubuntu image or an nvflash rom as they are seeded into
the image.
Install instructions:
1) Download the specific flavour of OLiFE that you want to use, and
extract it with "tar xvf <filename>".
2) If needed inject android rom and ubuntu image.
3) From the directory that OLiFE was extracted in run the main script
with the command ./OLiFE.sh.
4) Read the text that comes up and answer the question it asks.
5) Follow the menu to the option you want (below is a breakdown of
what each menu item is) and follow the instructions prompted. (also below
is instructions on how to get into the modes requested).
Menu items:
1) Backup Menu:
1) Full Backup (stock)
- Full backup (stock) takes a full backup of a stock
android system. This gives you an option to also back
up your user data(this will take a while).
2) Full Backup (ubuntu)
- Full backup (ubuntu) takes a full backup of a system
that dualboots android and ubuntu, this backs up your
system, and the ubuntu image. This gives you an option
to also back up your user data(this will take a while).
3) User data only
- This backs up the user data partition on your device.
(This option takes a while)
4) Android ROM
- This option backs up the android system only. This
option generates all the files (minus bootloader, and BCT)
required to flash a rom via nvflash.
5) Ubuntu Install
- This option backs up the ubuntu install on your device.
2) Flash Device:
1) Dualboot:
- This option will install ubuntu to your device in a
dualbooting configuration with android. During the
installation process it asks you which OS you would like
to boot by default.
2) uboot (linux only):
- This option will install ubuntu with u-boot and the
ChromeOS kernel that supports acceleration. This option
is currently unavailable, but should be available soon.
3) asus boot (linux only):
- This option will install ubuntu with the asus bootloader
with this configuration you will use all the eMMC for ubuntu
and there will be no android system installed on your device.
4) stock:
- This option will partition the device in a stock way and
install the android system that is in ./images. Use this
option if you no longer want ubuntu on your device.
3) Update Device:
1) Android Kernel:
- This option will update the android kernel on your device
with the boot.img from ./images/. This allows you to install
your own kernel on the device for android rather than the one
that comes with your chosen rom.
2) Ubuntu/Linux Kernel:
- This will update the ubuntu kernel on your device to the version
included in this flashkit. This option is for updating just the
kernel with nvflash rather than using the blob method. This method
is also good for if you flash a bad ubuntu kernel to the device.
3) Android ROM:
- This option will update the android rom on the device with the
one from ./images/. This is good for if the ROM you use is updated
or you would like to change ROMs and there is an nvflash image for it.
This option does not destroy your data.
4) Ubuntu Rootfs:
- This will update your ubuntu image on the device. This is destructive
to data stored in the ubuntu image.
5) Advanced (Unsupported):
- Any option in this menu is not supported and should be considered
unstable. There may be bugs in these options and they are not maintained
at this point in time.
1) Flash ChromeOS Kernel (Primary Boot):
- This option will flash the ChromeOS kernel to the primary boot
partition. This option may not currently work in it's current
configuration.
2) Flash ChromeOS Kernel (Secondary Boot):
- This option will flash the ChromeOS kernel to the secondary boot
partition. This option may not currently work in it's current
configuration.
3) Update Uboot Partition:
- This option will update the u-boot boot partition that u-boot
reads the kernel and boot script from. This option does work if
you have installed u-boot by compiling it from source and installed
it yourself.
4) Flash ClockworkRecoveryMod:
- This option allows you to temperarily flash CWR to the device so
you can update the installed rom. It backs up the current kernel in
the recovery kernel position and then flashes CWR. When you have finished
using CWR you then push any key and put the device back in APX mode and
it will restore the kernel that was in that position. (This only works if
android is your primary boot option at this time).
4) Inject Firmware:
1) Bluetooth firmware (default install):
- This option will inject the Bluetooth firmware from the
android ROM located at ./images/ in to the ubuntu of your
currently running system.
2) Bluetooth firmware (CrOS Kernel):
- This option will inject the Bluetooth firmware from the
android ROM located at ./images/ in to the ubuntu of your
currently running system and flashes the proper u-boot kernel
if you no longer need adb support.
5) Onscreen Keyboard:
- This runs OnBoard so that you can run through oem-config properly
you only need to use this option if you do not have a keyboard dock
and on the first boot.
1) Standard Kernel:
- This will invoke oem-config on the standard kernel installed
on the device.
2) ChromeOS Kernel:
- This will invoke oem-config on the u-boot kernel that is
installed on the device and flashes the proper u-boot kernel
if you no longer need adb support.
Device Modes:
APX Mode:
-This mode is used by nvflash to write files to the eMMC device.
To boot in this mode you press Power and Vol-Up.
Recovery Mode:
- This mode is where CWR or Asus recovery normally lives, but is
replaced by the secondary OS in the dualboot configuration.
To boot in this mode you press Power and Vol-Down, then Vol-Up when prompted.
Normal Boot:
-This mode is where android normally lives.
To boot in this mode you press the Power button until the screen turns on.

Changelog
------------------------------------------------------------------
1.2a - Release name: Odyssey
* New name for kit: OLiFE
* New menu system
* Updated README
* Better handling of platform detection
* Bluetooth support in ubuntu.img
* Preliminary support for ChromeOS kernel
* Preliminary support for uboot
* Fixed touchpad
* Fixed network manager
* Updated to ubuntu oneiric
* More options for flashing and updating
* OTB Wireless support (No more injecting)
* Smaller ubuntu.img for faster upload to device
* Auto resizing of rootfs on first boot
* Larger partition size (6GB) for ubuntu
* Refactored to more easily between devices
* Maybe something else I have missed
1.1 - Release name: Daedalus
* Firmware injector for BT and wifi firmwares
1.0 and silent updates - Release name: Prometheus
* Support for x86_64 linux distributions
* Updated README for release on xda-developers
* Fixes to install scripts
* Initial Release

Downloads:
RootFS md5sum(1a9fa8a698e4a96245a3c08511841eb4)
OLiFE md5sum(c30263fd8271a23bb211fd9fdd69fa45)
OLiFE Prime Edition md5sum(767779ccfa200e5e00b2f1e33a3d73a9)
Sources:
http://gitweb.lilstevie.geek.nz
To clone the repos "git clone git://lilstevie.geek.nz/$(name of repo).git"

lilstevie said:
This is running natively and from the eMMC so no µSD card required,
The video is a class2 µSD card and speeds are not an example of speeds from this kit.
Click to expand...
Click to collapse
Thanks for your hard work, but I'm a bit confused by those 2 statements, contradicting each other :/
Also, if I understood properly, there is no CWM after selecting dual boot
Finally, is this a final release, or for testing purpose only ?
If final, a step by step guide would be very welcome
Edit : Just saw there is the tag [DEV] so forget about my last question (guide)

Wow, amazing work here. Haven't been able to do much to my Transformer as of late (due to uni starting up again, and been seeing how the TF goes as a substitute for my usual netbook), but absolutely can't wait to try this out when I got some time.
And yeah, I'm a tad confused here as well. I'm assuming that you mean the video was of Ubuntu running of your microSD drive using Jhinta's scripts but now this allows us to run it off the internal drive... am I right?
And how is the speed difference so far, running off internal vs class 2 microSD?
EDIT: Also, I'm assuming the same things that didn't work on Jhinta's aren't working on this (network-manager gui, touchpad etc)? Or have you changed things up a bit? And the tegra ppa you talk about; that contain the proprietary 3D drivers you were talking about having a lack of in the video?

Nice to see the post in XDA Good work !

bud77 said:
Thanks for your hard work, but I'm a bit confused by those 2 statements, contradicting each other :/
Also, if I understood properly, there is no CWM after selecting dual boot
Click to expand...
Click to collapse
The video was taken before I was stable enough to even think about using internal memory, where as this kit is not using the µSD
and yeah you lose recovery after selecting dual boot, not much we can do about that for the time being.
poltak11 said:
Wow, amazing work here. Haven't been able to do much to my Transformer as of late (due to uni starting up again, and been seeing how the TF goes as a substitute for my usual netbook), but absolutely can't wait to try this out when I got some time.
And yeah, I'm a tad confused here as well. I'm assuming that you mean the video was of Ubuntu running of your microSD drive using Jhinta's scripts but now this allows us to run it off the internal drive... am I right?
And how is the speed difference so far, running off internal vs class 2 microSD?
EDIT: Also, I'm assuming the same things that didn't work on Jhinta's aren't working on this (network-manager gui, touchpad etc)? Or have you changed things up a bit? And the tegra ppa you talk about; that contain the proprietary 3D drivers you were talking about having a lack of in the video?
Click to expand...
Click to collapse
I started back at uni this week myself, and have been using my transformer as a netbook replacement with ubuntu. The video is using my stuff but before I had it running on the internal memory.
speed diference is massive between the class2 and internal. It was so great of a difference that I forget that it is arm now that it is on internal
the PPA will have things such as kernel updates, bluetooth enabler and all that. as for what is working in the release, things are pretty similar to Jhintas release, touchpad does not work correctly network manager gui doesn't work, I have something to enable bluetooth, that works nicely, but it isn't in the fs or up on the ppa yet. 3D drivers are a work in progress, still no EGL and the likes with the L4T releases, so it is really just acceleration for normal use, I have been working on them but as of yet no dice.

So using the PPA, in theory we won't have to flash the device again (at least for the ubuntu part), it will be able to auto-update itself ?

ErGo_404 said:
So using the PPA, in theory we won't have to flash the device again (at least for the ubuntu part), it will be able to auto-update itself ?
Click to expand...
Click to collapse
yes, that is the plan anyway

lilstevie said:
the PPA will have things such as kernel updates, bluetooth enabler and all that. as for what is working in the release, things are pretty similar to Jhintas release, touchpad does not work correctly network manager gui doesn't work, I have something to enable bluetooth, that works nicely, but it isn't in the fs or up on the ppa yet. 3D drivers are a work in progress, still no EGL and the likes with the L4T releases, so it is really just acceleration for normal use, I have been working on them but as of yet no dice.
Click to expand...
Click to collapse
Ah lovely idea with the PPA. When new 3.2 based Prime gets released, I'll try to get a few hours to myself to get this all working together.
Just a few quick questions first:
How do your scripts change the eMMC layout? Does eMMC work the same as a standard HDD/SSD partitioned with a GPT? As in, have you made separate partitions for Android and Ubuntu, or is it somehow shared?
And also related, how much room will it take up on the eMMC (as I've only got a 16GB TF)?
And finally, since you've been using yours at uni running Ubuntu, have you got any idea of the battery life running Ubuntu? I'm assuming it'd be pretty similar to stock, but yeah the battery indicator wasn't working last time I was playing around with Ubuntu from the microSD. Also, does the second keyboard battery work?

poltak11 said:
Ah lovely idea with the PPA. When new 3.2 based Prime gets released, I'll try to get a few hours to myself to get this all working together.
Just a few quick questions first:
How do your scripts change the eMMC layout? Does eMMC work the same as a standard HDD/SSD partitioned with a GPT? As in, have you made separate partitions for Android and Ubuntu, or is it somehow shared?
And also related, how much room will it take up on the eMMC (as I've only got a 16GB TF)?
And finally, since you've been using yours at uni running Ubuntu, have you got any idea of the battery life running Ubuntu? I'm assuming it'd be pretty similar to stock, but yeah the battery indicator wasn't working last time I was playing around with Ubuntu from the microSD. Also, does the second keyboard battery work?
Click to expand...
Click to collapse
The second battery does work, unless you get one of those dodged ones that just randomly stops charging which happened to me, with the dock connected and the battery in it refusing to charge my battery lasted 6 hours.
the layout is different to standard, UDA(User DAta partition) is 4.2GB smaller than what it was, so you have 9.99gb for android and 4.2 for ubuntu, the kernel and recovery kernels are moved up to the end of the flash as well so that they are accessible through /dev

Just finished installing it. Yea, from internal memory it's working much faster. ~20 second boot time!(I didn't have timer with me, so I counted in the head) That's like my laptop with SSD + 10 second bios booting. With a dock it feels like a true netbook. I think I'll even dare to test c/c++ IDE on this thing. Good job!
Used online timer. It's 21 seconds.
Hmm how do I start wifi? eth0 is not even showing in the list of devices.

aligatro2010 said:
Just finished installing it. Yea, from internal memory it's working much faster. ~20 second boot time!(I didn't have timer with me, so I counted in the head) That's like my laptop with SSD + 10 second bios booting. With a dock it feels like a true netbook. I think I'll even dare to test c/c++ IDE on this thing.
Used online timer. It's 21 seconds.
Hmm how do I start wifi? eth0 is not even showing in the list of devices.
Click to expand...
Click to collapse
Sorry forgot to mention in the first post, firmwares are not included in this release due to potential licensing issues, you can push the wifi firmware via adb to /lib/firmware and also the nvram, they are located in /system/vendor/fw_bcm4329.bin and /system/etc/nvram.txt on your android system, the module will autoload on boot once you have the firmware in place, and the interface will be named wlan0

lilstevie said:
Sorry forgot to mention in the first post, firmwares are not included in this release due to potential licensing issues, you can push the wifi firmware via adb to /lib/firmware and also the nvram, they are located in /system/vendor/fw_bcm4329.bin and /system/etc/nvram.txt on your android system, the module will autoload on boot once you have the firmware in place, and the interface will be named wlan0
Click to expand...
Click to collapse
nvram.txt to /etc right? I copied them straight from android partition, but it still doesn't load. Could it be because of the bcm4329_sta.bin or nvram should be placed in /lib/firmware ?
It works now.

So basically we will be able to dual boot Windows 7 and Android?

liorry said:
So basically we will be able to dual boot Windows 7 and Android?
Click to expand...
Click to collapse
No, Windows 7 doesn't have arm version. Windows 8 maybe in future, long future ....

aligatro2010 said:
nvram.txt to /etc right? I copied them straight from android partition, but it still doesn't load. Could it be because of the bcm4329_sta.bin or nvram should be placed in /lib/firmware ?
It works now.
Click to expand...
Click to collapse
the wifi firmware should be called fw_bcm4329.bin and nvram.txt should be in /lib/firmware, I probably should have been a little clearer, but I posted that just before going to bed, and was a little tired

lilstevie said:
the wifi firmware should be called fw_bcm4329.bin and nvram.txt should be in /lib/firmware, I probably should have been a little clearer, but I posted that just before going to bed, and was a little tired
Click to expand...
Click to collapse
"bcm4329_sta.bin" was already there before I even copied 2 modules and it was also loaded as module when I did modprobe. (not 100% sure about the second)That's why I thought it was conflicting with android's modules.

Wow, great work! Can't wait to try it.
Sent from my Transformer TF101 using XDA Premium App

I've probably missed something obvious.. But I get this.
file not found: linux.img
failed executing command 2147483647 NvError 0x4
command failure: create failed
rm: cannot remove `linux.img': No such file or directory
Click to expand...
Click to collapse
After like 5 minutes of NvFlash installing stuff.

If u want to start with android dev.

Read this :-
I don't take any credit I Googled everything. I do take credit of modifying some stuff in word. The idea came from here. I may have took some of his work. SO credit him and Pirateghost for the information about Android.
ADB → Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device..
Android →Unveiled on 5 November 2007, Android is a mobile operating system running on the Linux kernel developed by Google.
ASOP → Android Open Source Project
Apps2SD → Move applications from the internal NAND memory on the device to a removable SD Card.
Bloatware → Software bloat is a process whereby successive versions of apps include an increasing proportion of unnecessary features that are not used by end users, or generally use more system resources than necessary, while offering little or no benefit to its users. Like all the crap that comes from At&t
Brick → When used in reference to consumer electronics, "brick" describes a device that cannot function in any capacity (such as a device with damaged firmware). This usage derives from the fact that some electronic devices (and their detachable power supplies) are vaguely brick-shaped, and so those which do not function are useful only as actual bricks. The term can also be used as a verb. For example, "I bricked my phone when I tried to modify its firmware."[
Hard Brick → When your phone does not turn on at all. When you can’t get in to CWR/CWM Or Stock recovery. You are basically screwed.
Soft Brick → When your phone bootloops. When you can get into CWR/CWM. When You can use jigtag to get into download mode.
Busybox → BusyBox provides several stripped-down Unix tools in a single executable. It runs in a variety of POSIX environments such as Linux, Android, FreeBSD and others, such as proprietary kernels, although many of the tools it provides are designed to work with interfaces provided by the Linux kernel. It was specifically created for embedded operating systems with very limited resources. Platforms counterparts, but they are pretty close and useful nonetheless.
CWR OR CWM ClockworkMod Recovery →A custom recovery for Android phones and tablets that allows you to perform several advanced recovery, restoration, installation and maintenance operations on your Android device that aren’t possible with the stock recovery.
DEODEX → Apk files have respective odexes that devs use to supposedly save space. Deodexing means you convert it back to a .dex file and put it back inside the apk. This allows you to easily replace file (not having to worry about odexes), but the main point was to deodex services.jar so that you can change all text to different colors (such as the clock color to white) and to deodex services.jar, you need to deodex everything.
Flashing → The process of applying a firmware image (or ROM) to a device. It generally entails a very specific order of steps. Failing to complete any one of these steps properly may result in bricking the device.
Firmware → is a term often used to denote the fixed, usually rather small, programs and/or data structures that internally control various electronic devices. Programs stored in the ROM, EPROM, or flash memory that usually control various internal electronic devices (Hard Drives, Keyboards, Displays, etc). Firmware is typically 'fixed' software that is not updated in consumer devices, however it is often updated (or 'flashed') by advanced users to fix bugs or add features to the device. Flashing firmware designed for one device onto a different device, or not following a specific procedure while flashing will often render the device unusable.
Kernel → is the main component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components
Radio → The cellular radio on the device which needs control software called firmware to control it.
ROM → Read Only Memory. In the context of an Android device, ROM is the internal flash memory where the core operating system resides. It can also refer to a specific version firmware that can be applied to a device through a process usually referred to as flashing. An improperly flashed ROM can often brick the device, rendering it unusable.
Superuser→ A program, which gives unlimited access privileges to perform any or all operations on the operating system.
ODIN → Odin is the Samsung software used to update Samsung phones. It does not work with any other devices other than official Samsung phones.
OTA or FOTA → (F)OTA stands for (Firmware) Over The Air and is the process by which required updates and enhancements to your phone's basic operating system can be sent to you through the cellular network. The Galaxy S II software update will be sent via FOTA and is available through Samsung Kies mini.0
ODEX → In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
SDK → Software Development Kit.
Logcat → A debugging tool built into Android devices that displays system logs as they occur. See Logcat.
NANDroid → A set of tools that will enable anyone who has root on their Android device to make FULL system backups, in case something goes wrong or you want to try out that new experimental ROM/theme. NANDroid will backup (and restore) /system, /data, /cache, and /boot partitions.
Recovery Mode → A special environment that you can boot into for troubleshooting and upgrading purposes.
Kang → The process of creating a code based of someone else's code or reapplying code that someone else created into your own code (e.g. git cherry-pick)
Rooting → is a process that allows users of mobile phones and other devices running the Android operating system to attain privileged control (known as "root access") within Android's Linux subsystem with the goal of overcoming limitations that carriers and manufacturers put on some devices.

[GUIDE] Proxyme - Android System Access Tool

The purpose of this thread is to provide a guide for users who have Proxyme preloaded in their device's firmware and want to find out how to use it effectively. Ideally, this will be a place to share experiences and ideas to further improve the tool and provide solutions to problems that people may have.
Introduction
Proxyme ( proc-zahym ) represents a system access solution comprised of the following components:
System service - provides access to privileged system environment
SSH daemon - provides secure shell (ssh) and file (scp) access (based on dropbear)
proxyme.apk - user interface module
This solution is offered as a preloaded option in firmware images and consequently cannot (should not) be installed as a regular app, either from the Play Store or being side loaded. The reason for pre-loading stems from the requirements of the system service component to be able to integrate at system level and not be bound by operating restrictions within the Android application and framework platform environment (Zygote and Dalvik sandbox). The Play Store has been enlisted as the primary and preferred source in providing updates to the user interface component; the actual app you will be interacting with.
Proxyme offers the following functionality through its user interface:
Installation/de-installation of the su binary to provide/remove root access
(useful only for other applications which require root level access)
The persistent behaviour of the su binary can be controlled by a one-shot switch
Register/de-register tag-along scripts for su enable and disable actions
(more details on this below)
Control availability and location of busybox toolbox
Start/Stop SSH daemon
Configure listening port for the SSH daemon
Configure user accounts for the SSH daemon
Submit and execute a shell script
SU Binary
The option to enable or disable the su binary switch (on/off) in the user interface is the equivalent of rooting and unrooting the device. When enabled, you are providing root access to apps which require it to perform correctly. Currently, Proxyme does not have built-in support for monitoring and 'policing' the actual access to root.
Auto Root @ Boot
This switch in the Proxyme app allows you to indicate whether the su binary should be installed or removed during a reboot or startup of the device. Setting it to the 'on' position will make the su binary persistent throughout reboot cycles and leave your phone permanently 'rooted'.
Registering Tag-along Scripts
Whenever you enable or disable the su binary with the on/off switch in the user interface, there exists an option to execute a user script just prior to and one unique to each action. This is possible by pre-registering a script for one of or both enable/disable actions. A script can virtually perform anything and is always executed within root context. Note that you must be very cautious about the scripts you are registering and be certain about their intentions, because a rogue script could cause irreparable damage to you device.
Each script has the option to override, and thus block, the intended action (enable or disable) by setting a system property named proxyme.override to anything but blank.
One purpose of having tag-along scripts would be to 'freeze' and 'unfreeze' specific root-shy apps, which do not 'like' rooted systems. This is one area where we can share the experience of pre-coded scripts for certain target apps and I do hope it will be put to good use.
To submit a script file, tap on one of the SU Enable Script or SU Disable Script text elements to start browsing for a file.
Busybox
Busybox is just that, busybox. Options are available to determine one of two hard-configured locations where it can be installed and to enable or disable it.
More to follow later...
SSH Daemon
The SSH daemon is based on dropbear. It has been modified to support logon accounts in Android, which are configured with the following parameters:
username
password
home directory
which shell to use
user ID
group ID
For whatever reasons, you can restrict access by specifying non-root user and group (0:0) IDs. The IDs you can choose from are derived from a system list which was used and known within Android at the moment of booting the device. If you have installed new apps in the meantime and would like to use their newly assigned IDs, then please reboot the phone to update this list.
Executing Shell Scripts
The ability to submit and execute a shell script from the user interface can be considered a convenient and quick way to get some tasks done. Take note however that your scripts are run in a privileged environment under the root account and that there are risks involved. A rogue or insufficiently tested script can cause major problems if/when it makes changes to key system partitions, which are normally mounted read only for obvious reasons.
Most rom images will include a sample de-bloating script,which removes ROM specific branding apps. The script. /sdcard/Proxyme/debloat.sh, shows how this is done and could serve as a base for more extensive clean-up of firmware components, if you so desire.
Operational Notes
Whenever a device boots from a factory reset condition (i.e. after wiping data), there will be no UID/GID list available in the user management screen. The reason for this is that the SuMeD setup process will complete before the app data store, the location where aforementioned list is stored. has been initialised. Restart the device in order to make this list available.
Behind The Scenes
For details regarding how Proxyme's system service components are integrated in a firmware image, please follow this trail...
Device Support
Before taking the next step to flash your phone/device, please be aware of the risks involved with performing such an operation. Prepare the device properly, i.e. sufficient battery charge, and be well informed of the correct flashing procedure(s) for your device's make and model. On Samsung devices, rooting will probably trigger 'custom' flag(s) and consequently render the warranty void. No matter how adventurous you may feel, it is always a bad idea to try to flash a firmware image which is not intended for your device. Having said all that, note that you will be flashing your phone at your own risk. You are solely responsible for anything you do to your phone/device, so make sure you are well informed and well prepared before deciding to flash or install anything on it.
The following list will be updated as soon as new firmware images are prepared for new and old devices.
Samsung Galaxy Note 10.1 2014
SM-P600 - (reference post)
Samsung Galaxy J
SC-02F (Docomo) - (reference thread)
SGH-N075T (Taiwan) - (reference thread)
Samsung Note 3
SM-N9005 - (reference post)
SM-N900A - (reference post - unconfirmed)
Samsung Galaxy S4
SHV-E330K - (reference thread)
SHV-E330L - (reference thread)
SHV-E330S - (reference thread)
SGH-I337 - (reference post - unconfirmed)
SC-04E - (reference post)
Samsung Galaxy Grand 2
SM-G710L - (reference post)
Samsung Galaxy S3
GT-I9300 - (reference post)
SC-03E - (reference thread)
SHV-E210K - (reference thread)
SHV-E210L - (reference thread)
SHV-E210S - (reference post)
SHW-M440S - (reference post)
Samsung Galaxy S2 LTE
SHV-E110S - (reference thread)
Samsung Galaxy S2
SHW-M250K - (reference post)
Planned Changes
built-in control of su access (much like what Superuser currently does)
choice of built-in simple file browser or use intents to initiate external app(s) for browsing and selecting files
...

Proxyme - Behind The Scenes
This section details how Proxyme's system service components are integrated in a firmware image.
If you are not up to speed with how a typical Android system is constructed, then I would like to suggest you at least make yourself familiar with this topic in order to fully understand what to do with the following text.
The system service components are integrated in the /system partition (mount point) in Android. In the case of changing a live system this will require mounting the appropriate partition read/write before applying the updates. If a static firmware image is to be updated, then extract the component which represents the /system partition from the package and apply the updates before re-packing the firmware image.
The following list describes the major system service components:
hijacker - this is a module you need to write, which has the role of initiating the system service in a privileged environment.
hjprepper - this module is started by the hijacker to prepare the environment prior to starting SuMeD
SuMeD - this one is what it's all about. The Proxyme app relies on this daemon to be up and running in order to perform any of its privileged functions
SSHD - the SSH daemon is represented by an updated implementation of dropbear on Android
Hijacker
The hijacker is a program you would normally have to write to replace an existing program in your rom, which is started during the boot process by for example initd. This part of the integration process requires your (creative) input, since you need to analyse the rom you are working on and figure out how and where to position the hijacker module. If you do find an existing module to hijack, make sure to always call that original module from your hijacker once it has managed to execute the hjprepper program. In some roms it suffices to start hjprepper from a shell script, which is run with root access... they exist, you just have to look for them.
This is what your hijacker could look like in C
Code:
#define PROP_HIJACK "proxyme.hijack.system"
#define HIJACKEE "/system/bin/original-program"
#define PREPPER "/system/xbin/hjprepper"
int main( int argc, char *argv[] )
{
char *lArgv[5];
char **lArgList;
int lArgCnt;
pid_t pid;
lArgList = (char **)malloc( sizeof(void *) * (argc + 1) );
for ( lArgCnt = 0; lArgCnt < argc; lArgCnt++ )
{
lArgList[ lArgCnt ] = argv[ lArgCnt ];
}
lArgList[ lArgCnt ] = NULL;
/* Fork parent process */
pid = fork();
if ( pid < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker Startup... spawning failed, prep first before xfer" );
system( "/system/xbin/hjprepper" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
else if ( pid > 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... spawned, parent ascends phase 2" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
if ( execl(PREPPER, PREPPER, (char *)NULL) < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... failed to call prepper" );
}
exit( EXIT_SUCCESS );
}
hjprepper
This program is responsible for setting up an operating environment for the SuMeD daemon. If you have full control over a rom's boot image, then include a call in your init process to start this module once during boot. If not, then use a hijacker program or look for existing and suitable scripts to initiate hjprepper.
hjprepper starts the SuMeD daemon once it completes the setup and configuration procedure.
SuMeD
This bad boy is responsible for the user requested actions through interaction with the Proxyme app.
Prebuilt Packages
To get you started, there are pre-built modules available,which you can download here. Currently, availability is limited to Android 4.3 and 4.4.2 only. The following zip archives are organized in a folder tree structure,which serves as a guide for where to place the modules within the /system path.
4.3 Prebuilts
4.4.2 Prebuilts

Filler 2
Filler 2

Filler 3
Filler 3

Please add support in latest SHV-E110S 4.1.2 rom(s)
Title says/asks it all...

Can You guide build pre-rooted rom by proxyme? Thank you very much.

linhbs said:
Can You guide build pre-rooted rom by proxyme? Thank you very much.
Click to expand...
Click to collapse
Behind The Scenes section has been added to the OP.

Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.

linhbs said:
Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.
Click to expand...
Click to collapse
Yes. You need to figure out how to get the SuMeD daemon started and that depends on the rom you want to integrate it in. The Behind The Scenes post highlights what areas to focus on when doing this.
Note that the first post includes 2 firmware images (both Android 4.3 and 4.4.2) for the international Note3 (SM-N9005). It's a no-brainer to copy the files from the appropriate directories to an equivalent and same level version firmware for another region of the same device.

Please add support N900A 4.4.2. Thank you very much.

linhbs said:
Please add support N900A 4.4.2. Thank you very much.
Click to expand...
Click to collapse
Has 4.4.2 been released on that device? If yes, a download link for the official stock firmware will help speed up the process. If not, then we wait or you could send a PM to davidcsv with the 10 or 11 digit s/n and he will monitor and download the latest release as soon as it becomes available...after that your new firmware image will be uploaded within a day.

Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!

linhbs said:
Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!
Click to expand...
Click to collapse
N900AUCECMLG (preloaded with Proxyme) (2014-01-04)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is a pre-release/leaked image and not the final deal. It includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link.
All feedback is welcome and will be appreciated. Enjoy!

Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813

linhbs said:
Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813
Click to expand...
Click to collapse
I337UCUFMLD (preloaded with Proxyme) (2014-01-02)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is also a pre-release/leaked image and not the final deal. It too includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link. A Google search shows that this image does have a few minor issues, so beware.
All feedback is welcome and will be appreciated. Enjoy!

Thank so much. I find the phone test. Will respond to you.

SC-04E Stock Firmware Proxyme Rooter images
Root Ready Stock Images
(Unfortunately, flashing these ROMs will trigger KNOX)
Kitkat 4.4
SC04EOMUFNI3 (Proxyme) (Build Date 2014-09-19)
This zip archive contains an Odin flashable file. It is not the complete stock image, so you MUST have OMUFNI3 already running on your phone or you will need to download it from the above reference sites, which carry complete stock firmware images, and flash it before continuing with this file. Instructions are included in the zip archive.
uploaded.net
mediafire
torrent, mirror2

I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.

Good.

linhbs said:
I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.
Click to expand...
Click to collapse
Please post the complete log from the message box in Odin. One more question, is your phone 16GB or 32GB model?
update: and also try again with newer version of Odin v3.09 instead of v3.07

zefieOS EFI Recovery System (Ares8) (Baytrail)

This is a developer level tool, aimed at advanced users
(see next post for releases)
My Ares8 allows you to boot from EFI by holding Home while powering on. This is good because fastboot blocks flashing the partition table and some partitions.
So I have created this mini OS (zefieOS) using Buildroot and a custom kernel I have been hacking together for the Ares8.
This system allows you to completely wipe and repartition your eMMC, restoring partition table and factory image.
A system like this will allow you to take greater risks with your tablet, especially useful for development.
If you wipe your eMMC to install Windows or Linux, you can easily restore to Android (if you have an Ares8, or use the upcoming backup feature).
It should be easy for developers to port to other boards by swapping out the kernel.
Buildroot custom files and configs are available on my GitHub. (may be needed for porting due to keymap overrides to navigate menus)
You can also check the "Projects" section on the GitHub to see what I am planning.
Video:
(QEMU Demo, but tested on my Ares8)
Features:
Restore compressed disk images (xz, bz2, gz)
Restore raw disk images
Restore TWRP raw eMMC images
Restore TWRP ext4 partititons, compressed and/or split
Secure Erase (Discard) entire eMMC and repartition
Copy log to USB
Entire OS is run from RAM Disk.
Shell access (keyboard required)
Dialog GUI navigable from device with keymap overrides
Restore without touching partition table
Multiple backup support
Source code available, easy to rebuild
Future:
To keep up on future plans, check out the "Projects" section on the GitHub
Disclaimer:
I have tested this on, and have successfully restored my Ares8 Gen2 (manufactured August 2016). However while this tool is being released on the assumption that it will work on all Ares8 devices, I will not be held responsible for any damage caused by this tool. This tool, in its current developer alpha state, is not meant to replace TWRP. It is meant to restore your tablet if it is otherwise useless to you, such as being in DnX mode (which means your ESP partition is corrupt or missing). Running this tool needlessly may cause damage, and this is solely your responsibility.

Releases can be found here:
https://archive.midnightchannel.net/zefie/linux/intel_baytrail_soc/zefieOS/
I am linking to a folder because I have decided to release zefieOS and the restore packs separately for easy updating.
To use, download the latest uploaded version of zefieOS, then download the Ares8 Gen2 restore pack.
More information can be found on the top of the page linked.
For now, I would not recommend this unless your tablet is in need of a FULL recovery (aka you are getting the DnX mode error), or if you are a developer interested in porting this to your device.
Developers should know the modular design of zefieOS is intended for easy porting to another device. This means you will not have to update your files 99% of the time when I release updates.
Eventually this will be a more user-friendly tool, but I wanted to release this functioning alpha release for those who may need to recover their Ares8 tablets.
I have successfully restored my Ares8 from DnX mode to a full working system using this tool.
I will continue to work on and improve zefieOS in my spare time.
Developers looking to port this to their devices should respond in this thread and I will help as much as I can.
Eventually there will be both a user guide as well as a developer guide.

Mobile/Android devices architecture

I'm having trouble understanding the architecture of mobile (and Android) devices. I compare it a lot to the design of PCs, laptops, etc, which I know quite well.
Here's my understanding on how PCs work when booting:
​The hardware has firmware stored in ROM (Read Only Memory). Actually, Flash memory is used nowadays, on which the stored content can of course be changed, unlike real ROM memories in the old days. Because the firmware is hardware-specific and its operation is very critical, its content is rarely updated or otherwise changed. Installing new firmware is called flashing. Firmware in a PC is most commonly BIOS or UEFI, the task of which is (briefly) to first run the POST tests, provide some interfaces and finally start the software in the mass storage. By mass storage, I mean memory separate from the firmware's Flash memory, which can also be Flash memory, such as an SSD disk, or a more traditional hard disk.​The BIOS (i.e. firmware) in the specified order (which first is the internal NVMe SSD or the external USB hard disk?) tries to load the software into the RAM memory for execution from mass storage MBR (Master Boot Record) part . Master boot record is a physical defined area in mass storage. Bootloader software is stored on this MBR part.​​When the bootloader (located on the MBR part) is loaded into RAM and run, it knows the contents of the end of the disk and starts the kernel from there.​​The kernel starts (in Linux) the init process, nowadays often Systemd, which starts the rest of the software.​--------------------
What kind of memories and storages are most commonly found in Android devices? One main memory (i.e. RAM)? One Flash memory for firmware (i.e ROM)? Another separate flash drive that acts as mass storage? Possibly SD card and USB stick as external mass storage?
What is firmware on Android devices?
What is the bootloader in (located in MBR part) on Android?
Linux is the kernel used by Android, which is started by the bootloader? After that, Android continues to boot, how?
A pile of terms, which I have ambiguities:
Bootloader; What's it like on Android? It is often characterized as hardware specific. So is it the case that the bootloader in Android is firmware? So in Android, the firmware runs the tasks of the PC world BIOS and bootloader (located in the MBR part), and then starts the Android located on the mass storage?
Recovery; What is this technically?
Android ROM; I can't understand this. As far as I know, Android is an operating system located mass storage, not Read-Only-Memory firmware.
Rooting; On a PC, we are used to the fact that the owner of the device has root rights. Is it just that the manufacturers have decided to set the default root password to some generated random string, and by default, the user only has access to the basic user account?
After the above has been answered, I would like someone to explain to me (separately) technically, starting from the hardware level (where and how), how do Android devices booting and work? Links to additional information are also welcome. hank you very much! If anyone can answer my questions, thank you very much!

Your questions should put you to shame.
Start reading yourself, building up your knowledge as you read.
Anyway, welcome to the forum. After a year of reading, you will laugh at your post.

ze7zez said:
Your questions should put you to shame.
Start reading yourself, building up your knowledge as you read.
Anyway, welcome to the forum. After a year of reading, you will laugh at your post.
Click to expand...
Click to collapse
I know my questions are stupid, but I'm impasse. It seems that there is much less information about designing for mobile devices than PCs. Could you link some articles on this? As the last article I read this, but it didn't help much, because I compare too much what I learned on PCs.

There are no stupid questions, there are only stupid answers.
Start with the basics based on information from google:
Architecture overview | Android Open Source Project
source.android.com

ze7zez said:
There are no stupid questions, there are only stupid answers.
Start with the basics based on information from google:
Architecture overview | Android Open Source Project
source.android.com
Click to expand...
Click to collapse
That is useful, but there is a reason why I asked about mobile/Android device design/architecture. Android itself is as far as I know (if I'm not mistaken) just an operating system, like the desktop operating systems Windows and Ubuntu, but mobile/Android devices are very different from PCs in terms of hardware and firmware. For example: https://www.quora.com/Is-there-anything-like-BIOS-in-mobiles-How-do-they-boot

How long is a huge ball of string?
No simple answer...
This is for those who are new to Android development and basically have NO understanding about the partition structure. I will give a high-level introductory explanation. PC GNU/Linux users: please note this is completely different from x86 (PC Linux) partition table. You will not come across partitions denoted as sda1, sda2, sdb1, sdb2, and so on. Instead, it will be structured as follows:
/boot
This is the partition that has all the data that is necessary for the phone to boot. It includes the kernel and the RAMDISK (these are the only components of the operating system that are stored in this partition. The remaining are stored in /System). Without this partition, the device will simply not be able to boot. Wiping this partition from recovery should only be done if absolutely required and once done, the device must NOT be rebooted before installing a new one, which can be done by installing a ROM that includes a /boot partition.
/system
This partition basically contains the entire operating system, except the kernel and the RAMDISK (as mentioned in /boot explanation). This includes the Android User Interface as well as all the system applications that come pre-installed on the device. Wiping this partition will remove Android from the device without rendering it unbootable, but you will still be able to boot into the /recovery partition to install a new ROM.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the device into a recovery console for performing advanced recovery and maintenance operations on it. Think of this like a proprietary recovery partition that PC companies put on prebuilt PCs. When you flash a custom recovery such as TWRP or CWM, you are overwriting this partition.
/data
Also called userdata, the data partition contains the user’s data – this is where your contacts, messages, settings and apps that you have installed go. Wiping this partition essentially performs a factory reset on your device, restoring it to the way it was when you first booted it, or the way it was after the last official or custom ROM installation. When you perform a wipe data/factory reset from recovery, it is this partition that you are wiping.
/cache
This is the partition where Android stores frequently accessed data and app components. Wiping the cache doesn’t effect your personal data but simply gets rid of the existing data there, which gets automatically rebuilt as you continue using the device.
/misc
This partition contains miscellaneous system settings in form of on/off switches. These settings may include CID (Carrier or Region ID), USB configuration and certain hardware settings etc. This is an important partition and if it is corrupt or missing, several of the device’s features will will not function normally.
/sdcard
This is not a partition on the internal memory of the device but rather the SD card. In terms of usage, this is your storage space to store your media, documents, downloads, pictures, videos, ROMs etc. on it. It is like the equivalent of the ' Users/[Username] ' folder in Windows and ' /home/~ ' folder in x86 Linux. Wiping it is perfectly safe as long as you backup all the data you require from it, to your computer first. Though several user-installed apps save their data and settings on the SD card and wiping this partition will make you lose all that data.
On devices with both an internal and an external SD card – devices like the Samsung Galaxy S and several tablets – the /sdcard partition is always used to refer to the internal SD card. For the external SD card – if present – an alternative partition is used, which differs from device to device. In case of Samsung Galaxy S series devices, it is /sdcard/sd while in many other devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored automatically on this external SD card and everything present on it has been added there by the user. You can safely wipe it after backing up any data from it that you need to save.
/sd-ext
This is not a standard Android partition, but has become popular in the custom ROM scene. It is basically an additional partition on your SD card that acts as the /data partition when used with certain ROMs that have special features called APP2SD+ or data2ext enabled. It is especially useful on devices with little internal memory allotted to the /data partition. Thus, users who want to install more programs than the internal memory allows can make this partition and use it with a custom ROM that supports this feature, to get additional storage for installing their apps. Wiping this partition is essentially the same as wiping the /data partition – you lose your contacts, SMS, market apps and settings.
/Boot (Is NOT viewable in Android)
/Recovery (Is NOT viewable in Android)
/Data (Userdata) (Is viewable in Android)
/Cache (Is viewable in Android)
/System (Is viewable in Android)
/Misc (Is NOT viewable in Android)
Ram
https://developer.android.com/topic/performance/memory-management
Understanding Firmware naming:
N986USQU1ATGM
N=Note
986U or F etc, the model of device
SQ, FX etc = CPU and model specific
U,S,E = Update, Security, Engineering, respectively
1,2,3,4,5 etc = bootloader revision (This is important! You cannot go to a previous revision)
A,B,C,D = Android version
T, U = Year (T=2020, U=2021 etc)
A,B,C etc = month (January A - December L)
1 - 9 and then A - Z =build compilation. This basically means how many builds there are in a month. They start at 1 and go to Z
So N986USQU1ATGM would be
N968-U-SQ-U-1-A-T-G-M
N968U (Note 20 Ultra Carrier version), SQ (Snapdragon), U (Update), 1 (Bootloader version), A (Build 10), T (2020), G (July), M (22nd build)
How to enter Download Mode:
Turn off the device.
Connect USB cable to your PC (Leave it disconnected from the phone)
Press and hold down the Volume Up and Volume Down buttons. While they are still pressed, plug in the USB cable into your phone.
The phone will go into download mode press volume up. In Odin you will see that phone is added.
Dirty Flash:
I would only do this if you are having to manually update to the newer firmware and would not do it if you are coming/going to U/U1 or from beta firmware or if you are on an old firmware. I'd also highly recommend doing a back up prior to the doing this
Load these into Odin
BL
AP
CP
HOME_CSC
Do NOT flash CSC or USERDATA, either of these WILL wipe your device
This is a "dirty flash" and these can sometimes cause issues. Keep in mind if things start going sideways and stuff starts not working right, your first step to a solution will be to wipe the device.
Tips on flashing U1 Firmware:
You will have to wipe, can NOT dirty Flash going between U and U1 firmware
Use the patched ODIN linked in post #2 or #3, Odin3_v3.13.3b (They are exactly the same)
Have an active US Carrier SIM installed to get carrier features
If you get your CSC Stuck on XAA/XAA/(Insert your carrier here), and can not get Carrier options back.
PIT files
https://ihax.io/samsung-pit-files-explained

plus_rlus said:
I know my questions are stupid, but I'm impasse. It seems that there is much less information about designing for mobile devices than PCs. Could you link some articles on this? As the last article I read this, but it didn't help much, because I compare too much what I learned on PCs.
Click to expand...
Click to collapse
The are no stupid questions.
Questions are asked when we do not understand something and want to learn.
There is nothing wrong or negative about asking questions.
Questions are a part of how we learn.
Cheers.

plus_rlus said:
<SNIP>
What kind of memories and storages are most commonly found in Android devices? One main memory (i.e. RAM)? One Flash memory for firmware (i.e ROM)? Another separate flash drive that acts as mass storage? Possibly SD card and USB stick as external mass storage?
What is firmware on Android devices?
What is the bootloader in (located in MBR part) on Android?
Linux is the kernel used by Android, which is started by the bootloader? After that, Android continues to boot, how?
A pile of terms, which I have ambiguities:
Bootloader; What's it like on Android? It is often characterized as hardware specific. So is it the case that the bootloader in Android is firmware? So in Android, the firmware runs the tasks of the PC world BIOS and bootloader (located in the MBR part), and then starts the Android located on the mass storage?
Recovery; What is this technically?
Android ROM; I can't understand this. As far as I know, Android is an operating system located mass storage, not Read-Only-Memory firmware.
Rooting; On a PC, we are used to the fact that the owner of the device has root rights. Is it just that the manufacturers have decided to set the default root password to some generated random string, and by default, the user only has access to the basic user account?
After the above has been answered, I would like someone to explain to me (separately) technically, starting from the hardware level (where and how), how do Android devices booting and work? Links to additional information are also welcome. hank you very much! If anyone can answer my questions, thank you very much!
Click to expand...
Click to collapse
Firmware is the hardware specific drivers, library files and other resources that are supplied by the manufacture(s) and are chipset specific.
The firmware is proprietary and normally closed source. Basically the parts that make the hardware work.
The bootloader is what actually boots the device.
This is supplied by the device manufacture(s) and is device specific.
It is separate from the system.​
Recovery is a mini Android environment.
- Factory (Stock) recoveries are restricted to the user but have unrestricted (root) access to the device.
- Custom recoveries (TWRP, OrangeFox, ..) allow the user unrestricted (root) access to the device.
Android ROM (rom) is the actual system (OS) and normally you would include the version that you are running.
Stock roms - Google 12L, AOSP xx, OOS 12, MIUI xx, ColorOS xx, ...
Custom roms - Lineage 19.1, crDroid 12.1, AospExtended 12.1, ...
In computer terms it would be..
Windows 7, Linux (Fedora 34), MacOS Monterey.​I am not sure what the current versions of MIUI and ColorOS are, hence the xx.​
Once the bootloader boots the device, a few things can happen.
- The system boot image (system kernel) takes over and boots the device into system (rom).
- The recovery boot image (recovery kernel) takes over and boots the device into recovery (mini Android environment).
- If system fails to boot, device reboots into recovery (Recovery Party) if recovery can boot.
- If no boot image takes over, you will stay in the bootloader, reboot into some special mode or just a good old fashion boot-loop.
There have been a lot of changes to Android though the years..
Each device, manufacture, Android version.. can be different from another.
The most common bootloader is (or supports) fastboot but, this is manufacture and device specific.
Not to be confused with fastboot_d (new story that started with Android 10/11?).​This has also changed though the years, some manufacture use their own variation of bootloader.
HTC had H-BOOT, Samsung does their own thing along with some other manufactures.
Rooting....
By default the substitute (switch) user su command is removed from Android.
This is what most refer to as superuser since it defaults to root user if you do not specify a substitute user.​
This has been a long and changing story in the Android world also.
Old but, well worth the read.
How-To SU - [chainfire.eu] - Link
The current most popular used root solution is Magisk.
It is a little more than just su. ​Magisk - [GitHub] - Link
---
It might be easier if you see an actual partition table.
Nexus 7 16 Gig WiFi - [PastBin] - Link
Might as well make it an ... interesting one.
In this example, userdata only has 1.2 Gigs since the rest is used by other partitions.
userdata is mounted as /sdcard.​
Save for boot, cache, system, misc, recovery and userdata.
The other partitions would be considered firmware.
When the device boots, the partitions get mounted to /dev/block.
Hope it helps more than confuse.
Cheers.