Database Info

Porting Tips

This thread covers what I have learned about porting. When possible, I'll include links.
This post primarily applies to Samsung devices, although parts can also be used by other manufacturer's devices.
Get the stock firmware for your devices. This step is very important. Besides needing it to reset your device, you will need the boot and recovery images that should be in the archive file.
Follow Cyanogenmod's Porting page.
Use Heimdall to get the partition table
Get the block size by taking the number of blocks from the pit file, and then dividing the size of the storage card by that. Round to the nearest power of 2. (E.g., 524 -> 512).
Use unpackbootimg to get the files in the boot and recovery images
Get the kernel building
Use PRODUCT_COPY_FILES to copy files to specific locations. It needs to be in a device_*.mk file. Use this for the initrc's, and anything else that needs to be in the recovery (e.g., kernel modules). Keep in mind that the only variables the mk file knows about are the ones you tell it about.
At this point, you may or may not have a booting recovery. In the event that you cannot boot into the recovery (e..g, it reboots immediately upon attempting to enter the recovery), try looking at the stock recovery files (especially the ramdisk files), and see what the differences are between it and your recovery image. Again, unpackbootimg is helpful.
As a side note, I'm trying to port Cyanogenmod to the Tab 3 7.0 without using anyone else's source. Right now, I'm stuck on (6), which I'm still going through. I'll try to remember to update this post as I learn new things.

Build Environment
I'm currently using Fedora Rawhide -- which doesn't have java 1.6 or 1.7. For building the recoveries, it does not seem to matter.
That said, building using just the "mka" command will error out, as Cyanogenmod 11 is not able to be built under java 1.8.
As such, my recommendation is to use an arch installation and the systemd-nspawn command for java 1.7 (also, see the AUR for older java packages).

[TOOL]TWRP/AROMA SPFlash | MediaTek

AROMA/TWRP version of SPFlash Tools.
This tool is for MTK devices with a GPT layout - (MT6732, MT6752 and their variants).
With some testing it may be possible to add some some support for the older devices using an MBR.
Requirements:Copy SPFlash contents to /sdcard/SPFlash
Rename *scatter.txt to scatter.txt
Run .zip from TWRP​MTK-64bit_SoCs-v*.zip:During testing there will only be info displayed on screen, nothing should be modified. (Unless otherwise stated)​SPFlash-v*.zip:This will install all .img/.bin in SPFlash folder if partition is large enough​Downloads:GDrive Folder​Changelogs:SPFlash
v10 - Readded internal sd - fixed aroma exit/about screen - (a few cosmetic issues introduced).
v8 - Aroma menus updated
v7 - Create 'flashable' zip from backed up partitions.
v6 - Zipped backups added
v4 - Backup + Install fixed -- Aroma "Quit Installation" stalls
v3 - Backup function added - untested -- backup works / install from v2 broken
v2 - Menu Select Added
v1 - Initial Release
MTK-64bit_SoCs
v8 - attempts to fix unrelated menu/alert
v7 - calculations done quicker
v6 - script rewrite/reorder
v1 - v5: Initial test builds​
Only follow menu Partition Related -> Scatter Information
Other menus/option are broken/dead ends...
Other things in the MTK folder:simg2img/img2simg are arm source compiled binaries to handle sparse files
file/magic were taken from @osm0sis's AIK (I can't seem to get file to compile)
MTKsplit is used to split boot/recovery images into it's individual parts. Normal images will split into 3; 1 = img ANDROID! header, 3 = kernel (zImage) and 5 = ramdisk (ramdisk). MTK images split into 5; 1,3,5 as before with 2 and 4 being additional headers.​
XDA:DevDB Information
TWRP/AROMA SPFlasher, Tool/Utility for all devices (see above for details)
Contributors
HypoTurtle
Source Code: https://drive.google.com/open?id=0B8WPOq9wZyKxfktHVWgxbW9nYmtJd1ZWc2RIM1NXUU5pSXpramg0bVBYYUdyRDhid3hwM3c
Version Information
Status: Testing
Current Stable Version: V8
Stable Release Date: 2015-09-03
Created 2015-09-03
Last Updated 2015-09-03

