Database Info

[GUIDE] The Noobs Guide to Android ROM'ing

Work in progress..
Now the purpose of this guide is only one, to guide you through “cooking” your own stock flashable ROM from a shipped ROM… That’s it. It’s not hard but it does help you start the journey of the real dev work. There are to many "Devs" around that just do something like this guide and copy files from other ROMs to theres, And this DOES NOT make you a Developer so please dont go posting stock deodexed ROMs everywhere and call yourself a Developer
Before starting I’m going to assume you have setup the correct ADB Drivers for your device although not really needed to make a ROM, it does make it easier in the long run.
Once you run through this guide you will have a stock ROM with ROOT permissions, DeoDexed, Zipaligned, Busybox and init.d support. From there you can modify your ROM to your hearts content, all this is doing is making your base. The real Dev work is .smali editing, modifying .xmls making your own apps, etc... This guide will just help you to not rely on other members to release "Stock deodexed ROMs"​
Wording:
ROM = An Android Operating system
Cooking = Making your own ROM
Shipped ROM = A Stock ROM for your device, e.g. a RUU.exe etc…
Kitchen = The Dsixda’s ROM Kitchen
ADB = Android De-Bugging
CWM = Clockwork Mod Custom Recovery
zImage = Kernel controls CPU, Battery etc.
Modem/Radio = Controls cell signal, internet etc.
ROOT = ROOT Permissions, access to the ROOT or / of your device, kind of like the Windows folder on your computer.
DeoDexed = Removing the .odex files from a ROM to allow for .apk customizing e.g. Theming etc..
.apk = Android application file
Init.d = Allows the running of scripts such as Memory tweaks and SD-Card tweaks etc.
SU = Superuser
CMD = Windows Command Prompt
MOD = Modification
Click to expand...
Click to collapse
ADB Short codes that may be helpful later:
Type these directly into your CMD window with your device plugged in.
adb reboot recovery = Reboots your phone straight into recovery mode
adb reboot = Reboots your phone
adb push = use this to push files to your phone, make sure you are in the folder with the file you want to push in CMD (Example, adb push c:\android\SystemUI.apk /system/app)
adb logcat = Tells you what your phone is doing.
adb remount = Remounts the partition specified (Example, adb remount /system)
Note 1:
When making a ROM the overall concept is the same for every device that runs CWM or any other custom recovery. The only main difference is extracting the files you need from the Shipped ROM​
Note 2:
It makes it easier to have a shortcut to your kitchen folder and any others you need in your favourites or dektop​
Part 1. Setting up the “Kitchen”
Go to THIS FAQ and choose the method you prefer to install on. If you are running Windows I recommend the Cygwin way. It’s easier and you don’t need to keep booting between Linux and Windows, You don’t even need Linux if you do it the Cygwin way. And please do get the pictorial guide HERE, it helps A LOT for “noobs” and don’t forget to install the Java JDK if you do Windows Option 1. Keep in mind that doing it on Ubuntu IS much faster.
NOW IF Cygwin is to difficult for you, just download Ubuntu and install it next to windows.
Part 2. Extracting the files you need.
There are a few different ways you can do this, the main ones are:
For HTC Devices
Get a RUU.exe from the internet for HTC Devices and extract the system.img and boot.img
Download the RUU and run it on Windows, proceed until you get to the screen with the picture of the phone, see bellow. – (No you don’t need to plug your phone in)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Open your Start Menu on Windows
In the Windows 7 search bar type %temp% and hit enter
In the folder that opens click in the search box in the top right corner and search ROM.zip
Drag ROM.zip to your desktop, open and extract system.img and boot.img to your desktop.
________________________________________________
For ANY Android Device (Or if you cant get them any other way)
Using a backup of a stock ROM, This way gives you the ability to make a ROM from pretty much any device that has CWM installed.
Taking the system.img and boot.img from the backup folder
________________________________________________
For Samsung Devices:
Extracting the following from a Samsung Shipped ROM
factoryfs.img (and optionally: cache.img, zImage, modem.bin)
TAR file containing factoryfs.img (optional: cache.img, zImage, modem.bin)
ZIP file containing factoryfs.img (optional: cache.img, zImage, modem.bin)
Any of these above methods can be used and the extracted files placed in the ORIGINAL_UPDATE folder of the kitchen in the next step. If your device is not compatible with these methods check the device list in this THREAD for more guides.
Part 3. Setting up the working folder.
Now we have the files needed to make our ROM let’s get to it!
Go to your kitchen folder then the original_update folder and place your files in It
Start the kitchen by starting Cygwin and typing cd kitchen then ./menu
Hit option “1. Setup working folder from ROM” press enter again
Select the option you want from the list e.g. “(1) system.img and boot.img”
Rename the folder if you wish but it doesn’t matter, hit enter
If you are working from system.img and boot.img you need to run through the extraction process in next step. Most new ROMs use an EXT4 file system so if you are unsure just hit option “2 – Run Ext2Explore (EXT3/EXT4)” and follow the instructions in the Cygwin window (If you are just using a .zip or .tar etc. you don’t need to do this step.)
When that’s finished hit “3 – I’m finished unpacking / abort”
Finally hit Y to see you working folder details once its run through the process.
Part 4. Add the options you want to add
A good thing to do now is, keep it simple. The kitchen is best to use only for making your ROM base, once you have the .zip file most customizing can be done from there unless you need to edit the boot.img etc. but we are not going to get into that in this guide.
Now, we are going to make a simple ROM base optimized for speed and functionality. Follow the next steps and by the end you will be ready to build the ROM.
The most obvious of all, we will add “ROOT Permissions”. So choose option 2.
Always stick with Chains method so hit option F, this won’t take long at all, wait for it to finish the press enter to continue.
Next add Busybox with option 3, hit Y to continue and enter when finished.
Most people disable boot sounds (option 4), I usually just do it later if I choose to.
Don’t worry about Zipaligning because we will do it when we build the ROM.
Next choose option 0 for advanced options.
If you ROM isn’t already DeoDexed choose option 11
If you wish you can backup both folders but I usually don’t bother.
Then select option B to Deodex BOTH folders, this one will take some time, on an HP Laptop core2duo with 4gig of RAM takes about 15 minutes.
Now add /data/app functionality so choose option 13 and select Y to continue, This allows you to move apps from the system folder to your /data/app folder before the install, which in turn allows the end user to uninstall the apps if they wish. This can ONLY be done with certain apps, like apps you get from the market.. YouTube, Google Maps, Twitter etc. DO NOT put dependent apps like SystemUI.apk etc in the /data/app folder.
Next add the Nano text editor on option 14
Next add Command Shell or “Bash” with option 15
Next add init.d support with option 17 to allow the running of init.d scripts, sometimes you may have to manually add the init.d folder to your ROM at the end or before build, either way it doesn’t matter.
Now we are ready to build the ROM and flash it. Understand that all these are optional, if you want to you can just deodex the ROM and go straight to option 99 and build the .zip file. This is just what I recommend you do
Next go to option 99 when you’re ready to build your ROM.
For now you will choose option 1 “Interactive Mode”
When it asks you to Zipalign your .apk’s you can now choose Y and it will quickly run through and Zipalign all the .apk’s in your build.
Once finished, it will start building you ROM.zip file this may take about 5-10 mins on a slow computer or if your CPU is busy already.
When that’s finished it will ask you to either continue with the updater-script or not, this is always a YES for you guys, so hit Y and move on.
Now we need to Sign our ROM, this is always a YES also
The final step is to either rename your ROM or not, it doesn’t matter if you do it now or just rename the .zip file later, so do what you wish and hit enter.
Congratulations you have made your first ROM! You can now backup your current setup in CWM and flash it from your SD-Card, be sure to do a full wipe if it’s the first time and install it.
Note 1:
Sometimes you may get an error and CWM wont flash it, USUALLY this is because the kitchen has screwed up the updater-script but this doesn’t often happen. If it does take one from another ROM on the SAME DEVICE (<< IMPORTANT) and add it to your ROM.​

