Database Info

[Q] Boot Galaxy Tab 3 10.1 from USB

I create bootable USB flash drives based on Fedora Linux or UEFI that have special purpose applications on them. I am able to use these flash drives on Windows 8 tablets that have the capability to select USB as the boot device. Thus allowing the tablet to be booted from this USB flash drive.
I have a Samsung Tab 3 10.1, the device model is GT-P5210 with 4.2.2 OS. My thought is I could connect the micro USB to a USB hub that has one of my bootable flash drives plugged in and boot the tablet from the flash drive.
However, I have searched the forums and wiki for posts on this or related to it but I have not see any.
Can someone point to a post that addresses this?

metaylor said:
I create bootable USB flash drives based on Fedora Linux or UEFI that have special purpose applications on them. I am able to use these flash drives on Windows 8 tablets that have the capability to select USB as the boot device. Thus allowing the tablet to be booted from this USB flash drive.
I have a Samsung Tab 3 10.1, the device model is GT-P5210 with 4.2.2 OS. My thought is I could connect the micro USB to a USB hub that has one of my bootable flash drives plugged in and boot the tablet from the flash drive.
However, I have searched the forums and wiki for posts on this or related to it but I have not see any.
Can someone point to a post that addresses this?
Click to expand...
Click to collapse
The generic boot-loader (*which resides on the chip-set) has no knowledge of USB etc, as the lk (Little Kernel) is more concerned about trapping keystrokes in order to chain-load into recovery or to boot directly into Android environment (When holding Vol+Down key in this instance) - in pseudo-code (this is from the context/aspect of lk, and also, the memory addresses pertaining to how to read the partitions are hard-coded into this lk so it will know how to process the logic!)
The lk kernel is the de-facto standard by Qualcomm for MSM chipsets (Snapdragon) and adopted by manufacturers such as Sony, Motorola, LG, Samsung and can be found in the AOSP source under bootable/bootloader.
if (Is Volume Down key pressed?) then
chain-load kernel from /recovery partition into particular address in memory and jump to it and start execution, in bringing up the recovery environment
else
chain-load kernel from /system partition into particular address in memory and jump to it and start execution in bringing up the Android environment.
end if.
As the kernel within lk is pretty limited, considering that the binary image of the kernel is burned into the chip and therefore no way of modifying it. And also should be mentioned that lk contains the fastboot protocol in preparation for flashing /boot, /recovery, /system and /data partitions. There are two sequences to boot, primary boot and secondary boot as it is:
Primary Boot -> lk (depending on outcome of logic)
Go into Secondary Boot -> /boot or /recovery
Side note: Samsung is fond of the PBL/SBL (Which is Primary Boot Loader and Secondary Boot Loader respectively) in their jargon when it comes to modding. Thing about Samsung, is that, in some handsets, PBL and SBL may be encrypted (Samsung Wave GT-S8500 is one such example, where porting Android to it was nearly impossible to do because of the DRM within the boot loaders which was a nightmare to deal with and made modding it extremely difficult, nonetheless, it is sort of working via an exploit in the FOTA code!)
This is why there are no extra facilities such as OTG functionality or anything else such as serial communications, reading from SDCard, graphics etc as it would make the lk kernel bigger than is intended. In other words, it is the smallest possible size of kernel that is designated to do just the above pseudo-code happen.
Also, another way of looking at it is this, and this is dependent on the Android version - the USB OTG functionality is fully brought up within the Android environment, i.e when the familiar home screen appears, then OTG's functionality is enabled. Unfortunately not the case when looking at it from lk's perspective.
If you're curious, here's the Qualcomm entry on the above lk which is a part of the tiny C source that has ARM assembly included and found in JellyBean's AOSP source in bootable/bootloader/legacy/usbloader/main.c
Source

[WIP]What you need to know before rooting&installing custom roms

