This thread is intended only for developers.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What is Acidify?
Acidify is a tool for building Android builds. It allows easy switching between build types and setting up everything that is needed to build Android.
That said, it is a tool designed for people that are already building Android but want to be able to switch between CM7, CM9, and AOKP easily. It's primarily a convenience tool for TeamAcid developers.
Can I use Acidify?
Of course you can use Acidify! Be aware that it grabs manifests from us (TeamAcid) so in its unmodified state you'll only be able to build Android the way we build Android. As of 0.2.4, however, there are configurable options that allow building for any device. Simply specify any local manifest URLs and the device name in the script.
What do I need to use Acidify?
Short Answer: A POSIX-compliant machine with bash which is capable of compiling Android.
Long Answer: Currently, you need a machine running version 10.10 of Ubuntu or higher to use every feature available in Acidify. Until people contribute code aimed at other distributions and versions, some features (such as grabbing needed packages) may be unavailable. The core features such as initializing the build environment, switching between build types, or building Android itself should theoretically work on any platform running bash and which has all the packages installed that are required to build Android.
How do I install Acidify?
Download a tarball of acidify or clone the repository. Put it somewhere safe and run
Code:
acidify setup
. That will install all the required packages for building Android (if you're on Ubuntu) and it will create a soft link to acidify in ~/bin so that you can access acidify from any directory (assuming ~/bin is in your PATH).
How do I use Acidify?
Run
Code:
acidify usage
for an explaination on how Acidify may be used.
Can I modify or redistribute Acidify?
Yes, you can! Acidify is licensed under the GNU General Public License version 3 (or greater). You can modify it and redistribute it under the terms of the license. See LICENSE for more information.
I found a bug with Acidify. Will you fix it?
For sure! Make an issue in the issue tracker to tell us about it.
I found a bug with Acidify and I fixed it. Do you want it?
We would love it! Submit a pull request.
I wanted X feature, so I implemented it. Do you want it?
Potentially. Submit a pull request and we can discuss it there.
Get it on Github!
Changelog
ABOUT TIME! I was waiting for this all day yesterday, it took you until today to post it, serioiusly, rabble rabble *gets smacked by m4xm4n* Okay okay I'll stop about the ETA's.
Nice work Max!
Oh boy!
This is gonna make my life better.
Sent from my SGH-T959V using xda premium
Well Max thanks dude this will help with some stuff
Sent from my SGH-T959V using xda app-developers app
I will never forget it.
Oh hey,
um,
If you try to switch between build types right now, it's going to mess a lot of stuff up. So don't do it until I push 0.2.0. hehe. whoops.
Changelog
Version 0.2.0 is up on the githubs.
schedtool will now be installed as a required package. (ubuntu only)
Fixed acidify init. Switch between build types cleanly and correctly.
Fixed acidify deploy. I had it deploying all builds as CM9 and not removing the correct builds. Blame it on late night programming.
Minor things you won't notice.
Version 0.2.1 is up on the githubs
Fixed a derp that made goo upload not work for CM7 and CM9
Version 0.2.2 is up on the githubs
Fix uploading to goo
Fix make clobber call in cleanenv()
Fix for acidify init in a clean directory
Add symlink to ~/bin/acidify (thanks fbis251)
Version 0.2.3 is up on the githubs
Add colorized output and timer (thanks fbis251)
Add error checking to checkenv() (thanks fbis251)
Version 0.2.4 is up on the githubs
Simplify configuration and increase acidify device agnosticism. You should be able to compile for any device now by configuring correctly for it. Simply change the local manifest variables and the device variable.
Version 0.2.5 is up on the githubs
Added temporary workaround for building AOKP (thanks fbis251!)
Version 0.2.6 is up on the githubs
Don't run timer on 'acidify version' or in the absence of a command.
Colorize error output
Version 0.2.7 is up on the githubs
Add automatic kernel building and cleaning to CM7.
Apply the AOKP build workaround only if the device is galaxys4gmtd.
Version 0.2.8 is up on the githubs
Make kernel cleaning device agnostic and clean before switching build types. Left over kernel build stuff from CM7 will break AOKP and CM9 builds.
Version 0.2.9 is up on the githubs
Install pngcrush as a required package in setup()
Fix Goo.im upload
curl isn't installed on ubuntu by default. Install the required packages before trying to grab repo using curl (thanks fbis251)
Update deploy() for AOKP milestone 6 (thanks fbis251)
Update deploy() to reuse code (thanks fbis251)
Update upload() (thanks fbis251)
Version 0.3.0 is up on the githubs
Added a check for lsb-release and made the error a little more readable (thanks xaocon)
Changed check for /etc/lsb-release to look for a readable regular file and changed the logic for defaulting the DISTRIB_ID value. (thanks xaocon)
Add Gummy support (thanks fbis251)
Version 0.3.1 is up on the githubs
Updated upload() to use rsync with resume support (thanks fbis251)
Add Linux Mint support to setup()
Version 0.3.2 is up on the githubs
Gummy: get-prebuilts added (thanks fbis251)
Version 0.3.3 is up on the githubs
Update constants and add ~/bin/acidify check (thanks fbis251)
Version 0.3.4 is up on the githubs
Add boot image flashing function
Version 0.4.0 is up on the githubs
Massive changes to how configuration works. Please update and read this.
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
jeffsf said:
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
Click to expand...
Click to collapse
You're using an old version. That error has been fixed.
FBis251 said:
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Click to expand...
Click to collapse
I left my laptop syncing before I left the house
Sent from my SGH-T989 using xda app-developers app
Awesome. We'll finally have some more people messing with the AOKP source. I've been hoarding it all to myself, but if I had tried to share it without the local_manifest.xml it would've gotten messy quick. Good thing Max made this script .
Tell me when you try building, I wanna see if all the problems I had aren't there anymore.
EDIT
You should hop onto IRC for a bit.
I just pushed a few updates to Acidify which brings us to 0.2.9
It was updates to upload() and deploy() if you're using goo.im for uploads or pushing the builds to your sdcard via ADB. It'll be easier to add new devices. Once I get the repo issues sorted with AcidGummy I'll also add it to the list of available roms that you can download and build.
Acidify version 0.4.0
This is the last bash release. I will be rewriting acidify in Python after this.
This release introduces a global configuration file so script modifications are no
longer required or encouraged. Additionally, all config options can be overridden by
the environment. This makes way for acidifies use in automated build scripts and
when building for multiple devices. Further more, if a build environment is
configured, you can invoke acidify from anywhere.
See config.sample to create a config for yourself. Save it as ~/.acidify/config
e.g. for running with environmental variables:
DEVICE=vibrantmtd MANUFACTURER=samsung acidify config
will run acidify config for the device vibrantmtd instead of whatever the script's
defaults are, or the options set in the config file (if present).
Options priority ENV(highest), config file, script defaults (lowest)
m4xm4n said:
Acidify version 0.4.0
Click to expand...
Click to collapse
I am trying to run latest script, and no go. What am I doing wrong?
[email protected]:~/src/aokp$ acidify setup
....
....
Your machine is ready to setup the Android build environment
Please see http://source.android.com/source/initializing.html for
instructions on setting up ADB and the udev rules required.
Elapsed Time: 10 sec(s)
[email protected]:~/src/aokp$ acidify init aokp
Acidify version 0.4.1
Attempting to initialize environment to build type aokp
This WILL REMOVE ALL LOCAL CHANGES
/home/galets/bin/acidify: line 54: /.acidify/buildtype: No such file or directory
Error: Could not write to /.acidify/buildtype !
do I need some env variables configured?..
**EDIT:** My bad... I guess I was supposed to create ~/.acidify/config
It's not listed anywhere, but... First run setup.
git clone https://github.com/teamacid/acidify.git
cd acidify
mkdir ~/.acidify
cp config.sample ~/.acidify/config
./acidify setenv
./acidify setup
./acidify init <yourtype>
./acidify init <yourtype>
Click to expand...
Click to collapse
Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Theraze said:
It's not listed anywhere, but... First run setup.Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Click to expand...
Click to collapse
I am stuck at the acidify init successfully downloading all but 3 projects. When I try to re-run "acidify init" or "acifidy sync", I'm geting this:
Fetching projects: 99% (311/314) Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com':
I can enter user name, but it won't accept my password
I will clean my work folder and try to re-fetch all...
Edit: I think following 3 commands will never complete:
galets 21984 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21986 21984 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_libhardware
galets 21996 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21997 21996 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_msm7k
galets 22024 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 22025 22024 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_qcom_media[/QUOTE]
I verified that my password is 8 characters (there's apparently a bug in git)
That's an issue with AOKP, not Acidify. You'll have to wait until they fix all the things they have tendency to break.
Sent from my super fancy SGH-T959V with Magic Debugging Powers
On AOKP build failures, you might want to follow [REF] Building AOKP -- Transient Issues -- 2012/09/18
Though until someone uploads the ics framework files, you're stuck. So... like I said...
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Click to expand...
Click to collapse
Watch that thread jeffsf pointed to and when FBis251 or someone actually uploads a working copy of the files, THEN you can build AOKP. Or you can build CM7 or CM9 right now.
Related
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Building Your ROM With The Linaro Toolchain
This guide will help you build your ROM with the Linaro toolchain, and any other 4.7, 4.8+ toolchains. Using one of these "updated" toolchains requires you to be able to search, read, and be able find information to be able to fix errors you may encounter varying from device to device, and depending on your Global optimization level. This guide is more for setting up your build and leaves you to play with the flags and optimizations. It takes a little work to get your environment set up but that's all the fun ..
1. Getting the toolchain
First you will need to get the toolchain. You can either pull it from a repo or download the zip straight from Linaro or Google. Keep in mind that the ROM is compiled with the arm-linux-androideabi and the kernel with arm-eabi. You can find all the release versions of Linaro's toolchains here along with nightly builds LINK, And Googles toolchains for Linux and Darwin here LINK. Focusing on building with Linux the path for them is "prebuilts/gcc/linux-x86/arm" with Linaro you can just extract the one folder into the directory but Google has them split up into arm-linux-androideabi-4.7, and arm-eabi-4.7.
2. Setting up your build repo
You will need to edit the build repo to point to the updated toolchains. From step one we either put the Linaro folder or Google's toolchains into the "prebuilts/gcc/linux-x86/arm" directory. Remember the names of the folder or toolchains as we will need them in these edits, Using the linaro folder name for both arm-linux-androideabi, and arm-eabi lines or just replacing them with the updated Google versions. You can follow this commit as a guide to setting up your Build repo Toolchain Edits
3. Dealing with build errors
From Linaro:
Getting rid of -fno-strict-aliasing enables rather efficient additional optimizations – but requires that the code being compiled follows some rules traditionally not enforced by compilers.
Given the traditional lack of enforcement, there’s lots of code out there (including, unfortunately, in the AOSP codebase) that violates those rules.
Fortunately, gcc can help us detect those violations: With -fstrict-aliasing -Werror=strict-aliasing, most aliasing violations can be turned into built time errors instead of random crashes at runtime. This allowed us to detect many aliasing violations in the code, and fix them (where doable with reasonable effort), or work around them by enabling -fno-strict-aliasing just for a particular subdirectory containing code not ready for dropping it.
There are many Projects in your source you will have to add patches to fix the violations or workarounds. I have 40+ patches to fix the numerous errors in my builds. Many can be found from Linaro's Gitweb LINK, and you can get some of them from CM Review LINK. This is the hard part and Google search can be your best friend :silly:.
4. Optimizations
Once you get your setup going successfully you can play around with some optimizations. You can find some information about flag optimizations from Linaro LINK and GNU LINK. an example can be like this for -O3 LINK, or more stable -O2 with some added flags that would be enabled by -O3 LINK. there's also options like Linaros string handling routines LINK.
MISC Links
DJLaMontagneIII Github
CM Review Linaro commits
Linaro Gitweb
Linaro Downloads
Google Source
SaberMod Github
trailblazerz Github
Please feel free to reference my Github for patches you may need and feel free to post any build errors you may be stuck on and need help because others my be in the same boat, but please use hide tags or pastebin for the terminal outputs:good:.
one
two
three!!!!
no, but is compiling a toolchain from source pretty effortless?
I need a darwin version.
airfluip1 said:
three!!!!
no, but is compiling a toolchain from source pretty effortless?
I need a darwin version.
Click to expand...
Click to collapse
You would have to use
https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.7/
https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.7/
Sent from my Nexus7 using Tapatalk HD
Hi @DJLamontagneIII Can I cherry-pick your commits for building kernel man? Cause the patches I applied to the kernel seems to screw my bootimage as my phone couldn't boot up (along with patches to the others were fine)
daothanhduy1996 said:
Hi @DJLamontagneIII Can I cherry-pick your commits for building kernel man? Cause the patches I applied to the kernel seems to screw my bootimage as my phone couldn't boot up (along with patches to the others were fine)
Click to expand...
Click to collapse
You can use what ever you need
All the very best for your own thread my friend.. As such you were doing this job for a long time till now.. Thanks for all the support !!!
Sent from my Find 5 using Tapatalk 2
Good write up DJ. Self help/teaching method Thanks for this
Hey @DJLamontagneIII. First of all, thanks for the very informational guide I was able to compile CM10.1 with Linaro for my phone (HTC Sensation) but it just hangs at the manufacturer splash for ~30 seconds then reboots into the recovery. I tried building with and without all the repos from your GitHub but it hasn't made a difference. I've also been building with the flags you're using but still no luck I've tried compiling with generic Linaro GCC 4.7 and 4.8 but the same thing happens with both. Any ideas for what I can do?
android1234567 said:
Hey @DJLamontagneIII. First of all, thanks for the very informational guide I was able to compile CM10.1 with Linaro for my phone (HTC Sensation) but it just hangs at the manufacturer splash for ~30 seconds then reboots into the recovery. I tried building with and without all the repos from your GitHub but it hasn't made a difference. I've also been building with the flags you're using but still no luck I've tried compiling with generic Linaro GCC 4.7 and 4.8 but the same thing happens with both. Any ideas for what I can do?
Click to expand...
Click to collapse
swap your boot.img out with one from a working cm-10.1 rom for your device and if it works, then it obviously indicates that it has something to do with the kernel and how it was compiled. If that's the case, I would take a look at what prebuilt you're pulling from for armeabi
IAmTheOneTheyCallNeo said:
swap your boot.img out with one from a working cm-10.1 rom for your device and if it works, then it obviously indicates that it has something to do with the kernel and how it was compiled. If that's the case, I would take a look at what prebuilt you're pulling from for armeabi
Click to expand...
Click to collapse
I've already tried that, still doesn't boot . I've been building the kernel with linaro for a while (I also have a custom toolchain path set in kernel.mk) and I was running it on my phone for weeks, so it's definitely not the kernel (or ramdisk).
Have you tried lowering the flags to -O2... -O3 could be causing issues
Sent from my SGH-T959V using Tapatalk 4 Beta
DJLamontagneIII said:
Have you tried lowering the flags to -O2... -O3 could be causing issues
Sent from my SGH-T959V using Tapatalk 4 Beta
Click to expand...
Click to collapse
I'm already using -O2 because I'm using the flags from your GitHub
android1234567 said:
I'm already using -O2 because I'm using the flags from your GitHub
Click to expand...
Click to collapse
The problem with my device in particular, was modifying the prebuilt line indicated in build/core/combo/select.mk
change that back to the default (which I believe was pointing to 4.6) and rebuild... You'll be surprised.
However don't feel discouraged about changing that line back to 4.6 as the envsetup.sh is where the magic really happens and decides which prebuilts to use.
My phone went from splash to darkness for 30 seconds, and then a reboot back into recovery.. If that sounds familiar, make that one change in your select.mk and give it a rebuild.
IAmTheOneTheyCallNeo said:
The problem with my device in particular, was modifying the prebuilt line indicated in build/core/combo/select.mk
change that back to the default (which I believe was pointing to 4.6) and rebuild... You'll be surprised.
However don't feel discouraged about changing that line back to 4.6 as the envsetup.sh is where the magic really happens and decides which prebuilts to use.
My phone went from splash to darkness for 30 seconds, and then a reboot back into recovery.. If that sounds familiar, make that one change in your select.mk and give it a rebuild.
Click to expand...
Click to collapse
That's what my phone is doing (splash to black screen to recovery) but it still doesn't boot after making the change. Just to make sure I did it right, do you have a commit I can see for the change you made in select.mk?
android1234567 said:
That's what my phone is doing (splash to black screen to recovery) but it still doesn't boot after making the change. Just to make sure I did it right, do you have a commit I can see for the change you made in select.mk?
Click to expand...
Click to collapse
I'm sorry buddy I told you the wrong file
It's in TARGET_linux-arm.mk
this is the original line:
TARGET_TOOLCHAIN_ROOT := prebuilts/gcc/$(HOST_PREBUILT_TAG)/arm/arm-linux-androideabi-4.6
as shown on the unmodified version here: https://github.com/CyanogenMod/android_build/blob/cm-10.1/core/combo/TARGET_linux-arm.mk#L46
Change that line in your modified build/core/combo/TARGET_linux-arm.mk to look identical to that, do a make clean, and rebuild with that change.
Actually, try doing it without a clean first and if it still doesn't boot, do a make clean and then try.
IAmTheOneTheyCallNeo said:
I'm sorry buddy I told you the wrong file
It's in TARGET_linux-arm.mk
this is the original line:
TARGET_TOOLCHAIN_ROOT := prebuilts/gcc/$(HOST_PREBUILT_TAG)/arm/arm-linux-androideabi-4.6
as shown on the unmodified version here: https://github.com/CyanogenMod/android_build/blob/cm-10.1/core/combo/TARGET_linux-arm.mk#L46
Change that line in your modified build/core/combo/TARGET_linux-arm.mk, do a make clean, and rebuild with that change.
Actually, try doing it without a clean first and if it still doesn't boot, do a make clean and then try.
Click to expand...
Click to collapse
But TARGET_linux-arm.mk is what controls which toolchain builds the whole thing... I know that envsetup doesn't set the toolchain; I experimented a lot and found that TARGET_linux-arm.mk is what controls the toolchain for the whole thing. It makes sense that it booted for you because I think you built the whole ROM with the 4.6 toolchain.
EDIT: It might not have booted for me because my build machine is apparently messed up
android1234567 said:
But TARGET_linux-arm.mk is what controls which toolchain builds the whole thing... I know that envsetup doesn't set the toolchain; I experimented a lot and found that TARGET_linux-arm.mk is what controls the toolchain for the whole thing. It makes sense that it booted for you because I think you built the whole ROM with the 4.6 toolchain.
EDIT: It might not have booted for me because my build machine is apparently messed up
Click to expand...
Click to collapse
https://code.google.com/p/android/issues/detail?id=3812
Have a read. envsetup.sh is what decides the toolchain. That particular target should be left alone. At least for my device.
target thumb C: libcrypto_static <= external/openssl/crypto/bio/bss_dgram.c
external/openssl/crypto/bio/bss_dgram.c: In function 'dgram_ctrl':
external/openssl/crypto/bio/bss_dgram.c:581:5: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness [-Wpointer-sign]
In file included from prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/netdb.h:66:0,
from external/openssl/e_os.h:563,
from external/openssl/crypto/cryptlib.h:65,
from external/openssl/crypto/bio/bss_dgram.c:64:
prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/sys/socket.h:73:18: note: expected 'socklen_t *' but argument is of type 'unsigned int *'
external/openssl/crypto/bio/bss_dgram.c:597:5: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness [-Wpointer-sign]
In file included from prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/netdb.h:66:0,
from external/openssl/e_os.h:563,
from external/openssl/crypto/cryptlib.h:65,
from external/openssl/crypto/bio/bss_dgram.c:64:
prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/sys/socket.h:73:18: note: expected 'socklen_t *' but argument is of type 'unsigned int *'
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
cc1: some warnings being treated as errors
make: *** [/home/gchild320/Source/out/target/product/i605/obj/STATIC_LIBRARIES/libcrypto_static_intermediates/crypto/bio/bss_dgram.o] Error 1
make: *** Waiting for unfinished jobs....
Anyone have any ideas on what is causing this?
[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
Those of you maintaining unofficial ROMs that need some device specific patches to the android platform that are not (yet) merged into the official sources often face the same problem: When syncing with upstream you either have to cherry-pick your patches again manually, or for those changes that are not committed there may be merge errors.
Additionally, when there are many patches in various repos it can get hard to keep track of them.
I faced the same situation while working on my phone, which needs changes not merges into any official sources except for NamelessROM. And those of you who know me, know that I like scripts doing the work for me.
So I decided to write a tiny script to do all that for me.
Sure, I could have written a script like
Code:
cd frameworks/base
git cherry-pick <blah>
git cherry-pick <blah2>
cd ../../system/core
git cherry-pick <blah3>
But I just don't like hardcoding, and maintaining the script would also be way, way harder.
So I came up with this solution:
Storing the fetch URLs as well as the commit IDs in arrays. Then I can call one after another fully automatic via for-loops.
One issue remained, though: if a cherry-pick fails the next commits would also fail. Which is why the repo gets automatically reset if a cherry-pick doesn't apply properly.
An example script can be found HERE or in the attachments.
Now, the most important part for you: How do you make the script compatible with your ROMs sources?
There are just a few values you have to take care of:
Code:
##### Definable values
remote_name="p880-dev_autofetch"
paths="frameworks/native frameworks/base frameworks/opt/telephony"
commit_id[frameworks_native]='8465cdba74a038bb29598cfb4f48754b83124f48 208b1fcc0df405dc15582798c4e5406ba16201a9 49beaf826eb1c4eae3fe3202ef682a5973213c2d c83b9661c0fca41a5f43473def58379c7d7ae7d7 0c880a230ef4331cc071d45b6b06a8b0572c5a8f'
commit_id[frameworks_base]='45b92f41db68285e87980fafaa263511a6568705'
commit_id[frameworks_opt_telephony]='e7490c2c565d388212d84f627fb59c2bcccf8d61'
repo_url[frameworks_native]='[email protected]:laufersteppenwolf/android_frameworks_native.git'
repo_url[frameworks_base]='[email protected]:laufersteppenwolf/android_frameworks_base-1.git'
repo_url[frameworks_opt_telephony]='[email protected]:laufersteppenwolf/android_frameworks_opt_telephony.git'
#####
remote_name specifies the name that should be used for fetching (doesn't really matter, it just helps keeping track of what this remote is)
paths specifies the paths to the repos the script is gonna cycle through.
commit_id[name] specifies the commit IDs of the repo "name". While "name" is the path to the repo, but with underscores instead of slashes. Example: if your path is "system/core", the name you have to specify would be "system_core".
repo_url[name] specifies the URL of the repo to fetch. The naming is the same as in commit_id with underscores.
That's it. You can specify as many repos as you need, the script will cycle one after the other.
For an example on how to update the script with more repos, you may want to take a look at THIS commit
Now, how to use the script?
It's as simple as it could be:
Set up the build environment (. build/envsetup.sh)
Execute the script from whereever you want (. cherry-pick.sh)
If you're running the script for the first time or the fetched repo needs an update, you have to add the --fetch argument to (re-)fetch the repo again. (. cherry-pick.sh --fetch)
If you happen to have questions or suggestions, please feel free to let me know!
Mine!
@laufersteppenwolf Nice bro!
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
m0d said:
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
Click to expand...
Click to collapse
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
laufersteppenwolf said:
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
Click to expand...
Click to collapse
I am trying to set up the script,
How must one go setting up repo url for:
https://android-review.googlesource.com/#/c/104728/
5a6037f1c8b5ff0cf263c9e63777444ba239a056
git fetch https://android.googlesource.com/platform/hardware/qcom/bt refs/changes/28/104728/1 && git cherry-pick FETCH_HEAD
I tried checking for the following,
commit_id[hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
commit_id[platform_hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[platform_hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'They all gave me:
Code:
*************************************************************
* Entering hardware/qcom/bt
*************************************************************
*************************************************************
* All commits applied successfully!
*************************************************************
There seems to be an error as it always says - * All commits applied successfully!
But, when I check for the commit changes they are not present.
Also,
Is it possible to have a revert in the cherry-pick script? As in before a particular cherry-pick I need to revert a commit,
so I need to check if the commit is a cherry pick or a revert,
Where as now it is sort of hard-coded:
for commit in ${commit_id[${commit_path}]}; do
sleep 1
cherry-pick "$commit"
doneand
for commit in ${commit_id[${commit_path}]}; do
sleep 1
revert "$commit"
doneAn if else needs to be added somehow,
will try to test once I get the script to start working
Hi there!
I know this thread hasn't had activity for years but it is the only possible resource I find for minimally automating security patching our rom sources... I am new to building and have a couple of viable nougat builds almost ready for Xiaomi Mi Mix, and a third one with more problems. One of the last things I am working on is security patching my working directories and as I have no background in programming or linux or any technical stuff in general, I get quite lost about git cherry-picking, git fetching, patching, merging, etc.
From what I see here this script could make the whole thing easier but I do not know if it works. Anybody out there willing to give me a hand here?
Thanks in advance
This thread is about Linux port for J120F. Test build is currently in beta state. But if you're a Linux user you can try it.
Status:
Display and touchscreen work
Hardware and software keyboards work
Wi-Fi works (and Firefox onboard )
USB works as OTG or serial gadget with a console (115200n8). UART JIG also works
Bluetooth. You can run hciattach (@115200) to get BT device but most tools don't see it
Known issues:
Touchscreen won't work if phone was started by attaching USB or charger. That's because Android can't start this way (phone shows battery status and goes off).
For same time after boot you can't click anything but cursor moves. Just wait ~30 sec.
This will be fixed in v1.3. Or you can execute:
Code:
rpm -ev --nodeps xinput-calibrator
Fixed:
Onscreen keyboard doesn't work. Sad but true
"Connect to Wi-Fi" button is out of screen. It's next to "DHCP" combobox in TAB order.
Display goes to sleep and can't be turned back on. You can restart X from SSH or USB console to turn it on again. (No timeout - no bug )
How to install:
Create 3 partitions on SD card. 1st is FAT for your Android data. 2nd for Link2SD (make it tiny if not needed). 3rd is ext2 for Linux (500 MB should be enough for now).
Extract rootfs.tar.xz contents to 3rd partition. It should be done as root and from terminal. GUI tools aren't good for this.
Flash kernel (boot.img) with heimdall. It can work as recovery too. In this case you will get dualboot.
Milestones:
1.0 Make it boot
1.1 Bring up major hardware
1.2 Make ROM easier for testing and building
1.3 Organize included software
My next major tasks:
Improve BSP. Make image recipe.
Make toggle screen on/off feature by power button.
Improve onscreen keyboard layout. Make keys bigger.
Done tasks:
Sort out all the patches I've made to FS. Make a BSP (OpenEmbedded machine layer).
Find a problem with USB serial gadget and make it work as console. For now I use UART JIG but only few people have such hardware.
Get Wi-Fi to work. Smartphone is not a smartphone without internet connectivity.
Make connman-gnome window usable with such small display. Currently you need to do blind TAB to connect to Wi-Fi.
Find a problem with on screen keyboard. The only way to input text now is USB keyboard over OTG.
Improve BSP. Integrate FS patches into it. Fix kernel so it can be built inside OE.
Fix screen timeout bug. (Timeout disabled so far)
Photos:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Link to my ROMs folder on MEGA.
Kernel source on GitHub.
OpenEmbedded Layer (BSP) source on GitHub.
Wi-Fi works!
dmesg from Android helped me to start Wi-Fi. To finish initialization you need to run
Code:
cat /proc/deferred_initcalls
Seriously!
Good news!
SSH is working over Wi-Fi.
USB gadget works after all!
To activate it do:
Code:
echo connect > /sys/class/udc/13580000.usb/soft_connect
Now I will try to make a build with all those things activated on boot
Version 1.1 released. It's MUCH more user-friendly but you still need some skills to install and use it.
It's possible to do this on Galaxy J120H?
jlfedmmc456 said:
It's possible to do this on Galaxy J120H?
Click to expand...
Click to collapse
OS image should start on J120H but you need a special kernel. So there are two answers on two kinds of questions:
1) No. This is impossible to [just] install kernel and OS from J120F to J120H because of different hardware.
2) Yes. This is possible to port this project to J120H. It's easy if you're ROM maker.
Good job. Thank you for this ROM.
Set up both keyboards.
To activate software one:
/etc/X11/Xsession.d/80matchboxkeyboard.sh
Code:
#!/bin/sh
. /etc/formfactor/config
CMD="matchbox-keyboard -d"
if [ "$CMD" ]; then
# Delay to make sure the window manager is active
# by waiting for the desktop to say its finished loading
dbus-wait org.matchbox_project.desktop Loaded && $CMD &
fi
To activate hardware one you need new kernel. It is on MEGA already (linux_1_2_boot.img).
Buttons:
RECENT -> Context menu
HOME -> My Computer
BACK -> Esc
Power and Vol keys are Power and Vol keys
To make HOME work as "show desktop" button add:
Code:
XF86MyComputer=desktop
to kbdconfig file.
That's all for now
Fixed Samsung kernel. Now it builds inside OE.
IIRC bitbake should be able now to build OS image without any "tricks".
BSP v1.2
Made proto BSP in a form of diffs. Changes are listed in fs_files.diff file. New files are in files folder. Patches are in diffs folder. New packages are in rpms folder.
Hey really great work; I have created 2 forks of your project for J120A here in the states... I haven't used bitbake before. I went and installed it, but not sure how to use it with the 2 projects you've uploaded. I tried "bitbake J120A" and "bitbake world" but that doesn't seem to be the thing to do. Can't seem to build the kernel manually with "make" either. Could you tell me what commands/config I need to do with bitbake to get this working? Thanks again for your hard work!
puargs said:
Hey really great work; I have created 2 forks of your project for J120A here in the states... I haven't used bitbake before. I went and installed it, but not sure how to use it with the 2 projects you've uploaded. I tried "bitbake J120A" and "bitbake world" but that doesn't seem to be the thing to do. Can't seem to build the kernel manually with "make" either. Could you tell me what commands/config I need to do with bitbake to get this working? Thanks again for your hard work!
Click to expand...
Click to collapse
You don't need bitbake. You need OpenEmbedded.
https://www.openembedded.org/wiki/Getting_started
https://www.openembedded.org/wiki/OE-Core_Standalone_Setup
Then add some layers. I have:
meta (oe-core)
meta-oe
meta-multimedia
meta-networking
meta-filesystems
meta-gnome
meta-initramfs
meta-perl
meta-python
meta-webserver
meta-xfce
meta-browser
meta-j120f
Setup a MACHINE to build for.
Code:
MACHINE ?= "j120f"
And allow non-free licenses
Code:
LICENSE_FLAGS_WHITELIST += "commercial"
Now you can try to build "core-image-sato". OE needs huge amount of free space and time to build! (~100GB)
You can also build packages: bitbake firefox
I doubt that F kernel will run on A version. So you need to port all my patches to the Samsung kernel source for J120A. It shouldn't be hard.
Then diff my linux defconfig with original one (for j120f) and add those changes to your (j120a) defconfig.
After that unpack stock boot.img for your device. And pack your zImage with original DT file.
This is how I do this:
Code:
android_img_repack_tools/mkbootimg --kernel zImage --ramdisk NONE --dt boot.img-dt --base 10000000 --pagesize 2048 --board SRPOI21A000RU -o new_boot.img
Now you can flash new_boot.img with heimdall
Code:
heimdall flash --BOOT new_boot.img
I think you should start with kernel. Patch, build, pack img and flash it. (Don't forget to unlock bootloader first!) Then you can install my OS build on SD card (replace /etc/wifi and /lib/firmware with your files). I hope v1.2 will be released already. And if it works you can start to build your own OS image
This is really great information, thank you so much for the assistance! I have gone through and started work on what you mention, but I realized I'm not sure which Kernel you originally downloaded for your device. There are a lot available for the J120F:
https://imgur.com/a/OeI9u
Do you remember which one you started with? It will make filtering down the diff a lot easier.
-W_O_L_F- said:
You don't need bitbake. You need OpenEmbedded.
https://www.openembedded.org/wiki/Getting_started
https://www.openembedded.org/wiki/OE-Core_Standalone_Setup
Then add some layers. I have:
meta (oe-core)
meta-oe
meta-multimedia
meta-networking
meta-filesystems
meta-gnome
meta-initramfs
meta-perl
meta-python
meta-webserver
meta-xfce
meta-browser
meta-j120f
Setup a MACHINE to build for.
Code:
MACHINE ?= "j120f"
And allow non-free licenses
Code:
LICENSE_FLAGS_WHITELIST += "commercial"
Now you can try to build "core-image-sato". OE needs huge amount of free space and time to build! (~100GB)
You can also build packages: bitbake firefox
I doubt that F kernel will run on A version. So you need to port all my patches to the Samsung kernel source for J120A. It shouldn't be hard.
Then diff my linux defconfig with original one (for j120f) and add those changes to your (j120a) defconfig.
After that unpack stock boot.img for your device. And pack your zImage with original DT file.
This is how I do this:
Code:
android_img_repack_tools/mkbootimg --kernel zImage --ramdisk NONE --dt boot.img-dt --base 10000000 --pagesize 2048 --board SRPOI21A000RU -o new_boot.img
Now you can flash new_boot.img with heimdall
Code:
heimdall flash --BOOT new_boot.img
I think you should start with kernel. Patch, build, pack img and flash it. (Don't forget to unlock bootloader first!) Then you can install my OS build on SD card (replace /etc/wifi and /lib/firmware with your files). I hope v1.2 will be released already. And if it works you can start to build your own OS image
Click to expand...
Click to collapse
puargs said:
This is really great information, thank you so much for the assistance! I have gone through and started work on what you mention, but I realized I'm not sure which Kernel you originally downloaded for your device. There are a lot available for the J120F:
https://imgur.com/a/OeI9u
Do you remember which one you started with? It will make filtering down the diff a lot easier.
Click to expand...
Click to collapse
You don't need to know it. Just take a look at commits: https://github.com/LONELY-WOLF/kernel-j120f/commits/master
Version 1.2 ready
ROM made more user friendly. Most patches are integrated in BSP. It's far more easier to test and build ROM now.
Fixes not included in 1.2:
xinput-calibrator should be removed as it's useless for modern touchscreens
keyboard layout was reworked but I still need to make keys bigger
removed "Ethernet" option from connman-gnome. This fix is available in proto_BSP_1.2 archive
Version 1.3 will be about included packages.
I want to delete and install some packages. Busybox will be replaced first!
BSP will get image recipe.
BSP builds without errors! My Ryzen 1700 (OC to 3800MHz) builds OS image in ~1 hour.
-W_O_L_F- thanks for leading work on a custom kernel and Linux userspace on SM-J120x. Great to see the improvements you've made on top of the vendor kernel to make it easier for developers to test (e.g. packaged boot.img, and userspace).
puargs: I'd also like to see a version for SM-J120A, however I expect we will be blocked running custom RECOVERY as the SM-J120A ships with a locked bootloader. So far I've been unable to find any bootloader unlock methods for SM-J120A.
Tried flashing linux_1_2_boot.img to RECOVERY with heimdall in "download mode" as a test, with no success.
The download mode recognizes an unexpected RECOVERY image, and reports "SECURE CHECK FAIL : (RECOVERY)" on the device.
Have you had any success? Perhaps you found a method that works?
Wow, this is some serious development going on for the SM-J120F! I'm surprised to see such projects for the Exynos platform.
Keep up the good work and may your project become successful!
Project moved to new hardware: Galaxy Note9.
https://forum.xda-developers.com/ga...linux-porting-native-linux-to-galaxy-t3936077
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