Current StatusMTK-64bit_SoCs-v8 .zip will output the partitions that it deems are incorrectly sized in the scatter.txt and will also check the .img/.bins in the SPFlash folder and determine what should go where and will determine if the partition is large enough for the respective .img/.bin
SPFlash-v1.zip will flash the entire contents of /sdcard/SPFlash folder
SPFlash-v3.zip allows selection of files /sdcard/SPFlash folder to install and has a backup option​
Improvements NeededFor SPFlash-v2 will add a basic menu select option for what you want to flash...
In future versions will add backup option and partition resize
Will start to look at resize...​

Derivative Work - using scatt and part from #1
ScatterfixGenerating a fixed scatter from a 'broken one'
Code:
[size=1]#!/sbin/sh
ldr=`pwd`
scatterfix(){
scatt \${b} \${c} \${d}
part \${p} \${q} \${r}
scttrbfr=`cat "${scatterloc:-$ldr}/scatter.txt"`
while IFS=" " read -r a b c && read -r d e f <&3; do
if [ $a = $d ]; then
if [[ ! ${b} = "DONT_USE" && ${b} != ${e} ]]; then
scttrafter="${scttrbfr//${b}/${e}}"
scttrbfr=`echo "${scttrafter}"`
fi
if [[ ! ${c} = "DONT_USE" && ${c} != ${f} ]]; then
scttrafter="${scttrbfr//${c}/${f}}"
scttrbfr=`echo "${scttrafter}"`
fi
fi
echo "${scttrbfr}" > ${scatterloc:-$ldr}/scatter-new.txt
done </tmp/scatter 3</tmp/parted-new
}
scatterfix
diff ${scatterloc:-$ldr}/scatter.txt ${scatterloc:-$ldr}/scatter-new.txt[/size]
Problems to fixThe code will change any hex value deemed wrong to a new calculated value - there is a chance that 4 values are the same but only one/two are wrong - to fix will need to add a loop through scatterfix until the scatter-new.txt generated is actually correct.​​Resize Userdata/IntsdMore of a precursor - bugs fixed and maintained by @odigitech
Thread located here​

Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
1. Is the preloader header custom or generic; and does it change when flashing the proloader?
2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?​

For v7 trying to add a backup + make installable zip option:
Have done it with basic dd backups; would prefer to use sparse/simg2img but simgimg can't seem to use zipped .img's; have looked into using dat/sdat2img but that would require getting python to run in recovery (unless I'm mistaken).

Have added the simplistic option as v7...

odigitech said:
@HypoTurtle I have made a modified version of MTKsplit with more human-friendly names, its in my Drive folder, if it's any use.
Click to expand...
Click to collapse
Thanks, I have updated mine to support non-MTK header-ed boot/recovery.imgs -- can't hurt to make it human readable I suppose.
MTKsplit will be used in the next uploaded version (v8) in the form of a simplistic porting tool...
Should be uploaded on Monday/Tuesday

odigitech said:
You made it work for non-MTK also? Nice one, is it on your Drive?
Sent from my thl 2015 using XDA Free mobile app
Click to expand...
Click to collapse
Should be... but I'll update it with the human-readable version now.
It's not vigorously tested; and not as robust as the (un)mkbootimg binaries out there but it seems to do the job.

@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app

AlexZap said:
@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Is it just the system.img that doesn't appear? And are you using internal or external SD?

HypoTurtle said:
Is it just the system.img that doesn't appear? And are you using internal or external SD?
Click to expand...
Click to collapse
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app

AlexZap said:
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)

HypoTurtle said:
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)
Click to expand...
Click to collapse
Screenshot of the folder, and the scatter. I checked it and it looked fine.

AlexZap said:
Screenshot of the folder, and the scatter. I checked it and it looked fine.
Click to expand...
Click to collapse
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.

HypoTurtle said:
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.
Click to expand...
Click to collapse
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app

HypoTurtle said:
Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
Q1. Is the preloader header custom or generic; and does it change when flashing the proloader?
Q2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?​
Click to expand...
Click to collapse
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:

AlexZap said:
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Not sure if you missed the edit. It was more for cosmetic reasons - I could have had say 12 files being displayed but if there's only one file to flash you would have a screen with a lot of blank entries. 3, 5 and 12 seemed the most appropriate without going down the route of creating a menu for all possible entries.
3 being typical install (system/boot and perhaps blank cache/userdata to wipe); 5 as 3 but with custom etc.
I figured that anyone with more than 5 flashable items in there would have dumped the entire SPFlash ROM which I calculated as ~12 items.
yuweng said:
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:
Click to expand...
Click to collapse
A2. I don't thing it contains the IMEI - but it is the database that the IMEI is coded against; I'm not aware of any devices (other than the P6000) suggesting that you recode the IMEI on an upgrade from KK to LP so there is probably not an issue here.