HI EVERYBODY,I WILL DISCUSS HERE ABOUT DEELOPMENT OF OUR DEVICE A110Q.WE ALL KNOW THAT OUR DEVICE HAS AWESOME HARDWARE SPECIFICATION,I AM MENTIONING SOME IMPORTANT ONES -​
Chipset - Mediatek MT6589
CPU - Quad-core 1.2 GHz Cortex-A7
GPU - PowerVR SGX544
RAM - 1GB
SCREEN - 480 x 854 pixels, 5.0 inches (~196 ppi pixel density)
CAMERA - 8MP REAR,2MP FRONT
CURRENT ANDROID VERSION - ANDROID 4.2.1
PLEASE DO NOT POST QUESTIONS IN THIS THREAS AS THIS POST IS WIP. PLEASE DO NOT POST COMMENTS IN THIS THREAD.IF YOU WANT TO MAKE A THREAD CONTRIBUTION ,POST LINKS TO INFORMATION OR INFORMATIVE POST PLEASE.​
IF U FINDING DIFFICULTIES IN UNDERSTANDING SOME TERMS THEN SEE AT BOTTOM OF POST FOR ABBREVIATIONS LIST.
FIRST STEP IN DEVELOPMENT OF DEVICE IS "ROOTING".IT MEANS GRANTING ROOT ACESS PERMISSIONS TO CERTAIN APPS
AND MODIFY PROTECTED STORAGE.
CONSEQUENCES - AFTER ROOTING YOUR DEVICE,YOUR WARRANTY WILL BE VOID.THERE ARE SOME WAY TO RETURN BACK TO
WARRANTY.
FOR ROOTING & UNROOTING A110Q-
http://forum.xda-developers.com/mic...l/micromax-a110q-canvas-plus-rooting-t2323893
SECOND STEP COMES IS INSTALLING CLOCKWORKMODE RECOVERY.THIS MEANS REPLACING CURRENT STOCK RECOVEY AND
MODIFYING IT BY INSTALLING CUSTOM ONE.THIS STEP CAN BE DONE AFTER ROOTING DEVICE OR VIA SP FLASH TOOL BUT WE HAVE CURRENTLY GUIDE FOR VIA ROOT AND SOME APPS ONLY.WE HAVE TWO RECOVEY-ClockWorkMod v5.5.0.4 Recovery & Philz Touch Recovery
HERE IS GUIDE FOR INSTALLING CUSTOM RECOVERY--
ClockWorkMod v6.0.0.4 Recovery-Stable & suggested
ClockWorkMod v6.0.4.8 Recovery-Having Backup Bug.
ClockWorkMod v5.5.0.4 Recovery-Stable
Philz Touch Recovery-Lots Of Bugs
THE NEXT THING IS INSTALLING CUSTOM ROMS.THIS MEANS REPLACING YOUR CURRENT ANDROID PROVIDED BY COMPANY BY A CUSTOM ONE DEVELOPED BY OUR DEVELOPERS OR PORTED FROM OTHER DEVICES.
BEFORE INSTALLING ANY CUSTOM ROMS,YOU ARE ADVISED TO TAKE NANDROID BACKUP YOUR CURRENT ROM.IT MEANS TAKING BACKUP OF FULL ROM INCLUDING APP,DATA,CONTACTS,CALL LOGS EVERYTHING.THIS WILL HELP WHEN YOU MESSED UP.
HERE IS LINK-
http://forum.xda-developers.com/micromax-canvas-2/help/how-to-nandroid-backup-t2645983
TO INSTALL CUSTOM ROMS YOU WILL HAVE TO FOLLOW THIS GUIDE-
http://forum.xda-developers.com/micromax-canvas-2/help/how-to-install-custom-roms-t2645977
IF YOU HAVE INSTALLED CUSTOM ROMS AND NEED TO GO TO SERVICE CENTER THEN YOU CAN EASILY FLASH STOCK ROM FROM
HERE(SP FLASH TOOL,THIS METHOD WILL DELEAT EVERYTHING AND BRING YOUR PHONE TO NEW STATE)--
http://forum.xda-developers.com/mic...ide-how-to-unbrick-micromax-canvas-2-t2492344
THIS IS SAME AS UNBRICKING.
OR THIS (THIS IS STOCK ROM FLASHABLE VIA CWM RECOVERY,IF YOU USED THIS METHOD AND YOU NEED TO VISIT SERVICE CENTER UNDER WARRENTY THEN YOU MUST UNROOT YOU DEVICE ALSO AS IT WILL NOT UNROOT)--
http://d-h.st/mZO (BY TEAM DARKDROID.)
DOWNLOAD THIS ZIP AND PLACE INTO SD AND FLASH AS OTHER CUSTOM ROMS.
IF YOUR DEVICE IS SOFT BRICKED THEN USE THIS LINK TO UNBRICK-
http://forum.xda-developers.com/mic...ide-how-to-unbrick-micromax-canvas-2-t2492344
NOW HERE IS A OPTIONAL AND SUGGESTED THING TO DO,IF YOU DO THIS YOU CAN ENJOY BETTER CUSTOM ROMS:-SYSTEM PARTITION INCREASE GUIDE FOR INCREASING SYSTEM PARTITION SO THAT LARGE SIZE BETTER ROM CAN BE INSTALLED.Earlier we were using too old method to increase partition and that was dangerous too as it Corrupts the IMEI
of device but fortunatly i developed a way to increase system partition by CWM without losing IMEI and anything.So no worry now.Go HERE
HERE IS LINK FOR INCREASING SYSTEM PARTITION By SP TOOLS BUT IT WILL CORRUPT YOUR IMEI SO USE ONLY CWM ONE:-
http://forum.xda-developers.com/micromax-canvas-2/general/increase-partition-a110q-canvas-2-t2568182
HERE IS LINK FOR PERMANENT IMEI RECOVERY SOLUTION IF YOU ARE TOO LATE-
http://forum.xda-developers.com/micromax-canvas-2/help/permanent-imei-solution-t2662403
YOU CAN TWEAK YOUR PHONE BY VARIOUS METHODS TO INCREASE PERFORMANCE,STABILITY.FOR TWEAKING YOUR ANDROID HERE SOME GUIDES--
INCREASE RAM BY SWAP MEMORY-
http://forum.xda-developers.com/mic.../mod-increase-extra-ram-canvas-a110q-t2589488
INCREASE APP STORAGE OF DEVICE-
http://forum.xda-developers.com/showthread.php?p=49081376
IF YOU FORGOTTEN YOU LOCK PIN OR SOFT BRICKED YOUR DEVICE THEN USE MY MMX A-I-O TOOL TO MAKE YOUR LIFE EASY:-HERE
ALL ROMS & MODS FOR A110Q​
IF YOU ARE A NOOB AND DO NOT KNOW ANYTHING ABOUT THESE,POST YOUR QUERIES ON THIS LINK-
http://forum.xda-developers.com/micromax-canvas-2/help/noob-freindly-post-t2645972
COMMON ABBREVIATIONS.BY@Deadly
XDA RELATED ACRONYMS
DEV: Developer
ERD: Elite Recognized Developer
FM/FSM: Forum Moderator/Forum Specific Moderator
RC: Recognized Contributor
RD: Recognized Developer
RT: Recognized Themer
SM: Senior Moderator
GENERAL
AFAIK: As Far As I Know
ATM - At the moment
BTDT - Been there done that
CRACK: The password / product key / license key illegally used for unauthorized usage are known as a crack of the software . Also please read the warning posted at warez meaning below. The same applies to cracks
ETA - Estimated time of arrival.. Note: Asking ETA in dev section is a big NO NO..!!
FTFY: Fixed that for you
FTW - For the win
FWIW: For what it's worth
FYI: For Your Information
IBTL/IB4L - In before the lock / In Before Lock
IDK: I Dont Know (Thats what it means and i am not saying i dont know about IDK!!)
IIRC - If I recall / remember correctly
IRC - Internet Relay Chat
LOL - Laugh out loud
NEWBIE: Someone who is new to this field/ forum and wants to learn how to do it rather than say "NOT WORKING! FIX IT!".
NOOB: Someone who is new and doesn't want to learn "HOW" its done, just want to "USE" the end product. So, please guys dont be a noob, be a newbie!
OP: Short for Original Poster, or the person who originally started the thread.
OT - Off Topic
PM: Short for Private Message. Allows users of XDA to send and receive non-public messages. Accessed from USER CP.
P.S: stands for Post Script. It is used when u wrote a message on a postcard and u forgot to mention an important information.*
ROFL - Roll on floor laughing
RTL: Right To Left support (In Some languages you have to start reading from right and end towards left side.. as against to usual method of reading from left to right)
SMH: Shake my head
STH: Something
TBH: To Be Honest
TIA: Thanks In Advance
THREAD: An individual issue page on the forum. This thing you're reading is a thread.
TLDR: Too long to read
TM: stands for Trademark.
USER CP: Short for User Control Panel. This button near the top of the XDA page allows users to update their avatar, personal information, and signature. PMs and subscribed threads can also be checked in this location.
WARES/WAREZ: Warez refers primarily to copyrighted works distributed without fees or royalties, and may be traded, in general violation of copyright law. To make it simple, it is any app/software which has to be paid to use them, but are used without paying any money.. PLEASE NOTE: THIS IS NOT TOLERATED AT XDA. SO PLEASE DONT POST WARES ANYWHERE ON XDA FORUMS. YOU WILL GET BANS/INFRACTIONS IF YOU DO SO!
ANDROID DEVICE RELATED:
ADB: Android Debug Bridge, a utility to run on a PC to allow connection to and control of an Android device. Part of the Android Software Development Kit (SDK), it allows for ROOT-level access to the Android device from a computer.
AOSP: Short for Android Open Source Project. The open-sourced code from which individuals can build new distributions of Android.
APK: An Android executable file, similar to the .exe file in Windows. Most programs will install with a .apk file.
Apps2SD:A method of storing applications and cache on the device's microSD card.
Bloatware: Software or 'apps' that you don't need, but come preinstalled to a device's /system partition, meaning that you cannot remove them unless the device has been rooted
Boot Animation: Boot animation is a term for a graphical representation of the boot process of the operating system. After you switch on / reboot phone you see this.
BOOTLOADER: There are two of these; the primary and secondary bootloaders. These programs tell the Android device how to start up, and are critical to its functionality.
Bootloop: When your system recycles over and over without entering the main OS.
BRICK/(HARD BRICK): An Android device that is completely non-responsive, i.e. nothing lights up, the screen does nothing, no combination of button presses cause any reaction. Can only be restored by JTAG or warranty service.
BUILD.PROP: A plain text file which contains environmental variables for the system to use during operation. Can be hacked to fake a different model for increased functionality, among many other operations. It is also used to make tweaks to boost speed/performance, etc.
BUSYBOX: An application that contains many standard Unix tools.
BUTTON COMBO/THREE BUTTON COMBO: The act of pressing several buttons at the same time to produce a desired result (e.g. press and hold volume up+home button+power button for 10 seconds will reboot into the RECOVERY menu at any movement when phone is on or Press and hold volume down+power button+home button to get into ODIN mode/DOWNLOAD mode).
Cache:A component that transparently stores data so that future requests for that data can be served faster.
CM: Short for CyanogenMod. CyanogenMod is an Android build built from the Android Open Source Project, and its builds are usable on multiple different Android Devices.
CPU: It stands for Central Processing Unit and handles all the complex mathematical formulas necessary to do everyday things like surfing the Internet.
CSC - File with Carrier Customizations
Custom bin counter: A line of code in several Samsung Galaxy devices' bootloaders that counts the number of times a user uses ODIN to flash ROMS/KERNELS to the device. Commonly used to detect software modification. This is called custom bin down in ODIN mode and it should be 0 to claim warranty. Can be reset with GALAXY TOOLBOX APP by Doky73
Custom: Independent developers who like to customize their devices beyond the standard options provided often tend to release the fruits of their labor for the rest to enjoy, in form of custom ROMs.
CWM: Short for ClockWorkMod Recovery Menu. This is a program that allows you to install custom ROMS/KERNELS as well as do many other customizations. Often referred to as the "RECOVERY MENU"/"CWM"
DALVIK CACHE: The collection of program information stored for use by the DALVIK program. This can be cleared from the RECOVERY menu to resolve issues with the Android OS.
DALVIK: The Android operating system's memory management tool. This program handles which other programs are running and assigns memory to them
DEODEXED: Removing the .odex files from an APK file. The .odex files contain a list of dependencies for the associated file, and if something changes, the .odex (and similarly, the associated file) not longer function correctly.
DMESG: dmesg (for "display message") is a command on some Unix-like operating systems that prints the message buffer of the kernel..
DOWNLOAD MODE: Read Button combo to know about this.
EFS: The directory /efs on the Android device's internal storage. Contains files with the Android device's IMEI, wireless devices MAC addresses, product code, and other information..
EMMC: Short for Embedded MultiMediaCard. A chip architecture consisting of an embedded storage solution with MMC interface, flash memory and controller, all in a small ball grid array package.
EXT4: A journaling file system (e.g. NTFS, FAT32 are file systems) often used by Linux distributions. Can be used with Android.
EXTERNAL SD: A micro SD card that has been inserted in the micro SD slot in the Android device. Can be removed.
FACTORY RESET: This will remove all user customizations in the Android OS, returning it to a factory state. Note: This will not wipe the Internal SD card. It will just make it as a phone just bought from the store state.
FC/FORCE CLOSE: When a program on the Android device becomes unstable/gets an error, the DALVIK program will force it to terminate to prevent further system instability which appears as a Force Close message usually in phone.
FLASHING: The act of writing code to the Android device. ROMs, MODEMs, KERNELs, and BOOTLOADERs can all be flashed. Independent from, and having nothing to do with, Adobe's Flash product.
FREEZE: Specific to LINK2SD/TITANIUM BACKUP. Using these 2 apps, the user changes a program into a non-functional, but still installed, state. Useful for identifying problem and FCs.
gapps - Google Applications, like GMail, Calendar, Maps, G+, etc
GB - Gingerbread, AKA Android OS 2.3.X
GOVERNOR: A program that interacts with the device hardware to increase or decrease the processor's clock speed (e.g. at low usage, it will set the processor speed to 400 MHz, but as usage increases, it would scale up to 1000 MHz).
HSUPA/HSDPA: Short for High Speed (Up/Down) Packet Access. This is 3G+, and is the Android device's internet speed level between 3G and 4G.
ICS: Short for Ice Cream Sandwich, the Android OS version 4.0.x.
IMEI: Short for International Mobile Equipment Identity. A unique number to identify GSM, WCDMA, and iDEN phones. Used by GSM networks to identify valid devices.
INTERNAL SD: The internal storage memory of the Android device. Not a physical SD card that can be removed.
JB: Short for Jelly Bean, the Android OS version 4.1.x.
JIG: A piece of hardware that makes a physical connection between pins of the USB slot to force the Android device into DOWNLOAD mode.
JTAG: A process of connecting directly to the main board of the Android device to rewrite corrupted BOOTLOADERS.
KERNEL: The kernel is a program that constitutes the central core of a computer operating system. It has complete control over everything that occurs in the system.
LAST_KMESG: last_kmsg is a dump of the printk statements from the kernel before the operating system itself crashed.
LAUNCHER: A program that launches programs in Android. Examples are Touchwiz (Samsung), HOLO Launcher, Launcher Pro, ADW Launcher, and Go Launcher EX.
LCD Density: Pixel density is a measurement of the resolution of devices in various contexts; typically computer displays, image scanners, and digital camera image sensors.
LOGCAT: A command to view messages in one of the system logs. See Android logger.
LTE: Stands for Long Term Evolution. It is based on the GSM/EDGE and UMTS/HSPA network technologies, increasing the capacity and speed using a different radio interface together with core network improvements.
MAI77 method: Its only known here. So dont say this out of SGY forum. This is a method to flash kernel through CWM using Kernel flasher tool made by MAI77. Its basically you have kernel flasher tool and boot.img file in SDCARD root and you select kernel flasher tool in CWM and it will install boot.img file which is the kernel you selected.
MD5 CHECKSUM: A 32-digit (128-bit) hash number generated by a cryptographic program to ensure that a downloaded file matches the original file. The original file is run through the MD5 generator program, which creates the 32-bit number. This number is checked against the md5 number created with the file the end user receives to ensure file integrity.
MIUI: A Chinese built-from-source ROM. Short for "Mobile Internet User Interface". Also can refer to the MIUI music player, which has been included in other ROMs.
Mod: The act of modifying a piece of hardware or software or anything else for that matter, to perform a function not originally conceived or intended by the designer.
MODEM: The software that interfaces with the phone's radio hardware to connect to cell phone towers.
NANDROID BACKUP: A complete system image backup of the Android device except for the MODEM and KERNEL. Can be accessed from CWM.
ODEX: A file that is associated with an APK file, containing a list of the dependencies for the program. See also DEODEXED.
ODIN: A Samsung proprietary program that allows the Android device to be flashed back to stock or with custom software.
OVERCLOCKING/OC: Setting the processor's clock speed to run faster than its default setting, i.e. 1248 MHz (1.2 GHz) vs 832 MHz (Default)
OTA - Over-the-Air (usually used as "OTA update" for firmware updates that can be installed directly via 3G/4G/Wi-Fi without the need of an PC)
PIT FILE: Short for Partition Information Table file. One of the possible file types used while flashing with ODIN or HEIMDALL.
Port: To Take a rom or app from one phone and program it to work on a different one.
Ram: (Random Access Memory) A group of memory chips, typically of the dynamic RAM (DRAM) type, which function as the computer's primary workspace.
RECOVERY: The menu that allows a user to do many low-level operations on the Android Device. This menu can either be the stock Samsung menu, or the CLOCKWORKMOD RECOVERY MENU (CWM). See also CWM.
RFS: A Samsung-proprietary file system (e.g. NTFS, FAT32 are file systems) used on some Android devices. Stands for Robust File System.
RIL - Radio Interface Layer
ROM: The collection of programs, themes, and settings that create the general look-and-feel of your Android device. This is what most users will initially be wanting to change. Or custom ROM firmware file, Can also refer to a Read-only memory.
ROOT: Changing the permission level of the Android system to its most powerful level, the root user, allowing full access to the file system. More like Administrator permission in Windows OS.
SGY /SGYD /SGYP /SGYPD : Samsung Galaxy Y / Samsung Galaxy Y Duos / Samsung Galaxy Y Pro/ Samsung Galaxy Y Pro Duos
Sideloading: It means installing applications without using the official Android Market.
SOFT BRICK: A device that is not functioning correctly, but still shows some signs of operation. See also BRICK.
STOCK: The Android software version that comes installed on new devices, prior to sale to the user. Can also be used to refer to the Android software issued from Samsung or the carrier.
Superuser/SU: On many computer operating systems, the superuser is a special user account used for system administration. Depending on the operating system, the actual name of this account might be: root, administrator or supervisor.
TETHER: Connecting the Android device to a computer via a wired or wireless connection to allow the transfer of data through the Android device's internet connection. Commonly used to provide internet access to a laptop or desktop computer when other methods are not desired or available.
THEME: A collection of images, backgrounds, colors, font types, and other visual items to change the Android device's look and feel. Separate from LAUNCHER, and is usually FLASHed in CWM.
TWRP2 - an alternate recovery mode for your phone
UNDERVOLTING/UV: Setting the voltage levels drawn by the Android device to a lower level to reduce overall battery usage.
Updater Script: When Android devices install updates via CWM/recovery mode they have to perform a wide range of functions on files and permissions. The scripting language is called Edify and is defined primarily in the bootable/recovery/{edify,edifyscripting,updater} directories of the Android source-code tree.
WCDMA: Short for Wideband Code Division Multiple Access. An air interface standard in 3G mobile communications networks that allows higher speeds and more users.
ZIPALIGNED: An archive alignment tool that provides important optimization to APK files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Reduces RAM consumption.
ALL THE LINKS,MATERIALS OR THREAD I AM REFERRING IN THIS POST OWN THE CREDIT AND THEIR OP.
I AM ONLY HELPING YOU TO UNDERSTAND AND FIND ALL THINGS EASILY.
NO RIGHTS RESERVED BY ME.

