Database Info

[Q] ndk-building does not link stdio properly?

I am working with some large open source projects and some smaller custom C code. I can successfully compile and link these using the ndk-build API even when linking against shared object files within the Android tree. I get functional shared object files and executables for the Android platform. However, it seems that when the applications are built as stand alone (meaning outside the Android source code tree using only ndk-build) the stdio functions do not operate properly. When the same code is placed under external within the Android source code tree and built with Android, the stdio functions work exactly as expected.
I have tried building with ndk r4 and r6, then we tried building with the ndk r4 from within the Android tree. (2.2.1)
the functions in question are
close() - hangs a process when the process is forked
fprintf() - nothing gets written
fopen() for write - the file does not get created as a new file
remove()
unlink()
etc.
I have not tested beyond these functions.
The question is why does the stand alone built code not function properly while the same code built within the Android tree executes properly?
Any insight would be greatly appreciated.
Thanks,
Adam

Edit your post and add a meaningfull thread title.

additional info
Seems in particular that close(0), close(1), and close(2) cause a process hang when fork() is used.
When built with Android code under the external directory, everything works as expected.

[KERNEL][DEV-ONLY][SGH-T959V/W] Kernel Cleanup [GingerBread][2013/12/17]

[INTRO]
Well, hello there stranger.
This is a development only thread. If you are having a problem building, installing, using the kernel or it's source code, please turn to the Q&A Thread.
If you found a bug and have a log from dmesg or logcat, or have a patch, this is where to comment on development activities.
I'm trying to keep this a short OP, because you all know the problems we've had in the past with this kernel, so @jeffsf and myself are going through the stock drop and cleaning out any unused code so we can easily port forward and possibly figure out aries kernel issues.
Currently, as you can see in the OP title, this is for GingerBread. I know, nothing terribly new. But that tag will change. Right now, it's in the cleanup phase. This OP will probably change a lot to keep up to date with the development conversations that will follow in this thread.
I've already started a bunch of work, but I'm always open to help.
[GOALS]
Clean out any code that is different from v2.6.35.7 that has nothing to do with SGS4G.
Clean up code that is different (inline) to use "#if defined" so that this platform could be disabled, and another platform could be enabled cleanly with Kconfig. (think about multiple phones in one source tree...)
Once code is cleaned up (section mismatches removed, warnings caused by code we've added, etc..) and tested, porting to newer kernel versions like 3.0.x and 3.4.x becomes much easier.
If you plan on helping out, I have a few rules:
This is a long term project. I'm looking at 3.4.x and 3.10.x android kernels. You won't find fancy bells and whistles here. As this project progresses, releases will be cut. At release points, other developers are welcome to fork and add features. I will start different branches for 'porting' and for 'features' to keep track of the two activities so we can keep moving forward.
Every commit must be tested. Make sure it boots, and area's you've affected work properly. No new build warnings or section mismatches.
Try to keep your commits targeted... An example of a non targeted commit was the v2.6.35.7 merge I made. I also cleaned up a few things that should have been done in separate commits. Oh well. The rest of the commits I made were exactly what I mean.
make it awesome, I think this device can keep working for a while and be up to date!
Try to use ./scripts/checkpatch.pl to check the changes you made to a file. Fix the errors and warnings, only on code you have changed. If it is a lint error/warning in code that is upstream code, leave it alone. We are not maintaining the kernel, we are only maintaining the changes we are making to it.
Either use 'git format-patch' to send me patches or fork the repo, make changes to your local fork, and open a pull request.
[PROGRESS]
I've cleaned out a ton of other platform cruft that has nothing to do with SGS4G, as seen here.
I tried to merge 2.6.35.14, but tfsr broke. So moving to MTD.
It would be nice to not have to rebuild a ROM over and over. Anyone feel up for making a GB MTD rom?
[BUILDING]
I use linux to build. Other platforms: Your Mileage May Vary!
Code:
sudo mkdir -p /build/galaxys4gmtd /opt
sudo chown -R $(id -un):$(id -gn) /build /opt
curl -O ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 http://sourceforge.net/projects/bhundven.u/files/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2/download
cd /opt
tar jxf ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
cd /build/galaxys4gmtd
git clone https://github.com/bhundven/android_kernel_samsung_galaxys4gmtd
git clone https://github.com/bhundven/android_initramfs_samsung_galaxys4g
cd android_kernel_samsung_galaxys4gmtd
git checkout -b android-samsung-2.6.35-galaxys4g-scrub-deux origin/android-samsung-2.6.35-galaxys4g-scrub-deux
./build.sh
the file in 'out/galaxys4g/arch/arm/boot/zImage' is the kernel image you'd flash to the kernel partition.
[BRANCHES]
I have a few guidelines for branching and branch names.
Name them what they are. Long branch names allow everyone to read it and know what it is.
A few of them are upstream like 'linux-2.6.35.7' is a branch of the tag 'v2.6.35.7'.
Ones that are named too similarly, like the aosp and cyanogen(aries) 2.6.35 samsung kernels get the name prepended for clarity:
Code:
cm-aries_android-samsung-2.6.35
aosp_android-samsung-2.6.35-gingerbread
As for working branches, I name it:
android-samsung-<version>-<board>-<branch topic>
Where version would be the full minor version, like 2.6.35 or 3.0. Not the full version including the stable version number.
Board is the board name. 'galaxys4g' is what we've always used for BML kernels, and 'galaxys4gmtd' for MTD kernels.
This kernel will eventually be MTD, hence the repository name.
The branch topic is something you could describe in <= 3 words.
Current branch topics:
scrub: no numbers, so the original addition of the sgs4g code.
upgrade: merged in the linux-2.6.35.7 branch (technically, the v2.6.35.7 tag in this case)
scrub-deux: After merging v2.6.35.7, there are a few rather large commits with the initial source drop and file permission fixes that make it hard to diff through commits. This branch was branched from tag v2.6.35.7 and had the difference of 'linux-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade' applied to HEAD. This allows us to start chopping up that one large patch into smaller commits that are more easily merged/rebased to other branches (for porting).
Future branches coming up will have to do with the results of cutting up the one patch. One for drivers (each driver), one for sound, one for architecture specific, etc.
Once things are broken down this way, a lot of code will have been cleaned up and as I said in the scrub-deux branch description, it will make merging, rebasing, and cherry-picking these changes for porting purpouses.
[RELEASES]
There are currently no planed releases.
Since it looks like I'll have to start moving to MTD sooner rather then later, I'm also looking at skipping ICS and JB, and going to KK.
As for testing the build, I'm using the Stock_KJ6_+_root-One-Click.jar
Let the rom settle after it boots up, and power it off. Heimdall flash the built zImage. TADA.
If you don't understand what I just said, don't forget to ask in the the Q&A Thread.
[SOURCE]
Source
Wiki
Issue Tracker

If you're interested in helping out, or just got here because you searched "flash kernel" or the like, I prefer heimdall to manage "raw" flashing. I find it to be very robust and also runs on Linux and Mac OS.
http://forum.xda-developers.com/showthread.php?t=755265
http://glassechidna.com.au/heimdall/
https://github.com/Benjamin-Dobell/Heimdall
This is not a one-click kind of thing (though you could use one of the one-click installers to get back to GB).
I'm a command-line guy for simple tasks, so I use (v1.3.x)
Code:
heimdall flash --kernel path/to/kernel/boot.img
Edit -- When I tried to flash on my Mac using v1.4.0 (ignoring @bhundven warnings in the next post), I found that I needed to match the returned PIT partition name to get it to work:
Code:
heimdall flash --KERNEL path/to/kernel/boot.img

Make sure for now that you only use the 1.3.1 version found here.

checkpatch.log
Attached to this post is the latest checkpatch.pl output of the files different from upstream.
Generated by:
Code:
for i in $(git diff --name-only linux-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade); do
echo -e "\nRunning checkpatch.pl on: ${i}\n";
./scripts/checkpatch.pl -f ${i};
done 2>&1 | tee out/checkpatch.log

[FAQ/HOWTO] An introduction to how-to-build a kernel for MT6589

Hi guys,
I was working on this since some time and here it is
Please read FAQ first
FAQ :
Can I compile a MT6589 kernel for every phone ?
As you know, a MT6589 kernel won't fit in every MT6589 smartphone because of specific configs/files in the kernel source tree.
So, if you compile my kernel which is expected to work on a Faea F2S don't expect it to work on a Acer Liquid E3 for example.
Conclusion : You have to get the kernel source for your phone​
How can I check my kernel source ?
Of course, this is not enough to see "source code for ZTE N986", you have to check if it's full or not and if it works.
Most people don't know what is working kernel source. You just have to read the GPL guidelines that every manufacturer have to complain with :
“ The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. ”
The part which has not to be included is the toolchain but there should reference to it (which toolchain to use)
For MT6589 kernel, the toolchains arm-eabi-4.6 and arm-linux-androideabi-4.6 should be used. (mtk used arm-linux-androideabi-4.6 for kernel but it should be arm-eabi-4.6)
So now you know which toolchain to grab and then for kernel source you have to check this minimal structure :
bionic
kernel
mediatek
build
config
custom
kernel
platform​README​
If I have kernel source, can I build it for my device ?
Erm... Sometimes the structure is here but the kernel source is messy... Why ?
Because you were not provided the matching source of the kernel used on your smartphone and the reasons are multiple (I won't give details).
So, the idea is to run a first build. If you get errors, then check the step above about toolchain and structure.
The next step for fixing errors is to play with source. Good luck for that.​
What are the benefits of a custom kernel for MT6589 ?
First big benefit is to introduce kitkat compatibility because there was an issue on android binder driver in mtk kernel source.
Next benefit is to be able to remove some stuff from mtk which is useless on user side and waste ressources (a lot of debug for example).
Others benefits will be in optimizations or new features (see frandom for example)​
HOWTO :
Build from my repo (specific devices supported) - It's not for compiling your kernel source but to understand how kernel build works​I explain how to build from my repo first because it can help you to understand how you should build kernel source
Prerequisites : A build environment (actually Ubuntu Saucy x64 with build-essentials, ccache, repo, java, perl v5.14+ and openssl) and I won't explain how to get one as there is multiple howto on the net.
For repo, the idea is to create a bin directory in your $HOME (usually /home/accountname/), copy repo binary inside it and then add this bin to $PATH var.
BE CAREFULL TO WHAT YOU DO WITH $PATH VAR ! I always see people doing :
Code:
export PATH=/home/foo/bin
this is erasing $PATH var, just check before and after with echo $PATH
So the idea is to introduce your path AFTER the actual $PATH var
This is easy...
Code:
export PATH=[COLOR="red"]$PATH:[/COLOR]/home/foo/bin
And of course, $PATH is reset once you close terminal and I won't explain how to set $PATH automatically.
Once you got this, everything should be working and it will be easy
Code:
mkdir workdir
cd workdir
repo init -u https://github.com/Dr-Shadow/android_kernel_mt6589_manifest.git -b master
repo sync
Then you should get this in your workdir :
kernel
manifest
mtk-tools
out
ramdisk
scripts
toolchain​Just do :
Code:
cd kernel
./certificates.sh
./build.sh
./certificates.sh is needed only once (it's for signing flashable zip and it will setup some keys for it, just reply to questions and don't add passphrase)
And of course, the build.sh contains most things you need to know on steps for building kernel (which commands to use) and you need to know how it works ​Build from your own kernel source​
I'm building the doc... I have to remind which vars need to be overriden

Reserved

Reserved #2

Thanks for making this thread brother it will help us to learn... Subscribed

Looking forward to the how-to to build with your own kernel source.

Dr-Shadow said:
Hi guys,
I was working on this since some time and here it is
Click to expand...
Click to collapse
Thank you Dr-Shadow! This is very cool. I'm going to try it out!

Great
It's always nice to see further development on MTK Based Devices.
Regards

I'll chip in and say thanks too. Finally getting around to trying to compile Alcatel's OneTouch Hero (aka TCL Y910) provided sources.

I might be in as well with A820, but I'm relatively new to Android and have only done porting of 4.1 and 4.2 so far.
Haven't built anything although I have some knowledge about the source code and SDK, which I've only used for reference purposes and the tools from it.
Will try to compile the stock kernel this weekend, but I'm not quite sure if something else is needed, even if the kernel source seems complete to me.
I'm a quick learner and have a lot of programming experience in other technologies, even thought I'm more of a front-end developer these days.

[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

Adding files to Android ROM source

Hello! I've just used phh's Treble Build script to sync and build a GSI ROM, but now I would like to add/modify some files in the source files, specifically in regards to the ROM apps (packages/apps/). I suspect that I cannot just drop the source files of the new apps in there without the build script complaining (uncommited changes in repo sync or something like that), so how can I add the files in there? And do I need to specifically tell the build script to compile the new files? Thank you!

"Android source code has apps under the path packages/apps/, likewise services are located under packages/services, etc.
To add an application to your compiled Android build, you need to
Make a new dir under packages/apps/ for your app, eg. MyNewApp
Add your app source code into that dir
To tell the build process about the app available to build and it's properties (here you have flags for src path, resource path, location to ship in system, shared libs, etc) Android.mk/Android.bp is used. You can refer to Android.mk from other apps under packages/apps/ to get an idea.
Blueprint or .bp is a new soong build system that is in process to replace Makefile-based system/Android.mk (src: AOSP)
Add 'MyNewApp' entry to 'PRODUCT_PACKAGES' flag under your target device tree makefile (device/<vendor>/<model>/) or if you want it to build globally into system, you can add the entry to 'PRODUCT_PACKAGES' under build/target/product/."