i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...

yuweng said:
i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...
Click to expand...
Click to collapse
On the 64bits at least it is also on a hidden partition (nvram) - and it just gets copied to /data/nvram or something (ie. its not mounted but it's files are there). The DB files etc are present in /system as well as in the full SPFlash ROM so I guess things like MTKEng and apps like chamelephon use that when setting/'fixing' the IMEI.
What are the file formats used by intel stock ROMS? This tool isn't really MTK dependant - it's GPT partition dependant (with a scatter for validity check- I'll post a bear minimum of what a 'scatter.txt' needs to have).
Anyway v8 added - so that files to flash aren't hidden (max. 12 files).

Hmm, further digging seems MTK IMEI is at /dev/nvram, same thing happening on intel, users just never spell out everything, they use the format/ erase flash/ emmc that wipes out the IMEI partition but never tell...
i think on the X3, its not possible as its NOT an Android image file but proprietary fls file which they got it when they acquire infineon i think...
Manual fastboot/ dd backup/ restore & you'll end up with a brick device, ATM, no custom recoveries that boot on the x3, i haven't figure out how to repack its recovery that has three separate different region that requires three proprietary download file that packs it together into a fls file & only their FlashTool_E2 is able to download it correctly...
Can't really understand infineon/ intel for developing such cheap device but with such high end software tools...

[DEV][TOOL][Linux]Android System Extraction and Repack Tool

Introduction
You probably know already that starting from Android 5.x (Lollipop) compiled roms (aosp,cm,stock) are not compressed anymore the way they used to be on previous android versions. On previous versions all content inside /system folder that has to be extracted within our device was either uncompressed (simple /system folder inside our flashable zip) or compressed in a system.img file, which it is a ext4 compressed file; both of these, anyway, were readable and we could see all system files (app,framework, etc).
The problem comes in >=5.0 versions, this method is not used anymore. Why? Because roms started to be always larger, so it is necessary to compress them even more.
Note : Introduction was taken from here : https://forum.xda-developers.com/an.../how-to-conver-lollipop-dat-files-to-t2978952 by @xpirt so thanks to him
So in order to save myself and others who most port Custom & Stock Roms, i decided to use some part of my time to write this script for easy work done.
What this script does :
It basically Unpack and Repack system.new.dat alongside with file_context.bin convertion which is seen in android 7.0/7.1
ITS USAGE:
NOTE
First Clone the repo.
Make sure that Android_System_Extraction_and_Repack_Tool is located at Desktop
Run "Xtrakt" from it's location in terminal
Copy "file_contexts.bin" from your Rom to "file_context_zone" folder
Use "f" from menu to convert "file_contexts.bin" to text readable "file_contexts"
Copy : system.new.dat, system.transfer.list & file_contexts to "convert-dat" folder.
Use "i" from menu to unpack, which the output will be name as "rom_system" for modifications of apks & files.
Use "y" from menu to repack, which the complete new "system.new.dat", "system.patch.dat" & "system.transfer.list" will be located at "Finish-new.dat" folder
Done !
EXAMPLE:
Again , Make sure that Android_System_Extraction_and_Repack_Tool is located at Desktop
In your terminal, type the following to start the script:
Code:
git clone https://github.com/iykequame/Android_System_Extraction_and_Repack_Tool.git
mv android_system_extraction_and_repack_tool ~/Desktop/
cd ~/Desktop/android_system_extraction_and_repack_tool/
./Xtrakt
OR
Code:
Double-click the Xtrakt file and choose "Run in Terminal" if your OS supports it.
##ALERT!!!##
sudo is requested in the script.
How To Get It {Tool]
Clone from one of the below ;
From GITHUB :
Code:
git clone https://github.com/iykequame/Android_System_Extractrion_and_Repack_Tool.git
From BITBUCKET :
Code:
git clone https://[email protected]/zac6ix/android_system_extraction_and_repack_tool.git
Or
Download zip
AFH
GIT-RELEASE
Sources :
Android_System_Extraction_and_Repack_Tool
GITHUB
BITBUCKET
Threads :
sdat2img 1.0 - img2sdat 1.2
For file_context.bin conversion by: Pom Kritsada @ MTK THAI Developers.
Credit to :
@xpirt
@SuperR.
-all xda threads which helped
-Android Matrix Development - here
-Nana Yaa for her time.

hi, your tool sounds good but it seems it doesnt work.
i press f and nothing happen ..
Use "f" from menu to convert **"file_contexts.bin"** to text readable **"file_contexts"**

Blackball said:
hi, your tool sounds good but it seems it doesnt work.
i press f and nothing happen ..
Use "f" from menu to convert **"file_contexts.bin"** to text readable **"file_contexts"**
Click to expand...
Click to collapse
Sorry for the Late reply !
Directories linking has been fix .
You can go ahead and try again

Thanks for sharing!

Don't work
When i press i ..Don't work.say file missing.but i already put all file..Please help meView attachment 4249470

Doesn't do anything with file_context.bin, doesn't even check if file is there.

oreo supported???

I am getting this error on repacking:-
Code:
WARNING! WARNING!! WARNING!!!
Please Check & Trace Where Errors.
There Is NO rom_system found
file_contexts -->> Missing !
Android SDK -->> not detected !
Please help.

Black_J said:
I am getting this error on repacking:-
Code:
WARNING! WARNING!! WARNING!!!
Please Check & Trace Where Errors.
There Is NO rom_system found
file_contexts -->> Missing !
Android SDK -->> not detected !
Please help.
Click to expand...
Click to collapse
I see that this thread is not supported.
Anyways, I observed that the tool works for file_contexts.bin but not for other options.
So , I followed the other link in the thread for individual commands and was successful.

Works perfectly on Android Pie! Have to do some tweaks, PM me if anyone wants to make this work for Android Pie.

[GUIDE] How to build an unsupported rom using sources from other roms

Hello all and welcome to my first how-to guide
I began the process of learning about ROM about 4 months ago (so excuse this post if there are any inaccuracies and please feel free to correct me in the comments - I will absolutely update this post to ensure it has the best information)
Whilst I was trying to learn, I noticed there was a lack of information regarding how the actual build process works. Many roms will provide instructions allowing you to build your own unofficial version for one of their official devices, but very rarely do they inform you as to how you may do this for a device not officially supported.
This is what I shall try and explain here.
Building for a newer version of android is another challenge, so this guide will focus on building an unsupported rom from device sources that support the same version of android (e.g building Lineage oreo from AOSCP oreo sources etc)
Requirements
A relatively fast PC with a least 4 cores (less may work but it will take a long time)
At least 8GB ram
A swap-file set up in the event that your ram is fully filled
A significant amount of storage (each build can take 150-200GB)
Set up your PC for building
Firstly, allocate Jack enough memory to complete the build process by running
Code:
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"
And adding that line to your ~/.bashrc file
Also (optional) enable ccache by running
Code:
export USE_CCACHE=1
and adding that to your ~/.bashrc
If you choose to use ccache, also allocate a set amount of memory to use with
Code:
ccache -M $G
Where $ is a value of your choice between 50 and 100
First things first, we need to download the main source code for the target rom
Firstly you need to sync the sources from the manifest of your chosen rom. This will normally be called android, or manifest (or something similar) and will contain some xml files layed out like the example local manifest below
Find this repo and copy the link. Then move to the location you wish the entire android code to be stored, and then perform the following command
Code:
repo init -u <url of manifest repo>.git -b <branch you want to build>
e.g. for lineage 15.1 it would be
Code:
repo init -u https://github.com/LineageOS/android.git -b lineage-15.1
Finally, run "repo sync" to download the source code. It is very large (approximately 30GB) so it will take a while. Should you need to cancel this, a simple CTRL+C will stop it, and it will continue from where it stopped next time you run repo sync
Now we need to understand which components we need to build a custom rom.
We need (anything inside the <> needs to be replaced with relevant information for your device)
A device tree. This contains all the information needed to configure the rom build to your device's needs. Often this comes as more than one repo (one for your exact device and one for the general model - e.g. for my LG G4 H815, we have the h815 repo and the g4-common repo). The format for these repos is generally android_device_<vendor>_<device model>
A kernel. This contains all the drivers and more needed for your device to be able to run Android. Often these are named using your device's chipset name and follow the format android_kernel_<vendor>_<chipset>, although occasionally they can use your model name instead of the chipset.
Proprietary blobs. These are the closed source blobs that come bundled in your OEM software and contain the non-OSS (open source software) drivers for your device. They normally come in a repo labeled proprietary_vendor_<vendor> which normally contains blobs for all the devices released by that vendor (that are supported).
Any other repos specified by the dependencies file (more on that later)
All of the above repos go into the path specified in the name - for example, android_device_<vendor>_<device model> will go into the device/<vendor>/<device model> directory.
To sync these, you should create a local manifest in the <android source>/.repo/local_manifests/ folder. Name it anything you like (make sure it's an xml file) and fill it out like so
Code:
<manifest>
<remote name="<your chosen name for this url>"
fetch="<url to your git organisation>"
revision="<branch if different to the one used in repo init (otherwise, miss out revision)>"
<project name="<name of repo inside git org>" path="<destination of the repo>" remote="<remote name chosen earlier>" revision="<revision if different to one specified above>" />
</manifest>
After adding this manifest, re-run repo sync to pull the extra repos
Understanding the device tree.
Inside the device tree (model specific one if there are more than one) there will be a file with a naming scheme along the lines of <rom brand>.mk (e.g. lineage.mk). This is the starting file for your device and is detected when you begin a build for your device. (Pie roms are currently using AndroidProducts.mk as a placeholder containing a link to this file). It contains links to the common configuration of your device (phone, tablet etc) at the top, and also specifies the name of the product (normally <rom>_<device model>) which is part of the command used to build the device.
There will also be some build prop overrides - these contain information like the device name and the build fingerprint (used to verify to google what device you are - lots of devices leave this as the last stock fingerprint to pass google CTS)
In most device trees, there will also be a <rom>.dependencies file. This contains all the additional repos needed to build for your particular device. This file is parsed automatically if you use the official methods and use the breakfast command. If you do it manually, they must be added to a local manifest.
The <device model>.mk file is what defines what open source packages need to be built in the build. Devices either include everything in this file or they can link to a product folder in which every .mk file is included.
BoardConfig(Common).mk includes configuration options for the device, and often links to config files to inform the builder of certain flags that need to be applied for the build. Similarly to the <device model>.mk, this is often linked to a board folder containing configurations
The kernel
The kernel is a massive topic and one that I cannot explain in depth here. However, for rom building it is useful to know that the defconfigs used to build a kernel are located in kernel/<chipset/device model>/arch/<arm or arm64 depending on device>/configs and the one used is normally in the format <rom>_<device model>_defconfig (e.g my lineage one is lineageos_h815_defconfig). Should you wish to change the name, simply change the name and alter the defconfig name in the BoardConfig.mk for your particular device.
So...to the main part - how do you build a rom.
Essentially there are a few main commands that are spoken about
"source build/envsetup.sh". This runs the builder script and loads all the custom commands.
"breakfast". This simply pulls the device specific code from the official repos. You do not need this if you are building unofficially
"brunch". This effectively performs breakfast, but assuming everything is synced correctly, it will finish without an issue. Then it will go on to begin the build. Normally brunch is run as brunch <rom name>_<device model>-userdebug (or eng if you are developing). User is used for OEM releases but most roms use userdebug as it is slightly more relaxed on conditions
To build a rom from unsupported sources requires a bit of thought. Firstly, ensure you have all the dependencies synced (hopefully from the target rom) as well as the device sources.
Then you need to go into the device tree and modify
The <rom>.mk file to now be renamed to your new rom.
You need to enter that file and modify any stuff relating to your old ROM look for your new rom instead (device type configurations are normally the main one here).
You need to remove any stuff inside your device tree relating to features not in your new rom.
Then run "source build/envsetup.sh"
"brunch <rom>_<device model>-userdebug"
This will hopefully begin the build and assuming everything is setup correctly, should continue through to finish building the rom of your choice
If you have any questions/issues with this process, I will be happy to answer to the best of my ability
Also, big thanks to the LineageOS guide for giving me a basis upon which to base this guide on

PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE directly
Specify Framework Compatibility Matrix Version in device manifest by adding a target-level attribute to the root element <manifest>. If PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE is 26 or 27, you can add "target-level"="1" to your device manifest instead.
how to implement this?

nadeem_naddy said:
PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE directly
Specify Framework Compatibility Matrix Version in device manifest by adding a target-level attribute to the root element <manifest>. If PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE is 26 or 27, you can add "target-level"="1" to your device manifest instead.
how to implement this?
Click to expand...
Click to collapse
Sorry for the late reply
What Android version are you building (this determines the api level). Also, what rom and device (links are helpful as I can see what it going on)
I would imagine you need something like https://github.com/LineageOS/androi...mmit/c24f0fff1fb1fc46d638e91777281ec7efc3e239

ThePiGuy said:
Sorry for the late reply
What Android version are you building (this determines the api level). Also, what rom and device (links are helpful as I can see what it going on)
I would imagine you need something like https://github.com/LineageOS/androi...mmit/c24f0fff1fb1fc46d638e91777281ec7efc3e239
Click to expand...
Click to collapse
i did not get the way to override or more precisely i dont know where to put the code to over ride this flag so i simply commented this in BoardConfig.mk itself. as it says its deprecated.
now i encounter this -
66% 2/3] glob frameworks/base/core/java/**/*.java
ninja: error: unknown target 'nitrogen_X00TD'
01:34:03 ninja failed with: exit status 1
it would be great help if you let me know from where does frameworks pick the device info in device tree. where do we need to set path.. i am building nitrogen pie for my device X00TD. thanks

the latest issue am facing is -
ninja: error: '/home/matin1117/nitrogen/out/target/common/obj/java_libraries/qcrilhook_intermediates/classes.jar', needed by '/home/matin1117/nitrogen/out/target/common/obj/packaging/boot-jars-package-check_intermediates/stamp', missing and no known rule to make it.
please suggest a fix.
thanks,
Nadeem

nadeem_naddy said:
the latest issue am facing is -
ninja: error: '/home/matin1117/nitrogen/out/target/common/obj/java_libraries/qcrilhook_intermediates/classes.jar', needed by '/home/matin1117/nitrogen/out/target/common/obj/packaging/boot-jars-package-check_intermediates/stamp', missing and no known rule to make it.
please suggest a fix.
thanks,
Nadeem
Click to expand...
Click to collapse
Is Pie ready for your device. For most ROMs it requires a lot of cherry-picking etc before it will build

ThePiGuy said:
Is Pie ready for your device. For most ROMs it requires a lot of cherry-picking etc before it will build
Click to expand...
Click to collapse
yes the device have many pie roms but i want to build nitrogen. i
can see niteogen os pie built for many other phones using sd636.

nadeem_naddy said:
yes the device have many pie roms but i want to build nitrogen. i
can see niteogen os pie built for many other phones using sd636.
Click to expand...
Click to collapse
Pie is an oddball case at the moment. Many ROMs work if you cherry-picking fixes off Gerrit (I built Pie Lineage for my G4 but it required about 20 cherry-picks off the lineage Gerrit before it built)
In your case, it looks like you are possibly missing a ril-caf repo (look in the nos.xml and you will see only the non-caf repo is being synced). You can add the caf one but it's possible it isn't ready yet

thanks a lot, i can see one ril related entry in nos.xml. let me do some research on it.
thanks a lot for all your help buddy.

iam facing this error ? can u help please..... ?
see attachment ! 
 @ThePiGuy
Thanks in advance

vignesh95 said:
iam facing this error ? can u help please..... ?
see attachment !
@ThePiGuy
Thanks in advance
Click to expand...
Click to collapse
Ok can you show me the result of
Code:
ls device/oneplus

here u have it (see attachment)
ThePiGuy said:
Ok can you show me the result of
Code:
ls device/oneplus
Click to expand...
Click to collapse
Hi @ThePiGuy

vignesh95 said:
Hi @ThePiGuy
Click to expand...
Click to collapse
ok. And now
Code:
ls device/oneplus/oneplus2

here u have it (see attachment)
ThePiGuy said:
ok. And now
Code:
ls device/oneplus/oneplus2
Click to expand...
Click to collapse
revised 
 @ThePiGuy

vignesh95 said:
revised
@ThePiGuy
Click to expand...
Click to collapse
Ok. Sorry for the late reply.
You need to open the AndroidProducts.mk file and rename the lineage_oneplus2.mk line to aosp_oneplus2.mk.
You also need to change the lineage_oneplus2.mk file so it is called aosp_oneplus2.mk, and inside it you need to change any occurrences to aosp (basically you are rebranding the device tree to use the aosp versions rather than the lineage branded ones)

ThePiGuy said:
Ok. Sorry for the late reply.
You need to open the AndroidProducts.mk file and rename the lineage_oneplus2.mk line to aosp_oneplus2.mk.
You also need to change the lineage_oneplus2.mk file so it is called aosp_oneplus2.mk, and inside it you need to change any occurrences to aosp (basically you are rebranding the device tree to use the aosp versions rather than the lineage branded ones)
Click to expand...
Click to collapse
thanks! @ThePiGuy
now i am getting this error
[944/944] including vendor/qcom/opensource/dataservices/Android.mk ...
device/oppo/common/configpanel/Android.mk: error: ConfigPanel (APPS android-arm64) missing org.lineageos.platform.internal (JAVA_LIBRARIES android-arm64)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
build/make/core/main.mk:837: error: exiting from previous errors.
20:05:06 ckati failed with: exit status 1
#### failed to build some targets (03:05 (mm:ss)) ####
Please help !

vignesh95 said:
thanks! @ThePiGuy
now i am getting this error
[944/944] including vendor/qcom/opensource/dataservices/Android.mk ...
device/oppo/common/configpanel/Android.mk: error: ConfigPanel (APPS android-arm64) missing org.lineageos.platform.internal (JAVA_LIBRARIES android-arm64)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
build/make/core/main.mk:837: error: exiting from previous errors.
20:05:06 ckati failed with: exit status 1
#### failed to build some targets (03:05 (mm:ss)) ####
Please help !
Click to expand...
Click to collapse
Sorry, I don't think I can help with that
Make sure your build environment is set up correctly (wiki.lineageos.org/devices/oneplus2/build will help with that) and also ensure you are using Pie device sources (from what I have gathered you are trying to build Pie, but if you are using device trees and kernel from Oreo or anything else then it will require much more than this guide details)

Hi bro, i want to build lineage OS for unsupported device(Xiaomi Vince), please give me the step
---------- Post added at 08:57 AM ---------- Previous post was at 07:58 AM ----------
iam get error like this
including vendor/lineage/vendorsetup.sh
build/make/core/envsetup.mk:264: error: TARGET_ARCH not defined by board config: device/xiaomi/vince/BoardConfig.mk.
15:41:16 dumpvars failed with: exit status 1
Device vince not found. Attempting to retrieve device repository from LineageOS Github (http://github.com/LineageOS).
Repository for vince not found in the LineageOS Github repository list. If this is in error, you may need to manually add it to your local_manifests/roomservice.xml.
build/make/core/envsetup.mk:264: error: TARGET_ARCH not defined by board config: device/xiaomi/vince/BoardConfig.mk.
15:41:18 dumpvars failed with: exit status 1
build/make/core/envsetup.mk:264: error: TARGET_ARCH not defined by board config: device/xiaomi/vince/BoardConfig.mk.
15:41:19 dumpvars failed with: exit status 1
** Don't have a product spec for: 'aosp_vince'
** Do you have the right repo manifest?
No such item in brunch menu. Try 'breakfast'
Click to expand...
Click to collapse

Help me
Hey
I have a common device source, which has linked my device to 3 more configuration files. I tried to change lineage to other rom in every possible location I can find but on building this error comes into action.
The error is same for every AOSP based rom
[email protected]:~/AEX$ mka aex -j4
vendor/aosp/config/bootanimation.mk:32: warning: Target bootanimation res is undefined, using generic bootanimation
============================================
▄▄▄ ▓█████ ▒██ ██▒
▒████▄ ▓█ ▀ ▒▒ █ █ ▒░
▒██ ▀█▄ ▒███ ░░ █ ░
░██▄▄▄▄██ ▒▓█ ▄ ░ █ █ ▒
▓█ ▓██▒░▒████▒▒██▒ ▒██▒
▒▒ ▓▒█░░░ ▒░ ░▒▒ ░ ░▓ ░
▒ ▒▒ ░ ░ ░ ░░░ ░▒ ░
░ ▒ ░ ░ ░
░ ░ ░ ░ ░ ░
AospExtended-v6.3 9
============================================
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=9
EXTENDED_MOD_VERSION=AospExtended-v6.3-20190311-0935-UNOFFICIAL
TARGET_PRODUCT=aosp_fortuna3g
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv8-a
TARGET_CPU_VARIANT=cortex-a53
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-4.15.0-20-generic-x86_64-Linux-Mint-19
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=PQ2A.190205.001
OUT_DIR=/home/jmpfbmx/AEX/out
PRODUCT_SOONG_NAMESPACES= hardware/qcom/audio-caf/msm8916 hardware/qcom/display-caf/msm8916 hardware/qcom/media-caf/msm8916
============================================
[1/1] /home/jmpfbmx/AEX/out/soong/.minibootstrap/minibp /home/jmpfbmx/AEX/out/soong/.bootstrap/build.ninja
[55/56] glob prebuilts/ndk/stl.bp
[80/80] /home/jmpfbmx/AEX/out/soong/.bootstrap/bin/soong_build /home/jmpfbmx/AEX/out/soong/build.ninja
/home/jmpfbmx/AEX/out/build-aosp_fortuna3g-cleanspec.ninja is missing, regenerating...
vendor/aosp/config/bootanimation.mk:32: warning: Target bootanimation res is undefined, using generic bootanimation
/home/jmpfbmx/AEX/out/build-aosp_fortuna3g.ninja is missing, regenerating...
vendor/aosp/config/bootanimation.mk:32: warning: Target bootanimation res is undefined, using generic bootanimation
[25/1110] including development/build/Android.mk ...
development/build/build_android_stubs.mk:43: warning: android_stubs_current
development/build/build_android_stubs.mk:43: warning: metalava_android_stubs_current metalava_android_stubs_current
development/build/build_android_stubs.mk:43: warning: android_system_stubs_current
development/build/build_android_stubs.mk:43: warning: android_test_stubs_current
development/build/build_android_stubs.mk:43: warning: metalava_android_system_stubs_current metalava_android_system_stubs_current
development/build/build_android_stubs.mk:43: warning: metalava_android_test_stubs_current metalava_android_test_stubs_current
[271/1110] including frameworks/av/camera/Android.mk ...
frameworks/av/camera/cameraserver/Android.mk:18: warning: Target has integrated cameraserver into mediaserver. This is weakening security measures introduced in 7.0
[607/1110] including system/sepolicy/Android.mk ...
system/sepolicy/Android.mk:88: warning: Be careful when using the SELINUX_IGNORE_NEVERALLOWS flag. It does not work in user builds and using it will not stop you from failing CTS.
[1110/1110] including vendor/samsung/serranovexx-common/Android.mk ...
bootable/recovery/Android.mk: error: recovery (EXECUTABLES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
device/samsung/qcom-common/doze/Android.mk: error: SamsungDoze (APPS android-arm) missing org.lineageos.platform.internal (JAVA_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/interfaces/health/1.0/default/Android.mk: error: [email protected] (SHARED_LIBRARIES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/samsung/AdvancedDisplay/Android.mk: error: AdvancedDisplay (APPS android-arm) missing org.lineageos.platform.internal (JAVA_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
system/core/healthd/Android.mk: error: charger (EXECUTABLES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
build/make/core/main.mk:850: error: exiting from previous errors.
10:40:35 ckati failed with: exit status 1
build/make/core/main.mk:21: recipe for target 'run_soong_ui' failed
make: *** [run_soong_ui] Error 1
#### failed to build some targets (05:24 (mm:ss)) ####

itexpert.120 said:
Hey
I have a common device source, which has linked my device to 3 more configuration files. I tried to change lineage to other rom in every possible location I can find but on building this error comes into action.
The error is same for every AOSP based rom
[email protected]:~/AEX$ mka aex -j4
vendor/aosp/config/bootanimation.mk:32: warning: Target bootanimation res is undefined, using generic bootanimation
Click to expand...
Click to collapse
Ok so what it looks like - did you sync only the device trees and any common ones and then use the "brunch" or "breakfast" command to download the rest of the repos. If so, then it's still pulled the repos from lineage (in all the dependency files, you can see where they come from)
If you did, try finding the AEX equivalent repo and replacing that in the .dependency file that it is referred to in.
If this is not what you did, please detail what you did to get your environment

[ROM][UNOFFICIAL] LineageOS 17.1 for Unihertz Atom L (20200828)

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