All Available Roms
ROMS-​
Stock Romwith flashing unbricking guide.
Stock Rom V3 SP tool (use same V1 method for flashing)
Pre-Rooted Stock Rom
Lewo Rom
MIUI RoM
SGalaxy V1 V2
Baidu Rom
Xperia-Fusion FINAL
Color Os
Xtrme rom
Lewa os 5
Kitkat Themed ROM
BEAST STOCK ROM
MiVo ROM
Note3 Rom
Project Doge Rom
X'Os
CyanogenMod 10.2
Pure Xperia Rom
CyanogenMod 11

MODS
MODS-​
INCREASE EXTRA RAM
SYSTEM PARTITION INCREASE
INCREASE APP STORAGE OF DEVICE
Flashable Fonts Via CWM

Helpful Videos
Micromax Canvas 2 plus IMEI Permanent Fixing Solution
How to Increase System Partition Of Micromax Canvas 2 plus.
Rooting + Installing CWM in Micromax Canvas 2 plus.
How to revert to the Stock Rom from increased system partition

reServed

You might wanna check this guide out http://forum.xda-developers.com/micr...k-rom-t2714611

Nyc post helpful
Sent from my A110Q using XDA Premium 4 mobile app
---------- Post added at 05:18 PM ---------- Previous post was at 04:54 PM ----------
Yes
Sent from my A110Q using XDA Premium 4 mobile app