Part 5. Further Mods and tweaks:

Resources:

Last one..

Well be the first one to reply this is amazing for a person like me who is in the learning process.

Mr.Oug said:
Well be the first one to reply this is amazing for a person like me who is in the learning process.
Click to expand...
Click to collapse
That's the idea
Sent from my Nexus S using xda premium

Awesome work! I'll be following this interesting thread. Thanks bro!
Sent from my GT-S5660 using XDA Premium App

Thank you very much. I've tried and passed from your guide and do I expect further intermediate and advance guide ?

Can't wait to start on this tonight.
I changed my ics lockscreen on my one with help from someone.
Now i finaly can learn to mod a rom on my own.
THX for the tutorial.
Time to learn more from my android

This tutorial worked like a charm.
Nice to see that everything worked and that i learned a lot from it.
Can wait to see how to mod it all.
Keep updating and i will follow the threats.

730000229 said:
Thank you very much. I've tried and passed from your guide and do I expect further intermediate and advance guide ?
Click to expand...
Click to collapse
Coming soon guys
Sent from my Nexus S using xda premium

A good tutorial for those with HTC devices, the tablets such as those from Samsung do not follow the file structure as before and will require a correct Edify definition file to create an update script that will work.

lorinkundert said:
A good tutorial for those with HTC devices, the tablets such as those from Samsung do not follow the file structure as before and will require a correct Edify definition file to create an update script that will work.
Click to expand...
Click to collapse
The kitchen should still sort it out. I've not had a Samsung tablet but its not going to be that different and if the updater isn't formatted properly compare it to a pre made ROM and see what's different
Sent from my Nexus S using xda premium

hi i have i9100G and i used the guide as written from top to bottm but for my i9100g it ask to change the framework.i tried the guide twice and both times i get stuck at the boot...

manishdev said:
hi i have i9100G and i used the guide as written from top to bottm but for my i9100g it ask to change the framework.i tried the guide twice and both times i get stuck at the boot...
Click to expand...
Click to collapse
What do you mean it asked to change the framework. More details mate. Make sure you have the right base ROM for your device
Sent from my Nexus S using xda premium

I'm definitely gonna try this out. Thanks for the instruction!

I want to follow this but i see no specifics on how to set up the kitchen on an Ubuntu machine, i purposely took one of my older dell latitude d420 and completely removed windows and installed the latest version of ubuntu, which is 11.10. would you please if possible, post some specifics on how to go about setting up the kitchen for an ubuntu machine, the faq links are pretty much windows specific. you said that using ubuntu would be much easier to go about this adventure, and i am dying to try it out, but im stuck, I know i have the java files and i have the android sdk all installed and stuff (or so i think). Any kind of enlightenment would be much appreciated,,,,,,,im refreshing this thread like every 2 minutes.....i really wanna dive into this

kevace1 said:
I want to follow this but i see no specifics on how to set up the kitchen on an Ubuntu machine, i purposely took one of my older dell latitude d420 and completely removed windows and installed the latest version of ubuntu, which is 11.10. would you please if possible, post some specifics on how to go about setting up the kitchen for an ubuntu machine, the faq links are pretty much windows specific. you said that using ubuntu would be much easier to go about this adventure, and i am dying to try it out, but im stuck, I know i have the java files and i have the android sdk all installed and stuff (or so i think). Any kind of enlightenment would be much appreciated,,,,,,,im refreshing this thread like every 2 minutes.....i really wanna dive into this
Click to expand...
Click to collapse
Just skip everything cywgin. Cywgin basically runs Linux commands on Windows
Sent from my ARCHOS 80G9 using xda premium

Everything will be heaps faster if you run it on ubuntu
Sent from my Nexus S using xda premium

so basically just do all comands written and just omit any refeernce to cywgin? when i extract the zip from the kitchen file, i get 3 folders and a "menu" file, and a readme text. what command do i have to use on terminal to start the kitchen?

[Kernel] EFIDROID - Ultimate preboot enviroment! - Multiboot / Fastboot / UEFI

