Related
Okay so I'm looking to modify the original filesystem code how would I go about this by searching a certain string I've seen on one of the warning dialogs ?
Sent from my Nexus 7 using Tapatalk HD
Well if you pulled the aosp codebase then your gonna just have to know where to look, but its pretty easy to find what your looking for
most everything is in frameworks/base and hardware folders
Sent from my Nexus 4 @1.72 GHz on Stock 4.2.2
If you are in *nix and the string is fairly unique, you could try a grep search. At the very least, doing a search like that should narrow down the location of the files you are looking for.
If you've got the aosp sources then resgrep should sort you out which is a command in the android "build environment" . after running . build/envsetup.sh type "hmm" , this gives you a list of all the "aosp" functions
Code:
Invoke ". build/envsetup.sh" from your shell to add the following functions to your environment:
- lunch: lunch <product_name>-<build_variant>
- tapas: tapas [<App1> <App2> ...] [arm|x86|mips] [eng|userdebug|user]
- croot: Changes directory to the top of the tree.
- m: Makes from the top of the tree.
- mm: Builds all of the modules in the current directory.
- mmm: Builds all of the modules in the supplied directories.
- cgrep: Greps on all local C/C++ files.
- jgrep: Greps on all local Java files.
- resgrep: Greps on all local res/*.xml files.
- godir: Go to the directory containing a file.
[B]Look at the source to view more functions. The complete list is:[/B]
addcompletions add_lunch_combo cgrep check_product check_variant choosecombo chooseproduct choosetype
choosevariant cproj croot findmakefile gdbclient gdbwrapper get_abs_build_var getbugreports get_build_var getlastscreenshot
getprebuilt getscreenshotpath getsdcardpath gettargetarch gettop godir hmm isviewserverstarted jgrep key_back key_home
key_menu lunch _lunch m mangrep mm mmm pid printconfig print_lunch_menu resgrep runhat runtest set_java_home
setpaths set_sequence_number set_stuff_for_environment settitle smoketest stacks startviewserver stopviewserver systemstack tapas tracedmdump
If find godir pretty useful for traversing the sources.
If you haven't got the aosp sources then androidxref.com is the place to look, they offer fully indexed sources of all the major releases of android and also the main branches of the android kernel.
hope that helps :good:
Test-Bump
AnyKernel3 -- Flashable Zip Template for Kernel Releases with Ramdisk Modifications
"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allowed a device-specific kernel zImage to be flashed over device-specific ROM and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this was that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. Enter AnyKernel2.
AnyKernel2 pushed the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the installation experience to their kernel. AnyKernel3 adds the power of topjohnwu's magiskboot for wider format support by default.
A script based on Galaxy Nexus (tuna) is included for reference. An example of ramdisk-only changes can be seen in my GN Synapse Injector repo. For an example that also modifies ROM and properly injects init.d support using busybox run-parts and sepolicy-inject see CosmicDan's CosmicTweaks project. For a multi-partition example and an example of how to handle a device which only has a ramdisk when rooted see my N5X/6P BLOD Workaround Injector. Other working AK2/3 examples for more recent devices may be found on eng.stk's blu_spark device repos under Releases.
Please see the linked posts here for instructions on enabling full AVBv1 (Pixel), AVBv1, A/B slot and/or system-as-root (SAR) or 2-stage init (2SI) device support, and further guidelines for system-as-root/2-stage init (/system/system in recovery) modifications in general.
Please also see the post here for important notes about the current state of AOSP vendor_boot v4 support and AVBv2 flag options.
Magisk root is automatically detected and retained by patching the new Image.*-dtb as Magisk would!
My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!
Source: https://github.com/osm0sis/AnyKernel3/
Download: https://github.com/osm0sis/AnyKernel3/archive/master.zip
Instructions
1) Place final kernel build product, e.g. Image.gz-dtb or zImage to name a couple, in the zip root (any separate dt, dtb, recovery_dtbo, dtbo and/or vendor_dlkm should also go here for devices that require custom ones, each will fallback to the original if not included)
2) Place any required ramdisk files in /ramdisk (/vendor_ramdisk for simple multi-partition vendor_boot v3 support) and module files in /modules (with the full path like /modules/system/lib/modules)
3) Place any required patch files (generally partial files which go with AK3 file editing commands) in /patch (/vendor_patch for simple multi-partition vendor_boot v3 support)
4) Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for any added ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
5) `zip -r9 UPDATE-AnyKernel3.zip * -x .git -x .github README.md *placeholder`
The LICENSE file must remain in the final zip to comply with licenses for binary redistribution and the license of the AK3 scripts.
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
[DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
Not required, but any tweaks you can't hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes. On newer devices Magisk allows these within /overlay.d - see examples.
It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK3 zip, the suffix -debugging may be added to the zip's filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
Staying Up-To-Date
Now that you've got a ready zip for your device, you might be wondering how to keep it up-to-date with the latest AnyKernel commits. AnyKernel2 and AnyKernel3 have been painstakingly developed to allow you to just drop in the latest update-binary and tools directory and have everything "just work" for beginners not overly git or script savvy, but the best practice way is as follows:
1) Fork my AnyKernel3 repo on GitHub
2) `git clone https://github.com/<yourname>/AnyKernel3`
3) `git remote add upstream https://github.com/osm0sis/AnyKernel3`
4) `git checkout -b <devicename>`
5) Set it up like your <devicename> zip (i.e. remove any folders you don't use like ramdisk or patch, delete README.md, and add your anykernel.sh and optionally your Image.*-dtb if you want it up there) then commit all those changes
6) `git push --set-upstream origin <devicename>`
7) `git checkout master` then repeat steps 4-6 for any other devices you support
Then you should be able to `git pull upstream master` from your master branch and either merge or cherry-pick the new AK3 commits into your device branches as needed.
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: All authors of the included binaries and the tools I used to port them over for their amazing work. koush for the original AnyKernel concept.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
Script Commands Reference
Everything to edit is self-contained in anykernel.sh. A quick-reference for the commands and properties included are as follows.
Properties / Variables
These are some values that will be read during the install process, allowing you to customize your installation, e.g. block= is a shell variable to specify the kernel/boot block partition that the dump_boot command method will copy and unpack.
Code:
kernel.string=KernelName by YourName @ xda-developers
do.devicecheck=1
do.modules=1
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=maguro
device.name2=toro
device.name3=toroplus
device.name4=tuna
supported.versions=6.0 - 7.1.2
supported.patchlevels=2019-07 -
block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
patch_vbmeta_flag=auto;
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device, ro.build.product, ro.product.vendor.device or ro.vendor.product.device from the build.prop files for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren't being used.
do.modules=1 will push the .ko contents of the modules directory to the same location relative to root (/) and apply correct permissions. On A/B devices this can only be done to the active slot.
do.systemless=1 (with do.modules=1) will instead push the full contents of the modules directory to create a simple "ak3-helper" Magisk module, allowing developers to effectively replace system files, including .ko files. If the current kernel is changed then the kernel helper module automatically removes itself to prevent conflicts.
do.cleanup=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) - this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) in case of installation abort.
supported.versions= will match against ro.build.version.release from the current ROM's build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 - 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.
supported.patchlevels= will match against ro.build.version.security_patch from the current ROM's build.prop. It can be set as a closed or open-ended range of dates in the format YYYY-MM, whitespace optional, e.g. 2019-04 - 2019-06, 2019-04 - or - 2019-06 where the last two examples show setting a minimum and maximum, respectively.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts any partition filename (from by-name), e.g. boot, recovery, or vendor_boot.
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack. Changing auto to gz, lzo, lzma, xz, bz2, lz4, or lz4-l (for lz4 legacy) instead forces the repack as that format, and using cpio or none will (attempt to) force the repack as uncompressed.
patch_vbmeta_flag=auto allows automatically using the default AVBv2 vbmeta flag on repack, and use the Magisk configuration (Canary 23016+). Set to 0 forces keeping whatever is in the original AVBv2 flags, and set to 1 forces patching the flag (only necessary on few devices).
customdd="<arguments>" may be added to allow specifying additional dd parameters for devices that need to hack their kernel directly into a large partition like mmcblk0, or force use of dd for flashing.
slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active.
no_block_display=1 may be added to disable output of the detected final used partition+slot path for zips which choose to include their own custom output instead.
Command Methods
Code:
ui_print "<text>" [...]
abort ["<text>" [...]]
contains <string> <substring>
file_getprop <file> <property>
set_perm <owner> <group> <mode> <file> [<file2> ...]
set_perm_recursive <owner> <group> <dir_mode> <file_mode> <dir> [<dir2> ...]
dump_boot
split_boot
unpack_ramdisk
backup_file <file>
restore_file <file>
replace_string <file> <if search string> <original string> <replacement string> <scope>
replace_section <file> <begin search string> <end search string> <replacement string>
remove_section <file> <begin search string> <end search string>
insert_line <file> <if search string> before|after <line match string> <inserted line>
replace_line <file> <line replace string> <replacement line> <scope>
remove_line <file> <line match string> <scope>
prepend_file <file> <if search string> <patch file>
insert_file <file> <if search string> before|after <line match string> <patch file>
append_file <file> <if search string> <patch file>
replace_file <file> <permissions> <patch file>
patch_fstab <fstab file> <mount match name> <fs match type> block|mount|fstype|options|flags <original string> <replacement string>
patch_cmdline <cmdline entry name> <replacement string>
patch_prop <prop file> <prop name> <new prop value>
patch_ueventd <ueventd file> <device node> <permissions> <chown> <chgrp>
repack_ramdisk
flash_boot
flash_generic <partition name>
write_boot
reset_ak [keep]
setup_ak
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"scope" may be specified as "global" to force all instances of the string/line targeted by replace_string, replace_line or remove_line to be replaced/removed accordingly. Omitted or set to anything else and it will perform the default first-match action.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_generic can be used to flash an image to the corresponding partition. It is automatically included for dtbo and vendor_dlkm in write_boot but can be called separately if using "OG AK" mode or creating a simple partition flashing only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain Image.gz, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.
Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= to the partition (without slot suffix) again, slot_select=inactive and ramdisk_compression= to the desired options for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "<text>" to write messages back to the recovery during the modification process, abort "<text>" to abort with optional message, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
Binary Inclusion
The AK3 repo includes current ARM builds of magiskboot, magiskpolicy, lptools_static and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and Flashlt packages, respectively, here:
https://forum.xda-developers.com/t/...kernel-ramdisk-win-android-linux-mac.2073775/ (Android Image Kitchen thread)
https://forum.xda-developers.com/t/...-and-ends-multiple-devices-platforms.2239421/ (Odds and Ends thread)
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
mkbootfs - for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)
flash_erase, nanddump, nandwrite - MTD block device support for devices where the dd command is not sufficient
dumpimage, mkimage - DENX U-Boot uImage format support
mboot - Intel OSIP Android image format support
unpackelf, mkbootimg - Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
elftool (with unpackelf) - Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
mkmtkhdr (with unpackelf) - MTK device boot image section headers support for Sony devices
futility + chromeos test keys directory - Google ChromeOS signature support
boot_signer-dexed.jar + avb keys directory - Google Android Verified Boot 1.0 (AVBv1) signature support
rkcrc - Rockchip KRNL ramdisk image support
Optionally moving ARM builds to tools/arm and putting x86 builds in tools/x86 will enable architecture detection for use with broad, device non-specific zips.
Boom . dibs on first :good:
You get 2 thank button presses fro me lol
Awesome work man as always
Good thing that this amazing work has it's own thread. Congrats buddy.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Thanks guys!
I figured it would be nice to get it out there and also have it as a "Help Desk" thread for kernel devs who have questions about implementation, etc. too. Some devices might require switching it from dd to MTD-Utils, so I can help with that. So on and so forth.
Once we get a few devs who know how to use it, it should be pretty easy to help others. I'm looking at you Smitty. No pressure.
I finished my thanks ... but as always a great job.
ak said:
I finished my thanks ... but as always a great job.
Click to expand...
Click to collapse
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
milojoseph said:
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
Click to expand...
Click to collapse
Haha I wrote "device-specific" in the OP to try and avoid this very confusion.
Since I answered this same question earlier tonight in my Odds and Ends thread I'll just paste it here:
caspboy said:
so now devs can use kernels from other devices with their roms?
Click to expand...
Click to collapse
osm0sis said:
No. That's crazy talk. :laugh:
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allows device-specific kernels to be flashed over device-specific ROMs and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, but in the old AnyKernel format there was no way to do this. Until now.
AnyKernel 2.0 makes it easy for kernel devs to use a number of simple command methods to automate the process of adding tweaks into a ROM's underlying ramdisk during the flashing process. :good:
Click to expand...
Click to collapse
Hopefully that helps. Basically exactly what's in the OP since that's where I edited it in from.
The only way I can explain it any further is with the very basics: that kernel boot.img files contain a zImage and a ramdisk. "AnyKernel Classic" just slaps the custom kernel zImage on top of the ROM's untouched default kernel boot.img ramdisk. AnyKernel 2.0 allows kernel devs to also modify the ramdisk to add anything required for kernel features in addition to the usual repacking it with the custom zImage and flashing it.
Great thread!! Best of lucky bro!!!
Sent from my Galaxy Nexus using xda app-developers app
AnyKernel will work on my phone now ? Thanks for enhancing awesome @osm0sis but DrRamdisk to the rest of you guys ?
wow,thats very cool,great work.
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
osm0sis said:
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
Click to expand...
Click to collapse
Hi osm0sis,
Have You update anykernel 2.0 to work with cyanogen11 roms ? Thanks for Your hard work !
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
osm0sis said:
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
Click to expand...
Click to collapse
Recently I had used Your method on Cyano11 but boot stopped on "Google".. new Cyano11 (that required ramdisk changes) had just come out and maybe anykernel 2.0 was not ready yet (I had just discovered your brillant work on It ! : Dita incrociate.
I'll try again ... if I have trouble going to ask you for help ...
I am already spreading the word : Cool:
Thanks man : Good:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
osm0sis said:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
Click to expand...
Click to collapse
Two kernels... My custom kernel (from cyanogenmod sources) and recently Fancy kernel (dirty-fancy)... now I want to try Fancy Kernel .. I need of a hibryd ramdisk for best final results and Your project is perfect for It !!! You're a genius !!!
Please, Can You link me Your dirty-V kernel re-pack by Anykernel 2.0 ? So I can follow It as an example. Thanks a lot...
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
osm0sis said:
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
Click to expand...
Click to collapse
Yes !
osm0sis ? If I want include init.rc original file by "real" ramdisk can I copy It as is into patch folder ?
It would go against the idea of AnyKernel to include the file like that. Remember, everything automatically comes from the original ramdisk, I just give you the ability to alter those files to add tweaks. :good:
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
Hello,
I'm trying to learn how to create a device tree from scratch without copying stuff from other device trees. So far I have gathered device info and I have a rough idea of the makefiles that are required (Android. mk, BoardConfig.mk, etc). I understand that shared libraries are extracted from the vendor image/partition and go into /vendor/manufacturer/device and then referenced in the device tree?
Vendor config files (.xml) are copied from the vendor image/partition to the device tree?
I have seen in many device trees there's some source code (.cpp, .h) files, where's this from and how do I know if I need it?
Also, is there a full list of possible variables for the makefiles? Right now all I can seem to do is look at other device trees and try to set similar variables. I'm thinking the variables should match the props from the stock rom?
Another thing I've been wondering is why, especially for treble devices, we need to copy vendor files at all? can't we just keep the stock vendor image and flash a custom system image? are shared vendor libraries referenced and required to build the system image?
Lastly, is there any reading material you would recommend that is up-to-date (for treble devices and android 10+)?
Hello everyone!
I want to use extra flag in iptables (connlabel), but in default make this extension is not available. I found in iptables/extentions/Android.bp file this code:
gensrcs {
name: "libext_srcs",
tool_files: ["filter_init"],
cmd: "$(location filter_init) $(in) > $(out)",
output_extension: "c",
srcs: ["libxt_*.c"],
exclude_srcs: [
// Exclude some modules that are problematic to compile (types/headers)
"libxt_TCPOPTSTRIP.c",
"libxt_connlabel.c",
"libxt_cgroup.c",
"libxt_dccp.c",
"libxt_ipvs.c",
],
So i delete "libxt_connlabel.c" from this list, and while compilation I have this error:
out/soong/.intermediates/external/iptables/extensions/libext_srcs/gen/gensrcs/external/iptables/extensions/libxt_connlabel.c:8:10: fatal error: 'libnetfilter_conntrack/libnetfilter_conntrack.h' file not found
#include <libnetfilter_conntrack/libnetfilter_conntrack.h>
I see this library in path: external/libnetfilter_conntrack/include/libnetfilter_conntrack/libnetfilter_conntrack.h but I don't know how to add this lib to Android.bp
Thanks for any help!
I think that is the wrong modification to make.
Instead you should undo that change and just enable these module(s) for your device's defconfig:
CONFIG_NF_CONNTRACK_LABELS=y
and also maybe:
CONFIG_NETFILTER_XT_MATCH_CONNLABEL=y
Here are examples for a random devices defconfigs that I found:
https://github.com/search?q=org:Lin...TRACK_LABELS=y"+filename:*defconfig&type=Code
Note that I have personally not tried building with these modules before and I also don't know what device kernel you are building on, so you'll need to experiment with the different combination of config changes above to see what works for your device kernel.
You can look at this Makefile in your particular device kernel's tree, to see what netfilter CONFIG_ flags are available for you to enable (do not modify this file, again only modify your device's defconfig to enable it):
net/netfilter/Makefile
For example:
android_kernel_moto_shamu/Makefile at lineage-17.0 · LineageOS/android_kernel_moto_shamu
Contribute to LineageOS/android_kernel_moto_shamu development by creating an account on GitHub.
github.com