your r awesome bro...

Where is the link of stock recovery?
Sent from my Micromax A110Q using XDA Premium 4 mobile app

Paras1259 said:
Where is the link of stock recovery?
Sent from my Micromax A110Q using XDA Premium 4 mobile app
Click to expand...
Click to collapse
You dont need the link :| you can just disable custom recovery

Front camera
A small mistake in the specifications, our phones has a 2mp front camera not 5 other than that it's a very useful thread good job

Very Useful posts

@digyvijaykumar123 : Can you please help me on this threadhttp://forum.xda-developers.com/micromax-canvas-2/help/camera-proximity-sensors-micromax-a110q-t2962167. All i need is to disable only the Proximity Sensor so that the screen wont go black whenever i try to make a call

sandeep37 said:
Very Useful posts
Click to expand...
Click to collapse
[email protected]� said:
A small mistake in the specifications, our phones has a 2mp front camera not 5 other than that it's a very useful thread good job
Click to expand...
Click to collapse
Thanks for pointing,corrected now.

How can I increase my phone memory

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.

[INFO] BOOT PROCESS: ANDROID vs. LINUX

NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profile​Read more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel

RESERVED

RESERVED

RESERVED

RESERVED

You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.

NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.

Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.

NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.

mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.

Question Many questions from a total Android newbie

