Related
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
FIsH a la carte - A porting guide for the FIsH framework.
Proudly introducing Android FIsH: Fluffy Incredible steadfasterX Hijack
{
"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"
}
FIsH: Fluffy Incredible steadfasterX Hijack
First of all:
All this is for the brain of DEVELOPERS.
Well.. to be more specific: not really for developers but for COMPILERS
For using FIsH You do NOT need to DEVELOP anything - normally - the only thing you should be able to do is COMPILING -> e.g. TWRP.
If you have the knowledge to compile TWRP then FIsH is what you need to bring it on your locked device.
Just follow the menu card in the post #3 "Bring FIsH on the menu card" and your job is done.
If you are a user wanting to have FIsH for your device: FIND A COMPILER (a person who is able to compile TWRP/ROMs/.. for your device!!).
DO NOT ASK IF I CAN PORT FIsH TO YOUR DEVICE!
DO NOT ASK IF I CAN COMPILE [FILL IN WHATEVER YOU WANT] FOR YOU!
-> instead find a person willing to port FIsH plus the ramdisk of your choice (e.g. TWRP) and point him/her here.
When do you feel like a compiler or u want to be one: read on
if not: really still here? I said find a compiler!
Table of content
This whole thing here is damn long.. but that's one of the major difference for the FIsH: I try to explain what I do
For a better handling I splitted the guide into several parts:
This post: Explain me the FIsH (What it is)
Post #2: FIsH bowels (What's inside)
Post #3: Bring FIsH on the menu card (porting FIsH)
Post #4: FIsH cuisine (examples)
Post #5: FIsH hydra (multiboot in FIsH)
Post #6: Chew the FIsH (Copying/License)
Post #6: FIsH mutation history (Changelog)
Post #7: Go FIsHing (enduser installation guide example)
Overview
You can not unlock your bootloader? So now it's all over right?
TWRP and flashing custom ROMs on locked devices is impossible right?
Oh no wait there are hacks (up to KK) which have a workaround for this but I couldn't find anything for LL (sorry if I missed something) and what I found was not easy to port so nothing generic which i could just adapt easily.
Here is where the Android FIsH (refered to just FIsH in this whole doc) steps in
FIsH means: [F]luffy ncredible teadfasterX [H]ijack
FIsH is different from Safestrap or other hijacks because it should be better understood as a kind of framework for any ramdisk image you want to load.
FIsH will not harm the Android boot chain! Means it will not modify /boot, /recovery or aboot partitions. It will just modify /system.
FIsH:
... is NOT MultiROM (see post #5: FIsH hydra)
... is NOT efidroid (see post #5: FIsH hydra)
... is NOT Safestrap
... is NOT TWRP (booting with FIsH is tested and works)
... does NOT root your phone
... does NOT unlock your phone
... is a WORK IN PROGRESS!
... but FIsH could (in theory) "BOOT" any of the above!
U got it? FIsH is the hack to boot whatever you want.
This also means atm it is tested on some devices only and the only FIsHFOOD (ramdisk) FULLY tested and so stated to be working is TWRP.
Nevertheless I'm hard working currently on porting either MultiROM-in-FIsH or efidroid-in-FIsH to bring custom ROMs to locked devices as well (see post #5: FIsH hydra).
What the FIsH is (in short words)
Read about the full details of the implementation of FIsH in the next post (Post #2: FIsH bowels (What's inside)) but to give you a short overview:
FIsH is a boot hijack and wants to be a FRAMEWORK for booting any fishfood (ramdisk) you like.
FIsH is portable to other devices
FIsH gives you all possibilities to make the most of your device by letting you boot whatever you like
FIsH will not provide or contain any ROM or recovery by it's own - THATS YOUR HOLY OWN JOB NOW!
FIsH is the tool -> but building a ROM or recovery is (still) up to you.
These questions may come up in your mind now
Will FIsH void your warranty? Not more or less then rooting your device.
Will FIsH unlock your bootloader? omg NO! read it again!
Is there a risk with FIsH? For example could it soft-brick my device? Well.. absolutely! Safe is the death only. There are always risks especially for untested devices. I do all I can to keep this risk as low as possible and I provided a way to get out of bootloops but again you will get no guarantees here and elsewhere.
Will it work on Android version ICS, KK, LL, MM, N, O, ....? Check the pre-requirements. If you can answer them with yes it should work. If not then not. That easy.
Will I need a recovery partition to use FIsH? No. FIsH ran in RAM only. Even if your device does not have a recovery partition it will work.
Will FIsH work for my device? FIsH is more than just a hack for a special device or model it is a hack for ALL devices of ANY vendor! wtf? yes. Your FISHFOOD is device specific so the question would be better: Will the FISHFOOD (e.g. TWRP) work on my device? The answer is it depends. You need to compile it for your specific device and it should but who knows.
To narrow it a little more down:
you have to met the pre-requirements and there has to be done some things to get a value out of it but those are straight forward for a good compiler/developer like you!
FIsH pre-requirements
Here are the pre-requirements you have to met!
If you can't get them: Close this page and FORGET it (until the day you met those reqs)!
Here are the 2 simple requirements you have to met:
a) root by SuperSU >=v2.76 (greater or equal v2.76)
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
--> for many devices - if not all - this means you HAVE TO downgrade/install LL. It also means that you have to upgrade your SuperSU to this version by e.g. FlashFire if you have a lower version installed!
--> SU by phh is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> Magisk is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> I will NOT provide downgrading guides there are plenty of them so search and read.
--> I will NOT provide any guides in rooting your device
--> Before you think about downgrading to LL read about ANTI-ROLLBACK protection some devices and may have! Anti-Rollback means you CAN NOT downgrade - it would HARD-BRICK your device (wtf thinking the vendors who we are?? Is this even legal?!)! Check that before!!
b) you have to be able to disable SELinux in your booted Android
--> You do NOT need to set SELinux permanently to permissive. Just CHECK if you COULD get it MANUALLY. If you can get it OK. If not.. you obviously have not full root access but check the forums maybe there is something you can do about this.
--> I will NOT provide any guides enabling SELinux but some lines later you will see how u can execute the very simple check
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
Those above are hard facts so it may NEVER work with MM. Google has changed the way on how the boot chain will be verified and that means changes in /system will void it from now on.
If MM can get fully rooted somehow/somewhen on your device with SuperSU installed and you are able to disable SELinux the method will work there as well.
If you can not meet ALL of the above 2 requirements lay down and cry.
For the others: calm down and read on!
You can simply test those both requirements by downloading FIsH and execute the installer with the testing parameter:
./install.sh --check
Example output:
############# Checking for busybox
...downloading busybox
--2017-03-24 13:37:44-- https://busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/busybox-armv6l
fishing/busybox 100%[========================>] 1,06M 542KB/s in 2,0s
2017-03-24 13:37:47 (542 KB/s) - »fishing/busybox« saved [1107664/1107664]
Waiting for your device... (you may have to switch to PTP mode on some devices!!)
Android Debug Bridge version 1.0.36
Revision 7.1.1_r13
############# checking Android version
-> Good. Matching exact the required Android SDK: 22
############# checking SuperSU version
-> Matching required SuperSU version: 279
############# temporary disable SELinux
-> command ended successfully (err=0)
SELinux mode: Permissive
... restoring SELinux mode to Enforcing
Tests finished! Check the above output!! Exiting here because in checking mode. Nothing installed.
Click to expand...
Click to collapse
The important lines are:
Matching required SuperSU version: XXX
"SELinux mode: Permissive"
If you see "SELinux mode: Enforcing" or any error messages you may doing something wrong or it just do not work for you.
Limitations!
Keep in mind what I said above: FIsH does NOT unlock your bootloader!
That means with FIsH itself you can NOT "install" anything. FIsH actually is the FRAMEWORK(!) for the FIsHFOOD (ramdisk) you want to load.
One good example is TWRP. This can be loaded even on devices do not having a recovery partition (I believe Sony is one of those).
Let's stay by the example of TWRP.
Keep in mind that when you use FIsH to provide TWRP you can NOT
Install a custom ROM like CM/Lineage (this will modify boot = SOFT-BRICK. for this u would need efidroid or multirom as FIsHFOOD)
Install a custom Kernel (this will modify boot = SOFT-BRICK)
Install a custom recovery (this will modify recovery =may SOFT-BRICK)
In short: do nothing which modifies boot or recovery partitions. Those changes will break your boot signing chain.
You can of course flash everything which is modifying /system /data only (e.g. xposed, Audio mods, etc...)
You're able to backup and restore as well of course and doing any other modifications which you may can't while the Android system is running.
Download
You will get the most current downloads at github but I uploaded all stable releases here at XDA as well to mirror them.
Latest stable (well tested and so hopefully fewest bugs): Download latest release at github (click)
Mirror / older stable versions: DOWNLOAD-TAB (click)
Next stable (lesser chances of issues but may still not released yet): github master branch
LIVE/FRESHEST code u can get (high chances of failures, bugs, unexpected behavior - but the latest and greatest features/bugfixes): github develop branch
FIsH helpers
If you want to reboot directly to an implemented version of FIsH from within Android check out this:
Thanks to @sdembiske who has onboarded the developer @AntaresOne we have an option to reboot into FIsH very comfortable now!
Check it out here: QuickReboot App
Support / IRC Channel
(DEVS/COMPILERS ONLY - NO ENDUSER SUPPORT!)
IRC means Internet Relay Chat and you will get best support here only.
This channel mentioned here is NOT an ENDUSER channel!!
It is for developers and compilers only!)
Endusers should use: #Carbon-user instead !
Choose how to get in:
PC (HexChat and Pidgin are only 2 of them! This list is not complete!)
Android (Yaaic, AndChat, HoloIRC, AndroIRC are only a few of them! This list is not complete!)
Web (KiwiIRC-Web,FreenodeWebchat])
When you have to choose a channel it is: #Carbon-Fusion (this is NOT an ENDUSER channel!! It is for developers and compilers only!)
Endusers should use: #Carbon-user instead !
When you be asked for a server network choose: freenode
Credits (without them - no FIsH!!!)
If you feel that someone / you is missing on this list lemme know!
Chainfire for SuperSU! This is the main part of FIsH.
TeamWin for TWRP
@cray_Doze, @dssmex, @Aaahh and @KeiranFTW for their hijack implementations (e.g. https://forum.xda-developers.com/showthread.php?t=2608408, first steps to a G4 hijack)
@dibbled for creating the android FIsH logo
steadfasterX for the android FIsH !
Famous last words
You may say: When this will work for up to LL only.. Why the hell are u releasing this now? We just see the upcoming Android O and you talk about LL? Well.. This whole thing is just a fun project. I want to learn and I want to give back something which helps others.
So at the end.. If u don't like.. its ok. If you don't need it.. ok. If you can't get any value out of it.. ok..
But maybe it helps others out there instead.
So if you're still not scared and want to continue.. what u r waiting for??
XDA:DevDB Information
android FIsH, Tool/Utility for all devices (see above for details)
Contributors
steadfasterX, BigCountry907, Rees86
Source Code: https://github.com/Carbon-Fusion/android_FIsH
Version Information
Status: Stable
Current Stable Version: v3.0
Stable Release Date: 2017-06-14
Created 2017-03-24
Last Updated 2017-09-11
FIsH bowels (What's inside)
This is for ppl understanding the basics. I will not explain it for dummies
Ok prepare urself for the naked magic
Actually FIsH is mostly similar to other RAM hijacks around with 3 major differences:
1. FIsH is based and depends on SuperSU.
YES - I make my life EASY. You actually need a rooted devices for the most kind of hijacks.
... and I assume the most ppl using SuperSU as their su binary.
... and SuperSU does not require to modify boot (at least until LL)
With this in mind and reading the SuperSU docs I had read that beginning from version 2.76 SuperSU
comes with a special kind of internal init.d support means: It executes custom scripts very early with full SELinux perms available.
Check out the docs here: https://su.chainfire.eu/#updates-sud
2. FIsH tries to be a generic framework with instructions to bring it on all devices.
The hack here is not device specific due to its nature of just executing a custom script by SuperSU.
I've made all scripts inside as easy portable as possible and given hopefully good descriptions and
porting instructions for EACH variable you may need to adjust.
3. it works for up to LL (when u can met the pre-reqs for MM or N, O or whatever comes then - it will work there as well!)
I found only methods for up to KK (e.g. 2nd init and others) but nothing for LL (sorry if I missed someone!) so I started FIsH.
So in sum FIsH is:
a set of scripts and tools which gets executed by SuperSU on early boot stage which hijacks the boot process to bring up your own ramdisk.
FIsH vs Flashfire
Flashfire is absolutely an AMAZING tool! You can backup, installing ZIPs etc all without an unlocked bootloader.
Due to it's nature it is not possible to do EVERYTHING with it (on a locked device), e.g. restoring your whole system partition.
TWRP-in-FIsH (FIsH plus TWRP as FIsHFOOD ramdisk) can provide this - even with a locked bootloader.
Besides this FIsH can do more like (hopefully) bringing you custom ROMs on locked bootloader devices.
FIsH vs Safestrap
Safestrap is supported up to KK and besides this it actually is some kind of MultiROM pendant (+ the hijack part).
FIsH supports any Android version up to LL (GB, ICS, KK, LL,..) as long as the 2 bloody requirements can be met.
Safestrap is a very customized version of TWRP and so limited to updates from there.
FIsH lets you boot any ordinary TWRP completely unmodified. This makes it easier to get new TWRP features on your device.
Besides this FIsH wants to be easy to port for everyone thats why it uses standard components only.
AFAIK it is not supported anymore anyways.
FIsH vs other RAM hijacks
The main reasons why FIsH exists are described already (LL support, easy portable and easy to use) so if you still feel that this is not different from the others... i dunno what to say
FIsHing (Hijacking) means:
FIsH kills all running services, scripts, binaries it can find.
Afterwards it will unmount everything and delete all files left behind from the initial ramdisk.
Now in that more or less clean state it will replace the initrd with the FIsHFOOD - means your own ramdisk like e.g. TWRP.
Some other stuff may happen also but at the end a binary will be started - normally a /init from your own ramdisk
So in sum it is a live replacemnt of the current ramdisk with your own.
Requirement <SuperSU>
It prepares the system to run the FIsH init script and also ensures that SELinux can be run in permissive mode.
Keep in mind that FIsH will enforce permissive mode on boot to do it's job so you do not have to do anything (normally) to let the FIsH boot.
Main components of FIsH:
./install.sh (file)
The installer is the first part you may need to adjust when you want to port FIsH.
This installer is for Linux users only. If you want to have Windows users executing FIsH point them to https://tinyurl.com/FWULatXDA !!
.. but you're free to port the installer to Windows (if u like: bring it back to me so I may include it..)
Your FIsHFOOD (your own ramdisk) has to be compatible to your running STOCK ROM. If you have LL 5.x running your ramdisk has to run / build for it.
important variables:
MINSDK: Adjust this SDK level to match your runnin STOCK ROM which has to be compatible with your FIsHFOOD
MINSU: The minimum SuperSU version required. Do not use anything lower than 279 (means 2.79) because this may not work!
BUSYBOXURI: This is a full URL to a busybox binary compatible with your device. You may have to adjust this but ensure u use a compatible version
because we highly depend on its syntax. The reason why FIsH does not come with busybox bundled is besides license stuff (I do not wanted to provide their
sources ) it may be required that you need another binary then me.
fishing/ (directory)
The real FIsH. Means all files which gets copied to the target device.
fishing/busybox (file - will be auto downloaded by the installer)
You should know what it is..
FIsH comes without busybox but the installer will download it automatically and place it here.
FIsH uses busybox to have all commands with the expected syntax in place and we highly depend on this in the hijack process!
fishing/fishfood.gz (file)
The FIsHFOOD is your own ramdisk - in gziped cpio (e.g. TWRP)
This ramdisk has to be compatible to your device's ROM. Means when you have a STOCK ROM 5.1 installed your ramdisk have to be compatible to LL 5.1.
You can ensure this within the installer (see FIsH Installer) where the Android version will be read and compared before FIsH installs actually.
fishing/fishfood.release (file)
The version and content of your FIsHFOOD
I recommend the following naming convention:
[yourFIsHFOOD]-in-FIsH-v[VERSIONNUMBER]_[DEVICE-MODEL]_[Android-Version]
e.g.
TWRP-in-FIsH-v1_LG-G4_LL
You can write in here whatever you like. The content will be send to the fish.log to identify which version the user has installed (helps debugging).
fishing/callmeFIsH (file)
a caller script which gets executed at very first.
The only task callmeFIsH has is to prepare the whole FIsH to get started out of /system and then starting FIsH from /res. After this it immediately exists to not keep open tasks on /system. callmeFIsH will be placed in /system/su.d/ to get autostarted by SuperSU.
fishing/FIsH (file)
The heart of the FIsH.. Get's called by callmeFIsH.
It will be executed by SuperSU on boot and will hijack the process and prepare and setup everything to let your FIsHFOOD coming up.
fishing/FIsH.me (file)
Functions and vars a user/dev normally wouldn't need to change. They are internal stuff only.
fishing/FIsH.porting (file)
As you're trying to port FIsH this file is your main part when it comes to customization for your device.
Here you should find everything required to be adapted and there are very high chances that you HAVE to adjust this to your device.
fishing/gofishing.sh (file)
The remote installer part. It will actually run as root and prepare your system for FIsH.
You normally will never need to touch this.
FIsH target directories
/system/fish/
All the bowels of FIsH like, FIsH, Busybox, fishfood.gz and fishfood.release go here
/system/su.d/
The FIsH caller (callmeFIsH) goes here
/cache/fish/
The most important directory for you: Here you will find all logfiles required for debugging!
.
Bring FIsH on the menu card (porting FIsH)
So you may now have a little bit understanding of what FIsH can do for you and what not.
When you feel FIsH could work for your device then why not just trying to port it?
This guide should help you for this task.
FIsH was made from scratch with portability in mind.
That means I tried to make it as simple as possible for you to port.
I really hope that task has been accomplished..
1. Met the pre-requirements
You have to understood that FIsH will work ONLY when the pre-requirements are met.
There is no way around or "if i met 1 of the 2 - will it work?" NO. You need BOTH!
If you will be asked by a user to port FIsH -> Ensure that the requirements can be met first before investing your time.
There is an easy test u can go for this: just execute the installer like this:
./install.sh --check
The installer will test and check if it get what it needs and then EXIT without(!) any installation.
2. Build your FIsHFOOD (your custom ramdisk)
I recommend to start with TWRP but choose whatever you like. For this guide i stay with TWRP.
Keep in mind that your FIsHFOOD has to be build with the same sources as your running STOCK ROM.
If you want to support multiple STOCK ROM versions you may have to build multiple FIsHFOOD versions.
Testing your FIsHFOOD is not that easy on locked devices so your only option is to go on once you feel your build is ready.
3. Cook the FIsHFOOD
When you build images or ramdisks you may end up with an image file needed some preparation first:
create a gziped cpio of your initial ramdisk u wanna load
example of twrp build by you:
after your build has finished you will find several img files in your out/ directory and you just need to copy the following file:
out/target/product/<YOURCODENAME>/ramdisk-recovery.img
and move it to:
fishing/fishfood.gz
example of an existing twrp image:
abootimg -x twrp.img (will extract the twrp image)
file initrd.img (should tell something like: gzip compressed data. if NOT: gzip it!)
mv initrd.img fishing/fishfood.gz (moves the extracted initial ramdisk)
Some Notes:
- this cpio has to be compressed with gzip (.gz file ending is importat!)
- the name of this file should be fishfood.gz (exactly this)!
- edit or add a file fishing/fishfood.release and type in what ur fishfood is (e.g. TWRP)
and the version of it course (a good example is: TWRP-in-FIsH-v1_LG-G4_LL)
Click to expand...
Click to collapse
4. Prepare the FIsH installer
Download FIsH and extract it.
open the file install.sh
Check the variables u may need to adjust: Check Post #2 above for some explanations and read the comments within
Note about the Android goFIsHing installer (fishing/gofishing.sh)
You normally do not need to touch this file. It may be required if you cannot install FIsH but that should hopefully not happen..
5. Cook the FIsH
open fishing/FIsH.porting
You will find 2 sections: GLOBAL and PORTING
Each section has hopefully meaningful comments to give you an idea what they do and how you should modify them.
Most vars also have example instructions to find the correct values for your device.
When you're trying to port FIsH you may have to try & error FIsH several times before and you may do not want to use your defined key combo to do so.
For this and also as a convenient option when you want to boot directly into FIsH from Android you can set a special flag to always boot FIsH.
Use it with care because it may let it bootloop while in your testing phase.
The file which activates FIsH without a key press is: /cache/recovery/boot
It can make sense to use this for an easier testing process (don't need any key presses to activate FIsH).
In sum the following command comes very handy while developing:
./install.sh && adb shell "su -c touch /cache/recovery/boot" && adb reboot
So the other way is using a key combo without the need to boot into Android.
For this you will find everything you need in the file fishing/FIsH.porting which you usually have to adjust to your specific device.
Providing user feedback for activating the FIsH:
FIsH gets NOT activated by default. That means if you would reboot your device it will just reboot.
To activate FIsH you need either to use a key combination (provided by you) or using the FIsH file flag.
The idea of the FIsH booting process is (see fishing/FIsH.porting)
a) WAIT_LED: show a LED color indicating FIsH has been STARTED (not ACTIVATED)
---> the user has to press the magic key combo NOW
b) VIBRATE: will vibrate to indicate that the time for pressing the magic key combo is over
c) FISH_LED: show a LED color indicating that FIsH has been ACTIVATED .... or NOT!
d) boot into either Android or your FIsHFOOD depending on what the user wants
If your device does not support different LEDs you can instead use the path to vibrate in the LEDs.
e.g. WAIT_LED="$VIBRATE". This will let the device vibrate instead of showing a LED color.
Whatever you end up with you have to check and adapt the enduser installation guide ofc as well..
6. Let the FIsH swim
Now it's time to test your FIsH port. But BEFORE:
You will take a high risk here at this early stage because it CAN bootloop/soft-brick your device if something goes totally wrong!
I hope I had done all to keep the risk for this low but no guarantees!!
So make a FULL backup of ALL your apps and do not forget to backup your internal storage with all your pictures etc.!!! (just a reminder: TWRP does NOT backup your internal storage!! Read the explanation here)
If the worse case happens you may need to totally bring your device back to pure STOCK so you have been warned!
7. Finally give the FIsH a name
If your FIsH swims... omg.. CONGRATS well done !!! The most hardest stuff is done now! Woot u r a REALLY good dev did u know that?! Your community will praise u!
Of course u r free to choose a name but I recommend to name your FIsH package like this:
[yourFIsHFOOD]-in-FIsH-v[VERSIONNUMBER]_[DEVICE-MODEL]_[Android-Version]
e.g.
TWRP-in-FIsH-v1_LG-G4_LL.tgz
Note: Did u see the different use of dashes and underscores? Keeping it that way is important.
This way we all get a clear understanding what it is, which TWRP-in-FIsH version, for which device and for which STOCK ROM version.
8. Release your FIsH to the wild ocean
Ok I will not tell you how you should release but it would be nice if you tell the users where this all comes from
Do not forget to report back to this thread if you have implemented a port so I can add it here for reference.
An example installation guide for your endusers can be found at Post #7: Go FIsHing
If you struggle somewhere you can find me in the IRC (see OP)
When you have to choose a channel it is: #Carbon-Fusion
When you will be asked for a server network choose: freenode
Trouble / Bootloop fix
if you encounter a bootloop (should never happen but who knows) you have 3 choices at least:
Option 1a: (TWRP-Bootloop) Within TWRP open Advanced -> File Manager -> Goto: /system/su.d and click "select" button -> Delete
Option 1b: (TWRP-Bootloop) From your PC: adb shell rm -rf /system/su.d/
Important: Catch the fish log (see next topic)
Option 2 (this works also for a bootloop without twrp): boot into download mode and use LGLaf to get a shell
then:
setenforce 0 <-- if that doesn't work you may have to do a FULL restore to stock
mount -oremount,rw /system
rm -rf /system/su.d/
reboot. You are out of the bootloop.
Important: Catch the fish log (see next topic)
Option 3: Last resort: Reflash STOCK. sorry.. there is always a risk..
Catch the FIsH logs
when in TWRP (or other ramdisk providing adb shell):
adb shell "cat /cache/fish/fish.log"
adb shell "cat /tmp/recovery.log"
OR - when in Android:
adb shell "su -c cat /cache/fish/fish.log"
adb shell "su -c cat /cache/fish/fish.log.old"
adb shell "su -c tar cvzf recoverylogs.tgz /cache/recovery"
adb pull recoverylogs.tgz
Upload the output to https://paste.omnirom.org and paste the link in the IRC channel
FIsH cuisine (examples)
Example implementations
LG G4 (any model):
TWRP-in-FIsH (https://forum.xda-developers.com/g4/development/locked-twrpinfish-locked-g4-devices-t3573048)
HTC Desire 626s:
FIsH-in-SDCARD - big thx to @BigCountry907 (https://forum.xda-developers.com/showpost.php?p=71630297&postcount=35)
HTC DESIRE 526 VERIZON:
FIsH-in-SDCARD - big thx again to @BigCountry907 (https://forum.xda-developers.com/desire-526/general/super-sd-htc-526-vzw-t3596497)
LG Flex 2 (h955):
TWRP-in-FIsH - big thx @ergo911 (https://forum.xda-developers.com/g-flex2/development/fish-flex-2-t3583093/post71690950)
If you have ported another device or know about one just post to this thread so I can list it here
.
FIsH hydra (multiboot in FIsH)
Bringing multiboot to your device is still not finished yet.
I just wanted to release FIsH now because I was able to proof the working concept based on TWRP and as FIsH is nothing device specific anything else should do so as well.
I have little hope that maybe other developers step in and trying to help me with this but well if not it doesn't matter.. just taking longer
The whole thing of multiboot is a WIP (work in progress) currently.
But now you can prepare yourself for a possible way on this by starting a port of TWRP-in-FIsH first to see if the FIsH concept works for your device. This is strongly recommended to start with whereever we will end up here. Then come back here and hopefully until then I have some news about that topic..
So in theory multibooting by FIsH should be possible. FIsH is just executing your ramdisk so..
The only thing we would need is a way to start any of the tools already available right?
Correct. But.. any of them have its own requirements and way of work. So I need to investigate the bowels of them first to adapt them to FIsH.
Let's think about my first choice: multiboot by efidroid.
While it is quite new for me and it's implementation of booting multiple ROMs is very nice and different from MultiROM. Kudos to MultiROM which provide multi boot of custom ROMs for years but I really like the approach of efidroid (even when I just starting to use it).
When you would be able to boot into efidroid with FIsH you could use as many (unpatched) ROMs as you like. Just 1 or 20 - depending on your disk space mainly. So what does that mean? With FIsH you can hijack the boot and jump in efidroid and now u r able to boot whatever custom ROM you like. That's the theory.
The practice is: efidroid is a bootloader and so completely different to TWRP for example. Using the same hack here will not work without modifications of efidroid and maybe FIsH. The key here is to use the efidroid binary plus the cmdline needed to get a custom ROM booted.
Don't get me wrong what NEVER will work is booting into efidroid like fastboot boot uefi_boot.img can provide. The first thing what I'm trying to achieve is to use the efidroid binary plus the needed cmdline to boot up a manually added custom ROM (thx to the efidroid dev @m1cha by the way.. I promise to bug u as often as possible ). When this works we have won. Well it will be far away from user friendly leaving it this way but it should be possible to write a GUI (e.g. based on AROMA) and then doing the actions efidroid offers in its boot menu. So.. at the end some kind of MultROM but without kexec patches would be possible then.
The other way around: multiboot by MultiROM.
A long player in the game of multiboot and often ported to many devices. The problem here is that it is more than just a ramdisk. It is splitted into a modified TWRP plus MultiROM itself which needs to be flashed from within TWRP. This flashing will inject modifications in your /boot image so it will not work this way on locked devices out of the box.
Before I want to dive into the deeps of a possibly MultiROM implentation for FIsH I want to end my testing for efidroid. So atm I cannot say if there will be a way or not because for this I need to find out what MultiROM really do in the boot image and adapt this change to FIsH. I strongly believe that this can be adapted but my time is limited and my priority lays on efidroid for the moment.
Tbh bringing up the modified TWRP version should be easy because it will work the same way as bringing the ordinary TWRP to FIsH but the other part in the boot image is what I'm not sure about what it does (haven't had the time to look into this yet).
If u feel like a developer and you are able to unbrick a soft-bricked device then feel free to investigate and try on your own and let me know
Update (2017-06-27):
I had the time to look into the possibilities of a multirom port to FIsH.
The bad news: its not easy as thought. Its near impossible yet not complete impossible.
I was a little bit confused by a new compile flag in multirom named MR_NO_KEXEC which allows you to use kernels not patched for kexec-hardboot.
Well but its not that easy..
- using kexec-hardboot needs a patched kernel
- and not using it (MR_NO_KEXEC flag set) will replace the whole boot partition(!) when a secondary ROM boots
So both options will break and can't be used.
The only way to go would be to modify the multirom sources (likely the trampoline part) to behave like efidroid does (heavy usage of loop devices instead of the current phys ones).
You can think of that this modification goes VERY deep, means a LOT of work and requires heavy C / C++ skills.
That's why I can't proceed here. I don't think that it is worth it tbh so I will investigate the other options and abandon the MultiROM approach.
The FIsH plate (sdcard booting)
Thanks to @BigCountry907 we could boot FIsH on every qualcomm device in a manner which has the potential to root any device, boot any ROM and more.
You remember? FIsH can be installed on a rooted device ONLY!
That's still true but with this you can boot e.g. TWRP-in-FIsH even on a not rooted MM / N /... by using the FIsH plate..
The whole process makes use of a qualcomm feature which let you do this.
- the whole process is incredible complicated to get it working!!!
- the whole process is very sensitive and you have to find the right combination of needed partitons to make it work
- the whole process is a complete try & error
- if I mean IF I get this working I could patch the bootloader partition on that sdcard partition without touching the REAL bootloader to test without bricking...
- I work together with @BigCountry907 to get it working but we live in complete diff timezones which makes it not easier
-
If you want to help you can find me in the IRC (see OP)
.
Chew the FIsH (Copying/License)
# This is Android FIsH: Fluffy Incredible steadfasterX Hijack
#
# Copyright (C) 2017 steadfasterX <[email protected]>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see http://www.gnu.org/licenses/
Click to expand...
Click to collapse
FIsH mutation history (Changelog)
android FIsH v3.0
Released: 2017-06-14
Full Changelog: https://github.com/Carbon-Fusion/an...oidFIsH_v2.0...Carbon-Fusion:androidFIsH_v3.0
Download: see the OP
Summary Changelog:
adding the possibility to exclude easily process names/pid's from being killed (coming with a default exclusion list already)
check it out: `fishing/FIsH.porting` --> `EXCLUDEPROCS / EXCLUDEPIDS`
several fixes regarding the ramdisk extraction
heavy speed improvements regarding kill & mount
adding a version string to FIsH to be able to identify which framework is running
added a better `ps` command than the one provided by `busybox ps`
android FIsH v2.0
Released: 2017-04-11
Full Changelog: https://github.com/Carbon-Fusion/an...oidFIsH_v1.0...Carbon-Fusion:androidFIsH_v2.0
Download: see the OP
Summary Changelog:
Improved general speed by factor 4
Many bug fixes
Many improvements for the installer like a new clean function (uninstall FIsH)
android FIsH v1.0
Released: 2017-03-24
Full Changelog: https://github.com/Carbon-Fusion/android_FIsH/commits/androidFIsH_v1.0
Download: see the OP
Summary Changelog:
first general public release
Go FIsHing (enduser installation guide example)
COPY & PASTE template for your own XDA thread (completely pre-formatted)
installguide_XDA_format.txt
.
Special FIsH Dinner (Notes)
TWRP
The first step to get a success with FIsH is to use TWRP as your FIsHFOOD.
Once started the first thing coming in your mind may be backup & restore but use it with care!
FIsH will brutally unmount /system in - afaik - all cases because there will be open files on it which can't be avoided.
In order to use TWRP successfully you should set at least this special flag:
# Always use rm -rf to wipe
TW_ALWAYS_RMRF := true
This is a workaround because it means wiping /system or /data will behave differently then you might expect normally. Without this flag TWRP will format the partition. With this flag set TWRP will use rm and delete all files on it without formatting the partition.
Very interesting. I actually have a locked (bootloader) device which I'm looking for a way to unlock. I feel likr I could get something (*cough*TWRP*cough*) working because of this. Keep it up :good:
veez21 said:
Very interesting. I actually have a locked (bootloader) device which I'm looking for a way to unlock. I feel likr I could get something (*cough*TWRP*cough*) working because of this. Keep it up :good:
Click to expand...
Click to collapse
Just remember the limitations and leave thanks to @steadfasterX
I am very happy to have stumbled on this today.
I cant wait to get a little deeper into it but i must say very nice job.
I have been working on a big project myself. For creating a clone of any device emmc.
Burn the GPT Partition Table to a External_SD Card and flash the images.
What I have found is that If you make the SD Card right the Qualcomm Devices will boot from the sd card.
To the extent that If i unlock a device that normally can not be unlocked using my XTC-2 clip then copy the images ect from the unlocked device burn to sd card and then boot into H-boot or Download mode the Unlocked Status for example Bootloader Unlock and S-off and Super Cid ect ect ect will be present on the locked device. Thus giving elevated permissions. My setback has been there is no normal way for me to write any partitions yet. Anything I flash through H-boot writes to the SD Card. And I have been unable to make TWRP boot this way.
My initial though is to set up my unlocked device with fish and get it all working. Then create the sdcard image that includes the installed fish scripts. It would be simple to modify the external sd to meet all the fish requirements. even if the device itself can not meet the requirements. My device currently meets the requirements but it isnt for me. Its for the community of people that dont have java cards. This could potentially lead to a way of overcoming both of our current limitations.
All i need is a way to boot TWRP from my elevated privileged sd card and I can utilize that to provide unlocking.
Awesome
BigCountry907 said:
I am very happy to have stumbled on this today.
I cant wait to get a little deeper into it but i must say very nice job.
I have been working on a big project myself. For creating a clone of any device emmc.
Burn the GPT Partition Table to a External_SD Card and flash the images.
What I have found is that If you make the SD Card right the Qualcomm Devices will boot from the sd card.
To the extent that If i unlock a device that normally can not be unlocked using my XTC-2 clip then copy the images ect from the unlocked device burn to sd card and then boot into H-boot or Download mode the Unlocked Status for example Bootloader Unlock and S-off and Super Cid ect ect ect will be present on the locked device. Thus giving elevated permissions. My setback has been there is no normal way for me to write any partitions yet. Anything I flash through H-boot writes to the SD Card. And I have been unable to make TWRP boot this way.
My initial though is to set up my unlocked device with fish and get it all working. Then create the sdcard image that includes the installed fish scripts. It would be simple to modify the external sd to meet all the fish requirements. even if the device itself can not meet the requirements. My device currently meets the requirements but it isnt for me. Its for the community of people that dont have java cards. This could potentially lead to a way of overcoming both of our current limitations.
All i need is a way to boot TWRP from my elevated privileged sd card and I can utilize that to provide unlocking.
Awesome
Click to expand...
Click to collapse
cool. your project sounds amazing as well keep us updated please .. !
btw I personally do not need FIsH .. lol.. i have all my devices unlocked but there were many users for my current device which cannot unlock (LG G4 -> only a few models can be unlocked) so I started FIsH..
so don't give up and if u need help.. go to IRC channel #Carbon-Fusion on freenode.. see us there
.
You may have just saved the Verizon sgs4 from total death. We have to see if selinux can be changed first.
ninjasinabag said:
You may have just saved the Verizon sgs4 from total death. We have to see if selinux can be changed first.
Click to expand...
Click to collapse
just use the installer..
./install.sh --check
will tell you..
.
steadfasterX said:
just use the installer..
./install.sh --check
will tell you..
.
Click to expand...
Click to collapse
Knox disables selinux permission changes by default. So I know the install.sh will return with a negative.
I posted the link to this thread on the VZW S4 forums in the hopes someone will pick up.
ninjasinabag said:
Knox disables selinux permission changes by default. So I know the install.sh will return with a negative.
I posted the link to this thread on the VZW S4 forums in the hopes someone will pick up.
Click to expand...
Click to collapse
So no root available there?
.
Sent from my LG-H815 using XDA Labs
@steadfasterX
In my mind it is threads like this and projects like this that make this place so great.
Same reason for my project. To unlock HTC devices. Verizon devices cannot be unlocked easily.
If you ever need any help with the bash script let me know.
I'm pretty good with it. Bells and whistles like menus and whatnot too.
I was glad to see your shell scripts.
I know the language and it makes this easy.
steadfasterX said:
So no root available there?
.
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
Root, but barely. We've gotta use kingroot to open the door before replacing kinguser with SuperSU.
This is where the sd card trick works well.
See if we can boot TWRP off of it then we automatically have root access in adb.
Then its a matter of flashing the right partitions ( Device Specific ) to unlock permanently.
DevUt said:
Just remember the limitations and leave thanks to @steadfasterX
Click to expand...
Click to collapse
No , I reached my thanks limit. I do know the proper ways of man :good:
Zip Builder is a stand-alone Windows exe (ZipBuild.exe) that can be used to build and sign Android zip-based installers from Windows folders. All required components to build and sign a zip installer are included - no additional files or software are required. The only requirement is that you have a current version of Java installed on your system. Zip Builder can be used on both shell-script and edify-script based installers and performs the proper build and signing methods, accordingly.
Although it's highly recommended to install the software using the Windows Installer (see below), the stand-alone exe is all that's required to use the program. The program command line options are as follows:
ZipBuild.exe <option1> <option2...> <*Folder Name>
Valid options are as follows:
'm' or '-manual': Manually select folder to be processed
's' or '-signed': Append '-signed' to the output file name
'5' or '-md5': Generate corresponding MD5 checksum file
'c' or '-confirm': Confirm options before building
'g' or '-gitinclude': include .git folders and related files
* Ignored when using manual selection mode
OPTIONS EXPLAINED
'm' or '-manual': In Manual mode you will be presented with a dialog box where you can manually select the folder containing the files to be processed. *When using Manual mode, the folder name will be ignored if it was provided in the command line
's' or '-signed': This option will append '-signed' to the output file name. For example: Folder name 'UPDATE-adb.Installer.v1.0.36' would produce a signed zip file named 'UPDATE-adb.Installer.v1.0.36-signed.zip'.
'5' or '-md5': This option will create a separate, corresponding MD5 checksum file that can be used to verify file integrity in TWRP or with other Windows checksum utilities.
'c' or '-confirm': When this option is used, you will be presented with a dialog box where you can confirm (or change) the 2 options above. If either (or both) options above have been specified on the command line, the checkboxes will be pre-selected accordingly. Once you're satisfied with your selections, click the 'Build Zip File' button to begin the zip building and signing process.
'g' or '-gitinclude': This option will include any .git folders and related files (.git, .gitignore, and .gitattributes) that are excluded from the zip file by default. [Should rarely be needed, if ever]
ZIP BUILDER SETTINGS MANAGER
Zip Builder Settings Manager (ZipBuildSettings.exe) is an optional companion app that can be used to manage the settings and options (shown below) for Zip Builder:
You can choose to create Windows Context (Right-Click) menus that will allow you to build a signed zip installer simply by right-clicking on a folder name. Folder names that end in '20YYMMDD' or '20YYxxxx' as well as folder names that begin with 'UPDATE' are supported in Windows 7 and above. You can also enable the option to build from any folder by holding the SHIFT key while selecting the folder.
You can choose when to display the confirmation dialog
You can choose when to append '-signed' to output file names
You can choose when to create md5 checksum files
You can choose to include all .git folders and related files (see above)
DATE CODE FEATURE
If you're building from a Windows folder name that ends in '20YYMMDD' or '20YYxxxx', Zip Builder will give you the option to change or update the date code portion of the file name before building the zip (it will also suggest the current date's date code - YYYYMMDD). And, if you're building a zip installer that includes a g.prop file (found in many GApps packages), the installer will read the date code from the 'ro.addon.*_version=' property and automatically use it in place of the date code from the Windows folder name.
WINDOWS INSTALLER
As mentioned above, you'll have the best user experience if you install Zip Builder using the Windows installer. It runs in standard user mode (no Admin access required or requested) and installs the Zip Builder and Zip Builder Settings exe's in: 'C:Users<user>AppDataRoamingZip Builder'. The installer will create a program group and shortcuts in the Windows start menu (and optionally on the desktop) that can be used to launch Zip Builder in 'manual selection mode', where the user can manually select the folder they wish to build. The installer will automatically run Zip Builder Settings Manager at the conclusion of the install where you can configure the settings and options to your personal preference.
Uninstalling Zip Builder from the Windows Uninstall menu will remove all traces of the software from your system. And, since Zip Builder, Zip Builder Settings Manager, or its installer will NEVER prompt for UAC access, you can be confident that it's not touching the Windows operating system. Of course, all source code is available if you want to check for yourself - you can even build it for yourself, if you want!
TECHNICAL NOTES
Version 4.3+ of Zip Builder includes the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installed on a 32-bit Windows XP machine with only 1GB of RAM.
If you have had java heap size issues building zip installers in the past, version 4.3+ of Zip Builder should completely eliminate these problems.
XDA:DevDB Information
Zip Builder, Tool/Utility for all devices (see above for details)
Contributors
TKruzze
Version Information
Status: Stable
Current Stable Version: 4.5.2
Stable Release Date: 2020-09-06
Created 2018-01-23
Last Updated 2020-09-06
Anti-Virus False-Positives
ANTI-VIRUS FALSE-POSITIVES
There have been reports of false-positive flaggings of Zip Builder and/or the Windows installer. While I can, personally, assure you that there's no malware included in Zip Builder or its installer, I also understand that there may be some concern with using software that's been flagged on your machine.
To allay your concerns as best as possible, I have included 100% of the original source code for you to inspect and/or build the software yourself. Again, there is no possibility of malware as I do all of my compiling on a clean machine that is not connected to the internet. I have also submitted all 4 Windows executables to the major AV inspection service on the net. Below are the results of these inspections:
VirusTotal.com
ZipBuild.exe (32 bit) 7/68
ZipBuild.exe (64 bit) 2/68
ZipBuildSettings.exe 4/67
Zip Builder_4.5.2_Setup.exe 1/69
Sources & Acknowledgements / Recent Changes
SOURCES AND ACKNOWLEDGEMENTS
Zip Builder has existed for me since way back in 2013 when I started developing GApps packages. I've added features here and there and finally decided to share it. After privately sharing with @osm0sis, I received a lot of very constructive feedback and based on this, I polished the interface and added some new features. A big thank you to @osm0sis for this feedback. Without his input, it would look a lot clunkier than it does today.
All source code is provided, however, it's only appropriate for me to publicly acknowledge that this work includes code and binaries from several third party sources. Below is a complete list of these sources. You will also find this list as well as the actual code and binaries in the Source Code Zip file available for download.
Zip Builder
------------
Zip Builder is Copyright (c) 2013-2020 by @TKruzze
Original source code and compiled executables can be found on
XDA Developers. Zip Builder also includes code and compiled
executables from the sources listed below:
ZipSigner
---------------
ZipSigner is Copyright (c) 2016-2020, John Wu @topjohnwu)
Original source code and license can be found at:
https://github.com/topjohnwu/Magisk
The version of ZipSigner used in Zip Builder was built by @topjohnwu using the source code above and optimized using ProGuard optimizations
Info-ZIP
----------
Info-ZIP is Copyright (c) 1990-2007 Info-ZIP
Original License can be found at:
http://www.info-zip.org/license.html
Downloads can be found at:
ftp://ftp.info-zip.org/pub/infozip/win32/
Original source code can be found at:
https://sourceforge.net/projects/infozip/
Hashutils
----------
The MD5 Checksum code and executable are from code.kliu.org
Original source code and compiled executables can be found at:
http://code.kliu.org/misc/hashutils/
SUMMARY OF RECENT CHANGES
SEPTEMBER 6, 2020 - v4.5.2
Fixed RegEx bug (oversight) that only supported automatic folder renaming through the year 2019. Now we're good through the year 2029.
As always, the best and easiest way to update is to simply install the new version using the Windows installer without uninstalling the previous version. All of your settings and options will be retained
NOVEMBER 1, 2018 - v4.5.1
Updated the cleanup function to also include removal of the SignAPK*.tmp files that are created in the %TEMP% folder during the signing process.
- Thanks to @osm0sis for reporting
MARCH 26, 2018 - v4.4.0
Updated the ZipSigner java executable to v2.1-min. This version is significantly smaller than v2.1 (458K vs 4.0MB) and was built by @topjohnwu, himself, using using ProGuard optimizations
Recompiled Zip Builder Settings Manager (ZipBuildSettings.exe) without UPX compression to try and further minimize AV false-positives
Windows installer now built using lzma2/max compression and no longer uses solid compression. This was done to optimize installation speed and further minimize AV false-positives
MARCH 25, 2018 - v4.3.0
Updated signing code with the new ZipSigner 2.1 Java executable that was rewritten from the ground up by @topjohnwu for use in his Magisk root management software. This change will allow you to build the largest zip installer on even the smallest 32-bit machine. I was able to build a 1.0+GB shell-script based installer on a 32-bit Windows XP machine with only 1GB of RAM.
- Thanks, of course, to @topjohnwu, but also to @osm0sis for the heads up on its existence
- Thanks to @jenslody for building it for inclusion here.
Since memory and java heap size issues are now resolved with the above change, I have removed all memory and java heap size checks from Zip Builder. The above change also allowed me to remove the separate test key files (testkey.pk8 and testkey.x509.pem), signapk.jar, zipadjust, and minsignapk.jar executables as their functions are all now contained in the new ZipSigner 2.1 Java executable mentioned above.
Installer will now clean up its 'temp folder' files before displaying the 'COMPLETED' message. On slower systems this should reduce the delay when selecting the 'Close' button after Zip Builder completes the signing process.
- Thanks to @osm0sis for reporting and helping track down the issue
Zip Builder is now built without UPX compression on the Windows exe's. This was done to try and reduce false-positives that may be reported by your AV software. If you're still having AV hits, please read the ANTI-VIRUS FALSE-POSITIVES section on the OP.
Fixed bug in installer that would corrupt the context (right-click) menu settings on an update (not initial) installation.
- Thanks to @osm0sis for reporting and helping track down the issue
Excellent! Glad to see a public release! I was using Zip Builder all day to prepare my latest round of updates for my Odds and Ends thread, and it couldn't be easier!
It's been great working with you again @TKruzze, I knew you couldn't stay away from contributing awesome things to the community for too long.
Looks very cool! You're inspiring me to clean up and release a tool that I built which has no current equivalent.
Seeing as this uses Java, what would it take to make it work under linux? As a staunch Linux/osx user who only runs a windows VM for flashing his Samsung with odin, I would love to integrate this into my workflow, but without linux or Mac support for me personally that will be difficult ?
This is an incredible contribution. Thank you for making this public and for your hard work!
partcyborg said:
Seeing as this uses Java, what would it take to make it work under linux?
Click to expand...
Click to collapse
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
wow thanks @TKruzze :good:
this will be really helpful for my future firmware updates ✌
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
papasmurf879 said:
Ok im very very new to all this but does this make zips that are flashable in twrp? Im wanting to learn how to do that if you guys could point me in the right direction id be thankful.
Click to expand...
Click to collapse
yes
you need update-script and update-binary along other files
TKruzze said:
The only thing I'm actually using Java for is the signing portion of the process. There's no real way I can think of to easily port the rest of it to Linux. Thanks for the feedback!
Click to expand...
Click to collapse
My mistake. Thanks for the explanation! I'm sure then that this will run in wine however, I may give it a shot at some point. If I do I will let you know.
kamilmirza said:
yes
you need update-script and update-binary along other files
Click to expand...
Click to collapse
Thank you for replying im doing searches right now trying to figure it out.
papasmurf879 said:
Thank you for replying im doing searches right now trying to figure it out.
Click to expand...
Click to collapse
Advanced, but check out my thread here and the linked resources: [DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
The EDIFY references/resources are the place to start. :good:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Ash225 said:
Can i create flashable zips of my apks. I Flash custom roms very often and some apps are needed as my daily driver so can i make a flashable zip of those apk file and flash via this tool
Click to expand...
Click to collapse
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
madbat99 said:
Have you tried this?
This tool in this thread is for making a zip if you already have the components (updater script and binary).
Click to expand...
Click to collapse
Thanks but i knew about this app i want to creat zips from my computer and not from my phone thats why i asked the question thanks for your prompt reply
This looks like this tool that will, hopefully, be helpful for one of my other little projects that I had to put aside till I finish catching up with some other projects/developments that's already on my plate.
I already have a working set of script commands for safely disabling the Google Play Protect but, i will need a medium/delivery system before I can release it and this looks promising to help with this.
~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Yeah, I'm sure one of the most respected developers on XDA would do that. I'd be more worried about those antivirus softwares you're using than anything.
Djentist said:
Did you just give me a Trojan? Because Defender says so and even VirusTotal was positive about this. Beware about using this software!
Click to expand...
Click to collapse
Definitely not a very responsible post to make. There's nothing wrong about reporting your findings, but to make an accusation like this is a bit irresponsible. I also seriously doubt that Microsoft Defender identified this as a virus (as you claim).
Anyways, here are the facts: There is no virus or malicious behavior. Below are the actual results of scans by VirusTotal and VirScan
Zip Builder_4.2.1_Setup.exe
VirusTotal.com (0/65)
VirScan.org (1/39)
ZipBuildSettings.exe
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (32 bit)
VirusTotal.com (2/66)
VirScan.org (2/39)
ZipBuild.exe (64 bit)
VirusTotal.com (1/65)
VirScan.org (1/39)
Based on personal experience, ANY file that is not signed with a Microsoft Root Certificate and/or uses UPX compression is going to produce false positives with the heuristics deployed by some of these 'so called' anti-virus software products in the marketplace. I'm actually surprised the numbers are as low as they are.
All that said, if you are not comfortable using the software, fine. But please exercise responsible reporting if you have questions or concerns. A big part of the reason for me releasing all the source code is to avoid having to defend myself from people making exactly this type of assertion.
Note: This is a bash script, meaning to use it you must be on Linux.
Note: You must already have fastboot and adb installed on your system.
Background
I like messing around modding my device, and quite a few times that has resulted in bootloops, and other issues. After getting tired of repeating the recovery process so many times, I decided to just write a bash script to almost completely automate the process. It guides you with easy user-prompts, and can be used by someone with little knowledge.
I'm not a professional, I just have some skills that allow me to develop simple tools for myself. I'm just releasing it in-case it might be helpful to someone else.
Restrictions
It's only for Moto X4 Payton Fi phones, any other device would require modifications to the script. Over time I do plan on making more updates to it as I develop it for myself. It will become and all-in-one tool, with more functionality in the future.
Features
- Ability to recover your phone from soft-bricks automatically.
- Ability to install the latest TWRP as a custom recovery automatically.
- Ability to install latest firmware automatically.
- Ability to install systemless root via Magisk automatically.
Download
The latest version will always be available on my git repository.
Github Repository: github.com/menevia16a/Firmware-Recovery_MotoX4
Thank you, now may actually unlock this device. Still on fence, with no signed images. I may wait for Pie update, if it ever happens. These tools will be a big help.
kkjb said:
Thank you, now may actually unlock this device. Still on fence, with no signed images. I may wait for Pie update, if it ever happens. These tools will be a big help.
Click to expand...
Click to collapse
Thanks for the reply, when the firmware image for the pie update is released I should do another update to this too. But honestly you can always use the tool and when it installs the system and boots up, go to the ota update before continuing the script and accept the ota updates and continue the script once the system is booted up again.
Introduction
This thread contains the LineageOS 17.1 custom firmware images for the Unihertz Atom L, a rugged Android phone released by Unihertz in July 2020, and the accompanying LineageOS Recovery used for flashing the firmware.
Please note that this ROM is one of my side projects, for which I could provide zero warranty. By installing this ROM, you acknowledge that you take all the risks that come with installing custom firmwares on your devices, including but not limited to bricking your device, losing your data, etc. You are always suggested to keep backups and make sure you know how to flash back to official ROM before trying any custom ROMs.
Please find the download links in the Download section. The following sections are guides to installing the ROM.
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Working Features
- All basic features (Telephony, VoLTE, Audio, Camera, NFC, WiFi, Bluetooth, ....)
- Programmable PTT (red) button (Functionality can be set in Settings - System - Buttons, under the "Search Button" section)
- 48MP camera seems to be working (unlike on many other super resolution devices)
Known Issues
- VoLTE is working (at least for me) but sometimes quirky. If you find it somehow stopped working, usually turning it off and back on again (in Settings - Network - Mobile Network) will fix it. Putting the device to SELinux Permissive mode also fixes most of the VoLTE quirks but this is not recommended (a few quirks in Enforcing mode is better than having the whole device Permissive)
Unlocking
1. Boot your Atom L to the official OS
2. Go into Settings - About phone, tap "build number" several times to enable developer settings
3. Go to Settings - System - Developer Settings, enable OEM unlocking and ADB debugging
4. Run `adb reboot bootloader` on your PC (there is no way to enter bootloader directly, only possible through adb)
5. Run `adb flashing unlock` and comfirm unlock on device (THIS WILL WIPE ALL DATA)
6. Reboot and now you should see an unlocked warning during boot screen.
Installing LineageOS Recovery
For now the only working recovery is the LineageOS Recovery, because the device's kernel does not load the touch driver in recovery mode for whatever reason, rendering TWRP useless.
1. Download `lineage_recovery_XXX.img` and `vbmeta.zip`, unpack `vbmeta.zip` to get three .img files starting with `vbmeta`
2. Run `adb reboot bootloader` to put your device in bootloader mode
3. Run `fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img`
4. Run `fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta_system.img`
5. Run `fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta_vendor.img`
6. Run `fastboot flash recovery lineage_recovery_XXX.img`
7. Run `fastboot reboot recovery` to reboot into the newly-installed LineageOS Recovery
The LineageOS Recovery is operated by volume keys as selection and power as confirmation (or entering sub-menus). To return to upper levels of menus from sub-menus, press volume up until the selection goes to the first item and then disappears, then press power (i.e. there's a hidden "Go Back" item at the very top of each sub-menu).
The recovery will show a verification failed prompt for most packages that are not signed with the AOSP keys. This is safe to ignore.
Installing LineageOS 17.1
The LineageOS image must be installed via LineageOS recovery.
1. Download `lineage-17.1-Atom_L-XXX.zip`
2. Reboot your device into recovery (`adb reboot recovery` or simply hold volume up while turning power on)
3. Wipe all data (factory reset) (THIS DELETES EVEN INTERNAL STORAGE)
4. Choose Apply Update, then Apply Update from ADB
5. Run `adb sideload lineage-17.1-Atom_L-XXX.zip` from your PC
6. Wait for the process to finish. (The recovery might prompt something about verification failure, just ignore it and continue anyway)
7. At this point, you can then sideload the LATEST Magisk and OpenGAPPS Nano at your will (note that the size of the system partition might only be enough for the `nano` variant of OpenGAPPS) (If installing Magisk / OpenGAPPS fails, you can try rebooting into recovery again in advanced menus, then try installing them again)
8. Reboot into system and enjoy (Note that Magisk might cause your device to boot loop once or two but it will eventually boot)
When updating to a newer build, you have to flash the new zip, and then re-flash whatever mod you have installed previously (Magisk / GAPPS).
Download Links
LineageOS:
lineage-17.1-Atom_L-20200828-peter-signed.zip: https://mega.nz/file/bAgh1BZA#jzMs_0e9NUR9NcALXWp51ZeWttM5rl_3K5T8Or9hAW0
- Synchronized updates from LineageOS upstream.
lineage-17.1-Atom_L-20200728-peter-signed.zip: https://mega.nz/file/vBwlmL5D#wpw8RovBHyVFCLFlhQ2H5QAIb0ECXkT4of0FRijiP6A
LineageOS Recovery:
lineage_recovery_20200728.img: https://mega.nz/file/yc4Dnbyb#yx0Ci9p3q9_lfAiXkGfgWDFnRJI-JSGrv3kyawkU3fw
vbmeta:
vbmeta.zip: https://mega.nz/file/nF51mBoY#ZNY4j92wc_6a1dXch3l5r-w4VFl9QjN7YJaRMKRoEGk
XDA:DevDB Information
LineageOS 17.1 for Unihertz Atom L, ROM for the Android General
Contributors
PeterCxy
Source Code: https://cgit.typeblog.net/android/device/unihertz/Atom_L/
ROM OS Version: Android 10
Version Information
Status: Alpha
Created 2020-07-28
Last Updated 2020-07-28
How different is the Atom XL?
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
tvroman said:
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
Because Unihertz publishes completely different firmware files for the L and XL, so the safest assumption is that there is more difference than just the UHF radio. If you want to risk it, then you CAN try using this ROM on the XL, as long as you know how to revert back to official if things go wrong. (But I cannot guarantee if the kernel image from L that this ROM uses will not cause serious issues like corrupted baseband or something on the XL)
My suggestion is that instead of trying this ROM directly on the XL, someone with XL can try to modify my device tree for L, replacing the kernel, dtbo images and other vendor blobs from the ones from XL, and then re-compile the ROM for XL. This would be the proper way to handle these two devices.
Click to expand...
Click to collapse
Going XL
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
a-dead-trousers said:
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
Click to expand...
Click to collapse
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
PeterCxy said:
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
Click to expand...
Click to collapse
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
a-dead-trousers said:
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
Click to expand...
Click to collapse
> None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
> my dtb file is in the "device" directory and not being transfered into "out" during building.
Because most tools other than `unpack_bootimg` extracts dtb incorrectly.
> Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
Those don't matter. Either will work as long as you flash it with the correct parameters as given in my post.
> And reguarding the rather smallish system partition
No don't do that. Android 10 does not use a separate system partition anymore, instead both system, vendor and product are sub-partitions in a huge super partition. When flashing a new ROM, the partitions are automatically resized to match the new image exactly, instead of leaving free space unused like before Android 10. That's why I need to reserve space in BoardConfig.mk for gapps to be installed correctly.
Still not able to build.
PeterCxy said:
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
Click to expand...
Click to collapse
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
a-dead-trousers said:
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
Click to expand...
Click to collapse
> Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
> Where did you get the "config.xml" and "power_profile.xml" from
Exactly from those apks. Just decompile them using apktool.
PeterCxy said:
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
Click to expand...
Click to collapse
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
PeterCxy said:
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
Click to expand...
Click to collapse
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
a-dead-trousers said:
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
Click to expand...
Click to collapse
> Still giving me errors.
Looks like that dtb.img error was totally my fault -- it was due to my jerry-rigged solution of using prebuilt dtb image that conflicted with one of Lineage's update in August and I haven't built the ROM for a month. Now I have fixed it in the latest commit.
> Can you tell me how you got the list of needed files?
All of those files are for VoLTE support and I started with the list from a commit in Redmi Note 7 Pro's device tree that imported those VoLTE blobs, and then added what was missing one by one (when something is missing the Phone process will crash and you can see what got missing in the logs). I don't think the list will be any different on Atom XL so you can just use the one in my device tree.
Hi.
Thanks to you everything is running smoothly here. But what bugs me is that TWRP is not working on our devices.
Although for the Atom there is a possibility: https://forum.xda-developers.com/android/development/twrp-modded-to-unihertz-atom-t3885793
Before I want to go public with my build I wanted to solve this last "mystery".
So I tried to include it in my current source tree according to the (official?) guide but some errors prevented me from a successful build.
Naturally I asked for some guidance at the most reasonable places I know of but got nothing so far:
https://forum.xda-developers.com/showpost.php?p=83443611&postcount=4622
https://forum.xda-developers.com/showpost.php?p=83455271&postcount=4623
https://github.com/TeamWin/android_bootable_recovery/issues/70
I even tried different repositories (omnirom/android_bootable_recovery) and revisions (android-9.0) but these resulted in missing library "type" (static vs. shared) errors so I assume these are too old for LineageOS 17.1
What I want to know is how you managed to get TWRP to built for your device even though the touchscreen wasn't working?
Did you use your LineageOS source tree or one of the many "minimal" manifests? If so, which one would be the "best" to use?
wkr ADT
@PeterCxy and @a-dead-trousers
Thanks for all the work on this so far. I've got an Atom L and have gotten the ROM's PeterCxy posted running on them as in the OP. Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
dirtylimerick said:
[MENTION=5351691] Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
Click to expand...
Click to collapse
I documented my steps to setup up the build environment in the readme of my repo:
https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL
But leave out the TWRP part. It isn't working yet mostly because TeamWin/android_bootable_recovery and LineageOS/android_bootable_recovery are too similar.
To figure out all the bits and pieces needed for the device I followed the commit log of @PeterCxy build.
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
a-dead-trousers said:
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
Click to expand...
Click to collapse
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. That patching guide is pretty out of date and I imagine it won't work on most recent kernels. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code. Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
PeterCxy said:
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code.
Click to expand...
Click to collapse
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
PeterCxy said:
That patching guide is pretty out of date and I imagine it won't work on most recent kernels.
Click to expand...
Click to collapse
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
PeterCxy said:
Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
Click to expand...
Click to collapse
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
a-dead-trousers said:
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
Click to expand...
Click to collapse
Happy to hear that you were able to figure the touchscreen out. I tried to port TWRP at the very beginning when I started tinkering with the device but quickly grew frustrated and just ported Lineage Recovery instead. I guess I might try patching the kernel image too at some point later.
BTW, for TWRP to work with devices released after Android 10, I'm pretty sure you need an extra set of patches that are not yet fully merged to the main TWRP repository. I remember there's some guy providing another manifest with all the patches applied but I couldn't remember the name.
Hi.
I just officially announced my build for the Atom XL:
https://forum.xda-developers.com/android/development/rom-lineageos-17-1-unihertz-atom-xl-t4171407
Could you please put a link in your first post for those in search of the Atom XL and found your thread instead. Thanks.
wkr ADT
hi @PeterCxy.
During my daily usage of the phone I encountered a strage problem:
The audio jack isn't working. Plugging in some headphones I get this slight click in the earpieces when the circuits connect but nothing else happens. Neither a "headphone" icon in the status bar nor hearing anything coming from the headphones itself. The main speaker of the phone keeps playing the music. Using bluetooth everything is working as expected though. So I used logcat to see if something is coming up during plugging in but nothing "catchy" shows up in the logs. My guess is that some (vendor?) service is missing or not started during booting. Next I checked If something shows up on logcat during boot but I'm not sure for what to look exactly. There are quite a few errors and warnings though. In my despair I started to "fix" the "avc: denied" (SEPolicy) entries. Thats when I found a specific error reguarding VoLTE. Maybe this would fix the problems you had with VoLTE in enforcing mode:
https://github.com/ADeadTrousers/an..._Atom_XL/blob/master/sepolicy/private/init.te
(The line with "socket_device:sock_file")
My provider doesn't support VoLTE so I'm not sure if this helps or not. Maybe you could check it.
Anyway can you please tell me if your device's audio jack is working or not?
If you're (by some mysterious coincidence) not affected by this, can you at least give me some pointers for what to look for to get this fixed on my side.
The Internet Is not very helpful when searching for "android audio jack" or something similiar.
Thanks in advance.
wkr ADT