Hi Everyone,
I have recently decided to build a custom ROM for my Nexus 5 and I've set up the VM and downloaded the source code. I'm a little confused when it comes to making my modifications. Do I stay on the Google repo and just modify from there (using git add, git commit and then repo sync)? Or am I supposed to create my own to save all of my modifications.
Thanks in advance
(Sorry if this is in the wrong place, I'm a little unsure about where this should be posted.)
p3ntyne said:
Hi Everyone,
I have recently decided to build a custom ROM for my Nexus 5 and I've set up the VM and downloaded the source code. I'm a little confused when it comes to making my modifications. Do I stay on the Google repo and just modify from there (using git add, git commit and then repo sync)? Or am I supposed to create my own to save all of my modifications.
Thanks in advance
(Sorry if this is in the wrong place, I'm a little unsure about where this should be posted.)
Click to expand...
Click to collapse
repo sync will erase all your changes and sync with AOSP.
You'll want to push your changes to a Github (or similar) repository, and create your manifest to init from, as well as to sync from your own repos instead of using Google's AOSP ones.
e.g. https://github.com/Elluel/elluel_manifest, https://github.com/Elluel?tab=repositories
Elluel said:
repo sync will erase all your changes and sync with AOSP.
You'll want to push your changes to a Github (or similar) repository, and create your manifest to init from, as well as to sync from your own repos instead of using Google's AOSP ones.
e.g. https://github.com/Elluel/elluel_manifest, https://github.com/Elluel?tab=repositories
Click to expand...
Click to collapse
Thanks! So, am I right in saying that I should 'repo init -u' to my repository and this 'git clone' AOSP into it? If so, how would I update the Android version without wiping the modifications I've made? And secondly, I have created a repo in github but I'm not sure how to how to create a manifest.
Elluel said:
repo sync will erase all your changes and sync with AOSP.
Click to expand...
Click to collapse
There's a way around that.
Create a new local branch, have git set it to track whatever tag or remote branch you want. Make your changes in that new branch.
When you repo sync after this, repo will try to merge upstream commits onto your local branch, fast forwarding your own changes, instead of discarding them.
beekay201 said:
There's a way around that.
Create a new local branch, have git set it to track whatever tag or remote branch you want. Make your changes in that new branch.
When you repo sync after this, repo will try to merge upstream commits onto your local branch, fast forwarding your own changes, instead of discarding them.
Click to expand...
Click to collapse
Thanks, but it seems like the method of creating my own repo would be easier. I'm just confused about the manifest and if I should clone AOSP into my repo...
p3ntyne said:
Thanks, but it seems like the method of creating my own repo would be easier. I'm just confused about the manifest and if I should clone AOSP into my repo...
Click to expand...
Click to collapse
Whatever makes you go. I wasn't really talking to you, but hey, if you know git, this is trivial.
How difficult is it to build your own rom? Is it worth learning or do I need programing skills? I have modified a little bit of code before but using guides ect.. Could I use a guide to build my own ROM or is there a lot more to it?
It is not that difficult once you have your build environment set up. Lots of guides to help you, hint it is not device specific (I mean the concept of building, it is when you are building). I first started using slim, check out the slim builders collective, lots of info there.
beekay201 said:
There's a way around that.
Create a new local branch, have git set it to track whatever tag or remote branch you want. Make your changes in that new branch.
When you repo sync after this, repo will try to merge upstream commits onto your local branch, fast forwarding your own changes, instead of discarding them.
Click to expand...
Click to collapse
Well yeah, but I was saying if he just simply went and used it without making a local branch lol.
wangdaning said:
It is not that difficult once you have your build environment set up. Lots of guides to help you, hint it is not device specific (I mean the concept of building, it is when you are building). I first started using slim, check out the slim builders collective, lots of info there.
Click to expand...
Click to collapse
Do I need to use Linux to build? So I'd need a vm with umbuntu? how much ram would I need? I'd love to build a stock rom with only the tweaks I need, I love lite ROMs and every aosp ROM feels so much faster than the others. Just feels like every ROM out there is always near perfect but has something I'd have to compromise. I'm thinking about 5.1 stock with xposed when its stable but maybe a self built ROM would be better if I am able to build it.
cyberdude020 said:
Do I need to use Linux to build? So I'd need a vm with umbuntu? how much ram would I need? I'd love to build a stock rom with only the tweaks I need, I love lite ROMs and every aosp ROM feels so much faster than the others. Just feels like every ROM out there is always near perfect but has something I'd have to compromise. I'm thinking about 5.1 stock with xposed when its stable but maybe a self built ROM would be better if I am able to build it.
Click to expand...
Click to collapse
Yes, you will be building on Linux. RAM isn't a huge issue, even 4GB would probably be more than enough. If you have a very poor performing CPU however, it'll probably take many hours for the first clean build.
Elluel said:
Yes, you will be building on Linux. RAM isn't a huge issue, even 4GB would probably be more than enough. If you have a very poor performing CPU however, it'll probably take many hours for the first clean build.
Click to expand...
Click to collapse
OK thanks, I have six core at 3.5 GHz and 4gb of ram, used to have 8gb but one stick went bad. I could always buy another 4gb stick if i run low on memory. I'll look at some YouTube videos to see if it looks like something I could do.
cyberdude020 said:
OK thanks, I have six core at 3.5 GHz and 4gb of ram, used to have 8gb but one stick went bad. I could always buy another 4gb stick if i run low on memory. I'll look at some YouTube videos to see if it looks like something I could do.
Click to expand...
Click to collapse
Your CPU is fairly decent. Some people have built on cheap/thin laptops (Intel Atom, etc..) and it takes them 12-24 hours for a clean build.
If you're running in a VM and your entire system only has 4GB it could possibly be an issue if you're unlucky, but running it natively should definitely be fine.
I wouldn't look at YouTube videos as they are probably much harder to follow. There are plenty of written guides on XDA, a quick Google search will yield many results.
---------- Post added at 12:46 ---------- Previous post was at 12:18 ----------
p3ntyne said:
Thanks, but it seems like the method of creating my own repo would be easier. I'm just confused about the manifest and if I should clone AOSP into my repo...
Click to expand...
Click to collapse
You can clone the AOSP manifest I guess (5.0.2: https://android.googlesource.com/platform/manifest/+/refs/heads/android-5.0.2_r1)
Then create a new branch in the manifest, call it whatever you like (when you init from this manifest, you'll reference the manifest branch, e.g. to init from mine, you use "repo init -u https://github.com/Elluel/elluel_manifest.git -b lollipop", where "lollipop" is the my manifest branch's name).
If you look at default.xml (https://android.googlesource.com/platform/manifest/+/refs/heads/android-5.0.2_r1/default.xml), then look at mine (https://github.com/Elluel/elluel_manifest/blob/lollipop/default.xml), you will see a difference.
The beginning part defines remote locations.
e.g. in mine I have additionally added:
Code:
<remote name="rascarlo"
fetch="git://github.com/rascarlo/" />
<remote name="Elluel"
fetch="git://github.com/Elluel/" />
<remote name="lichti1901"
fetch="git://github.com/lichti1901/" />
<remote name="CyanogenMod"
fetch="git://github.com/CyanogenMod/" />
<remote name="linaro"
fetch="git://github.com/ArchiDroid" />
Then if we look at the referenced projects:
I'll use frameworks/base as an example, line 282 in the AOSP default.xml:
Code:
<project path="frameworks/base" name="platform/frameworks/base" groups="pdk-cw-fs" />
then if we look at mine:
Code:
<project path="frameworks/base" name="android_frameworks_base" groups="pdk-cw-fs" remote="Elluel" revision="lollipop" />
"path" is the directory the project will be stored when manifest is synced from (you'll usually leave this alone)
"name" is the name/location of the remote repo (note my Github uses "android_frameworks_base" instead of "platform/frameworks/base" so I changed it here as such)
"remote" is the remote to fetch it from, as defined at the beginning of the manifest (in this case "Elluel", which was defined as "git://github.com/Elluel")
"revision" is the branch of the remote repo to sync from (if you look at my android_frameworks_base, my main branch is named "lollipop")
If the remote or revision is not defined, it will use the default revision, which is also at the beginning of the manifest with the remotes, in the "default" tag (best to leave this alone unless you want to fork/clone every single AOSP repo and keep up with them all lol..):
Code:
<default revision="refs/tags/android-5.0.2_r1"
remote="aosp"
sync-j="8" />
You'll probably fork/clone the AOSP repos then push them to your Github, create your new manifest branch then add your Github remote, and point the projects at your Github repos + branches instead of AOSP.
Elluel said:
Your CPU is fairly decent. Some people have built on cheap/thin laptops (Intel Atom, etc..) and it takes them 12-24 hours for a clean build.
If you're running in a VM and your entire system only has 4GB it could possibly be an issue if you're unlucky, but running it natively should definitely be fine.
I wouldn't look at YouTube videos as they are probably much harder to follow. There are plenty of written guides on XDA, a quick Google search will yield many results.
---------- Post added at 12:46 ---------- Previous post was at 12:18 ----------
You can clone the AOSP manifest I guess (5.0.2: https://android.googlesource.com/platform/manifest/+/refs/heads/android-5.0.2_r1)
Then create a new branch in the manifest, call it whatever you like (when you init from this manifest, you'll reference the manifest branch, e.g. to init from mine, you use "repo init -u https://github.com/Elluel/elluel_manifest.git -b lollipop", where "lollipop" is the my manifest branch's name).
If you look at default.xml (https://android.googlesource.com/platform/manifest/+/refs/heads/android-5.0.2_r1/default.xml), then look at mine (https://github.com/Elluel/elluel_manifest/blob/lollipop/default.xml), you will see a difference.
The beginning part defines remote locations.
e.g. in mine I have additionally added:
Code:
<remote name="rascarlo"
fetch="git://github.com/rascarlo/" />
<remote name="Elluel"
fetch="git://github.com/Elluel/" />
<remote name="lichti1901"
fetch="git://github.com/lichti1901/" />
<remote name="CyanogenMod"
fetch="git://github.com/CyanogenMod/" />
<remote name="linaro"
fetch="git://github.com/ArchiDroid" />
Then if we look at the referenced projects:
I'll use frameworks/base as an example, line 282 in the AOSP default.xml:
Code:
<project path="frameworks/base" name="platform/frameworks/base" groups="pdk-cw-fs" />
then if we look at mine:
Code:
<project path="frameworks/base" name="android_frameworks_base" groups="pdk-cw-fs" remote="Elluel" revision="lollipop" />
"path" is the directory the project will be stored when manifest is synced from (you'll usually leave this alone)
"name" is the name/location of the remote repo (note my Github uses "android_frameworks_base" instead of "platform/frameworks/base" so I changed it here as such)
"remote" is the remote to fetch it from, as defined at the beginning of the manifest (in this case "Elluel", which was defined as "git://github.com/Elluel")
"revision" is the branch of the remote repo to sync from (if you look at my android_frameworks_base, my main branch is named "lollipop")
If the remote or revision is not defined, it will use the default revision, which is also at the beginning of the manifest with the remotes, in the "default" tag (best to leave this alone unless you want to fork/clone every single AOSP repo and keep up with them all lol..):
Code:
<default revision="refs/tags/android-5.0.2_r1"
remote="aosp"
sync-j="8" />
You'll probably fork/clone the AOSP repos then push them to your Github, create your new manifest branch then add your Github remote, and point the projects at your Github repos + branches instead of AOSP.
Click to expand...
Click to collapse
Thanks! I just reset the VM so I could start fresh and typed in
Code:
repo init -u https://github.com/p3ntyne/Lollipop-ROM.git
(which is the name of the repo I created). The only issue I'm having is that it says:
Code:
fatal: manifest 'default.xml' not available
fatal: manifest default.xml not found
p3ntyne said:
Thanks! I just reset the VM so I could start fresh and typed in
Code:
repo init -u https://github.com/p3ntyne/Lollipop-ROM.git
(which is the name of the repo I created). The only issue I'm having is that it says:
Code:
fatal: manifest 'default.xml' not available
fatal: manifest default.xml not found
Click to expand...
Click to collapse
If you look here: https://github.com/p3ntyne/Lollipop-ROM
You're missing a default.xml, you can clone/fork/whatever it from the AOSP version tree you're building, then create a new branch in your manifest repo and modify it from there.
Elluel said:
If you look here: https://github.com/p3ntyne/Lollipop-ROM
You're missing a default.xml, you can clone/fork/whatever it from the AOSP version tree you're building, then create a new branch in your manifest repo and modify it from there.
Click to expand...
Click to collapse
Right. Well I forked Android but it created an entirely new repository. Is that what's supposed to happen? Anyway, I created a new branch named "Modifications" but I want to make sure It's correct before I sync it. BTW, the new repository is called 'p3ntyne/android'. Can I change the name to the name of my ROM? (Sorry if I'm annoying but I'm compeletely new to modifying any source code despite having done some development before!)
And, how do you think building would be on a computer with a 1.7 - 3.3GHz i7 with a VM assigned to 2 threads, 6 Gb's RAM and 200 GB SSD space?
Thanks for all your help so far!
p3ntyne said:
Right. Well I forked Android but it created an entirely new repository. Is that what's supposed to happen? Anyway, I created a new branch named "Modifications" but I want to make sure It's correct before I sync it. BTW, the new repository is called 'p3ntyne/android'. Can I change the name to the name of my ROM? (Sorry if I'm annoying but I'm compeletely new to modifying any source code despite having done some development before!)
And, how do you think building would be on a computer with a 1.7 - 3.3GHz i7 with a VM assigned to 2 threads, 6 Gb's RAM and 200 GB SSD space?
Thanks for all your help so far!
Click to expand...
Click to collapse
You forked Github's Android app, not AOSP source LOL
You want to fork the AOSP manifest repo (relevant to the Android version), create a new branch on it, then point it at your own other repos, as shown in my previous post (then push it to your Github of course).
You can name a repo whatever you want as long as the manifest points to it's name correctly (most people leave this alone to avoid confusion when other people look at it).
Your initial build ("clean") will probably take around 3–6 hours (maybe more), subsequent builds ("dirty") should be much faster, as if you have it set up correctly, it'll only need to recompile parts that were changed.
Elluel said:
You forked Github's Android app, not AOSP source LOL
You want to fork the AOSP manifest repo (relevant to the Android version), create a new branch on it, then point it at your own other repos, as shown in my previous post (then push it to your Github of course).
You can name a repo whatever you want as long as the manifest points to it's name correctly (most people leave this alone to avoid confusion when other people look at it).
Your initial build ("clean") will probably take around 3–6 hours (maybe more), subsequent builds ("dirty") should be much faster, as if you have it set up correctly, it'll only need to recompile parts that were changed.
Click to expand...
Click to collapse
Ok. So I think I understand now. So I run repo init to the original google source, then create a branch and then link that branch to my github (somehow?!) Is that right?
p3ntyne said:
Ok. So I think I understand now. So I run repo init to the original google source, then create a branch and then link that branch to my github (somehow?!) Is that right?
Click to expand...
Click to collapse
1. You init and sync to AOSP source
2. Create a new branch in the manifest
3. Push your manifest to a Github repo.
Then when you modify other parts/repos of the source:
1. Create a branch then push that to another new Github repo
2. Point your manifest at this new Github repo (as my previous posts described)
If you're still confused look at my Github's manifest, then look at my other Github repositories, it might give you a general idea.
Elluel said:
1. You init and sync to AOSP source
2. Create a new branch in the manifest
3. Push your manifest to a Github repo.
Then when you modify other parts/repos of the source:
1. Create a branch then push that to another new Github repo
2. Point your manifest at this new Github repo (as my previous posts described)
If you're still confused look at my Github's manifest, then look at my other Github repositories, it might give you a general idea.
Click to expand...
Click to collapse
Thanks - that makes more sense. So, just to summarise once more, once repo sync is finished, I navigate to the manifest and type repo start (name of the branch) . ? And then repo upload to push it to github? How will it know to go into my one?
Thanks again.
Related
Hello everyone,
This morning I used repo to get cyanogenmod repository from github (10go!!!) and I was able to build cm from source for the first time.
I now have a pretty update-cm-7.2.0-RC0-glacier-KANG-signed.zip I could flash to my phone.
All credit go to CM team and to sykopompos' tutorial :
http://forum.xda-developers.com/showthread.php?t=915435
My next goal is to create a kang which is :
- A barebone CM7 (strip everything I can)
- minimalbread theme as default
I have a couple of questions and I'm seeking help.
1- What is the best way to work on some part of CM7 ? Fork each parts on github ? Use git manually or continue with repo ?
2- repo tool fetched everything from github. The device folder contains code for other phone than glacier. Can I delete them without issue ?
3- Do you have essential docs I could read to get familiar with folder structure, important config file, etc.
4- To learn, I'm searching easy modifications I can make. Any ideas ?
Some info :
I already have a github account and I'm working on Archlinux64.
Android SDK, eclipse and others dev tools are installed.
I'm a web developer (mainly J2EE / JSF) and I'm very familiar with Java.
Thanks for your help.
Regards.
Bump + Answer to myself and maybe some others seeking the same informations...
1- What is the best way to work on some part of CM7 ? Fork each parts on github ? Use git manually or continue with repo ?
Click to expand...
Click to collapse
Easiest : start with Kitchen on compiled zip.
To work on some part, I will fork them on github.
Example, I want to mod framework-res. Safer to work with git and rollback if I mess everything.
2- repo tool fetched everything from github. The device folder contains code for other phone than glacier. Can I delete them without issue ?
Click to expand...
Click to collapse
Next repo sync they will comeback...
3- Do you have essential docs I could read to get familiar with folder structure, important config file, etc.
Click to expand...
Click to collapse
Android website is cool but I'm still searching for more...
4- To learn, I'm searching easy modifications I can make. Any ideas ?
Click to expand...
Click to collapse
I will try to ship the ROM with custom host file (block pub) and other small goodies.
11-5-13 -- See here for the start of the CM 11.0 (based on Android 4.4 KitKat) discussion.
7-27-13 --- See here for my build instructions for CyanogenMod 10.2 (based on AOSP 4.3)...
Hey all,
So I've ported my "Build CyanogenMod" instructions (Nook Color, Nook Tablet, and HP Touchpad) to the Nexus 7.
The doc basically covers unlocking the N7, getting the build environment ready, downloading source, building, installing, and updating the source. The walkthrough is for Linux, but you should be able to do it via a virtual machine running on OS X and Windows such as Virtualbox (free).
The idea is that building Android from scratch should be possible for almost anyone to learn. So this guide walks you through it.
If you're running into difficulties, this thread is a place to exchange info, tips, questions, etc.
It's also a good place to proclaim loud and clear to the world...
"I'm running an OS I built myself from source!"
Thanks to eyeballer for reviewing.
CyberCitizen said:
Sorry for my ignorance, but besides bragging rights, what is the whole point of self compiling stock cm10 for your device?
Click to expand...
Click to collapse
Off the top of my head...
You never, ever have to wait for a nightly
You can add or remove as-yet uncommitted features with ease.
You learn how Android works under the hood
You learn how to use Linux
You'll learn how to use git
You may, even accidentally, pick up a little C, Java, C++, and learn about the build system.
You can personalize Android-- make your own tweaks, replace kernels, modules, graphics, add or remove projects, overclock, underclock etc. In other words, you have control over every aspect of your device's functionality. Your build is custom to you.
You can audit the code for potential security issues such as back doors or trojans (as opposed to just trusting a random person who posts a build). Since CM10 source is open, you can examine every commit, and there are many eyes looking at the code. (does not apply to proprietary blobs, but these are pulled from your device, so you have and are using them already)
You can contribute features/fixes back upstream
You can start ports to other as-yet-unsupported devices (start by copying folders from similar devices to devices/manufacturer/model)
You come to really understand that Android phones and tablets are full-fledged general-purpose computers just like laptops and desktops.
AAAAND....you get huge bragging rights
The extent to which you delve into the above is entirely up to you. The walkthrough is just an introduction to that world. If N7 is anything like the NookColor/NookTablet/TouchPad, some people will build once and never do it again... but others will start to tinker and make changes to their own build and want to share them with others, and soon some will start making contributions back to official CM10 upstream... or port to new devices... and by fixing bugs and all this... everyone benefits.
Plus...
It's fun.
ALSO: Here are some little bits that resulted from this thread:
Dealing with build errors
What's where in the CyanogenMod source folder
A little about make clean and make clobber
Update: A lot of the above info, as well as much more original articles, can now be found on the CyanogenMod wiki. So check there, especially the dev center.
That's it! Happy building!
How to Build CM10.1 Instructions for the Nexus 7 (CM Wiki version)
Addendum for CyanogenMod 10.2
Highly recommend fattires walkthrough. I was a total noob when I had the nook color and he initially made a build from source guide but now I know the basics and can make personal builds for my nexus 7 and epic 4g touch
Sent from my Nexus 7 using Tapatalk 2
Totally forgot I reserved this spot lol. Anyways great guide fattire. For those of u that want to learn how to build from source whether its cm, aokp, bamf, aosp or whatever u want to build this guide is a great start. While this guide is strictly for CM it will give u an understanding of the steps of building from source. Great work again fattire.
Highly highly highly recommend for anyone that loves to flash ROMs, but never built one before. fattire is one of several who have done absolute wonders for the Nook Color community. Not just developing for the device, but pulling people together to get this stuff running. :good:
I am one of the obsessives who almost didn't buy this machine when I saw they yanked the sdcard. But when fat-tire said he was getting one, I immediately went to the Play store.
His walk-thru for encore ICS was how I first learned to build. I have been building CM10 for my grouper for several weeks, although the repo sync was incomplete. I ended up having to write m own cm.mk files as well as several other weird little changes in order to make it boot. Glad those changes are finally checked I, I am going to delete my home-baked files so I can get any changes from upstream.
I have an issue I am hoping you can shed some light one, fat-tire. Inconsistencies in the ContentResolver file between my builds and those in Official Cyanogen night lies. I haven't seen any commits that change those files.
I have asked eyeballer about it, but he isn't sure either. I am building a clobber right now, but if I still have the issue, I will post particulars.
I am real glad to see you here...it has been a pretty wild and wooly forum thus far...
Whoa. How come this thread got moved from Nexus 7 Android Development to Nexus 7 General? I can't think of anything more Develop-y than building Android.
In any event- thanks all for the kind words. Mateorod, not sure from your description what issue you're having. I'll def. need more specifics.
Glad you got the N7? I am-- I use it for hours daily...
mateorod said:
I am one of the obsessives who almost didn't buy this machine when I saw they yanked the sdcard. But when fat-tire said he was getting one, I immediately went to the Play store.
His walk-thru for encore ICS was how I first learned to build. I have been building CM10 for my grouper for several weeks, although the repo sync was incomplete. I ended up having to write m own cm.mk files as well as several other weird little changes in order to make it boot. Glad those changes are finally checked I, I am going to delete my home-baked files so I can get any changes from upstream.
I have an issue I am hoping you can shed some light one, fat-tire. Inconsistencies in the ContentResolver file between my builds and those in Official Cyanogen night lies. I haven't seen any commits that change those files.
I have asked eyeballer about it, but he isn't sure either. I am building a clobber right now, but if I still have the issue, I will post particulars.
I am real glad to see you here...it has been a pretty wild and wooly forum thus far...
Click to expand...
Click to collapse
Hey, n00b builder here. First off big thanks for posting the guide I'm afraid I'm having a problem though. Once I've sync'd the cyanogenmod repo I don't seem to have "asus/grouper" in my device folder. Any idea what I could've done wrong?
Try this...
h00py said:
Hey, n00b builder here. First off big thanks for posting the guide I'm afraid I'm having a problem though. Once I've sync'd the cyanogenmod repo I don't seem to have "asus/grouper" in my device folder. Any idea what I could've done wrong?
Click to expand...
Click to collapse
Did you try the "lunch grouper" command? (you have to do . build/envsetup.sh first as described in the documents)
If this command doesn't work, you may need to add these directories to the repository manifest (a list of all the different projects that make up CM10). To add it to the list, try creating a file called local_manifest.xml in the .repo directory (it is a hidden directory as it starts with a period) and put this in the file:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote fetch="git://github.com/" name="gh" review="review.cyanogenmod.com" />
<project name="CyanogenMod/android_kernel_asus_grouper" path="kernel/asus/grouper" remote="github" revision="jellybean" />
<project name="CyanogenMod/android_device_asus_grouper" path="device/asus/grouper" remote="github" revision="jellybean" />
</manifest>
Alternately, you can do it this way from your root (~/android/system or wherever you put the source)
Code:
curl https://raw.github.com/gist/dcef0eadc4c8d31ae46d/d27a0cc718607b1a6e4958f9d0e57887b2eb4eb3/gistfile1.xml > .repo/local_manifest.xml
This local_manifest.xml file will add the needed grouper repos to the manifest. So then just repo sync again and see if they show up. If so, let me know and I'll add it to the instructions.
Update: I added it to the instructions. Let me know if it works. At some point these will be added to the official manifest so the local_manifest.xml won't be needed.
Deleted my whole source folder and started again following the updated instructions. Everything worked fine this time. It's building now and I'll report back if/when it finishes.
Thanks again for the help
h00py said:
Deleted my whole source folder and started again following the updated instructions. Everything worked fine this time. It's building now and I'll report back if/when it finishes.
Thanks again for the help
Click to expand...
Click to collapse
Heh np. Thought you didn't need to delete the folder-- the nice thing about repo sync is that it will update everything automatically, even if you change the manifest
As a linux nerd, I thank you.
TWRP2 instead of CWM
So we're back in the Android Development forum.
Update: I hear there's a non-N7-specific permissions issue (the build sets perm 0600 on /tmp) when building TWRP2 in jellybean source. Until this is resolved, consider the below purely informational. In other words, don't try it yet until the code is updated. (Thanks, eyeballer for letting me know)
-----
Here's another quick tip-- if you want to build TWRP2 recovery instead of ClockworkMod recovery for the Nexus 7, add the following two lines to the local_manifest.xml file (where the similar-looking lines are):
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project path="bootable/recovery" name="TeamWin/Team-Win-Recovery-Project" remote="github" revision="master"/>
Assuming I typed that right, when you repo sync, this will replace the cwm source with the twrp source. When you then do your next build, your recovery.img in $OUT will be TWRP2. It can then be flashed with fastboot per the instructions.
Build competed & flashed with no problems. :victory:
/proud
Welcome to the club!
h00py said:
Build competed & flashed with no problems. :victory:
/proud
Click to expand...
Click to collapse
Woo! Congrats! :cyclops:
Now that you have your build going, you can try out some of the experimental commits that are sitting on CyanogenMod's code review site. These are commits with new features and bugfixes that may be experimental but need people to try them and report back if they work or not.
If you're interested in risking everything, first go to review.cyanogenmod.com AKA Gerrett and find a proposed commit that looks interesting. Read any comments or caveats that may apply, and have a look at the code itself to make sure it looks okay. Each proposed commit is part of a specific git project, listed under "Project", that correspond to directories in your source code. For example, CyanogenMod/android_frameworks_base corresponds to the repository in frameworks/base.
To try one, click on the little brown icon halfway down the web page under Downloads, on the right. This will copy the instructions to the left to the copy buffer. Then, cd to the appropriate repository directory in your source code and paste the command. It should download and commit the patch. You can check it by typing "git log" and looking for the commit at the top of the list.
If all went well, you can rebuild and hopefully will see your change in the new build. The next time you repo sync, the commit you made will be lost (unless the proposed commit actually was merged into mainstream), so if you want it again, you'll need to re-download it using the method described above.
That's it! Way to stay bleeding edge!
Hello, I have never built a rom from source before but I will use this guide and try it out. Specially since I want to use linaro.
Do you think you could link me or help me get this working? As far as I understand instead of using g++ or so I woudl use the linaro tools to compile and so. How much different would this be from your instructions?
How can I get linaro?
I'll be researching into this but I hope you can provide an answer.
Rafase282 said:
Hello, I have never built a rom from source before but I will use this guide and try it out. Specially since I want to use linaro.
Do you think you could link me or help me get this working? As far as I understand instead of using g++ or so I woudl use the linaro tools to compile and so. How much different would this be from your instructions?
How can I get linaro?
I'll be researching into this but I hope you can provide an answer.
Click to expand...
Click to collapse
I built linaro optimized cm9 for nookcolor (OMAP3) a few months back (thread starts around here). Some of the linaro optimizations to libc and the frameworks already have been added to the ICS source and I assume the Jellybean source has it already too for CM10 (and they have been adopted upstream by Google I believe as well). I haven't tried to build the grouper kernel using 4.7-- the 2.6.32 kernel and 3.0.8 kernels for NT and NC required a few minor changes-- the grouper kernel may or may not need them... but I know what to do if someone wants to try it.
Before trying linaro stuff, I would focus first on getting the build to work normally. Familiarize yourself with the process, and then investigate linaro. The system is so ridiculously fast IMO... I guess even faster is better, but I don't have any complaints
fattire said:
I built linaro optimized cm9 for nookcolor (OMAP3) a few months back (thread starts around here). Some of the linaro optimizations to libc and the frameworks already have been added to the ICS source and I assume the Jellybean source has it already too for CM10 (and they have been adopted upstream by Google I believe as well). I haven't tried to build the grouper kernel using 4.7-- the 2.6.32 kernel and 3.0.8 kernels for NT and NC required a few minor changes-- the grouper kernel may or may not need them... but I know what to do if someone wants to try it.
Before trying linaro stuff, I would focus first on getting the build to work normally. Familiarize yourself with the process, and then investigate linaro. The system is so ridiculously fast IMO... I guess even faster is better, but I don't have any complaints
Click to expand...
Click to collapse
I'm currently downloading source. It is taking its sweet time. ... nvm it just finished.
But I'm going to try to build and if everything goes well I will check into "cherry picking" and make my own personal custom build. I want to use linaro for the rom and kernel.
---------- Post added at 06:08 AM ---------- Previous post was at 05:10 AM ----------
fattire said:
So we're back in the Android Development forum.
Update: I hear there's a non-N7-specific permissions issue (the build sets perm 0600 on /tmp) when building TWRP2 in jellybean source. Until this is resolved, consider the below purely informational. In other words, don't try it yet until the code is updated. (Thanks, eyeballer for letting me know)
-----
Here's another quick tip-- if you want to build TWRP2 recovery instead of ClockworkMod recovery for the Nexus 7, add the following two lines to the local_manifest.xml file (where the similar-looking lines are):
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project path="bootable/recovery" name="TeamWin/Team-Win-Recovery-Project" remote="github" revision="master"/>
Assuming I typed that right, when you repo sync, this will replace the cwm source with the twrp source. When you then do your next build, your recovery.img in $OUT will be TWRP2. It can then be flashed with fastboot per the instructions.
Click to expand...
Click to collapse
mkdir -p out/target/product/grouper/recovery/root/res/
host C: libz <= external/zlib/zutil.c
cp -fr bootable/recovery/gui/devices/common/res/* out/target/product/grouper/recovery/root/res/
cp -fr bootable/recovery/gui/devices//res/* out/target/product/grouper/recovery/root/res/
cp: cannot stat `bootable/recovery/gui/devices//res/*': No such file or directory
make: *** [out/target/product/grouper/obj/STATIC_LIBRARIES/libgui_intermediates/twrp] Error 1
make: *** Waiting for unfinished jobs....
[email protected]:~/android/system$
yup I should have read the whole post
---------- Post added at 06:30 AM ---------- Previous post was at 06:08 AM ----------
I reverted back but im still having problem building.
fattire said:
Whoa. How come this thread got moved from Nexus 7 Android Development to Nexus 7 General? I can't think of anything more Develop-y than building Android.
In any event- thanks all for the kind words. Mateorod, not sure from your description what issue you're having. I'll def. need more specifics.
Glad you got the N7? I am-- I use it for hours daily...
Click to expand...
Click to collapse
Ha, I lost the thread. They shouldn't play like that.
Yeah, I am glad. I have a project that requires java on-device, and the Nook just couldn't quite make it. But this thing can crunch through it, been though the temp spikes almost 20 degrees in the process!
I don't really want to derail all these first time Android ninjas coming out efforts. I have fund a workaround of sorts. It is just that I port some software to end users by decompiling system apps from patched builds, creating patches and applying them to end-user ROMs. Kind of a way fr people who don't or can't build to have access to certain software.
This process works like a charm on unofficial builds from any source. I pretty much could guarantee successful patching on CM9 night lies. But whenever an official RC or Final would come out, the patches would never work for those builds, while continuing to work for unofficials of the same day as well as the surrounding.
The same thing has just happened for official JB nightlies. We have tried matching the builds commit for commit, the whole thing.
I went into greater depth than I intended. If you know, awesome, if not, I will go start a thread somewhere and take it up there. This thread has a grander purpose.
Thanks!
definitely gonna give this a go on my next day off.
I started over, fresh ubuntu install and everything, I follow the steps and while it is building the computer just shutdown.
I turn it back one and try again and then I get errors.
I'm going to try again redoing the steps to see if that will fix anything.
When getting the blobs from my device I get this.
Pulling /system/vendor/lib/libwvm.so to ../../../vendor/asus/grouper/proprietary
remote object '/system/vendor/lib/libwvm.so' does not exist
Edit: got it from a stock rom I guess this is cause I'm using EOS build.
My N7 3G (tilipea) is running Android 4.4.3. I am trying to do a kernel mod. I want the source code on my Ubuntu VM. This table tells me to look in kernel/tegra, but the master branch is empty, and all of the other branches have similar names, so I have no idea which one to use.
Also, I noticed the table says to use device/asus/grouper, even for tilipea, but a also saw a folder for tilipea, and it has less files and folders in it. Do grouper and tilipea both share the grouper kernel?
In the table, what is the difference between Binary location, Source location, and Build configuration? I think Binary location is the firmware source and Source location is the kernel source. What is Build configuration? Where is the source for the bootloader and baseband?
Why are repositorys so unorganized?
Sorry if those are dumb questions, I am new. Thank you
git clone the kernle/tegra repo and the checkout to the last commit.
Use the tegra3_android_defconfig to build.
Cheers.
Hey folks,
i'm trying to get a "vanilla" aka unmodified device tree for the Shield Tablet K1. I know that you can sync over from nvidia's gitweb, tough the device tree is looking weird.
When i look at let's say cm's android_device_nvidia_shieldtablet it looks different. So i wonder how i would go from nvidias mutated tree to cm's layout without actually just forking it from cm.
Reason is, i want to port another custom rom over to the shield tablet, but i can't neither figure out how i'd do that with nvidias sources, nor how i would create a device tree similar to cm's, without any modifications.
I googled around for about 2-3 months now and still have no clue, so if anyone could give me a hint, i'd be very grateful!
What's wrong with the cm tree?
Unjustified Dev did the initial port of everything by hand. I've done maintainance manually since then. And to my knowledge, there's only been one other person to do a manual conversion (vartom). All custom ROMs derive from my tree. Should work in aosp as well. If there's something you need different from the cm tree, you can just add it on top. Or if something is broke in general, I need to know and fix it.
There's nothing "wrong", just not " clean", if you catch my drift. It's just a matter of reverting inwanted things, but yeah.. feels dirty.
Anyways, thanks for the info, man.
*shrugs* Okay, if you want to set up a new tree, nothing's stopping you. I wouldn't mind someone else knowing how to do it (pretty sure I'm the only active dev that has experience there), but it's a lot of parsing and research. I'll say that CMs trees are 95% unmodified from Nvidia's upstream, though. It's just rearranged into an aosp style tree. The kernel is a merge of the console and tablet since they were 98% identical anyways. I do my best to keep everything as clean as possible since I don't want to do through the work of making a lot of modifications every time a new release comes out... Engineers are lazy like that. I think the only things that aren't pure identical copies are the LTE init files and the unified device stuff (making the wifi only and lte models work in one ROM).
Nah, don't get me wrong there, i don't want to discredit you there.
I'm more talking about cm specific things like gello browser and stuff. Like i said, just a matter of a few changes to not include these. I'm just a beginner in any way, i can just follow instructions at best, i don't know c, and almost no java at all. So what you do is an astounishing task - it's just a personal preference coming and starting with nexus devices to tinker around, i have had the luxury of an AOSP tree, that's pretty much "my dilemma". I'm unexperienced and thus this might take a while for me. I've started to modify your device tree the day before yesterday, but i have something done wrong, as when i start compiling it'll ask if it should use " full_eng" config. (6.0.1 is used)
Again, thanks for putting me in the right direction, also for your efforts in maintaining our device.
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Steel01 said:
What ROM are you trying to build? You could look at Carbonrom or Blissrom to see the rename changes needed to use the tree in a different ROM. Those should be similar across the board. I think the only CM specific package references would be gello and snap. Those commits could be reverted easily enough. Or if the ROM doesn't have them, I think they'd be ignored even if left as is.
Click to expand...
Click to collapse
I'm trying to port OmniROM https://docs.omnirom.org/Porting_Omni_To_Your_Device
Shouldn't be that difficult, i'm just doing something wrong.
kylon said:
Hi,
you can take a look at here
the base was the official cm tree, this is not vanilla but it s a K1 only tree.
Click to expand...
Click to collapse
Thank you, man.
I've forked it and will use it as a base.
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Steel01 said:
Oh, omni. I build TWRP from omni. Take a look at the following two commits.
https://github.com/TeamWin/android_...mmit/c8e564a5ea44d963ab8d0e7829d9becd2ad5b0c0
https://github.com/TeamWin/android_...mmit/9b8772627795492f3380d2bf86680c09aada92c9
I haven't built the full ROM, but that should work. If you're using a K1 specific tree, the only difference should be in omni_shieldtablet.mk, instead of gsm.mk, use whatever omni has for tablet wifi only.
Click to expand...
Click to collapse
Thank you, man. In fact i heavily orientaded on TWRP sources in this case. Also took a look at zombipop's repo.
Still whatever i do all i get is
[[email protected] omni]$ brunch shieldtablet
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
WARNING: Trying to fetch a device that's already there
Traceback (most recent call last):
File "build/tools/roomservice.py", line 352, in <module>
fetch_device(device)
File "build/tools/roomservice.py", line 320, in fetch_device
git_data = search_gerrit_for_device(device)
File "build/tools/roomservice.py", line 81, in search_gerrit_for_device
device_data = check_repo_exists(git_data, device)
File "build/tools/roomservice.py", line 58, in check_repo_exists
"exiting roomservice".format(device=device))
Exception: shieldtablet not found,exiting roomservice
build/core/product_config.mk:241: *** No matches for product "omni_shieldtablet". Stop.
** Don't have a product spec for: 'omni_shieldtablet'
** Do you have the right repo manifest?
No such item in brunch menu. Try 'breakfast'
Click to expand...
Click to collapse
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Steel01 said:
Oh, brunch won't work because it wants to sync from the upstream server. Use lunch instead. Then run make to build.
Click to expand...
Click to collapse
Looks like a derp moment, i just had to modify the devicetree in another directory which is the actual working dir, instead on androidsrc/device/nvidia/shieldtablet directly. Like i said i just did something wrong.
It' compiling now, thank you for all the support!
Here we have linage Oreo 8.1.0 built by XDA member gavin19
A working bootable lineage 8.1.0 that he hand built himself so all credit's go to him
We are needing a dev to go over and fix a few things like camera app not opening
Apart from that it seems fully functional and smooth,
Disclaimer:
We are not responsible for anything that may happen to your phone as a result of installing custom roms and/or kernels. you do so at your own risk and take the responsibility upon yourself.
Install full wipe
Flash latest firmware 8.something
Flash lineage 15.1
Flash gapps 8.1
Once os has booted go back Into recovery and flash magist 14.5 for root
Done
https://mega.nz/#F!rhpExB7L!ypCJwgXQqhQjaJ0muml1aw 15.1+ magist 14.5
https://mega.nz/#F!zlJBQJhJ!BJuv0brw0doTafuLTXJATw. Latest firmware
Thanks too.
LineageOS team
Xda member Gavin19
And all other open source Devs
Google+ community
Telegram group
ROM source
Tree of all official devices
Kernel Source
All thumbs up please send gav not me
Thank you @gavin19 for the build and thank you @mr911 for the thread :good:
omerbagi10 said:
Thank you @gavin19 for the build and thank you @mr911 for the thread :good:
Click to expand...
Click to collapse
Yeah gav is the man, he devoted alot of time to building it smart guy, I've hit quite a big issue since running Oreo 8 I've fully restored fine back to vipor os through twrp restore but I'm guessing somehow Oreo has done something to my twrp and I can't back up any more I hit error createTarFork() process ended with ERROR=255 every time I try and do a back up re flashing twrp gives the same error but firmware flashed fine,
Edit fixed*
Coming from Oreo created a file called addons.d in system, stopping me from making new backups in twrp after flashing my original vipor os backup
1 dirty flash os once your original backup restores (so you don't have to start a fresh)
2 flash gapps
3 reinstall busy box/magist .zip
4 backups work perfect.
Most important thing here is that I'm not a dev. All I did was follow the build guide to the letter. After the initial 'breakfast lithium' stage, I copied this manifest into the .repo/local_manifests folder, ran 'repo sync' again, ran 'breakfast lithium' again then continued with the guide to the end.
Note, you'll need ~170GB of HDD space to build (unless you start trimming some packages). Build time for me with a 4690k at 4.4GHz/16GB RAM and on an SSD was still just over 3 hours.
The build isn't optimised (better toolchain, no removed packages to speed up build process etc) but it was pretty smooth. Not AICP smooth, but pretty close.
For installation I had to remove the device check because our working TWRP builds won't let it install (error 7). You'll need a recent firmware too. Another quirk is that if you try to install GApps immediately after flashing the ROM (for me at least) it complained that it was the incorrect Android version (once reported 7.1.2, then 6.0.0??), and it wouldn't boot properly. What you'll need to do is boot into the ROM and go through the usual setup then reboot and flash GApps and it'll work fine. For root, only Magisk 14.5 worked for me.
Calls, wi-fi, DT2W, sound etc all work.
Camera is broken. Vibrate only works partially (not on tap for example). Keyboard sometimes defaults to voice search for some reason. I didn't find any other issues except that I couldn't install apks from any other file manager than the Lineage one.
This was just a proof of concept. I was asking myself for months why the Mi Max (a bargain Mi Mix) and other Xiaomi devices have several Oreo ROMs (and with working cam), when we had nothing. It was either we were still waiting on some update/blobs etc **or** no-one had really tried. Turned out it was the latter.
EDIT: Moved to AICP from LOS since it's LOS-based and I much prefer it. Should be released very soon.
EDIT2 : https://forum.xda-developers.com/mi-mix/development/rom-aicp-13-1-t3746648
Which one is the latest firmware 8.1.4?
camoway said:
Which one is the latest firmware 8.1.4?
Click to expand...
Click to collapse
I posted a link to all the newest firmwares in my last comment.
gavin19 said:
I posted a link to all the newest firmwares in my last comment.
Click to expand...
Click to collapse
That really helped thanks some much!
gavin19 said:
Most important thing here is that I'm not a dev. All I did was follow the build guide to the letter. After the initial 'breakfast lithium' stage, I copied this manifest into the .repo/local_manifests folder, ran 'repo sync' again, ran 'breakfast lithium' again then continued with the guide to the end.
Note, you'll need ~170GB of HDD space to build (unless you start trimming some packages). Build time for me with a 4690k at 4.4GHz/16GB RAM and on an SSD was still just over 3 hours.
The build isn't optimised (better toolchain, no removed packages to speed up build process etc) but it was pretty smooth. Not AICP smooth, but pretty close.
For installation I had to remove the device check because our working TWRP builds won't let it install (error 7). You'll need a recent firmware too. Another quirk is that if you try to install GApps immediately after flashing the ROM (for me at least) it complained that it was the incorrect Android version (once reported 7.1.2, then 6.0.0??), and it wouldn't boot properly. What you'll need to do is boot into the ROM and go through the usual setup then reboot and flash GApps and it'll work fine. For root, only Magisk 14.5 worked for me.
Calls, wi-fi, DT2W, sound etc all work.
Camera is broken. Vibrate only works partially (not on tap for example). Keyboard sometimes defaults to voice search for some reason. I didn't find any other issues except that I couldn't install apks from any other file manager than the Lineage one.
This was just a proof of concept. I was asking myself for months why the Mi Max (a bargain Mi Mix) and other Xiaomi devices have several Oreo ROMs (and with working cam), when we had nothing. It was either we were still waiting on some update/blobs etc **or** no-one had really tried. Turned out it was the latter.
Click to expand...
Click to collapse
Mate can you shoot me a log dump of your rom? So that I can help you analyze and pinpoint the camera issue.
Also, fantastic work there mate!
Sent from my MI MIX using Tapatalk
E50AK said:
Mate can you shoot me a log dump of your rom? So that I can help you analyze and pinpoint the camera issue.
Also, fantastic work there mate!
Click to expand...
Click to collapse
Been testing for an hour so far just flash light not working, and camera, YouTube app no playback,plays fine through chrome.
Can't seem to find anything else broken
gavin19 said:
Most important thing here is that I'm not a dev. All I did was follow the build guide to the letter. After the initial 'breakfast lithium' stage, I copied this manifest into the .repo/local_manifests folder, ran 'repo sync' again, ran 'breakfast lithium' again then continued with the guide to the end.
Note, you'll need ~170GB of HDD space to build (unless you start trimming some packages). Build time for me with a 4690k at 4.4GHz/16GB RAM and on an SSD was still just over 3 hours.
The build isn't optimised (better toolchain, no removed packages to speed up build process etc) but it was pretty smooth. Not AICP smooth, but pretty close.
For installation I had to remove the device check because our working TWRP builds won't let it install (error 7). You'll need a recent firmware too. Another quirk is that if you try to install GApps immediately after flashing the ROM (for me at least) it complained that it was the incorrect Android version (once reported 7.1.2, then 6.0.0??), and it wouldn't boot properly. What you'll need to do is boot into the ROM and go through the usual setup then reboot and flash GApps and it'll work fine. For root, only Magisk 14.5 worked for me.
Calls, wi-fi, DT2W, sound etc all work.
Camera is broken. Vibrate only works partially (not on tap for example). Keyboard sometimes defaults to voice search for some reason. I didn't find any other issues except that I couldn't install apks from any other file manager than the Lineage one.
This was just a proof of concept. I was asking myself for months why the Mi Max (a bargain Mi Mix) and other Xiaomi devices have several Oreo ROMs (and with working cam), when we had nothing. It was either we were still waiting on some update/blobs etc **or** no-one had really tried. Turned out it was the latter.
Click to expand...
Click to collapse
GREAT JOB!!!! :victory::victory::victory:
PLease, could you clarify?? You are saying you just synced LOS repo for lineage-15.1, then device trees (lithium and common) also from lineageos repo, blobs from TheMuppets, compiled, and it just worked and boots???
If it's like that it's great news. Means, among other things, that LOS sources for Oreo 8.1 are ready or almost almost and that if you update your worktree periodically you would be able to get a better rom just from source.
It also means that newbies like me trying for some days to build Oreo from other rom sources, AOSP ones, can still have hope
Thanks again and good job, man.
E50AK said:
Mate can you shoot me a log dump of your rom? So that I can help you analyze and pinpoint the camera issue.
Also, fantastic work there mate!
Sent from my MI MIX using Tapatalk
Click to expand...
Click to collapse
Where would it be? The closest thing I could find was a build.trace file
---------- Post added at 16:12 ---------- Previous post was at 16:03 ----------
albertoduqe said:
GREAT JOB!!!! :victory::victory::victory:
PLease, could you clarify?? You are saying you just synced LOS repo for lineage-15.1, then device trees (lithium and common) also from lineageos repo, blobs from TheMuppets, compiled, and it just worked and boots???
If it's like that it's great news. Means, among other things, that LOS sources for Oreo 8.1 are ready or almost almost and that if you update your worktree periodically you would be able to get a better rom just from source.
It also means that newbies like me trying for some days to build Oreo from other rom sources, AOSP ones, can still have hope
Thanks again and good job, man.
Click to expand...
Click to collapse
It really was just the build guide I linked to, except I changed 'repo init -u https://github.com/LineageOS/android.git -b cm-14.1' to 'repo init -u git://github.com/LineageOS/android.git -b staging/lineage-15.1'. The key was using the local manifest where I referenced specific repos/revisions (15.1 or staging/15.1, whichever was the latest). The first time I tried manually cloning those repos and literally copy pasting them into where they were meant to go, but clearly I made a mistake somewhere.
The second time i used the cache (I assigned 30GB) but it only used ~4GB and the build time was only ~10 minutes quicker. I wanted to remove a bunch of packages but I was honestly afraid of removing something essential. I'm pretty sure I could remove all the darwin packages since they're only for Mac, e.g adding these into the custom manifest
Code:
<!-- Removals -->
<remove-project name="platform/prebuilts/clang/host/darwin-x86" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.8" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.9" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/host/i686-apple-darwin-4.2.1" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/x86/x86_64-linux-android-4.9" />
<remove-project name="platform/prebuilts/python/darwin-x86/2.7.5" />
<remove-project name="platform/prebuilts/gdb/darwin-x86" />
<remove-project name="platform/prebuilts/go/darwin-x86" />
Could probably remove a bunch more to speed up the build but I'd need to be 100% sure they weren't needed.
We share the camera as several other devices too, but it's the Mi Max that I think might help us out the most given it's also Xiaomi. If someone with more knowledge could merge what they have for the cam (and so the flashlight too) then we might at least get the rear one working (I think they have a different front).
gavin19 said:
Where would it be? The closest thing I could find was a build.trace file
---------- Post added at 16:12 ---------- Previous post was at 16:03 ----------
It really was just the build guide I linked to, except I changed 'repo init -u https://github.com/LineageOS/android.git -b cm-14.1' to 'repo init -u git://github.com/LineageOS/android.git -b staging/lineage-15.1'. The key was using the local manifest where I referenced specific repos/revisions (15.1 or staging/15.1, whichever was the latest). The first time I tried manually cloning those repos and literally copy pasting them into where they were meant to go, but clearly I made a mistake somewhere.
The second time i used the cache (I assigned 30GB) but it only used ~4GB and the build time was only ~10 minutes quicker. I wanted to remove a bunch of packages but I was honestly afraid of removing something essential. I'm pretty sure I could remove all the darwin packages since they're only for Mac, e.g adding these into the custom manifest
Code:
<!-- Removals -->
<remove-project name="platform/prebuilts/clang/host/darwin-x86" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/aarch64/aarch64-linux-android-4.9" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.8" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.9" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/host/i686-apple-darwin-4.2.1" />
<remove-project name="platform/prebuilts/gcc/darwin-x86/x86/x86_64-linux-android-4.9" />
<remove-project name="platform/prebuilts/python/darwin-x86/2.7.5" />
<remove-project name="platform/prebuilts/gdb/darwin-x86" />
<remove-project name="platform/prebuilts/go/darwin-x86" />
Could probably remove a bunch more to speed up the build but I'd need to be 100% sure they weren't needed.
We share the camera as several other devices too, but it's the Mi Max that I think might help us out the most given it's also Xiaomi. If someone with more knowledge could merge what they have for the cam (and so the flashlight too) then we might at least get the rear one working (I think they have a different front).
Click to expand...
Click to collapse
https://play.google.com/store/apps/details?id=rs.pedjaapps.alogcatroot.app
Use this app and select the share or save button from the options menu.
Sent from my MI MIX using Tapatalk
E50AK said:
Where would it be? The closest thing I could find was a build.trace file
---------- Post added at 16:12 ---------- Previous post was at 16:03 ----------
It really was just the build guide I linked to, except I changed 'repo init -u https://github.com/LineageOS/android.git -b cm-14.1' to 'repo init -u git://github.com/LineageOS/android.git -b staging/lineage-15.1'. The key was using the local manifest where I referenced specific repos/revisions (15.1 or staging/15.1, whichever was the latest). The first time I tried manually cloning those repos and literally copy pasting them into where they were meant to go, but clearly I made a mistake somewhere.
The second time i used the cache (I assigned 30GB) but it only used ~4GB and the build time was only ~10 minutes quicker. I wanted to remove a bunch of packages but I was honestly afraid of removing something essential. I'm pretty sure I could remove all the darwin packages since they're only for Mac, e.g adding these into the custom manifest
https://play.google.com/store/apps/details?id=rs.pedjaapps.alogcatroot.app
Use this app and select the share or save button from the options menu.
Click to expand...
Click to collapse
Yh I keep seeing camera outlined in red
mr 911 said:
Yh I keep seeing camera outlined in red
Click to expand...
Click to collapse
Okay, thanks. Are you guys available in telegram? It'd be more convenient for us to discuss over there. If yes, add me up - @AKWiro
Sent from my MI MIX using Tapatalk
gavin19 said:
Where would it be? The closest thing I could find was a build.trace file
---------- Post added at 16:12 ---------- Previous post was at 16:03 ----------
It really was just the build guide I linked to, except I changed 'repo init -u https://github.com/LineageOS/android.git -b cm-14.1' to 'repo init -u git://github.com/LineageOS/android.git -b staging/lineage-15.1'. The key was using the local manifest where I referenced specific repos/revisions (15.1 or staging/15.1, whichever was the latest). The first time I tried manually cloning those repos and literally copy pasting them into where they were meant to go, but clearly I made a mistake somewhere.
The second time i used the cache (I assigned 30GB) but it only used ~4GB and the build time was only ~10 minutes quicker. I wanted to remove a bunch of packages but I was honestly afraid of removing something essential. I'm pretty sure I could remove all the darwin packages since they're only for Mac, e.g adding these into the custom manifest
Could probably remove a bunch more to speed up the build but I'd need to be 100% sure they weren't needed.
We share the camera as several other devices too, but it's the Mi Max that I think might help us out the most given it's also Xiaomi. If someone with more knowledge could merge what they have for the cam (and so the flashlight too) then we might at least get the rear one working (I think they have a different front).
Click to expand...
Click to collapse
Would you mind sharing which projects you put in your local manifest? A copy-paste of the content would be great
Also if you guys don't mind adding me to telegram... I've been in contact with E50AK for a while now working on several nougat builds...
By the way camera errors point to camera service manager... E50AK is much better than me at logs but that points at some basic piece of camera drivers missing... Will need much more in depth work though...
---------- Post added at 07:09 PM ---------- Previous post was at 06:45 PM ----------
As I said I am by no means an expert but for the camera I would personally start looking at what this line points:
E/[email protected](15065): Could not get passthrough implementation for ...
Where do the hardware/camera repo comes from? Is it Lineage? Maybe you could try removing that one if it is lineage and syncing google's one... But I'm talking without real good knowledge...
albertoduqe said:
Would you mind sharing which projects you put in your local manifest? A copy-paste of the content would be great
Also if you guys don't mind adding me to telegram... I've been in contact with E50AK for a while now working on several nougat builds...
By the way camera errors point to camera service manager... E50AK is much better than me at logs but that points at some basic piece of camera drivers missing... Will need much more in depth work though...
---------- Post added at 07:09 PM ---------- Previous post was at 06:45 PM ----------
As I said I am by no means an expert but for the camera I would personally start looking at what this line points:
E/[email protected](15065): Could not get passthrough implementation for ...
Where do the hardware/camera repo comes from? Is it Lineage? Maybe you could try removing that one if it is lineage and syncing google's one... But I'm talking without real good knowledge...
Click to expand...
Click to collapse
This is the local manifest I used - https://raw.githubusercontent.com/gavin19/manifest/master/manifest.xml
The local_manifest folder only gets created after the first run of 'breakfast lithium', then I pasted it into that folder and ran 'repo sync' again to pull those down.
I went back to AICP so I can't even dump any logs from Oreo.
As for the camera, I tried looking at the Mi Max ROMs to see if their repos had any different camera-related entries. I found some like this, but whether they would make any difference is unknown. The thing is, I don't want to run blind 3-hour builds on the off chance that something might work or not. I need to figure out how to reduce build time (aside from the ccache which I've already implemented). Surely it shouldn't take ~3 hours?
On that topic, since my out folder is already populated with ~28GB of files, how would I go about cleaning that up for a new build. Should I just delete it or ...? Are there any other folders I should remove before trying further builds or any commands that i should run?
gavin19 said:
This is the local manifest I used - https://raw.githubusercontent.com/gavin19/manifest/master/manifest.xml
The local_manifest folder only gets created after the first run of 'breakfast lithium', then I pasted it into that folder and ran 'repo sync' again to pull those down.
I went back to AICP so I can't even dump any logs from Oreo.
As for the camera, I tried looking at the Mi Max ROMs to see if their repos had any different camera-related entries. I found some like this, but whether they would make any difference is unknown. The thing is, I don't want to run blind 3-hour builds on the off chance that something might work or not. I need to figure out how to reduce build time (aside from the ccache which I've already implemented). Surely it shouldn't take ~3 hours?
On that topic, since my out folder is already populated with ~28GB of files, how would I go about cleaning that up for a new build. Should I just delete it or ...? Are there any other folders I should remove before trying further builds or any commands that i should run?
Click to expand...
Click to collapse
I'll look into the local folder and the rest you say. I've always had to create it manually as haven't built any supported devices from any rom source (what would be the point other than in a situation like we have with Mix and oreo?)
Although I know some guys around here will be much more helpful than myself with the logs and ideas to fix camera, I can see that what you share is just a camera package, that is, the app that uses the hardware. The problem in the rom is at the driver level, I think, and will probably be fixed changing some stuff in hardware or whereabouts...
As to building time and resources: if you didn't erase your working dir, after the first build compiling can take as little as 15 minutes, or up to say 30, depending on the amount of modifications to your sources. The big thing you already did and will not take so long until you make clobber before another one.
---------- Post added at 08:24 PM ---------- Previous post was at 07:55 PM ----------
gavin19 said:
This is the local manifest I used - https://raw.githubusercontent.com/gavin19/manifest/master/manifest.xml
The local_manifest folder only gets created after the first run of 'breakfast lithium', then I pasted it into that folder and ran 'repo sync' again to pull those down.
I went back to AICP so I can't even dump any logs from Oreo.
As for the camera, I tried looking at the Mi Max ROMs to see if their repos had any different camera-related entries. I found some like this, but whether they would make any difference is unknown. The thing is, I don't want to run blind 3-hour builds on the off chance that something might work or not. I need to figure out how to reduce build time (aside from the ccache which I've already implemented). Surely it shouldn't take ~3 hours?
On that topic, since my out folder is already populated with ~28GB of files, how would I go about cleaning that up for a new build. Should I just delete it or ...? Are there any other folders I should remove before trying further builds or any commands that i should run?
Click to expand...
Click to collapse
I found this line strange in your local manifest:
<project name="LineageOS/android_hardware_qcom_media" path="device/qcom/media" remote="github" revision="staging/lineage-15.1" />
Did it came like this after breakfast you say? Cause that is a hardware project that exists already in the manifest.xml and goes to hardware/qcom/media and here it goes to device/qcom... Curious...
Might be one of the things making it work...
albertoduqe said:
I found this line strange in your local manifest:
<project name="LineageOS/android_hardware_qcom_media" path="device/qcom/media" remote="github" revision="staging/lineage-15.1" />
Did it came like this after breakfast you say? Cause that is a hardware project that exists already in the manifest.xml and goes to hardware/qcom/media and here it goes to device/qcom... Curious...
Might be one of the things making it work...
Click to expand...
Click to collapse
The manifest file was added by me. The 'breakfast' command only generates the local_manifests folder, but it doesn't add anything to it. I just discovered that that was where custom manifests are supposed to go.
I copied that manifest from another Oreo project (can't remember which offhand) and just replaced the device names to lithium and the revisions to whichever were the latest for the corresponding repos. I wasn't sure about that line either since it didn't appear to be especially relevant. The only reason I made the manifest was to make sure the build process was pulling in all the lithium-related repos since I couldn't find reference to them elsewhere.
gavin19 said:
The manifest file was added by me. The 'breakfast' command only generates the local_manifests folder, but it doesn't add anything to it. I just discovered that that was where custom manifests are supposed to go.
I copied that manifest from another Oreo project (can't remember which offhand) and just replaced the device names to lithium and the revisions to whichever were the latest for the corresponding repos. I wasn't sure about that line either since it didn't appear to be especially relevant. The only reason I made the manifest was to make sure the build process was pulling in all the lithium-related repos since I couldn't find reference to them elsewhere.
Click to expand...
Click to collapse
Yeah that is the way it is when device is not supported by rom: breakfast doesn't pull anything. It does for lithium nougat but lineage 15.1 is not out, so not ready.
Well it is more than clear that you did perfect as it worked. That line puts a project in a path that's not intended for but either it doesn't conflict with anything or it somehow should be there.
Thanks for the info and replies.
Hope u keep working on it and we can help you each in its measure to make it a fully working rom!!