Hi,
Although I passed my 40 I just bought my first smartphone a few week ago. It’s a Doogee S96Pro. As somebody who like to understand how it works, I already learn a few thing on the Android ecosystem.
I’ve been able to activate the developer mode and to use adb to uninstall some apps. I also managed to boot in fastboot mode to unlock the phone.
My first attempt at flashing was a fail, the phone was rebooting in a loop, indicating "Red state". I guess I should have never "fastboot flash boot/recovery foo.img" if "fastboot boot foo.img" didn’t work? What’s your opinion on this?
The Doogee support sent me a link to the files for my phone. In fact someone on this forum has had already posted it. The two archives are named :
S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02.zip
S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip
To make the phone boot again I flashed the boot partition with the boot.img file I found in the second archive. If I understood what I read, the file with "EEA" in it’s name is the "European version" while the other one is the "Global version".
Although I flashed with the boot.img that was in S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04.zip, if I go to the update info (About the phone > Update), I can see the string S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.0128.V3.03_20210128-1612. I don’t understand why this difference (v3.03 vs. v3.04).
Then I used the Magisk Manager to patch this boot.img file and flash it again. I now have root access on the phone which is nice.
Now the questions!
When booting the phone says: “Orange state, your phone’s unlocked”, then it boots normally. What’s the implication of this? I’m not sure but I think I tried to lock it again (fastboot flashing lock) but the message remains. Does it sound possible to you? I should check again this point…
In the Magisk Manager I also tried the "SafetyNet" check, which is refused. Is it OK? What does it imply? Why would I need to pass this SafetyNet test for?
I’m not sure I understood how the recovery thing works… I understand it’s another partition than "boot", and I know I can boot on it using the boot menu (pressing volume up when turning on the phone). What I don’t know is if it starts a recovering of the system automatically when booting on this partition (then erasing all data on the phone), or not.
Let’s say I flash the boot.img on the recovery partition (fastboot flash recovery boot.img). If I do a normal boot it should boot as usual, but if I boot on recovery it would boot on a virgin system. Am I right? Let says I configure nothing and reboot again, a normal boot this time. I then should get back to my usual, already configured system, as the "boot" partition hasn’t been modified. Is this also right?
Before doing anymore tests I would like to be able to backup an image with the phone already configured, with data and root access and applications. One (or maybe two or three?) file I can keep on my computer, and in case I break the boot on the phone, I could just fastboot flash boot my_custom_image.img to recover my phone configured. Oy maybe also flashing a "userdata" partition? Would I need some other partition? Is it more complicated than that?
It seems I have to identify the right partition(s) and carefully use dd to dump the partition to an image file… Before trying to do so I’d like to have some advice, hence this post!
Also. I read about a software called TWPR. Should I use it, and why ? I understand it’s a system aimed to be flashed on the recovery partition, is it right? What’s its use?
Finally I read about LineageOS which is the ultimate customization for the phone, it’s a “pure” Android, which is totally opensource (but it has to uses a lot of proprietary blob for devices AFAIK). I don’t think I’ll get there anyway. If I’m not mistaken it’s hard to do, especially with new phones nobody has ran LineageOS on, and there is something like no probability all the devices would work anyway.
Have a nice day.