updated4/4/2017 (Still does not work on stock 5.0) - Removed due to it still not booting stock 5.0, and ALSO now breaks booting unpatched.
twrp 3.1 is broken
twrp 2.7 is broken
twrp 3.0.1 works
some/most custom roms work
Most official/stock do not.
EFIDROID - Official link
Developer: m11kkaa
DO NOT BUG THE AUTHOR ABOUT BUGS/FEATURES, THIS IS UNOFFICIAL.
Most custom roms appear to boot
Install:​
assumes on stock firmware (Custom roms must report the DEVICEID as hlte, hltetmo, hltespr or hltevzw. Ask your Rom maintainer to correct it or visit post #51)
assumes root and bootloader unlocked
For now "efidroid" on playstore is not configured for our device, so we will do this using our own server:
Download "EFIDROID" from the playstore
Download "TerminalEmulator" from the playstore (or use adb shell)
Download "SimpleHTTPServer" from the playstore
NEW UNTESTED - Removed
OLD Download EFIDROID_SERVER_FILES from View attachment EFIDROID_SERVER_FILES.zip
Open and extract the "device" and "ota" folder to the INTERNAL storage of your phone
Open SimpleHTTPServer (do not change default settings)
Open Terminal Emulator and enter: (make sure you didn't forget any spaces)
su
setprop efidroid.server_url "http://localhost:12345"
Now open efidroid, it should automatically connect. Now press the menu key in the top left corner and press install, then press the big install button.
Now create your slot, and reboot.
Use the vol +/- to navigate up or down, use the power button to select an option
Long press power button on internal rom/recovery to boot without efidroid
Reinstalling/Updating:
Download the new OTAPACKAGE file and extract to INTERNALSD, replace old device/ota folders
Clear EFIDROIDMANAGER cache/data
Run the SETPROP command (don't forget su)
Turn on SimpleHTTPserver
Open efidroid and click uninstall, and then click install (Or click reinstall)
MAKE SURE YOUR BUILD DATE NOW MATCHES THE UPDATED BUILD DATE
Uninstall:
if you hit the uninstall button, the app copies the contents of the UEFIESP back to the real partitions and deletes the partition_*.img files. It does not delete the UEFIESP directory or any of the multiboot directories because they may contain other important files.
flashing boot+recovery outside of EFIDroid's control(e.g. using stock's fastboot/odin flash, or using unpatched boot) is pretty much the same as uninstalling efidroid without deleting the partition_*img files.
All that means that you don't have to worry about any of that if you restores your boot+recovery partitions(either through the app or manually). If you want to free up some space you can delete the UEFIESP directory using a root file manager.
Bugs/Issues:
REPORT ERRORS/BUG ON GITHUB
"can't find tagloader for type -1" - your recovery/rom is not supported (like twrp 3)
Report errors: https://github.com/efidroid/projectmanagement/issues
What you must include:
Exact steps to reproduce the error
Give the exact error shown on screen
If its storage related:
Give the output of "cat /proc/1/mountinfo"
EMERGENCY :
If you find yourself frustrated and just wanting things back the way they were:
Download odin
Download twrp (get the md5/tar version for odin)
Turn off phone (pull battery)
boot to download mode by holding vol down and home and power
Start up odin and press the AP button and browse for the TWRP file. Press start to flash.
Reboot phone into twrp recovery (vol up + home + power), and restore your boot/recovery partitions.
EFIDROID has now been effectively disabled[/HIDE]
Help and info:
If you are familiar with adding touchscreen support please visit us!
Join us on Slack : http://join-efidroid.rhcloud.com/
Once joined: https://efidroid.slack.com/
EFIDROID G+ page : https://plus.google.com/communities/...43671219382368
[/CENTER]

Works on N9005 LTE ?

It looks pretty cool but I've got limited knowledge. My N9005 is on phronesis rom v4.1, IdleKernel v6.6.5 and all partitions converted to F2FS, will it work on this format as well :/

As long as it is a note 3 on msm8974 (sorry exynos) it should work.
File system support should be trivial. I used that same FS myself

Is this an actual GRUB loader for android?
If so am ashuming this means it's possible for UNIX install
i.e. Arch Linux as OS.......

Hmmm.... Windows RT on Note 3... ^^
What about ACPI? We might need this for WinRT

With all due respect, I think you've posted a how to post bit earlier. I'm a flashaholic & the wait for the zip is killing me

I didn't think the day would come.
As a pleb, I will follow this thread with great interest.

djmalik420 said:
With all due respect, I think you've posted a how to post bit earlier. I'm a flashaholic & the wait for the zip is killing me
Click to expand...
Click to collapse
lololol

Wonder if this is ever going to work Great concept though.

Fake ¿ ???
Only what i see its a bootanimation, in the Video from a "older and other"

The OP account is suspended so I guess something fishy is going on.

Guess we will wait and see

oh come on now. I got suspended for being rude to a well respected member of xda. And its not fake... Really? Anyways... I took my ban as a break and just started back with m1cha on getting the uefi part to work with the screen.
A few pointers: You still need devs to port each os, like windows, true linux ect.
This is just a multiboot. So many devices lack that, some had safestrap, or kexec ect, but all those methods had quirks or special rules, or depended on android. This loads before even the kernel.
Also, it will have many tools that a typical recovery has, so you may not even need to reboot into recovery to setup partitions, also aroma was ported, so maybe even installing roms/kernels too.
Also, there will be an efidroid server "store" where you can get tools and apps to run in efidroid. So devs can extend functionality. Also there will be an android installer to make everything easier.
Just think of this as a pimped out safestrap.

SaschaElble said:
oh come on now. I got suspended for being rude to a well respected member of xda. And its not fake... Really? Anyways... I took my ban as a break and just started back with m1cha on getting the uefi part to work with the screen.
A few pointers: You still need devs to port each os, like windows, true linux ect.
This is just a multiboot. So many devices lack that, some had safestrap, or kexec ect, but all those methods had quirks or special rules, or depended on android. This loads before even the kernel.
Also, it will have many tools that a typical recovery has, so you may not even need to reboot into recovery to setup partitions, also aroma was ported, so maybe even installing roms/kernels too.
Also, there will be an efidroid server "store" where you can get tools and apps to run in efidroid. So devs can extend functionality. Also there will be an android installer to make everything easier.
Just think of this as a pimped out safestrap.
Click to expand...
Click to collapse
It doesn't matter what negative comments you get because "Criticism Is The Key To Innovation" it's my personal quotation ...I've been visiting this thread since day one at minimum of three times a day hopping that you would have uploaded the zip...Make it quick buddy & keep up the good work :good:

We need a samsung expert. Getting the display to work in uefi is troublesome. DTSI and gcdb display experience is needed.

SaschaElble said:
We need a samsung expert. Getting the display to work in uefi is troublesome. DTSI and gcdb display experience is needed.
Click to expand...
Click to collapse
as far as my knowledge is concerned, Master @darkera13 is kinda expert you're looking for...I don't personally know him or his skills but people around note 3 forums praise his work very much

Is this Note 3 specific?
This is kinda an off topic question, but, just a few days ago i wanted to try Remix OS out in my PC, but noticed that there is no direct EFI support...just thinking if this thread would be any benefit for PC UEFI users trying to boot Android x86 directly through efi file.
sorry for the question, might be my knowledge limitation on the field...

Using a x64 cpu and grub or refind you can boot RemixOS, they have a uefi image on their site. (Thats what they said) Basically you really don't need efidroid for this, as it would only make it more complicated.

grub is exactly my problem...
thanks a lot for clarifying

[MOD] Bootimage ADB Unsecure Patcher

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Bootimage ADB Unsecure Patcher
Android Bootimage ADB Unsecure Patcher is made to ease the development of ROMs.
Its purpose is to modify the ramdisk to set ADB into an unsecure mode,
in order to debug Android ROMs on clean / bringup boots without doing an 'eng' build.
It means adb can be used without any permissions to run logcat or other commands.
The project implements the logic from the MultiROM injection (originally by Tasssadar),
finds the bootimage of your device (boot naming similar to Chainfire's boot detection),
and applies the needed modifications to the ramdisk's default.prop configurations.
The objective of Bootimage ADB Unsecure Patcher is therefore to simply enable unsecure adb
on a regular ROM's bootimage for developers and users who would require it.
Developers no longer need to recompile a bootimage or full ROM with 'eng' pressets,
nor do users need to edit their bootimages with unsecure adb settings if they really need it.
The patcher needs to be flashed again after a ROM / bootimage update.
This is originally based on my bootimagedebuggable function from android_development_shell_tools.
The project also uses my version of libbootimg to support Sony ELF bootimages.​
Bootimage Debug Addition Patcher
Another part was added to this project: Bootimage Debug Addition allows developers
to debug unbootable Android builds by providing the following items:
Complete logcat service to /data/debug.logcat.txt
Kernel messages exported to /data/debug.kernel.txt
Runtime properties to /data/debug.properties.txt
Detailed tree of / to /data/debug.roottree.txt
Rebooting to recovery and reading the file contents can help resolving issues rather than guessing.
The patcher is called "bootimage_debug_addition", while the revert is called "bootimage_debug_removal".
For builds running with enforced sepolicies, you might need to flash Universal Kernel Permissive Patcher too.​
Downloads (Unlocked Bootloader only)
bootimage_adb_secure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_secure.zip
bootimage_adb_unsecure.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_adb_unsecure.zip
bootimage_debug_addition.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_addition.zip
bootimage_debug_removal.zip : https://github.com/AdrianDC/bootimage_adb_patcher/blob/master/release/bootimage_debug_removal.zip​
Other related useful projects
Universal Kernel Permissive Patcher - http://forum.xda-developers.com/-/-t3506338​
Source code
Project sources - https://github.com/AdrianDC/bootimage_adb_patcher (branch master)
libbootimg sources - https://github.com/multirom-dev/libbootimg (branch master)​
Bootimage ADB Unsecure Patcher created also thanks to :
- Tasssadar for the original MultiROM sources
- The MultiROM-Dev team for our evolution of MultiROM
- Chainfire for the boot detection
- Everyone involved in testing it​
XDA:DevDB Information
Bootimage ADB Unsecure Patcher, Tool/Utility for the Android General
Contributors
AdrianDC
Version Information
Status: No Longer Updated
Created 2017-06-07
Last Updated 2019-08-06

Reserved
Changelog
Code:
Bootimage Debug Addition Patcher - 12/06/2017
===========================================
* Complete logcat service to /data/debug.logcat.txt
* Kernel messages exported to /data/debug.kernel.txt
* Runtime properties to /data/debug.properties.txt
* Detailed tree of / to /data/debug.roottree.txt
Bootimage Debug Addition Patcher - 11/06/2017
===========================================
* Initial public release on XDA
Bootimage ADB Unsecure Patcher - 11/06/2017
===========================================
* Update release to support Oreo system default properties
Bootimage ADB Unsecure Patcher - 05/06/2017
===========================================
* Initial public release on XDA

Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.

kirito9 said:
Nice work, any chance adding support for MTK devices with /dev/bootimg path? The boot detection by chainfire doesn't detect it. Any other information you need I can provide.
Click to expand...
Click to collapse
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.

AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
It's the path and also requires an mtk header appended to the boot.img or it won't boot. I'll try the separate versions.

AdrianDC said:
I never had to work on MTK devices for now.
Is it only a question of different path, with a regular !ANDROID bootimage structure, or something else specifically to handle ?
If only the path, can easily be added. Please try the versions I pushed on a separate "staging" branch and let me know.
If valid, I can do the same for Kernel Permissive Patcher too.
Click to expand...
Click to collapse
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.

I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.

AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
MTK-support would be great..

AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
If it isn't a challenge then it isn't fun . I'll try to see if I can follow what was done for the libbootimg and see if I can get what is needed for MTK.
Also the libbootimg sources in the first post link needs changing to this libbootimg.

this is great its making life easier

kirito9 said:
The path you added helped me figure out how to allow Chainfire's boot detection can be used to detect the dev/bootimg. I had to modify it like bootimg BOOTIMG as I saw the others like that.
So boot image detection is working but I don't think your binary file can unpack the MTK bootimage or it could be another error. There's not enough logging to say at which point the script fails.
Magisk also uses Chainfire's boot detection so I was also able to add the dev/bootimg path to the Magisk script and it got to the point of the unpacking as well. It also doesn't support this MTK boot.img.
@osm0sis was able to use his mkmtkhdr binary to support the unpacking/repacking of this particular boot.img. Maybe implementing in some way can add support for my device :fingers-crossed:.
Click to expand...
Click to collapse
MTK boot.img headers are only for old mt65xx, that's not needed on newer mtk platforms I think you should consider making a mt65xx specific version of this tool (great tool btw, was looking for something similar ) because it's only (no offense) useful for a couple people still working on mt65xx (and mt65xx with 3.4 will probably never see Ng/Oc due to the egl/mali blobs crashing asap as devices enter suspend).
AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)

AdrianDC said:
I was expecting this.
It means (without much surprise) that our MultiROM libbootimg was never ported for and used on an MTK device.
A year ago I added full support for Sony ELF bootimages structures.
You might want to look into it and see if you can identify what's needed for MTK.
However if it's a lot to do / change, as we never needed it and none of us owning an MTK,
I'm not sure it'd be done, especially only for a Dev helper tool rather than MultiROM itself.
At least you can check what I do in my scripts and apply the same thing to a decompiled mtk bootimage.
Click to expand...
Click to collapse
Can you explain in simple language
What is this for.
Someone suggest me to flash this as my phone (codename merlin) was not booting after flashing somefeak kernel

Moyster said:
Mtk got a lot better, kirito has a mt65xx device as far as I know, most if not all platforms after mt6592 (meizu mx4 period) have vanilla boot.img, I'm pretty sure I saw some mtk devices (mt67xx) use MultiROM, so there shouldn't be any need for modifications (except for old undev'ed mt65xx SoCs)
Click to expand...
Click to collapse
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:

bigrammy said:
Yes your correct 98% of MTK devices now use the standard format boot.img.
There are exceptions like the Lenovo TAB 2 A10-70 but it's a pretty easy process convert the old format .img to the newer one and they still work just fine on device. Converting my Sony C4 from a 64bit .ELF to a standard format boot.img was a little more challenging but I got there in the end.
If you need any help @kirito9 converting your boot.img to the standard format drop me a PM :good:
Click to expand...
Click to collapse
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )

Moyster said:
Ha, sorry I didn't mention mtk tablets because I'm so lost with their mt81xx / mt76xx mt89xx, tho a10-70 ran with a mt8165 which is the 2014 generation (around mt6752 release, then they later refreshed their socs and release the mt6753/35 in 2015).
Most if not all mtk SoCs released after 2015/mt67xx work fine on vanilla boot.img, mt65xx and mt81xx (which are =<2014), still needs it
Since OP tool works fine, the only "really needed" thing is a small software to convert vanilla boot.img <-> mediatek headers boot.img, this way if you want to use OP tool with an old mediatek kernel, all it takes is to pre-convert / reconvert (actually, using any kitchen supporting mtk headers to unpack / repack old mtk kernels works just fine, not sure if there's a need for a dedicated tool )
Click to expand...
Click to collapse
You sure do your homework Moyster 100% correct :laugh:
I agree the OP should not have to alter their code to support the <2014 boot.img when it's so easy to convert it to a standard/vanilla format. :good:
:highfive:

Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.

CosmicDan said:
Necro post!
Is anybody still using this for modern devices (Oreo) and it still works for adb on boot for initial bring up? Would save me reinventing the wheel if so, I have some porting work ahead of me.
Click to expand...
Click to collapse
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.

AdrianDC said:
I always am while doing debugging & testings.
I released an update today on something I'm currently working upon, it adds Oreo support for most of the "recent" devices,
feel free to go along and test it, and to participate in the sources if you need something additional.
I also added a new part to the project, meant to ease unbooting builds debugging by automatically logging to /data/logcat.txt as a service.
We often do it manually for development purposes but let's do it automatically for anyone who would need it.
Click to expand...
Click to collapse
Cool stuff. I also compiled a "god mode" adbd binary that I can inject to initramfs, the idea being that it runs as root even on user builds, but for some reason it doesn't work on Oreo anymore. Might just need to update my sources for 8.1 or something, or I missed a compiler flag somewhere, but I'm thinking the init might not be actually running adbd in the right permissions. Tried anything like that?

Moto g5 plus, stock rom 7.0 + magisk 16.6. When connecting I get error:
error: device unauthorized.
This adb server's $ADB_VENDOR_KEYS is not set
Try 'adb kill-server' if that seems wrong.
Otherwise check for a confirmation dialog on your device.

@CosmicDan: Would you mind uploading a patched standalone adbd god mode binary? I Googled your name like "adbd god cosmicdan", only found some references on XDA and GitHub, but they appear to be device-specific. Would such a binary be universal (work on all commonly used CPU architectures/Android versions)? I think your patch is for ARM64, and I do own 2 ARM64 devices, but also a handful of older phones that are armv7a/32 bit.
Thanks!

Development Installing GSI by repacking super.img on SM-A127F and SM-A325F (Linux)

repacksuper
===========
Copyleft uluruman 2021-2022
(for LINUX/WSL only)
This is the minimalistic set of tools + a script for Linux for the automated
ground-up repacking and flashing of the Samsung Galaxy super.img, replacing
the stock Android system with something much less intrusive and obtrusive
(e.g. LineageOS). Or just some other GSI (Generic System Image).
Additional included scripts (since v1.1) simplify flashing of stock firmware or
separate image files under Linux using Heimdall.
Theoretically should work for any Samsung A-series phones, and may be even for
some others. Tested on SM-A127F/DSN made in India and Vietnam and SM-A325F/DS
made in India, on Debian Linux 11 x64. There are reports of successful flashing
of SM-A127M, SM-A032M and SM-A226B.
Why this method?
----------------
Repacking of super.img is the only method which allows changing of the phone's
operating system without screwing up the Verified Boot (VB) protection
mechanism. Keeping the VB allows you to be sure that everything besides the
platform was indeed compiled by Samsung and wasn't tampered with, no matter from
where you downloaded your stock firmware.
The other reason is that although there are alternative methods of changing the
OS, for phones with dynamic partitioning and no working version of TWRP
available they may be even more complicated than repacking of super.img
externally by this script.
Requirements
------------
Install the following tools from the official repositories of your Linux distro:
simg2img xz-utils lz4 unzip gzip jq file
Basic instructions
------------------
repacksuper.sh: main script for changing your phone's operating system
heimdall_flash_stock.sh: script for flashing stock firmware under Linux
heimdall_flash.sh: script for flashing any custom image file under Linux
Just run a script without any arguments to see help.
Extra tools used (x64 binaries and sources included)
----------------------------------------------------
GitHub - LonelyFool/lpunpack_and_lpmake: android super.img tools
android super.img tools. Contribute to LonelyFool/lpunpack_and_lpmake development by creating an account on GitHub.
github.com
GitHub - amo13/Heimdall: Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged.
Heimdall is a cross-platform open-source tool suite used to flash firmware (aka ROMs) onto Samsung Galaxy devices. This is a fork of the original repository with a few crucial pull requests merged....
github.com
Additional notes
----------------
The included binaries for the lpunpack, lpmake and Heimdall were compiled for
the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit
or ARM) you have to compile these tools yourself. The full source code is
included (or otherwise available on GitHub).
Spoiler: Changelog
0.9: Initial release
0.91: Non-sparse new system is now correctly moved into the super dir
0.91a: Bug in the new system file format checking fixed
0.91b: Better support for spaces in paths
0.92: Added checking for system requirements and an optional parameter for
setting of the final tar archive name.
0.92a: Fixed file ownership issues inside the tar distribution archive
0.93: Added support for SM-A325F. Several minor improvements.
0.94: Added support for gzip-packed GSI images. Packing into .tar is now done
without question if the command line parameter is given. Tar parameter
now can include the full path. Without the full path the default tar
location is now the same as the GSI. Several other minor changes.
1.0: Finally added working native Linux flashing using Heimdall (HUGE thanks
to amo13 and Benjamin Dobell). Two new options: using empty product.img
and silent (non-interactive) mode. Colored text. Bugfixes and minor
changes.
1.01: Option to specify the SUPER partition name manually (needed for flashing
SM-A127F with Heimdall). Now it is possible to place output .img and .tar
files in any directory and give them any name. Text terminology a bit
clarified, help text expanded. Done many internal optimizations,
additional sanity checks and minor changes.
1.02: Support for SM-A032F/M and similar firmwares with non-packed super.img.
Support for firmwares with/without additional partitions. Support for
arbitrary partition group names. Very experimental option to use empty
system_ext.img for additional privacy (applicable to some phone models/
regions). Lots of minor fixes.
1.03: Multiple .img files are now supported in GSI archive files (one of them
should be system.img in that case), e.g. Android AOSP zip files are now
supported directly. The logic of flashing with Heimdall now includes more
complex cases, such as flashing in two steps with a reboot. Unnecessary
code in GZ unpacking removed. Some other small fixes and optimizations.
1.1: New scripts heimdall_flash_stock.sh and heimdall_flash.sh added.
Lots of refactoring in repacksuper.sh (because of that there may be some
bugs left), improved and clarified UI logic, changes in where the files are
now placed (see help for details), direct work with stock Zip firmware
files, lots of minor changes.
1.11: Colored text now should be correctly displayed in almost any shell that
supports it except if it's explicitly disabled with NO_COLOR.
1.11.1: heimdall_flash.sh now can flash Super partitions unconditionally in one
step when using both the -s parameter and manually specifying parition
name (e.g. SUPER for SM-A127F).
1.12: The heimdall_flash_stock.sh script was significantly upgraded with lots of
new features. Now it theoretically allows upgrading of stock firmware
without erasing user data, keeping the GSI and custom recovery, etc.
(although it's not that straightforward, read the help for details).
A couple of fixes in the other scripts.
1.12.1: changed unlz4 to lz4 -d, as some distros don't have the needed symlink
1.13: In repacksuper.sh support added for the Vendor DLKM and ODM DLKM
partitions, as well as the experimental -v option to add or replace Vendor
DLKM with a custom image. A couple of minor fixes.
1.14: Greatly improved logic of heimdall_flash.sh, now it's possible to specify
both or either custom partition name and custom file name, and acquiring
PIT from device is done only when it's needed. Versioning scheme of the
scripts was unified: the script that was updated receives the updated
version number of the whole pack, the rest retain the old numbers.
1.15: up_param_tool.sh script was added: it allows altering of the boot
sequence images (logo, "not official" warning, etc.), as well as the
Recovery and Download internal graphics. Happy hacking, but please pay
attention to the warning displayed after extracting the JPEG files.
A couple of minor fixes in the other scripts.
1.15.1: Bug with failing LZ4 uncompression fixed in repacksuper.sh and
heimdall_flash_stock.sh.
1.15.2: Added the Ctrl+C trap in heimdall_flash_stock.sh, so now the temporarily
renamed files are correctly renamed back in case of flashing being
aborted with Ctrl+C. Upgraded Heimdall with the git pull requests, but
it seems those still do not cure the relatively rare issue when flashing
specific files gets completely stuck at some point.
1.15.3: The "file" tool used to identify PIT files was replaced with direct
reading of the file header as the first method proved to be unreliable.
1.15.4: Fixed a bug in heimdall_flash.sh (missing g flag in sed)
1.15.5: Fixed the compatibility issue with the older LZ4 compressors
1.15.6: Fixed compatibility issues with systems where /bin/sh is Bash, such as
ArchLinux
1.15.7: repacksuper.sh: fixed using the existing "repacksuper" dir as source,
also in this mode you can now specify "-" as new system image to reuse
everything inside the "super" subdir. New experimental -w parameter.
All scripts: the Ctrl+C trap now switched on and off the correct way.
Several other fixes.
1.15.8: Fixed using the heimdall_flash_stock dirs as source for repacksuper.sh.
A couple of other fixes.
1.15.9: heimdall_flash_stock.sh: fixed skipping of duplicate partitions (e.g.
vbmeta) for some shells; fixed upgrade-flashing of Galaxy A32 (default
behavior).
Spoiler: Known issues
During the script run you can see several "Invalid sparse file format at header
magic" warnings, just ignore them.
For some firmware files Heimdall may not work at all (freeze indefinitely or
exit with an error), in that case you have to resort to Odin. In many cases
Heimdall freezes when uploading files for some time, but that does not mean it
is completely frozen, just be patient.
In LineageOS, Dot OS and some other GSIs I tried on SM-127F the touch screen
remains not responsive for about 6 seconds after waking up. The problem is not
present at least with SM-127F/DSN phones made in India, but present at least in
those made in Vietnam. Another problem in the most, if not all, GSIs is that the
MTP USB file transfer does not work (at least on Linux) because of the "wrong"
(Samsung's instead of Google's) default MPT driver used by the kernel.
Both of the aforementioned problems can be solved by installing the fixed and
recompiled kernel.
For the last problem alternative solutions include using apps such as
Warpinator, Syncthing or ftpd.
Spoiler: Food for thought
When choosing a GSI to install I really don't recommend using ones which include
GApps and therefore use any of the Google services. Don't let corporations
gather your data. You bought the phone and from now on it should be all yours,
with all of its data, like a PC in the good old days. You own your device, and
nobody has the right to stick their nose into how you use your phone, gather any
statistics and push you any ads. You always have a choice to turn down
privacy-unfriendly stuff, the price of that "inconvenience" is actually
ridiculous. From my point of view, there is simply no point in using non-stock
systems if they are still littered with the privacy-unfriendly bloatware.
For the step-by-step guide (slightly outdated) read this and this post. Also be sure to read this post concerning the importance of optics.img. Concerning the up_param_tool.sh be sure to read this post.
The included binaries for the lpunpack, lpmake and Heimdall were compiled for the x86_64 architecture. If your PC architecture is different (e.g. x86 32-bit or ARM) you have to compile these tools yourself. The full source code is included (or otherwise available on GitHub).

Latest stable combinations of stock firmware and LineageOS (updated February 5, 2023):
SM-A127F: A127FXXU7BVI4 + LineageOS 20.0-td 20230115 arm64 bvS
SM-A325F: A325FXXU2CVK3+ LineageOS 20.0-td 20230115 arm64 bvS
Some recommendations (updated February 5, 2023):
If you are a newbie and don't know how to do unlock the bootloader and other such stuff, here is a good guide by LAST_krypton (follow the "Unlocking the booloader" section) or a shorter guide by cldkrs.
First flash the phone with the whole set of stock firmware using the heimdall_flash_stock.sh (Linux only) script with the -d parameter: the latter forces flashing the unsafe partitions, which are needed for complete re-flashing.
If you're on Windows use Odin instead. Although there is a "leaked" Linux version of Odin, it's still closed-source (of course), so I don't recommend using it on your main Linux PC. For using the Windows version of Odin on Linux you have to either use Windows in QEMU (tested and works) or probably Wine (untested). When using QEMU remember to add the SUBSYSTEM=="usb", ATTRS{idVendor}=="04e8", ATTRS{idProduct}=="685d", MODE:="0666" line to the udev rules (e.g. /etc/udev/rules.d/30-qemu.rules) to enable the write access to the phone.
Sometimes Heimdall cannot flash the stock firmware and gets stuck at some particular file. Although you can successfully flash such a firmware using Odin, I recommend to better to find another firmware, may be one release older, because that may indicate some sort of incompatibility with your particular version of the phone.
The stock firmware comes in different revision numbers (also known as the baseband version), which are upgraded about once a year. Generally it should be beneficial to use the latest revision, but note that once you have upgraded it to a later revision there is no way back (at least known to me). In case you want to experiment with flashing of special kernels and other flavors provided by the XDA developers, if possible, you should probably stick to the very first revision.
If you already have the bootloader unlocked (OEM unlock) then after flashing the stock firmware there is no need to set up the Android, just go straight into the download mode again and flash the repacked super.img.
When downloading LineageOS or any other GSI select the normal arm64 bvS version, not vndklite version.
After flashing the OS go into the Recovery mode (hold volume up and power when rebooting) straight away and do the Factory reset. If you cannot get into the Recovery mode be sure to connect the USB cable before trying to.
If flashing with Heimdall completely freezes at some point make sure you've downloaded and repacked the correct arm64 b or a/b GSI and not arm and not a or a-only variant. If "sw rev check fail" message appears on the screen at some point just ignore it.
You can forcefully reboot your phone at any time, even if it seems bricked, by holding the volume down and power buttons for several seconds.
To upgrade your system to the recent version of the same OS just repackage it again using the same script and flash it normally. If the phone does not boot, get into the Recovery mode and try wiping the Cache partition (all your apps and settings should remain intact).
Most probably you don't need TWRP or any other 3rd party recovery tool at all, as the stock recovery tool works fine for just the factory reset after flashing the super file.
Try to avoid using Magisk if you just want to install another OS and nothing else. It is also not needed for LineageOS bvS version as it already has the su utility integrated, you just need to install the additional Superuser app by Pierre-Hugues HUSSON from the F-Droid store (although it's very old it works just fine).
It's possible that SM-127F/DSN internally is not A12 but actually M12, at least most of the tools and kernels made for M12 work on SM-127F/DSN while those made specifically for SM-125 and even other SM-127 versions do not. Therefore you can find more relevant info and tools in the corresponding XDA thread (my script is still remains relevant though).

I should test this for a127f

Bugs fixed: v0.91 & v0.91a

Bug fixed: v0.91b

Added the "file" utility to the list of requirements, updated readme.txt.

Thanks A LOT, this works! I am finally able to run LineageOS on my phone!
For Windows 10+ users: WSL runs this script just fine with a few additional steps.
1. Install WSL 2 and any Linux distribution from Microsoft Store
2. Run the distribution to finish setup
3. Install the required packages from the post (sudo apt install for Ubuntu/Debian)
4. Shift + Right Click in the folder where you have the script, the AP and the GSI packages
5. Open Linux shell there
6. Unpack & run script as stated in its help
Voila!

Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?

jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
It is totally OK

jadfa said:
Wow ! Great job! I want to try it, but i'm getting many "Invalid sparse file format at header magic" while running the script, is it OK to flah the super.tar anyway?
Click to expand...
Click to collapse
Yes, it is fine. These are just warnings produced by lpmake, they can not be suppressed. I could only suppress all the stdout/stderr from lpmake but it's no good in case of more serious warnings.

Updated to v0.92 with a couple of minor improvements.

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What should I do next with the raw file?
"Unknown super file format" is this how it should be?

ANDARXapi said:
View attachment 5490897What should I do next with the raw file?
"Unknown super file format" is this how it should be?
Click to expand...
Click to collapse
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.

uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
The raw file opens as a picture

uluruman said:
Of course not. The format of each file is checked using the "file" utility, it should return the string "Android super image". Try to run file /home/toor/APfilles/super.stock.raw . What is the response? And try doing it all without sudo. There is no need in root privileges.
Click to expand...
Click to collapse
run without sudo: 168: ./lpunpack_and_lpmake/lpunpack: Permission denied Cannot correctly unpack the super file. Exiting ...

I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd

ANDARXapi said:
I managed to fix the script, you just need to give chmod +x rights to the files in the folder "lpunpack_and_lpmake": lpunpack, lpmake, lpflash, lpdump, lpadd
Click to expand...
Click to collapse
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.

uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Okay, I'll test it tomorrow, today I want to relax at the computer all day

uluruman said:
Hmmm. I have updated it, may be it'll help. Could you please test the latest version (v0.92a)? I want to work it out of the box for everyone, without sudo or any tweaks.
Click to expand...
Click to collapse
Checked, it works right away

Is there a way to install magisk and root?

[Firefly] [ROCKCHIP] 3.5-Month UPDATE: Firefly ITX-3588J (Rockchip RK3588) "Deskphone" WORKS! Almost.

After 3.5 months of trial and error, unresponsive communities, ups and down, spending $75 on a video card that may be proving unnecessary ... I finally present to you - an almost fully-working Firefly ITX-3588J Dual-Boot Android/Linux ARM Machine.
WHAT IS IT?
The Firefly ITX-3588J is a Mini-ITX - small PC form-factor - "single-board computer" that was released earlier this year by the Chinese manufacturer Firefly, aka. T-Chip Intelligent Technology Co. Ltd.. It features the Rockchip RK3588 (hence the name) ARM system-on-chip (SoC) in a package that adduces many different kinds of ports including a PCI Express x4 slot, multiple HDMI video outs that go to the on-chip Mali GPU, and an M.2 that can be used in theory to add a telephone network card, making it a mini-desktop and smartphone all in one.
I got one because I saw it as an opportunity to for once have an easily-transportable low-energy consumption system that would be both an alternative to x86 and also not the Mac while still offering reasonable performance even if far from top-of-the-line - and ideally, it'd be great if more such boards come later because other ARM SBC boards tend to be both more limited and also very awkward with their cables. This is the only one I'm aware of, besides certain Raspberry Pi breakout boards like the Turing Pi, that can use a standard PC case.
But getting it to work, on the other hand, proved to be MUCH more diifficult because while the vendors offered a choice between Android 12 and Ubuntu 20.04 operating systems, I realized I needed both: I wanted access to both software ecosystems on the same machine, and was determined to get that to happen. And I want to say that within the last few days I have finally come quite close to achieving this dream in full.
WHAT DOES IT DO NOW?
Right now, the machine dual-boots Android 12 and Ubuntu 20.04 using the vendor-provided patched 5.10.66 Linux kernel source tree, with the user-space data of both OSes stored on a SATA SSD hard disk instead of the embedded eMMC. Boot selection is possible on startup simply by hitting "Ctrl+C" and typing the appropriate command to select the Ubuntu OS; otherwise, Android 12 boots by default. All this happens by video console on U-Boot with no serial port requirement, making it function as a proper stand-alone dual-boot ARM PC.
WHAT IS STILL TO BE DONE?
Graphics support on Ubuntu 20.04. No idea why this isn't working even with the provided kernel and driver packages. Text console over monitor works fine, though.
WHAT DID IT TAKE TO MAKE IT GO?
In retrospect, it's not really all that difficult. The most difficult part was just figuring everything out because there was very little comprehensive documentation given beyond how to simply load the images, and I had before this point zero real experience actually piecing together an Android system on a mobile/embedded-style board and machine. One thing that's a casualty is the stock Ubuntu image; it turned out to be much more fruitful to simply install the system to the hard drive via a procedure analogous to, albeit having to be arranged manually, what a typical installer would do, i.e. setting up and using APT to load the whole Ubuntu system from the Internet over wi-fi with the only vendor-adulterated component being the kernel and Mali graphics drivers because Valhall, nor even the whole RK3588, is currently mainlined in the Linux kernel system.
WHAT DOES IT LOOK LIKE?
The machine:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Running Android:
Ubuntu (no graphics yet!):

@Shimmy99 Would you please offer the procedure you used to make the board boot from SATA SSD?
That would be greatly apprecaited. I have a similar board and I have been interested in installing Android on a SATA SSD but the vendors don't respond to messages and there is very little information on their forum.
Thank you

qwestmogul2012 said:
@Shimmy99 Would you please offer the procedure you used to make the board boot from SATA SSD?
That would be greatly apprecaited. I have a similar board and I have been interested in installing Android on a SATA SSD but the vendors don't respond to messages and there is very little information on their forum.
Thank you
Click to expand...
Click to collapse
Mmm. I don't have a direct boot from SSD possible yet. Getting it to this stage has required coding work on the provided U-Boot and I would share a source pack to my github but it will take more to get direct SATA boot because it crashes when the U-Boot is compiled with those config options enabled for some reason. My focus mostly was on getting graphical console on the U-Boot so that there is not need to use the serial debug simply to switch OSes ). The way it works currently is that the kernels for both Android and Ubuntu are loaded to the eMMC, then the userdata / rootfs are loaded to the SSD. That said, I could try to play with that for sure.

It would really be nice if there was an easy way to install OS on SSD drive,that would be a massive upgrade from the measly 128GB EMMC.
By the way I don't know if you have already figured this out but there is an easy way to install GAPPS without using the tedious method you used.
You simply patch boot.img with Magisk then use ADB to install it back to the unit. From there you can use Magisk to install Magisk GAPPS.
For the life of me I can't seem to figure out how to install GPS/GNSS drivers for Android. The stock firmwares provided by the vendor have GPS drivers but those stock firmware have 1920x1080 resolution whereas I want to use 3840x2160 screen.
One way of dealing with that is editing build.prop file in vendor folder which works but then the unit won't boot past boot screen when a patched boot.img is installed. so it is sort of catch 22.

qwestmogul2012 said:
It would really be nice if there was an easy way to install OS on SSD drive,that would be a massive upgrade from the measly 128GB EMMC.
By the way I don't know if you have already figured this out but there is an easy way to install GAPPS without using the tedious method you used.
You simply patch boot.img with Magisk then use ADB to install it back to the unit. From there you can use Magisk to install Magisk GAPPS.
For the life of me I can't seem to figure out how to install GPS/GNSS drivers for Android. The stock firmwares provided by the vendor have GPS drivers but those stock firmware have 1920x1080 resolution whereas I want to use 3840x2160 screen.
One way of dealing with that is editing build.prop file in vendor folder which works but then the unit won't boot past boot screen when a patched boot.img is installed. so it is sort of catch 22.
Click to expand...
Click to collapse
Thanks. Yes. I am currently working on trying to build up a software system that will enable proper booting from SSD "due to popular demand" from here (basically trying to modify the provided "RK U-Boot" and/or combine it with GRUB), however my progress has been set back after having lost the FIQ serial debug converter for my board and needing to get a new one. Also, I didn't know about that trick with Magisk, thanks! And when you say "won't boot past boot screen", what do you mean? Do you have any logs from the USB or from the FIQ serial stream for when that happens?

After the patched boot file is loaded back into the unit using ADB,the unit simply shows Firefly logo,the screen goes black then it shows the same logo,it never goes past that logo.
In other words I want a unit that has a patched boot file so that I can root it with Magisk and also have 4K resolution which only attainable by editing the build.prop file.
The root that is already in the stock firmware is inadequate because they lack SU binaries and therefore most apps that require root permission don't work effectively.
I have no way of generating logs,I don't have a serial debugger.
My goal is to have a simple Android system that I can install in my car with 4K portable screens and GPS.
I have tried the Android radios being sold out there and don't meet my needs for a system that can use 4K screens.They are still stuck in 1920x1080 or below resolution,not to mention that they can't play 4K video files without stuttering or freezing. They also lack storage that can store those large files.

qwestmogul2012 said:
After the patched boot file is loaded back into the unit using ADB,the unit simply shows Firefly logo,the screen goes black then it shows the same logo,it never goes past that logo.
In other words I want a unit that has a patched boot file so that I can root it with Magisk and also have 4K resolution which only attainable by editing the build.prop file.
The root that is already in the stock firmware is inadequate because they lack SU binaries and therefore most apps that require root permission don't work effectively.
I have no way of generating logs,I don't have a serial debugger.
My goal is to have a simple Android system that I can install in my car with 4K portable screens and GPS.
I have tried the Android radios being sold out there and don't meet my needs for a system that can use 4K screens.They are still stuck in 1920x1080 or below resolution,not to mention that they can't play 4K video files without stuttering or freezing. They also lack storage that can store those large files.
Click to expand...
Click to collapse
Wow, that is some really interesting use of this device. Are you able to capture anything via the debug serial interface? (TTL serial, port is called "DEBUG" on the board, it appears to be the preferred serial interface for this processor.) If you don't have a suitable TTL->USB converter, you might want to get one. It must be able to support 1500000 baud, though, so be careful to check. Firefly offers one, though I lost mine as I mentioned and I had to get another, though a different one so I can mount it permanently in the case and break out a back-of-the-case port.
If you can capture anything via the TTL serial line, that would be great. That should give you some idea of what it's choking on. Send me that just so I can think about it while I'm waiting on this.

I will definitely order one.I never thought I would hit such a roadblock.I have edited various kind of Android roms successfully.This one from Firefly though is something else.I suppose that is what happens when they make their work not open source.
By the way do you know how to unpack super.img? the unpack script provide does not recognize super.img even if I change the name to update.img

qwestmogul2012 said:
I will definitely order one.I never thought I would hit such a roadblock.I have edited various kind of Android roms successfully.This one from Firefly though is something else.I suppose that is what happens when they make their work not open source.
By the way do you know how to unpack super.img? the unpack script provide does not recognize super.img even if I change the name to update.img
Click to expand...
Click to collapse
Sorry for not responding sooner but I was diligently cracking away at this thing VERY much actually ... !!!
Ah yes, I think though I'm pretty close to getting it to work; most of the work so far has been in trying just to figure out how everything works given documentation is scant and I had never, ever worked with Android or anything else at this level before!
Very little of the material is not opensource - some of the tools required to generate the rockchip images does not appear to be and there are some binary-blob kernel drivers, but a LOT more than one thinks is; you just have to ask Firefly for the "board SDK" and they will provide on request. Other than what I mentioned, the code in there is pretty much all licensed under GPL (hence why they have to give you that code, given they've made kernel modifications to support the RK3588 - apparently mainstream support is coming along but is still not primetime yet).
Nonetheless, I see you've unpacked the Android image ROM, so perhaps you already have that - if so, great. Hence let's get to it (note maybe you know some of this already but I also want to make this post useful for as many people as possible): super.img - which I'm actually playing with right now - is not Firefly magic, but is generic Android and has been mentioned before on this forum if you search for "super.img" here. It's a "super partition" that contains partitions.
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
To unpack it you need to grab OTA Tools:
[GUIDE] OTA Tools LPUnpack
Please see this URL https://android.googlesource.com/platform/build.git/+/eec4a7cba4face3370acb6293ab357879920b467 and this for more information. Hi everyone. I'm surprised I havent seen a thread about ota tools yet and lpunpack. This zip file...
forum.xda-developers.com
and the way to do this is you should first use the program simg2img, which actually ships with Ubuntu as a package of the same name I believe. Suppose you're in the Linux terminal and working in the directory containing super.img. Create (if you haven't already) a directory to unpack it, e.g.
Code:
mkdir super_unpack
Then use simg2img to get a "raw" version:
Code:
simg2img super.img super.img.raw
then finally use the OTATools (replace the string "/path/to/otatools" with whatever, or put them on your PATH, or ...)
Code:
/path/to/otatools/lpunpack super.img.raw super_unpack/
and now you should have it fully unrolled into smaller .img files which will ACTUALLY mount. In particular, I needed this because product.img specifically seems to be the best place to load GApps into - they will both come up on first Android boot and they will be retained if you do an Android system reset ("reset to factory defaults").
Now REPACKING super.img ... that's the fun part!

I had actually managed to find the instructions to unpack the super.img and also managed to mount vendor.img which is where I wanted to make changes in modifying the build.prop file.
After repacking the super.img and flashing it using fastboot the Android did not boot.
I also managed to incorporate the super.img to a ROM but the Android did not boot as well.
My thinking is that Android 12 being a Dynamic partitioned rom does not allow any modification in the root system and that is why I have not had success making the Android boot.
It used to be so easy to do that on Android 10 but Android 11 and 12 are not.
Well,if someone manages to do it,I hope to understand how they did it.
As of now I am pretty much stuck with a vanilla rom which is very disconcerting considering how expensive the ITX-3588J is.
By the way I already have SDK which I have been using to make roms.
Please let me know if you manage to boot the Android using a repacked super.img
As always I am very grateful for your assistance. Happy Ney Year!

qwestmogul2012 said:
I had actually managed to find the instructions to unpack the super.img and also managed to mount vendor.img which is where I wanted to make changes in modifying the build.prop file.
After repacking the super.img and flashing it using fastboot the Android did not boot.
I also managed to incorporate the super.img to a ROM but the Android did not boot as well.
My thinking is that Android 12 being a Dynamic partitioned rom does not allow any modification in the root system and that is why I have not had success making the Android boot.
It used to be so easy to do that on Android 10 but Android 11 and 12 are not.
Well,if someone manages to do it,I hope to understand how they did it.
As of now I am pretty much stuck with a vanilla rom which is very disconcerting considering how expensive the ITX-3588J is.
By the way I already have SDK which I have been using to make roms.
Please let me know if you manage to boot the Android using a repacked super.img
As always I am very grateful for your assistance. Happy Ney Year!
Click to expand...
Click to collapse
Thanks. I did not see any mention about build.prop, though maybe you dropped that on another thread that wasn't in my notifications anymore.
You say the "Android did not boot". Do you have a adb dump? Do you have a serial (UART) debug dump (i.e. through the FIQ port)? Also, how are you repacking super.img? It is a tricky process as I mentioned at the end.

I did mention build.prop editing on my second comment of this thread.I initially tried to use root explorer file manager,that did not work.Then attempted to pull file from the system using ADB,edited it on my computer then pushed the edited file back to the system.That did not work either.
That is when I resorted to trying to edit it by unpacking the super.img.
I am still waiting to receive USB SERIAL debugger.
As for how I unpacked and repacked the super.img I used the instructions on the thread on this link
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com

Maybe this helps: https://forum.xda-developers.com/t/linux-porting-native-linux-to-galaxy-note9.3936077/
Somebody ported Linux to the Galaxy Note 9.