Related
So I set up a chain of scripts to build, package, and deploy CyanogenMod kang builds on Ubuntu 11.04 according to the guide in this thread: http://forum.xda-developers.com/showthread.php?t=1067519
Now that I can successfully build CyanogenMod, I'm wondering what the best (quickest, easiest, etc.) way is to cherry pick changes from the CyanogenMod code review which is found here: http://review.cyanogenmod.com/#q,statuspen,n,z
For example, if I wanted to allow the user to choose whether or not to show the "Hold" button in calls, I would need to pull this change: http://review.cyanogenmod.com/#change,6104. What would be the best way of doing this?
Thanks in advance for any help!
When I try to use the git cherry-pick command found on the commit page, I get this error: "fatal: You do not have a valid HEAD"
hmmm I would
Code:
cd android/system/packages/apps/Phone/
and then do
Code:
git pull http://review.cyanogenmod.com/p/CyanogenMod/android_packages_apps_Phone refs/changes/04/6104/1
but I'm pretty new on this too.
I've been building from source for a couple of weeks now and just finished my first kernel from source but I'm having problems pulling commits.
Whenever I try to pull or cherry-pick I get
Code:
fatal: Not a git repository (or any of the parent directories): .git
Were you actually able to pull the commit? I'm doing this from android/system. Should I be in a different folder?
Try this little tutorial. ^_~
http://forum.xda-developers.com/showpost.php?p=23527685&postcount=29
The important part that I was missing was to be in the correct directory based on the patch.
For instance
Code:
cyanogenmod dot com/p/CyanogenMod/android_packages_apps_Phone refs/changes/04/6104/1
would have to be in android/packages/apps/Phone
and
Code:
cyanogenmod dot com/p/CyanogenMod/android_frameworks_base refs/changes/29/11129/8 && git checkout FETCH_HEAD
would be in android/frameworks/base
Thanks for the help on this
Hi Folks
I wasn't sure where this should belong but as it is a bit of an Hack this forum is probably the most appropriate
Introduction
This short tutorial will show you how to patch the Android Build System to allow you to cross-compile Android AOSP host tools ( adb, fastboot etc ) for OSX using a linux based machine. This is something Google said was impossible or at the very least unsupported.
Assumptions
You have a linux based machine and working copy of the AOSP source tree.
You can/have successfully compile(d) a full Android Release from this tree.
A basic idea of how the Android Build System works is beneficial.
Getting Started
I've set-up a git repository which contains a binary copy of the OSX SDK 10.6 and the apple-darwin10-gcc cross compiler. So first things first. open a terminal and set the root of the AOSP sources tree to the current directory.
STAGE 1: Copy the OSX SDK
Step 1.
Clone the repo with the SDK and toolchain
Code:
git clone https://github.com/trevd/android_platform_build2.git build2
Step 2.
Create /Developer directory at your filesystem root, this is a known location for the SDKs
Code:
sudo mkdir /Developer
sudo chown $USER.$USER /Developer
Step 3.
Copy and unpack the SDK package
Code:
cp build2/osxsdks10.6.tar.gz /Developer
cd /Developer
tar -zxvf osxsdks10.6.tar.gz
rm osxsdks10.6.tar.gz
cd - # back to aosp root
STAGE 2 : Swapping the Toolchain
This is where the fun begins :laugh:
The Android Build system has the majority of the infrastructure in place already to build for OSX, the only problem is that you need OSX to build for OSX. However we can remedy that with a couple of dirty hacks :laugh:.
The prebuilts/gcc/darwin-x86 directory contains a toolchain compatible with osx ( mach-o binaries ). We are going to swap this for a linux compatible ( elf ) executables.
Step 4:
Copy and unpack the elf compatible darwin cross toolchain
Code:
cp build2/i686-apple-darwin-4.2.1.tar.gz prebuilts/gcc/linux-x86/host
cd prebuilts/gcc/linux-x86/host
tar -zxvf i686-apple-darwin-4.2.1.tar.gz
cd - # back to aosp root
Step 5:
Remove the mach-o binaries and symlink the elf binaries in it's place
Code:
cd prebuilts/gcc
rm -rf darwin-x86
ln -s linux-x86 darwin-x86
cd - # back to aosp root
Step 6:
We also need to replace the mach-o version of the ccache executable which live in the prebuilt/misc directory
Code:
cd prebuilts/misc
rm -rf darwin-x86
ln -s linux-x86 darwin-x86
cd - # back to aosp root
STAGE 3: Patching the build system .mk files
We need to patch a couple of files in the build directory namely the build/core/combo/HOST_darwin-x86.mk the main crux of this is swapping the ar tool for libtool so static libraries can be created without error.
Code:
patch -p1 < build2/build.patch
If the patch has been applied successfully you should see the following
Code:
patching file system/core/adb/Android.mk
patching file build/core/combo/HOST_darwin-x86.mk
patching file build/core/combo/select.mk
patching file build/core/envsetup.mk
patching file build/envsetup.sh
You are now ready to cross compile!! :good: ..... well not quite, but nearly.... here's why!
The Android Build System will attempt to build both the Target and Host files for most modules so I'd advise using a lunch option which already has a full target built for it or alternatively you can build the generic sdk using the following commands at the AOSP source tree root.
Code:
. build/envsetup.sh
lunch sdk-eng
make sdk
This will stop target dependency errors occurring when you build individual modules.
NOW we're ready to cross compile.
STAGE 4: Building Modules
At present module build is very much a piecemeal process. To build adb for example we need to build the dependencies first. This is not too onerous as most host modules have very few dependencies.
Building adb
adb has dependencies on the following libraries
Code:
external/zlib
external/openssl
system/core/liblog
system/core/libcutils
system/core/libzipfile
I've found the easiest way to compile the dependencies is to navigate to each directory in turn an use to "mm" build system command to compile the individual module. the commands I run to compile adb are as follows.
From AOSP Source Root
Code:
cd external/zlib
USE_DARWIN=true mm -j8
cd ../openssl
USE_DARWIN=true mm -j8
croot # go back to the AOSP root
cd system/core/liblog
USE_DARWIN=true mm -j8
cd ../libcutils
USE_DARWIN=true mm -j8
cd ../libzipfile/
USE_DARWIN=true mm -j8
cd ../adb
USE_DARWIN=true mm -j8
All being well you should now have and adb binary located at out/host/darwin-x86/bin/adb. running the file command on this binary should produce the following output
Code:
adb: Mach-O executable i386
Conclusion
Although this method is a little rough and ready, it should produce the desired results if you need to cross compile for OSX. The eventual goal would be to compile a full OSX Android SDK on linux in a similar manner to the way the windows-sdk is currently compiled. This requires more investigation as compiling the windows sdk on linux employs a little bit of trickery on the part of the build system.
Final Notes and FAQs:
Why can't I just type make <module> from the root?
Doing this triggers building of additional modules such as LLVM and clang which are to deployed out/host/darwin-x86/bin the build system then attempts to use binary later on. These are obviously built for the Mach-o architecture and as such are incompatible with the linux. This results in a build error which can and would be resolved by the above mentioned trickery ( see conclusion )
I use OSX binaries (along with Windows and my native Linux) in one of my projects. Thanks, I have always relied on finding compiled binaries elsewhere. Lack of an OSX aapt held up an update at one point.
One of those things that you don't really use until you need it, but I will try to remember to give it a shot. I don't have any doubt that it works.
mateorod said:
I use OSX binaries (along with Windows and my native Linux) in one of my projects. Thanks, I have always relied on finding compiled binaries elsewhere. Lack of an OSX aapt held up an update at one point.
One of those things that you don't really use until you need it, but I will try to remember to give it a shot. I don't have any doubt that it works.
Click to expand...
Click to collapse
Thanks. Yes this really is an edge case. Hopefully It will help some folks out.
Regarding aapt in particular.... It's perfectly possible to build aapt, however, we need to do some slight of hand with the clang and clang++ executables as libpng on which aapt depends uses these 2 binaries as part of it's build process.
Here's the build list and the clang trick if you want to try it some time.
Code:
build/libs/host
external/expat
external/zlib
system/core/liblog
system/core/libcutils
mkdir out/host/darwin-x86/bin
cp out/host/linux-x86/bin/clang out/host/darwin-x86/bin
cp out/host/linux-x86/bin/clang++ out/host/darwin-x86/bin
external/libpng
frameworks/base/libs/androidfw
frameworks/native/libs/utils
frameworks/base/tools/aapt
I started off with a clean out/host/darwin-x86 directory so I didn't miss any dependencies.
like I mentioned the clang "swap out" is something the make win_sdk option does automatically so with it a little more research I should be able to get the mac build to do the same but you'll have to "fill yer boots" with the ghetto method for now
For reference here's a link to the sdk building instructions http://tools.android.com/build which describes how to cross compile the windows sdk on linux ( in case anyone was wondering what the hell i'm on about)
My use case has come up
I will be cross-compiling for OSX today...specifically with aapt in mind. I will report back, but I fully expect it to work as described.
mateorod said:
My use case has come up
I will be cross-compiling for OSX today...specifically with aapt in mind. I will report back, but I fully expect it to work as described.
Click to expand...
Click to collapse
Cheers Man!
Hopefully no bitrot has crept in since april and now. I know I've changed my OS version since to Lubuntu 13.04, not like the OS version really matters any.
mateorod said:
but I fully expect it to work as described.
Click to expand...
Click to collapse
Then you Sir, are either Drunk or a Fool! LOL Keep expectations Quantum and only decided when the result is observed a'la Schrodinger Cat
okay...So I was trying to compile SlimRom (so as to get an OSX aapt binary with the SlimRom changes) and things did not necessarily go as planned. There were enough changes to the SlimRom android_build that your build/build.patch does not apply cleanly. I spent some time and tried to modify the patch so that it would work for both SlimRom, AOSP and probably others, but each android_build repo has some differences in surrounding the HOST_AR line, so commenting that just was not portable between flavors. Not cool.
Anyway, turns out that this method does not quite work out of the box for non-AOSP versions (not that you claimed that it did). I got some unfamiliar errors related to (I believe) some OSX toolchains. But in both times I tried this, I actually had to pretty immediately swap out of that flavor and so I was unable to do much debugging. (I keep all the flavors I build {CM, AOKP, SlimRom, PAC, PA, OpenPDroid, etc, etc, etc} all layered in one android/system/jellybean directory. It saves a ton of space, but only allows me to do one thing at a time.)
So the only feedback I have is nothing...I even formatted my hard drive in-between and forgot to put up a paste, so the errors are currently lost to history.
Things that I noticed, for better or worse
You recommend putting the SDKs in the root dir. I believe the documentation is recommending the Developer be placed in home (as per the SDK/ADT bundle docs).
You might want a
Code:
mv android_platform_build2 build2
line. I normally wouldn't bother, but it looks like you are trying to post a line-by-line guide.
I would put the recommendation that a full build be available to the out folder (or a built generic sdk) right at the top, since it is a preliminary step. I had to revert my handwritten changes, then build, then reapply the changes and rebuild since I thought it needed a clean out dir.
Did you have any trouble with git reverting the toolchain swap? On two separate machines, I had to go so far as to delete .repo/projects/prebuilts/gcc/* and prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6. It kept complaining of that the project in the .repo folder was a bad match. No amount of git trickery (which I am not terrible at) let me back out more easily.
I am willing to try again...but I have some other small things to attend to first. It is an admirable hack you have here sir. I will return to it soon and report back once more.
mateorod said:
okay...So I was trying to compile SlimRom (so as to get an OSX aapt binary with the SlimRom changes) and things did not necessarily go as planned. There were enough changes to the SlimRom android_build that your build/build.patch does not apply cleanly. I spent some time and tried to modify the patch so that it would work for both SlimRom, AOSP and probably others, but each android_build repo has some differences in surrounding the HOST_AR line, so commenting that just was not portable between flavors. Not cool.
Anyway, turns out that this method does not quite work out of the box for non-AOSP versions (not that you claimed that it did). I got some unfamiliar errors related to (I believe) some OSX toolchains. But in both times I tried this, I actually had to pretty immediately swap out of that flavor and so I was unable to do much debugging. (I keep all the flavors I build {CM, AOKP, SlimRom, PAC, PA, OpenPDroid, etc, etc, etc} all layered in one android/system/jellybean directory. It saves a ton of space, but only allows me to do one thing at a time.)
So the only feedback I have is nothing...I even formatted my hard drive in-between and forgot to put up a paste, so the errors are currently lost to history.
Things that I noticed, for better or worse
You recommend putting the SDKs in the root dir. I believe the documentation is recommending the Developer be placed in home (as per the SDK/ADT bundle docs).
You might want a
Code:
mv android_platform_build2 build2
line. I normally wouldn't bother, but it looks like you are trying to post a line-by-line guide.
I would put the recommendation that a full build be available to the out folder (or a built generic sdk) right at the top, since it is a preliminary step. I had to revert my handwritten changes, then build, then reapply the changes and rebuild since I thought it needed a clean out dir.
Did you have any trouble with git reverting the toolchain swap? On two separate machines, I had to go so far as to delete .repo/projects/prebuilts/gcc/* and prebuilts/gcc/darwin-x86/arm/arm-eabi-4.6. It kept complaining of that the project in the .repo folder was a bad match. No amount of git trickery (which I am not terrible at) let me back out more easily.
I am willing to try again...but I have some other small things to attend to first. It is an admirable hack you have here sir. I will return to it soon and report back once more.
Click to expand...
Click to collapse
Hi
Thanks for this, It sounds like you've suffered an exercise in frustration there. I wasn't aware that "SlimRom" had a different aapt ( just out of general ignorance and not having paid any attention )
SDK - My Tree last time I used this was /Developer directory in the root - I think It comes from what the toolchain is expecting, I just gave it what it wants
mv android_platform_build2 build2 - Yep I did mean that it's the git clone line which wants changing
Code:
git clone https://github.com/trevd/android_platform_build2.git build2
SDK Recommendation - I shall move that to the top, even though it is already in there, It should probably be highlighted better and possible it's own "Stage"
Reverting the toolchain - Ahh , It appears I work slightly different from most in this respect. I have a general mistrust of SCM's ( I lost too much code on too many different SCM's, Probably through my own inability to use them correctly but ) what I do to revert to change is
Code:
cd prebuilts/gcc/darwin-x86/host/
rm -rf i686-apple-darwin-4.2.1
repo sync i686-apple-darwin-4.2.1
You can do this "trick" on any project in the source tree it's only on rare occasions where I screwed up badly that I have to delete anything in .repo/projects but I also have my distro in their own individual directories with there own full git trees, which is a massive waste of space and has a ton of redundancy due to the AOSP repositories being mirror by every single one but switching between them is a lot easier
If SlimRom's changes are localized to aapt, I'd be more inclined to drop it into the AOSP build and try that... If you have a link to slimrom's frameworks/base repository I'll grab it and try it myself.
On a final note there's a "full version" of the HOST_darwin make file in the build2/core/combo directory the changes to envsetup.mk and select.mk are minimal and can easily be applied manually. You don't need to patch the adb makefile if your not building it.
Again Thanks for the feedback
This is a general open source linux development thread!
Android's kernel is a derivative of linux's kernel. Its good to know how to build both of these kernels. You might be already familiar with building kernels for various devices from sources. So I have made a new thread for guiding people on how to compile linux kernel from source (example taken as ubuntu kernel).
Requirements:
Any linux os x64 bit(example here: ubuntu 14.04)
Git (sudo apt-get install git)
Minimum of 4GB RAM and some reasonable linux-swap
To get the currently running kernel image, type the following:
Code:
apt-get source linux-image-$(uname -r)
Now we need to obtain Ubuntu Kernel Sources from its repositories. Make a new directory and inside it, initialise the git and clone the repository.
Code:
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-<release>.git
<release> : Type in the required source. It can be lucid, precise, trusty, utopic etc.
Setting up the build environment. There are lots of tools and packages that are very much essential for building a kernel. These tools can be downloaded as a whole bundle and can be installed easily. Here's the code to set it up:
Code:
sudo apt-get build-dep linux-image-$(uname -r)
NOTE: The above comand can be executed only after you obtain the currently running kernel image. I have already given the code to obtain it above.
Now, change directory to the root of the kernel and type the following:
Code:
chmod -R a+x *
The above code will set the required permissions for building and executing the kernel.
Now, run these two commands:
Code:
fakeroot debian/rules clean
fakeroot debian/rules editconfigs
The first command cleans up the code automatically.
The slightly tricky part is with the second line of the code. When you execute it, you will have to edit a series of menuconfigs. To make changes to the configuration file we need to edit the configuration file. The kernel developers have created a script to edit kernel configurations which has to be called through the debian/rules makefile, unfortunately you will have to go through all the flavors for this script to work properly. The script will ask you if you want to edit the particular configuration. You should not make changes to any of the configurations until you see your wanted flavour configuration
We have now covered about 70% of progress. The rest is building the kernel and testing it.
Building the kernel is quite easy. Change your working directory to the root of the kernel source tree and then type the following commands:
Code:
fakeroot debian/rules clean
fakeroot debian/rules binary-headers binary-generic
If the build is successful, a set of three .deb binary package files will be produced in the directory above the build root directory. For example after building a kernel with version "3.13.-0.35" on an amd64 system, these three .deb packages would be produced:
Code:
cd ..
ls *.deb
linux-headers-3.13.0-35_3.13.0-35.37_all.deb
linux-headers-3.13.0-35-generic_3.13.0-35.37_amd64.deb
linux-image-3.13.0-35-generic_3.13.0-35.37_amd64.deb
Testing the new kernel
Install the three-package set (on your build system, or on a different target system) with dpkg -i and then reboot:
Code:
sudo dpkg -i linux*3.13.0-35.37*.deb
sudo reboot
Guys, I hope I have made an easy tutorial. You are always welcome to ask doubts (even on PM). Thank You.
Specific Hardware/Architecture
Creating a new config
I’ll be using the method of creating a new flavour, this adds a bit more work but this way you can always compile the original kernels.
We’ll use the generic flavour as the base for our own flavour being i7, this extension needs to be in small caps.
Code:
cp debian.master/config/amd64/config.flavour.generic debian.master/config/amd64/config.flavour.i7
fakeroot debian/rules clean
debian/rules updateconfigs
To make changes to the configuration file we need to edit the configuration file. The kernel developers have created a script to edit kernel configurations which has to be called through the debian/rules makefile, unfortunately you will have to go through all the flavours for this script to work properly.
Code:
debian/rules editconfigs
The script will ask you if you want to edit the particular configuration. You should not make changes to any of the configurations until you see the i7 configuration
Code:
Do you want to edit config: amd64/config.flavour.i7? [Y/n]
Make your changes, save the configuration and then keep going until the script ends.
When you’re done, make a backup of the config flavor file.
Code:
cp debian.master/config/amd64/config.flavour.i7 ../.
Now we need to clean up the git tree in order to get ready for compilation.
Code:
git reset --hard
git clean -df
Getting ready for compilation
Because we are going to be creating a new flavour based on a existing flavour (generic in my case) we need to create some extra files. During compilation the process checks the previous release for some settings, as we’re creating a local flavour it doesn’t exist in the source, so we’re creating it.
To see the previous release we use:
Code:
ls debian.master/abi
cp debian.master/abi/3.0.0-12.20/amd64/generic debian.master/abi/3.0.0-12.20/amd64/i7
cp debian.master/abi/3.0.0-12.20/amd64/generic.modules debian.master/abi/3.0.0-12.20/amd64/i7.modules
Copy our flavored configuration file back.
Code:
cp ../config.flavour.i7 debian.master/config/amd64/
We need to edit some files:
File: debian.master/etc/getabis
Search for the line:
Code:
getall amd64 generic server virtual
Change it in:
Code:
getall amd64 generic server virtual i7
File: debian.master/rules.d/amd64.mk
Search for the line:
Code:
flavours = generic server virtual
Change it in:
Code:
flavours = generic server virtual i7
File: debian.master/control.d/vars.i7
This files does not exist and in order to make the compilation process aware of our own flavor we want to compile we need to create it.
Code:
cp debian.master/control.d/vars.generic debian.master/control.d/vars.i7
You can edit the file and make it your own.
Code:
arch="i386 amd64"
supported="i7 Processor"
target="Geared toward i7 desktop systems."
desc="x86/x86_64"
bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1)"
provides="kvm-api-4, redhat-cluster-modules, ivtv-modules, ndiswrapper-modules-1.9"
We need to commit our changes in the git repository.
Code:
git add .
git commit -a -m "i7 Modifications"
The text after -m is the message you add to your commit.
Compilation
It’s finally time for compiling, to keep our newly created branch in pristine condition we will do the compilation in a separate branch. We keep our branch clean as this will help later on when we want to update our new branch to a newer kernel.
Code:
git checkout -b work
fakeroot debian/rules clean
All the packages will be created in the directory /d1/development/kernel/ubuntu/oneiric
Create independent packages:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-indep
The above statement will create the following deb files:
Code:
linux-doc_3.0.0-13.21_all.deb
linux-headers-3.0.0-13_3.0.0-13.21_all.deb
linux-source-3.0.0_3.0.0-13.21_all.deb
linux-tools-common_3.0.0-13.21_all.deb
Create the tools package:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-perarch
The above statement will create the following deb file:
Code:
linux-tools-3.0.0-13_3.0.0-13.21_amd64.deb
Create the flavour depended files:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-i7
The above statement will create the following deb files:
Code:
linux-headers-3.0.0-13-i7_3.0.0-13.21_amd64.deb
linux-image-3.0.0-13-i7_3.0.0-13.21_amd64.deb
Installation
After the compilation is finished we’ll have the above packages in the parent directory.
To install the files
Code:
cd ..
sudo dpkg -i linux-headers-3.0.0-13-i7_3.0.0-13.21_amd64.deb linux-headers-3.0.0-13_3.0.0-13.21_all.deb linux-image-3.0.0-13-i7_3.0.0-13.21_amd64.deb
Check your bootloader if the newly installed Ubuntu kernel is the default one, for grub check the file /boot/grub/menu.lst or if you run grub2 check /boot/grub/grub.cfg
thx for your info
nice job mate..!! :good:
now i'm gonna try this..!!
Nice ,i can't say anything
faizauthar12 said:
Nice ,i can't say anything
Click to expand...
Click to collapse
Thank you for the great guide!!!
Nice thread. I'll try it at home
Thanks
Enviado de meu Moto G usando Tapatalk
Thx for the guide
tra_dax
Now tested up to downloading AOSP and make toolbox you should be all set
Please give thanks to this thread: https://forum.xda-developers.com/newreply.php?do=newreply&p=43622764
Warning: I hacked my way through this stuff a few weeks ago I am not an expert!
How to compile Android Open Source Code modules
I don't compile C code on Windows machines I have no idea about that.
Notice
This guide is a quick and dirty how to make a module. It will not cover finalizing setting up the source codes for your device. It is only my goal to enable you to compile binaries such as grep, toolbox, dumpstate, dalvikvm, jack and etc.
===>] Setup Ubuntu 64bit [<===Unplug that Windows drive, plug in a fresh hard drive and install Ubuntu latest/greatest. Ignore the recommendation to downgrade gnu make!, for now.
Open a terminal and issue these commands (warning ppa repository for OpenJDK 7 is said to have a security issue?, isn't being updated?.. whatevs it works)
Code:
sudo apt-get update
sudo apt-get upgrade
sudo add-apt-repository ppa:openjdk-r/ppa
sudo apt-get install openjdk-7-jdk
sudo apt-get install openjdk-8-jdk
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 libbz2-1.0:i386
sudo apt-get install git ccache automake lzop bison gperf build-essential zip curl zlib1g-dev zlib1g-dev:i386 g++-multilib python-networkx libxml2-utils bzip2 libbz2-dev libbz2-1.0 libghc-bzlib-dev squashfs-tools pngcrush schedtool dpkg-dev liblz4-tool make optipng
(choose Java 1.7 in the following way)
Code:
sudo update-alternatives --config java
(let me know if I missed anything please)
"Tried the Android SDK only it is missing too many things we need as a developer"
===>] Setup Android Studio SDK & NDK [<===Installation Paths:
*** I install to /home/username/Android and /home/username/Android/Sdk and /home/username/Android/Sdk/ndk-bundle ***
NOTE: from here forward username will == droidvoider
Note: Android Studio IDE isn't necessary only the SDK & NDK are needed to compile AOSP.
Install Android Studio Proper: (don't worry about setting up paths we will cover that, just install it)
https://developer.android.com/studio/install.html
or
SDK Only:
Typically we install these things manually by creating the directory then just unzipping the files there.
https://developer.android.com/studio/index.html#linux-bundle (scroll down for sdk only)
Code:
mkdir /home/droidvoider/Android
mkdir /home/droidvoider/Android/Sdk
(then unzip the sdk zip to that directory. I recommend the file explorer copy/paste right click uncompress and done.)
https://dl.google.com/android/repository/tools_r25.2.3-linux.zip
Install NDK through the SDK Manger:
(from terminal 'studio.sh' and then configure, and then sdk manger --- if this is hard to figure out tell me I will elaborate)
or
Manually Install Native Development Kit -- 'c programming support'
Download the Native Development Kit from Google: https://developer.android.com/ndk/downloads/index.html
Code:
mkdir /home/droidvoider/Android/Sdk/ndk-bundle
Then just unzip the ndk files into the directory we created above.
===>] Setup your toolchain [<===** This example is arm64-v8a aarch64 **
1. Navigate to /home/droidvoider/Android/Sdk/ndk-bundle/build/tools and then open a terminal "right click open area"
2. mkdir /home/droidvoider/toolchains
3. ./make_standalone_toolchain.py --arch arm64 --api 23 --stl=libc++ --install-dir /home/mm/toolchains/aarch64-linux-android-4.9
4. cd /home/droidvoider
5. gedit .bashrc and morph this in at the bottom.. (AND edit or replace the existing PATH variable)
DON'T just PASTE IN *my* $PATH export!! I included my entire path statements to show you.
Code:
export PATH=$PATH:/usr/local/android-studio/bin:/home/droidvoider/Android/Sdk/platform-tools:/home/droidvoider/Android/Sdk/ndk-bundle:/home/droidvoider/Android/Sdk/tools
I feel this is human readable, for example change Android_Build_Out to be on your desktop instead if you want.
Code:
export PATH=$PATH:/home/droidvoider/toolchains/aarch64-linux-android-4.9
export NDK=/home/droidvoider/Android/Sdk/ndk-bundle
export SYSROOT=$NDK/platforms/android-23/arch-arm64
export TARGET=aarch64-linux-android
export HOST=$TARGET
export BUILD=x86_64-linux
export ANDROID_NDK_BIN=/home/droidvoider/toolchains/aarch64-linux-android-4.9/bin
export CC=$ANDROID_NDK_BIN/aarch64-linux-android-gcc-4.9
export CPP=$ANDROID_NDK_BIN/aarch64-linux-android-g++
export AR=$ANDROID_NDK_BIN/aarch64-linux-android-ar
export OUT_DIR_COMMON_BASE=/home/droidvoider/Android_Build_Out
Note: You might want to setup an alternate toolchain also but this is all of the puzzle pieces.
===>] Google's version of this How To -- Just for reference [<===https://source.android.com/source/requirements.html
https://source.android.com/source/initializing.html
===>] Install the repo tool [<===https://source.android.com/source/downloading.html
(don't type repo init or repo sync --- I will be taking back over from there on the next page)
Added Repair Notes -- Not part of the install!
Have you accidentally installed or removed something you shouldn't have? (welcome to development, here try this before reinstall)
sudo apt-get clean
sudo apt-get update
sudo apt-get install -f
sudo dpkg -a --configure
sudo apt-get dist-upgrade
sudo apt-get install -f
sudo dpkg -a --configure
Selecting the correct AOSP branch and downloading it.
Tested up to downloading AOSP and make toolbox -- you should be all set
===>] Match your build number to it's AOSP sources [<===preface: You can get this from your device if you're on the same build id as your the available source code from your vendor for your device. Otherwise you need to open the AP file from the firmware that matches those available sources to extract the system.img, to extract build.prop. I explain how to open a system.img file below under retrieving your hardware drivers. build.prop is in the main directory of system.img
(Many times the build number is the same. For me I believe all of MM builds are using this number.)
Assumes sources match current device, worked out true in my case
1. Plug in your device and get it connected. (DEVELOPER OPTIONS|USB DEBUGGING) and select allow on device
2. Retrieve the build number that matches the available sources for your device.
From your ubuntu terminal retrieve the build id using this command:
Code:
adb shell getprop | grep 'ro.build.id'
Yields something similar to this: [ro.build.id]: [MMB29K]
3. Match it up to the Nexus build numbers (This info is for AT&T Note 5 Marshmallow MMB29K, get your specific build number!)
https://source.android.com/source/build-numbers.html#source-code-tags-and-builds
MMB29K android-6.0.1_r1 Marshmallow Nexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
===>] Bring down a specific AOSP source branch [<===
4. Make a directory for the source code.
Code:
mkdir /home/droidvoider/Desktop/AOSP_Android_6.01_r1
5.
Code:
cd /home/droidvoider/Desktop/AOSP_Android_6.01_r1
6. Bring down the sources, this one is approximately 13 gigabytes
Code:
repo init --depth=1 -u https://android.googlesource.com/platform/manifest -b android-6.0.1_r1
repo sync
===>] I'm not sure the rest of this is needed [<===For compiling toolbox the remainder wasn't needed.. But I have a large list of things to do so I can't test each item. If you can't compile a specific module continue reading.
===>] Merge Vendor sources & AOSP sources [<===
7. Download the available sources for your device. In this example I downloaded PE6 Marshmallow sources for AT&T Note 5:
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-N920A
8. Read the readme file from the sources platform zip to understand how to merge them into the AOSP sources. For the 2 Samsungs I've worked with the idea is to replace any directory that already exists. But if there is just one file such as core.mk only replace the one file. Then edit the .mk files as described in your readme. (and/or take info from cyanogen/lineagos) -- <I can help more, ask>
note: you probably don't need to take the configs from LineageOS and put them into your .mk files. However, if you do need to get more configs then you should get a big fat message when you type make 'modulename'. At first only edit .mk files as described by vendor device source readme file.
===>] Merge in Hardware drivers and etc [<===possibly unnecessary depends what you're doing
9. Obtain a copy of the firmware for your device that matches the version of the source code you are able to download from your vendor.
for me that was Build Number: MMB29K.N920AUCU2BPE6 but your mileage will almost certainly vary!
10. Download https://github.com/anestisb/android-simg2img
11. Unzip it right in your download folder, open the folder and then 'open in terminal'
12. Make it and then move it a directory in your path. Warning: My command puts in in the Ubuntu default /bin folder.
Code:
make
sudo mv append2simg img2simg simg2img simg2simg simg_dump.py /bin
13. Uncompress the AP file from the matching firmware and extract the system.img into it's own directory
then select that folder, right click, open in terminal
Code:
simg2img system.img sys.raw
mkdir sys
sudo mount -t ext4 -o loop sys.raw sys/
14. A drive mounted, look on your task bar it should've wiggled too. Copy the etc and vendor folders into the main folder of the sources we are merging
===>] Listing and building modules [<===Navigate to the folder where you download the sources "/home/droidvoider/Desktop/AOSP_Android_6.01_r1" and open in terminal.
Code:
make modules -- list the available modules
make <module name> -- builds a specific module
example: make dumpstate
description: Will build everything needed for dumpstate and place it in the folder we specified in our export (above step). The final build line will read install and detail the final output folder
Example successful output:
[CODE]
Install: /home/droidvoider/Android_Build_Out/Android_6.01_r1/target/product/generic/system/bin/dumpstate
===>] Android Build System, basic intro [<===Notice: I built this how to to answer the same question from 3 people regarding working with toolbox and the dirtycow exploit. So I decided to give a direct example of using toolbox.c from farm-root
#ifdef
Our makefile is Android.mk and that's where we link things together. If you look at the Android.mk file for farm-root you will notice bridge.c is used 3 different times called different 'module' names. bridge_pull, bridge_push, bridge_pull_boot. Each of these will be binaries of those names.
Inside bridge.c you will see #ifdef FARM_PULL and then you will see #else and further you will see #endif which you may have noticed matches inside the Android.mk file for the bridge modules -DFARM_PULL -DFARM_BOOT <== Notice the double define on bridge_pull_boot
toolbox.c
toolbox.c is going to be the same way. You will need to copy shared.h and shared.c into the directory where toolbox.c resides. Then edit the Android.mk, in our example:
1. Navigate to this directory and open: system/core/toolbox/Android.mk
2. CTRL + F and search for "LOCAL_MODULE := toolbox"
3. Add: LOCAL_CFLAGS += -DFARM_PULL -DFARM_BOOT (in this example add one, both or even new ones you created)
4. Navigate to the main directory of the sources, you should see a Makefile and a build_64bit.sh
5. from terminal: make toolbox
Note: I think from here you can Google it out in a few minutes if that is not the case please let me know.
Working with C cross platformUbuntu is Linux based just like Android and this makes testing blocks of code extremely easy. You of course can't use Android headers and in some rare cases you can't test the code on Ubuntu at all but in most cases you can. When I want to design something for Android I open gedit and save it as a .c file. Then I compile it using gcc -o mycode mycode.c There's plenty of examples on using gcc with linux but just understand you can do it all. Then before too much work test it on Android. (helpful commands at end of post)
My advice really is to build out your small blocks of code on your linux box but then paste them into your Android program folder, edit your Android.mk, add it to your Makefile including your 'push' section so that you can simply type make push to test it.
I am in fact trying to encourage you to learn C and not so much trying to encourage you to hack things. But I know that interest/passion is what teaches, not my words and not someone else's curriculum. So in that spirit I will do my best to give examples to help you with 'whatever' it is you are passionate about. Let me know what's missing.
Don't forget to compile for Android first
Before you can test your code you will have compiled it using the cross compiler for Android. ndk-build, or the correct gcc cross compiler. (Personally I put the .c file into a directory with Android.mk and a Makefile then just type make to build it to Android)
see examples section I will add a couple examples.
Android Developer Bridge -- a developers tool
adb is included with the Android SDK along with some other tools. Some of those tools are fastboot for unlocking bootloaders and another way of flashing. There is monitor which is a cool tool for remotely viewing processes, logcat, memory dumps and etc.
But pointedly what we will use the most is simply adb.
Using adb to test your code on locked down Android systems
Shell has fairly high privileges, you may not be aware but you can execute binaries and bash scripts. We use /data/local/tmp/ for these things. You can create a directory, add or remove files, execute your binaries and even execute shell scripts using sh script.sh
ndk-build places the binary in libs/(arch type) .. For a quick test you can just open a terminal in that directory then:
Code:
adb push mybinary /data/local/tmp/
adb shell
cd data/local/tmp
chmod 777 mybinary
./mybinary
Added:
Examples of basic make files for Android.
happy coding
If you get an errorPlease reissue the command but pipe the output to a file.
make toolbox > /home/droidvoider/Desktop/build_toolbox-output.txt
zip that up with your source code, including your customized header files and attach it to this thread.
puzzles are fun but I like all the pieces
droidvoider said:
Tested up to downloading AOSP and make toolbox -- you should be all set
===>] Match your build number to it's AOSP sources [<===preface: You can get this from your device if you're on the same build id as your the available source code from your vendor for your device. Otherwise you need to open the AP file from the firmware that matches those available sources to extract the system.img, to extract build.prop. I explain how to open a system.img file below under retrieving your hardware drivers. build.prop is in the main directory of system.img
(Many times the build number is the same. For me I believe all of MM builds are using this number.)
Assumes sources match current device, worked out true in my case
1. Plug in your device and get it connected. (DEVELOPER OPTIONS|USB DEBUGGING) and select allow on device
2. Retrieve the build number that matches the available sources for your device.
From your ubuntu terminal retrieve the build id using this command:
Code:
adb shell getprop | grep 'ro.build.id'
Yields something similar to this: [ro.build.id]: [MMB29K]
3. Match it up to the Nexus build numbers (This info is for AT&T Note 5 Marshmallow MMB29K, get your specific build number!)
https://source.android.com/source/build-numbers.html#source-code-tags-and-builds
MMB29K android-6.0.1_r1 Marshmallow Nexus 5, Nexus 5X, Nexus 6, Nexus 7 (flo/deb), Nexus 9 (volantis/volantisg)
===>] Bring down a specific AOSP source branch [<===
4. Make a directory for the source code.
Code:
mkdir /home/droidvoider/Desktop/AOSP_Android_6.01_r1
5.
Code:
cd /home/droidvoider/Desktop/AOSP_Android_6.01_r1
6. Bring down the sources, this one is approximately 13 gigabytes
Code:
repo init --depth=1 -u https://android.googlesource.com/platform/manifest -b android-6.0.1_r1
repo sync
===>] I'm not sure the rest of this is needed [<===For compiling toolbox the remainder wasn't needed.. But I have a large list of things to do so I can't test each item. If you can't compile a specific module continue reading.
===>] Merge Vendor sources & AOSP sources [<===
7. Download the available sources for your device. In this example I downloaded PE6 Marshmallow sources for AT&T Note 5:
http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=SM-N920A
8. Read the readme file from the sources platform zip to understand how to merge them into the AOSP sources. For the 2 Samsungs I've worked with the idea is to replace any directory that already exists. But if there is just one file such as core.mk only replace the one file. Then edit the .mk files as described in your readme. (and/or take info from cyanogen/lineagos) -- <I can help more, ask>
note: you probably don't need to take the configs from LineageOS and put them into your .mk files. However, if you do need to get more configs then you should get a big fat message when you type make 'modulename'. At first only edit .mk files as described by vendor device source readme file.
===>] Merge in Hardware drivers and etc [<===possibly unnecessary depends what you're doing
9. Obtain a copy of the firmware for your device that matches the version of the source code you are able to download from your vendor.
for me that was Build Number: MMB29K.N920AUCU2BPE6 but your mileage will almost certainly vary!
10. Download https://github.com/anestisb/android-simg2img
11. Unzip it right in your download folder, open the folder and then 'open in terminal'
12. Make it and then move it a directory in your path. Warning: My command puts in in the Ubuntu default /bin folder.
Code:
make
sudo mv append2simg img2simg simg2img simg2simg simg_dump.py /bin
13. Uncompress the AP file from the matching firmware and extract the system.img into it's own directory
then select that folder, right click, open in terminal
Code:
simg2img system.img sys.raw
mkdir sys
sudo mount -t ext4 -o loop sys.raw sys/
14. A drive mounted, look on your task bar it should've wiggled too. Copy the etc and vendor folders into the main folder of the sources we are merging
Click to expand...
Click to collapse
And where is exactly the main folder? Sorry, Im just confused
DigitalDoraemon said:
And where is exactly the main folder? Sorry, Im just confused
Click to expand...
Click to collapse
it's no problem this stuff isn't easy to just figure out on your own. remember to substitute droidvoider for your ubuntu user name
In this example my sources are on my desktop in a folder named Android_6.01_r1
Sources for toolbox for example:
/home/droidvoider/Desktop/Android_6.01_r1/system/core/toolbox/<sources will be here including Android.mk>
Script for modules, including toolbox
/home/droidvoider/Desktop/Android_6.01_r1/Makefile <--- this is our modules script, if you will
<open a terminal in the above folder then use that Makefile like so>
make toolbox <---- this will compile only what is needed to compile the module 'toolbox' (this takes a minute)
Out export folder we decided in ./home/droidvoider/bashrc
/home/droidvoider/Android_Build_Out/Android_6.01_r1/target/product/generic/system/bin
Anybody, please compile grep utility for arm and x86... Minimum Platform Version Android 4.0.3, API Level - 15
Thanks
Great & useful .
Hello.
Been working on how to get a device kernel from source for the Mi note 10 pro (Mi CC9 Pro). I have gotten up to the point where it builds but fails due to dts folder is not found.
I need an example of what goes in DTC_EXT=
All I see on the net is DTC_EXT=dtc
Please help.
I use the kbuild/clang system that has a config that I can run.
I have CC, aosp toolchain, build-tools, qcom 8.0 llvm as real_cc. All linked, the only thing that fails is the dts files not being found
this is the issue i have
find: ‘arch/arm64/boot/dts/’: No such file or directory
terminal below
Spoiler: Terminal
Setting up for build
+ cd xsource
+ make CC=/home/avm/android/xkernel/prebuilts-master/clang/host/linux-x86/clang-r353983c/bin/clang HOSTCC=/home/avm/android/xkernel/prebuilts-master/clang/host/linux-x86/clang-r353983c/bin/clang O=/home/avm/android/xkernel/out/android-4.14/xsource mrproper
make[1]: Entering directory '/home/avm/android/xkernel/out/android-4.14/xsource'
find: ‘arch/arm64/boot/dts/’: No such file or directory
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN .config
Used config
Spoiler: Build config
ARCH=arm64
SUBARCH=arm64
BRANCH=K4.14Q
CLANG_TRIPLE=aarch64-linux-gnu-
CROSS_COMPILE=~/android/xkernel/tsource/toolchains/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
CROSS_COMPILE_ARM32=~/android/xkernel/tsource/toolchains/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-
KBUILD_DEFCONFIG=~/android/xkernel/tsource/arch/arm64/configs/tucana_user_defconfig
DEFCONFIG=tucana_user_defconfig
POST_DEFCONFIG_CMDS=""
DTC_EXT=dtc
DTC_PREBUILTS_BIN=/scripts/dtc
KBUILD_OUTPUT=out
HOSTCC=gcc
CC=clang
AS=clang
AR=ar
CLANG_PREBUILT_BIN=/toolchains/clang/host/linux-x86/clang-r353983c/bin
BUILDTOOLS_PREBUILT_BIN=/toolchains/build-tools/linux-x86/bin
FILES="
arch/arm64/boot/Image.gz
vmlinux
System.map
"
Found out it has something to do with the arch folder itself.
I replace it with the arch folder in the AOSP-kernel folder and it does not show up saying its not found.
Still crashing due to a new error about the include folder and a file or 2 that is in it. still trying my best to get it working.
SOLUTION to DTS MISSING:
Replace the makefile in the boot directory of your ARCH= type for the device. with the make files in aosp kernel same location.
Just want to point out that you may not need to do any of this and it is normal for the build not to find anything due to it, needing to be created during the kernel build process. the Make file that is located in boot under the ARCH type has some settings in it if you are using a device source other then google devices which contains information that i think the build needs, in order to be made.
After everything I said above, further investigation has proven that the Make file in {ROOT}/arch/arm64/boot is incorrect based off the one in aosp-coral-4.14 correct config is below. copy and replace the whole thing in the file.
Spoiler: Correct Make file config
#
# arch/arm64/boot/Makefile
#
# This file is included by the global makefile so that you can add your own
# architecture-specific flags and dependencies.
#
# This file is subject to the terms and conditions of the GNU General Public
# License. See the file "COPYING" in the main directory of this archive
# for more details.
#
# Copyright (C) 2012, ARM Ltd.
# Author: Will Deacon <[email protected]>
#
# Based on the ia64 boot/Makefile.
#
include $(srctree)/arch/arm64/boot/dts/Makefile
OBJCOPYFLAGS_Image :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
targets := Image Image.bz2 Image.gz Image.lz4 Image.lzma Image.lzo dtbo.img
DTB_NAMES := $(subst $\",,$(CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES))
ifneq ($(DTB_NAMES),)
DTB_LIST := $(addsuffix .dtb,$(DTB_NAMES))
else
DTB_LIST := $(dtb-y)
endif
DTB_OBJS := $(shell find $(obj)/dts/ -name \*.dtb)
DTBO_OBJS := $(shell find $(obj)/dts/ -name \*.dtbo)
# Add RTIC DTB to the DTB list if RTIC MPGen is enabled
ifdef RTIC_MPGEN
DTB_OBJS += rtic_mp.dtb
endif
rtic_mp.dtb: vmlinux FORCE
$(RTIC_MPGEN) --objcopy="${OBJCOPY}" --objdump="${OBJDUMP}" \
--binpath="" --vmlinux="vmlinux" --config=${KCONFIG_CONFIG} \
--cc="${CC} ${KBUILD_AFLAGS}" --dts=rtic_mp.dts && \
$(DTC) -O dtb -o rtic_mp.dtb -b 0 $(DTC_FLAGS) rtic_mp.dts
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
$(obj)/Image.bz2: $(obj)/Image FORCE
$(call if_changed,bzip2)
$(obj)/Image-dtb-hdr: $(obj)/Image FORCE
echo -n 'UNCOMPRESSED_IMG' > [email protected] && \
$(call size_append, $(filter-out FORCE,$^)) >> [email protected]
$(obj)/Image-dtb: $(obj)/Image-dtb-hdr $(obj)/Image $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/Image.gz: $(obj)/Image FORCE
$(call if_changed,gzip)
$(obj)/Image.lz4: $(obj)/Image FORCE
$(call if_changed,lz4)
$(obj)/Image.lzma: $(obj)/Image FORCE
$(call if_changed,lzma)
$(obj)/Image.lzo: $(obj)/Image FORCE
$(call if_changed,lzo)
$(obj)/Image.gz-dtb: $(obj)/Image.gz $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/Image.lz4-dtb: $(obj)/Image.lz4 $(DTB_OBJS) FORCE
$(call if_changed,cat)
$(obj)/dtbo.img: $(DTBO_OBJS) FORCE
$(call if_changed,mkdtimg)
install:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image System.map "$(INSTALL_PATH)"
zinstall:
$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
$(obj)/Image.gz System.map "$(INSTALL_PATH)"
All this does is fix the build saying dts not found.
***UPDATE 2022***
You require dtc binary file from AOSP prebuilts/misc/dtc
Copy it to the devices kernel folder in scripts/dtc. Was able to build kernel (not sure if it works)
Does it come from any commit of git hub, could you give me the link, mine arch/arm... makefile is similar to your old but it compile with no error. so strange
namhoang235 said:
Does it come from any commit of git hub, could you give me the link, mine arch/arm... makefile is similar to your old but it compile with no error. so strange
Click to expand...
Click to collapse
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Squida said:
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Click to expand...
Click to collapse
yeah, your experiment is very useful for me, i am in these trouble you 've met yesterday.i help me a lot. thank again
i really dont want to edit makefile as i see many source have the same make file, so it is a compiler tool with some another input file for it to make, so i only edit makefile when it got error itsefl, if it is the path error, then i really dont want to edit it,
Squida said:
From my understanding you want the link to the makefile I got. Unfortunately it has been so long I am unable to remember where I got it from. But as a helpful tip. I searched Google for (device name) makefile and searched through links. I also tried. Device tree, build files. Hope that helps.
I gave up on building it because Xiaomi did not release any build files or device tree for Xiaomi CC9 PRO. Only released source files for it. So from my understanding. You would have to edit a pre existing one and match it to the device. Doing that is well above my knowledge.
In order to get at least a template for the CC9 device. You can get the template from Using Qualcomms AOSP builder which has the SM160 device in the list. It is seperate from Google's AOSP and requires a seperate download.
Also I would like to know how you managed to get the makefile working maybe I missed something and can go back fix it. May solve my problem I had.
Click to expand...
Click to collapse
can you give me a hint?
my kernel can make standarlone with bash script, but when compile with rom it make tons of errors about path, so which file i need to puth something like cc=clang,.... to make it pass when build rom
namhoang235 said:
can you give me a hint?
my kernel can make standarlone with bash script, but when compile with rom it make tons of errors about path, so which file i need to puth something like cc=clang,.... to make it pass when build rom
Click to expand...
Click to collapse
A hint. Sir I would tell you exactly if I knew how. I myself have failed to be able to get a working kernel let alone a rom running. When flashing a kernel that fails and it's supposed to be from the phone. So that tells me the device tree is incomplete and thus if it is, it fails the build as well as the kernel. I know of Qualcomm's own device builder but I am unable to get that working due to it, unable to locate clang for build. No matter how much I try and set a path I get errors using Qualcomm's builder. AOSP won't build the rom for the device because AOSP does not have the device tree or build files required to build it. You get a template from Qualcomm's builder. Though I can never get it to build. It's all because Xiaomi have not released the device tree or build files. And the people who have gotten it working are probably using someone else tree and build files or has edited their own. That is also why some features of ROMs do not work. It's due to missing info on device tree. Hope this all gives you a better understanding why it's hard for beginners to build a rom for this phone. Because Xiaomi does not have the files on their open source repo.
Squida said:
A hint. Sir I would tell you exactly if I knew how. I myself have failed to be able to get a working kernel let alone a rom running. When flashing a kernel that fails and it's supposed to be from the phone. So that tells me the device tree is incomplete and thus if it is, it fails the build as well as the kernel. I know of Qualcomm's own device builder but I am unable to get that working due to it, unable to locate clang for build. No matter how much I try and set a path I get errors using Qualcomm's builder. AOSP won't build the rom for the device because AOSP does not have the device tree or build files required to build it. You get a template from Qualcomm's builder. Though I can never get it to build. It's all because Xiaomi have not released the device tree or build files. And the people who have gotten it working are probably using someone else tree and build files or has edited their own. That is also why some features of ROMs do not work. It's due to missing info on device tree. Hope this all gives you a better understanding why it's hard for beginners to build a rom for this phone. Because Xiaomi does not have the files on their open source repo.
Click to expand...
Click to collapse
i built for ginkgo (superior rom) it have enough compile source, device, kernel, vendor (vendor is fine), but device and kernel not come from official source tree, maybe it have conflict and have to fork to edit mysefl. very hard for beginer
namhoang235 said:
i built for ginkgo (superior rom) it have enough compile source, device, kernel, vendor (vendor is fine), but device and kernel not come from official source tree, maybe it have conflict and have to fork to edit mysefl. very hard for beginer
Click to expand...
Click to collapse
Yeah building from a custom rom is easier then building from AOSP. Especially if the files for the device are available for building. Usually that's why you see ROMs that say unofficial and official ROMs. Unofficial is usually a modified version of another custom rom for another device to suit your own. Heavily modified. I could be wrong but this is how I took it.
Squida said:
Yeah building from a custom rom is easier then building from AOSP. Especially if the files for the device are available for building. Usually that's why you see ROMs that say unofficial and official ROMs. Unofficial is usually a modified version of another custom rom for another device to suit your own. Heavily modified. I could be wrong but this is how I took it.
Click to expand...
Click to collapse
they put tons of personal stuff without a comment, and some source are not update even they release rom once a week, they fear of clone their source while they clone from git too, they are destroy the ideal of open source itself
@Squida sir, do you meet this, i have gcc 9.3.0 by default and prebuilt gcc in source are updated, so what path i need to config for this can recognize my gcc
error Sorry, your version of GCC is too old - please use 5.1 or newer
In file included from /root/super/kernel/xiaomi/ginkgo/include/linux/compiler_types.h:58:0,
from /root/super/kernel/xiaomi/ginkgo/include/linux/kconfig.h:74,
from <command-line>:0:
/root/super/kernel/xiaomi/ginkgo/include/linux/compiler-gcc.h:159:3: error: #error Sorry, your version of GCC is too old - please use 5.1 or newer.
# error Sorry, your version of GCC is too old - please use 5.1 or newer.
Click to expand...
Click to collapse
namhoang235 said:
@Squida sir, do you meet this, i have gcc 9.3.0 by default and prebuilt gcc in source are updated, so what path i need to config for this can recognize my gcc
error Sorry, your version of GCC is too old - please use 5.1 or newer
Click to expand...
Click to collapse
Make sure no other versions of gcc are being detected. Probably have more then one.
Also could be it may not be set as default.
Type gcc --version in terminal to check what is installed
Squida said:
Make sure no other versions of gcc are being detected. Probably have more then one.
Also could be it may not be set as default.
Type gcc --version in terminal to check what is installed
Click to expand...
Click to collapse
[email protected]:~/super# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.3.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)
[email protected]:~/super#
Click to expand...
Click to collapse
This is a nut with me now.
namhoang235 said:
This is a nut with me now.
Click to expand...
Click to collapse
Lol yeah no idea. That's a lot of info for just doing a version check. If you don't want to uninstall and reinstall Linux. I would Google on how to set gcc xxx as default and see if that helps maybe even seeing if there is an automated .sh you can run so it installs and fixes the problems. I would do a search in the Linux repo on gcc and have a look for anything that says default. Usually those installers will also set it to default for you automatically. I myself am not good with Linux. So that's about as far as I could help on this situation you are in.
The gcc you may need is this https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/