there's no implication when you see "Orange state, your phone’s unlocked” unless you didn't the one who did it that means your device is tampered ..
also on SafetyNet is broad topic you can learn what it is here https://www.didgeridoohan.com/magisk/MagiskHideSafetyNet also
"Why would I need to pass this SafetyNet test for?" there are multiple reason such as you can't install banking apps,netflix, ...etc nor download them via playstore
moving on it is not recommend to backup userdata partition since it just contain all contains evidence of user activity. It contains call and SMS records, contacts, user-installed apps, app data, settings, and so-on-and-so-forth. In most newer phones, it also is likely to contain photos and videos and other user-generated files unless an external SD card is present. Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
TWRP is like recovery mode but more feature packed (you can backup partition with it not available on stock recovery)
also experience is the best teacher you must experience failure to improve

ineedroot69 said:
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
this prevent rooted application crawling on other application data such as paypal just stealing your login info and money
Click to expand...
Click to collapse
With a simple ADB command you can decrypt Android partitions:
Code:
adb shell "recovery --set_encrypted_filesystem=on|off" <- enables / diasables encrypted fs

Hi,
Many thx for your answers.
also experience is the best teacher you must experience failure to improve
Click to expand...
Click to collapse
I can confirm that. I accidentally uninstalled the stock launcher with ADB. I’ve been able to install another launcher (I think I’ll keep on Nova Launcher). I tested a few (Launcher<3 and KISS Launcher), although they work fine none of them support switching between running apps. It’s a little bit annoying but I have another way to stop running apps (with App Manager). I guess the only way to get this functionality back is to flash again the boot partition with the Magisk patched image I already used, and to re-configure all the phone again (this is good to learn and luckily I don’t have important data in the phone yet).
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
Click to expand...
Click to collapse
Couldn’t be possible to dump both boot and userdata partitions and then flash them back both “at once”. The key for encrypting/decrypting the user data being contains in the boot (system ?) partition?
I realize Android has a bunch of security configuration you rarely find on a Linux server. Also the hardware is full of devices which require close-source firmware to operate. This is definitively not a good platform for hacking, like most PC are or a Rasberry Pi is . And I bet Windows and Apple phones are evermore closed…
About encrypting, I have a file called "googlekey/kb_0000000000.bin", which is the same in two archives the support sent me
$ md5sum S9S88A7.DGE.DOOGEE.*/googlekey/kb*
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02/googlekey/kb_0000000000.bin
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04/googlekey/kb_0000000000.bin
Click to expand...
Click to collapse
This file is not “per device” knowing every S96Pro users get the same archives. What’s its purpose?
I wonder the same for many files in this archive but I won’t bother you, I’ll make some search.
The one thing I’d like to understand is why the archive is labelled "1203.V3.04" and the system on my phone (after I flashed the boot partition with (a Magisk patched made from) the boot.img in this archive says : "0128.V3.03_20210128". Could it be related to the Magisk patching? (I didn’t check what I had with the stock boot.img). Or I have been downgraded by Google during install?
With a simple ADB command you can decrypt Android partitions:
Click to expand...
Click to collapse
Thx for this. What does it imply to do so? Will the Android system run with this unencrypted data partition? Is there a way to encrypt it again? (With ADB or directly in the phone?)
I’ve seen there are dozens of partitions on a running Android. So far this is what I understood (is this correct?) : There are three important partitions : boot, recovery and userdata. "boot" et "recovery" are the only ones the device can boot on (except booting from an image in fastboot mode using "fastboot boot boot.img"?). Are they some other important partitions this is important to be aware of?
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe? The system must have a userdata partition and this one can’t be shared between to system…
I think I should buy an older Android smartphone to make all that kind of test, especially knowing I don’t have any other phone I can use for everyday use… Do you have some advice on brands and models which are more friendly with customization of the system?
Apart of ADB and fastboot, what are the other important tools to know about?
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Have a nice day.

Marotte said:
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Click to expand...
Click to collapse
My recommendation is GenyMotion for Linux. This emulator requires VirtualBox for Linux gets installed before.
Install GenyMotion
How To Install GenyMotion (Android Emulator) On Linux | 2DayGeek
2daygeek.com Linux Tips, Tricks & News today :- How to Install GenyMotion (Android Emulator) on Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Fedora, CentOS, RHEL, Mageia, Manjaro
www.2daygeek.com
DL VirtualBox
Linux_Downloads – Oracle VM VirtualBox
www.virtualbox.org

Marotte said:
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe?
Click to expand...
Click to collapse
Partitions /boot & /recovery explained:
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the kernel and the ramdisk. Without this partition, the device will simply not be able to boot.
/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.
That's what you can do from within the recovery console:
Reboot system now
Install ZIP from SD-card
Install ZIP from Sideload
Wipe data / factory reset
Wipe cache partition
Backup and restore

Hi,
Many thx for your answers.
also experience is the best teacher you must experience failure to improve
Click to expand...
Click to collapse
I can confirm that. I accidentally uninstalled the stock launcher with ADB. I’ve been able to install another launcher (I think I’ll keep on Nova Launcher). I tested a few (Launcher<3 and KISS Launcher), although they work fine none of them support switching between running apps. It’s a little bit annoying but I have another way to stop running apps (with App Manager). I guess the only way to get this functionality back is to flash again the boot partition with the Magisk patched image I already used, and to re-configure all the phone again (this is good to learn and luckily I don’t have important data in the phone yet).
Also it would be impossible to restore userdata partition since android is encrypting it with unique key every time you set up your device https://source.android.com/security/encryption/full-disk
Click to expand...
Click to collapse
Couldn’t be possible to dump both boot and userdata partitions and then flash them back both “at once”. The key for encrypting/decrypting the user data being contains in the boot (system ?) partition?
I realize Android has a bunch of security configuration you rarely find on a Linux server. Also the hardware is full of devices which require close-source firmware to operate. This is definitively not a good platform for hacking, like most PC are or a Rasberry Pi is . And I bet Windows and Apple phones are evermore closed…
About encrypting, I have a file called "googlekey/kb_0000000000.bin", which is the same in two archives the support sent me
$ md5sum S9S88A7.DGE.DOOGEE.*/googlekey/kb*
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.EEA.HB.HJ.AYYDVFAZ.1130.V3.02/googlekey/kb_0000000000.bin
ead8a1d0f11e5f12bdda0f7a22935c2b S9S88A7.DGE.DOOGEE.HB.HJ.AYYDVFAZ.1203.V3.04/googlekey/kb_0000000000.bin
Click to expand...
Click to collapse
This file is not “per device” knowing every S96Pro users get the same archives. What’s its purpose?
I wonder the same for many files in this archive but I won’t bother you, I’ll make some search.
The one thing I’d like to understand is why the archive is labelled "1203.V3.04" and the system on my phone (after I flashed the boot partition with (a Magisk patched made from) the boot.img in this archive says : "0128.V3.03_20210128". Could it be related to the Magisk patching? (I didn’t check what I had with the stock boot.img). Or I have been downgraded by Google during install?
With a simple ADB command you can decrypt Android partitions:
Click to expand...
Click to collapse
Thx for this. What does it imply to do so? Will the Android system run with this unencrypted data partition? Is there a way to encrypt it again? (With ADB or directly in the phone?)
I’ve seen there are dozens of partitions on a running Android. So far this is what I understood (is this correct?) : There are three important partitions : boot, recovery and userdata. "boot" et "recovery" are the only ones the device can boot on (except booting from an image in fastboot mode using "fastboot boot boot.img"?). Are they some other important partitions this is important to be aware of?
Having a bootable "boot" and a bootable "recovery" partitions, it should be possible to install two different Android OS? I guess this is not possible and the "recovery" partition is dedicated to recovering (ie: reinstall the system) but I don’t understand how and why exactly. The encrypting thing maybe? The system must have a userdata partition and this one can’t be shared between to system…
I think I should buy an older Android smartphone to make all that kind of test, especially knowing I don’t have any other phone I can use for everyday use… Do you have some advice on brands and models which are more friendly with customization of the system?
Apart of ADB and fastboot, what are the other important tools to know about?
For Android development (I mean development of apps for Android), does everyone use an emulator? What’s the best option for such an emulator on Linux?
Have a nice day.
Have a nice day.
jwoegerbauer said:
My recommendation is GenyMotion for Linux. This emulator requires VirtualBox for Linux gets installed before.
Install GenyMotion
How To Install GenyMotion (Android Emulator) On Linux | 2DayGeek
2daygeek.com Linux Tips, Tricks & News today :- How to Install GenyMotion (Android Emulator) on Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Fedora, CentOS, RHEL, Mageia, Manjaro
www.2daygeek.com
DL VirtualBox
Linux_Downloads – Oracle VM VirtualBox
www.virtualbox.org
Click to expand...
Click to collapse
I went for the official Android Studio from Google. I guess it’s the best for a complete newbie like me. I’ve been able to start a virtual phone with it.