Database Info

[HOWTO] Build CyanogenMod 11.0 for Nexus 7

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.

WARNING: You will need TWRP configuration in your device tree soon!

Sometime in the next few days (maybe this weekend), we will be merging https://gerrit.omnirom.org/#/c/1169/
This will allow TWRP to build properly on userdebug builds. As a warning, it WILL break anyone who doesn't have TWRP config in their device tree when it is merged! (You will get errors about missing files in bootable/recovery/res if I recall correctly)
See http://forum.xda-developers.com/showthread.php?t=1943625 for info on various TWRP device tree configurations. At an absolute minimum I believe you will need the device resolution added to avoid breaking your build.
For additional details, see:
Find5:
https://gerrit.omnirom.org/#/c/1633/
Yuga:
https://gerrit.omnirom.org/#/c/1682/ (Depends on fusion3-common changes)
pollux-common (pollux_windy and pollux don't have specific items and just inherit common):
https://gerrit.omnirom.org/#/c/1155/ (Depends on fusion3-common changes)
fusion3-common:
https://gerrit.omnirom.org/#/c/1152/
flo:
https://gerrit.omnirom.org/#/c/1634/
mako:
https://gerrit.omnirom.org/#/c/1635/

@Entropy512
Hey there!
Add me on hangouts sir:
[email protected]
What about this TWRP configuration for honami?
https://github.com/Omni-Xperia/android_device_sony_rhine-common/commits/cm-10.2
i have built one for pollux and it works

Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .

iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk

jakew02 said:
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
Click to expand...
Click to collapse
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.

iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
You mention mount points for the SD, I have been building for the HTC One S and while all the mount points in the my ville/rootdir are correct for example in the fstab.qcom file
# SD card
/devices/platform/msm_sdcc.1/mmc_host/mmc0 /storage/sdcard0 auto defaults voldmanaged=sdcard:36
The rom shows it as unavailable/missing and asks me to format the SD card, I tried and the message keeps popping up.
Basically my question is, will building twrp recovery for the device sort out the missing SD card.

iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well

iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.

jakew02 said:
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
Click to expand...
Click to collapse
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Entropy512 said:
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
Click to expand...
Click to collapse
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)

iofthestorm said:
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
Click to expand...
Click to collapse
I do, but it mostly collects dust these days. At some point I'll try to get Omni up on it, I've just had too much else to do lately.

So another question, what is the mechanism by which twrp.fstab is used? I decided to flash my recovery for the heck of it (sidenote: on the 4.4 branch it still has the AOSP recovery in the manifest, but I just added omnirom/android_bootable_recovery to my local_manifests.xml) and it actually runs but nothing appears to be mounted. I notice that some TWRPify commits have a twrp.fstab but they don't do a PRODUCT_COPY_FILES for that file so I'm wondering how it even gets used? I see for example that your commit for flo is doing it: https://gerrit.omnirom.org/#/c/1523/ but then this guy didn't actually add it to PRODUCT_COPY_FILES for hammerhead: https://gerrit.omnirom.org/#/c/1588/ . Is that just a mistake on Mithun's part, or am I misunderstanding how this fstab is used? Is there any reason for it to be any different than the fstab.smdk4x12 in the device tree? Just trying to figure out how things work here.
Also, is it preferable to use the by-name symlinks over the raw /dev/block/mmcblk0p9 type device identifiers? Should I open another thread for this?
My hackjob device trees are https://github.com/ibrahima/android_device_samsung_n80xx-common and https://github.com/ibrahima/android_device_samsung_n8013 .
Edit: I guess my main question is, how is that twrp.fstab different from TARGET_RECOVERY_FSTAB? Some of the device trees with it (eg. your flo changeset that I linked above) don't seem to set this unless I'm looking in the wrong place, and I've seen at least one that sets TARGET_RECOVERY_FSTAB to /etc/twrp.fstab. Found this quote from @Dees_Troy:
You can create a twrp.fstab file and then use PRODUCT_COPY_FILES += device/oem/codename/twrp.fstab:recovery/root/etc/twrp.fstab to get the twrp.fstab into the recovery ramdisk
Click to expand...
Click to collapse
from http://forum.xda-developers.com/showthread.php?p=45164117 . If I already have an /etc/recovery.fstab it should work without the twrp.fstab right?
Edit2: Oh, derp, the twrp.fstab explanation is in the "How to Compile TWRP" thread. Filing away for later reading... (this is fun and all, but my professors aren't going to accept an Android 4.4 build in place of my homework )
Edit3: My god, this is basically me: http://xkcd.com/356/ and the truck is my homework/midterms... welp, at least I got a recovery with proper fstab, so for anyone else trying to TWRPify yes, you do need a twrp.fstab because the new fstab format in Android 4.3+ is not used by TWRP yet so you need one in the older format for it to mount your stuff. Haven't actually tried flashing anything with my recovery yet, but I feel like it should probably work, but again... trucks and all that

If it's not in PRODUCT_COPY_FILES - yes, that is a mistake.
(hopefully that commit isn't merged - accessing omni's gerrit is problematic for me from some locations. If the TWRP FSTAB is added to the device tree but isn't being copied that's grounds for a -1)

Yeah, he -1ed it himself for other reasons I suppose. Cool cool, looks like I'm learning stuff
By the way, after the hard drive meltdown and subsequent loss of two weeks of gerrit data, a lot of the links in your OP are broken in that they go to different tickets which have now subsumed those ticket numbers that were lost. For those who are curious and have been foiled by Gerrit's somewhat obtuse search box, if you type message:TWRP in the search box (to search commit messages) you'll find examples.

oreo 8.1.0 by gavin19

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!!

[LENNY5][UNOFFICIAL][GSI]LineageOS 16 Treble with FLOSS, MicroG, Root, FakeStore

I DONT TAKE ANY WARRANTY WHATSOEVER IN ANY DAMAGE THAT MAY RESULT IN FOLLOWING THIS GUIDE OR USING THE SOFTWARE, ROM IN QUESTION, IN ANY WAY, MAY IT BE AS INTENDED OR NOT. IF YOU HAVE ANY FEELING YOU COULD END UP SUING ME FOR RISKS *YOU ALONE* ACCEPTED TO TAKE, YOU SHOULD IMMEDIATELY STEP BACK AND LEAVE THIS POST, ALL THE OTHERS: BE CAREFUL. YOU WILL LOSE ALL OF THE DATA ON YOUR PHONE'S USERDATA, CACHE AND SYSTEM PARTITION AND THE PHONE WILL BE FACTORY RESET!
STOCK FIRMWARE INSTALLER: https://support.wikomobile.com/maj/Lenny5_OPE_V34.zip <-- if you brick your device.
Hey folks
This is just a brief explanation on how i built this ROM, a complete guide to building the rom may be published at a later point in time. For the Downloads, go to the Links section. The flashing guide will be focused on Lenny 5, but the image may work on other treble-enabled devices, too, so feel free to try and report if your device works with this build.
Build variant: arm-aonly-floss-su-userdebug
If there's interest in other build variants (specifically with microg and floss - fdroid, moz-nlp, openweatherprovider - implemented), ask me, i will do my best.
Build description:
I have an old Wiko Lenny 5 around here and wanted to use it as a Kodi Remote etc. at home, but didn't want to use their stock ROM. Also i wanted some freedom in using my device, specifically a rooted device and microg implementation. After trying to build TWRP with no success and the Wiko Build information being massively outdated i then focused on Generic System Images, as Lenny 5 is Treble-enabled. Big thanks to @phhusson for the whole lot of effort he put into building AOSP GSI's (and also clues towards building LineageOS GSI's). After having AOSP9 installed on it for some time, i got bored and tried to compile LineageOS using the patch-and-build system provided on phhusson's github. That worked just great on AOSP9, but failed to build a bootable LOS16 in the first place. So after some recherche, i stumbled across @AndyYan's thread, containing some LineageOS GSI's prebuilt and ready to use. These worked great on my phone, but as stated above, i wanted to customize my LineageOS even further, so i manually patched my build-tree with AndyYan's Lineage-Treble-Patches by doing what this build script does, tested and it booted (i guess it's mainly related to the SELinux Policies not being correctly built for LOS with only phh's treble-patches). So far so good.
Additionally, i implemented the MicroG services by cloning these prebuilts on github to the respective folder in the build tree and before the build executed
Code:
export WITH_SU=true
to include LineageOS's root system in the build. I adapted the treble_arm_afS.mk device config to not use phh's su and the device/lineage/floss.mk file to include
FDroid
FDroidPrivilegedExtension (which is being built from treble sources)
MicroG services (use Play Store Apps)
FakeStore (use Play Store Apps)
MozillaNlpBackend (MicroG Network Location backend)
NominatimNlpBackend (MicroG Network Location backend)
OpenWeatherMapWeatherProvider (for LineageOS Weather Provider)
You are then free to use no Playstore at all or i.e. Yalp Store to download Play Store Apps.
After downloading the Image you may need to Unpack it via 7-zip or another tool.
Flash the device:
To install this custom ROM on the Wiko Lenny 5, in your stock ROM go to Settings->Developer Options->OEM unlock->Enable. Also, in the Developer Options, make sure, ADB Debugging is active and, on prompt, accept debugging connections from your computer.
On your computer, enter Command Prompt and issue the following commands:
Code:
adb reboot bootloader
*wait for device reboot*
fastboot oem unlock [COLOR="Red"]<-- this will factory reset the device!!![/COLOR]
*press vol up on the phone to allow unlocking the bootloader, and wait for the phone to return to fastboot mode*
fastboot erase userdata
fastboot format cache
fastboot format system
fastboot flash system <path-to-the-downloaded-gsi>
*wait for each process to finish*
fastboot reboot
now, wait for the phone to reboot, it should, after some time, show you the usual LineageOS startup screen. Take your time to set up your phone. To make MicroG and FakeStore work properly, you will have to Go to Settings->Apps&Notifications->App-Permissions->Spoof package signature->Menu->Show System Apps and allow FakeStore to spoof Signature. Go to Settings->System->Advanced->MicroG Settings and add your Google account. Activate Device Registration. Then activate Google Cloud Messaging and Google SafetyNet, if you want to take advantage of those services. Inside the UnifiedNlp Settings choose MozillaNlp in the first, and NominatimNlp in the second setting.
Go back and choose "Self check", if required, if required, grant MicroG GmsCore the permission to spoof signature, this should make most of the boxes go "checked". If Phonesky shows errors about signature spoofing, this should normally be gone after a reboot of the phone (given you allowed FakeStore sig spoofing). Disable battery optimization and then reboot the phone.
Check back in MicroG Settings->Self check, if all the boxes have been checked. If not, most mandatory points are self-explanatory.
This Lineage ROM will not allow you to update to a newer version. I cannot guarantee continuous updates, but encourage you to try building LineageOS treble with the way explained above, yourselves. If enough interest is around, i will consider doing updated builds from time to time.
Update:
Today i compiled a recent source tree containing the 5th of October patches. I will try to keep up with updating the Image whenever security fixes are released. The download links below have been updated to the newest version. To update your phone without deleting the data on it (make sure you have adb debugging enabled), you can simply do
Code:
adb reboot bootloader
fastboot flash system <system-image.img>
fastboot reboot
and then give your phone some time to "update". it should boot normally without erasing your data.
Links:
ROM .7z [~430MB]
ROM .img (~1.1GB)
(version was compiled at 19th of October '19, containing the October 5th security fixes.)
Let me know if this works for you, too!
Cheers
ivelischt

*reserved for additions/build guide*

Nice work
Nice work, I'll test the ROM later or tomorrow, also I like to see some development for this phone, also, It would be very nice to develop a custom recovery for it for better flashing experience and being able to flash gapps.
I have kinda workplace on my PC, I'm still wondering to build my first ROM but I think it will take lot of time.

Hanthonious said:
Nice work, I'll test the ROM later or tomorrow, also I like to see some development for this phone, also, It would be very nice to develop a custom recovery for it for better flashing experience and being able to flash gapps.
I have kinda workplace on my PC, I'm still wondering to build my first ROM but I think it will take lot of time.
Click to expand...
Click to collapse
Thanks. The custom recovery thing is a bit more difficult for treble devices, but i'd be happy to learn more from more experienced people.
I was not able to get TWRP running despite "successful" Custom recovery builds.
The build is quite straightforwards if you have some experience on compiling with linux. But you need around 200400Gigs of free space per build tree (lineage, aosp, ...). The most difficult thing for me was to alter the sources for inclusion of the packages i mentioned above, including microG. to build with opengapps, i expect, you'd use the same approach to include them in the build tree as with microG, just using the other packages and probably slightly customized CUSTOM_PACKAGES config. there is a k300 recovery out in the wild net. so there should be at least *some* possible way to port twrp for the k400, too.
about the time to build the rom: it took me about a day to sync sources and, using 2 cpus at 4gig's of java virtual memory, about 6 hours to compile the first round. after that, only compiling the changes made, it took me about another half an hour to recompile the changes. the editing process is marginal, if you know how to append to/remove from/patch the source files, the lineage4microg and treble rom-builder bash-scripts on github give you a pretty good insight in how to apply patches. also, from the dockerfiles you can get a list of all the dependencies your system needs to build the tree. i used these sorts of "tricks" to ensure my build runs well.
so far from me. i will try to find some free time in the future to put up some guide on how i built the rom as-is.
feel free to report if the rom works on your device!
best regards
edit: 400Gigs is better

ivelischt said:
Thanks. The custom recovery thing is a bit more difficult for treble devices, but i'd be happy to learn more from more experienced people.
I was not able to get TWRP running despite "successful" Custom recovery builds.
The build is quite straightforwards if you have some experience on compiling with linux. But you need around 200400Gigs of free space per build tree (lineage, aosp, ...). The most difficult thing for me was to alter the sources for inclusion of the packages i mentioned above, including microG. to build with opengapps, i expect, you'd use the same approach to include them in the build tree as with microG, just using the other packages and probably slightly customized CUSTOM_PACKAGES config. there is a k300 recovery out in the wild net. so there should be at least *some* possible way to port twrp for the k400, too.
about the time to build the rom: it took me about a day to sync sources and, using 2 cpus at 4gig's of java virtual memory, about 6 hours to compile the first round. after that, only compiling the changes made, it took me about another half an hour to recompile the changes. the editing process is marginal, if you know how to append to/remove from/patch the source files, the lineage4microg and treble rom-builder bash-scripts on github give you a pretty good insight in how to apply patches. also, from the dockerfiles you can get a list of all the dependencies your system needs to build the tree. i used these sorts of "tricks" to ensure my build runs well.
so far from me. i will try to find some free time in the future to put up some guide on how i built the rom as-is.
feel free to report if the rom works on your device!
best regards
edit: 400Gigs is better
Click to expand...
Click to collapse
The ROM works great but I'd like to see one like this with gapps to install on my device (freaking system image size), I've never used MicroG before and I don't know well how to use it.
Also, if you have the knowledge (I'm pretty sure you know more than me) we can investigate a way to create a TWRP version for K_400

Hanthonious said:
The ROM works great but I'd like to see one like this with gapps to install on my device (freaking system image size), I've never used MicroG before and I don't know well how to use it.
Also, if you have the knowledge (I'm pretty sure you know more than me) we can investigate a way to create a TWRP version for K_400
Click to expand...
Click to collapse
Hi Hanthonious
ivelischt said:
If there's interest in other build variants (specifically with microg and floss - fdroid, moz-nlp, openweatherprovider - implemented), ask me, i will do my best.
Click to expand...
Click to collapse
as the microG variant requires some "special sauce", namely the ability to spoof signature as well as other small fixes in the source code, my source tree is a bit different from the "vanilla/gapps" source tree. thus, to build variants not containing microg, you can simply sync the lineage source tree and apply the additional phh treble sources&patches. *edit: next to phh's patches, you will also need AndyYan's patches; you can find information about it in the OP. given, i write a guide (which i still intend to, but this takes some time), the patching step will be explained more clearly* basically, it's one step less than compiling it with microg. at the moment i cannot afford enough disk space to create another work tree, which is why i "can't promise" other build variants, until this issue is gone. which may be tomorrow or in a year. maybe you can find a gapps-version of treble-lineage 16 here in the xda boards. otherwise you will have to wait, or try to build it yourself. also, you might be interested in @AndyYan's lineage version, which is vanilla (no gapps or microg).
i would guess that the system image will not grow excessive just by including opengapps, but i may be wrong. i think that you'd possibly would have to choose a "non-complete" opengapps-package, to make it fit.
to quickly summarize what microg does is, that it spoofs its signature to make your phone think that you have the real Google Services Framework, Google Cloud Messaging, etc. services installed. this makes apps, which depend on these services, work even though you don't really "have" them. additionally, microg establishes an "essential" communication between itself and the real google services to allow you to use google services despite having all their bloatware.
to round this up, you have fakestore which spoofs existence of Google Play Store for those apps and games, which specifically check for GPS's existence (Phonesky app).
i think this should quite generally point out, what microg is for (an api which connects you to google, whilst only handing out information, which is crucial to keep a specific connection alive)
you can then use i.e. Aurora Store to download and update your preferred playstore apps. i tell you this specifically, as i hope that, using it right, microg might be able to give you a "fully stocked" phone experience, whilst keeping most of your data secure and your phone unbloated by google's app-hoard.
if you follow the instructions in the OP on how to fully enable microG, this might be a very handy solution for you, too, so maybe, you want to give it a chance.
to point out my issues with twrp (as far as i can tell using my little experience): twrp is device specific. which means, you need a vendor tree and you need to include it whilst building, so twrp can compile against it. now, treble is a way of excluding your device specific vendor tree from the build altogether (your system image basically doesnt contain the vendor files in a "folder" (/vendor), but in a seperate partition. this partition is "simply" beeing symlinked to from your system partition. this way you will never need to build vendor-specific sources but android builds against standardised "api's" which are being "serviced" by treble-enabled phone's vendor-files (lying at the vendor-partition). this makes building aosp and/or lineage, etc. easier as you can build one variant per architecture, which fits all treble enabled phones of that architecture (arm/64/binder32/64,a/ab,...). this is, very basically said, what is called a HAL (hardware abstraction layer) on a desktop computer.
but at the same time it's much more difficult to find vendor sources for those phones, as there is no more need at all for manufacturers to make these sources publich (as far as i understand it). as a matter of fact, you may not need these vendor sources for modern aosp (8.1+), which really is a grace!! but twrp doesn't seem to work when compiled against treble trees.
i even managed to compile a kernel which is mentioned at the wikogeek site for the lenny 5. i tried to include that kernel when compiling the recovery image but even that did not work out. as i am no experienced programmer (especially not in the high languages), i will not be the person to ask when it comes to finding out what bugs and how to circumvent it.
there is a little light at the end of the tunnel, though. as far as i understand it, treble-phones come with mostly generic kernels, which *could* make it easier to find a way to build a kernel/boot/recovery image in a similar fashion we build the gsi (generic system image) with. additionally, if there is some effort on it, i imagine, that it would be possible to generally modify twrp in a way so it's able to build against treble source trees with missing vendor source. this would enable twrp to run on virtually any phone which is treble enabled and there would be few to no need to port it for each device, specifically. maybe there would then be versions as in the treble gsi's (arm/64,a/b,...) as well as build variants for alternative display sizes etc.
but i wouldn't even know where to start...
i hope i was able to answer your questions. if you decide to stick with the variant in the OP, you should consider downloading and installing the most recent updated build.
best regards

Problems I found in the rom and if there is a way to solve them
Yo,
I wanted to point out the problems I found in the rom and if there is a way to solve
These are the problems I encountered:
1: *THE MOST IMPORTANT*
I can't pass the safetynet test, I researched a lot and I still couldn't solve
When I try to pass the safetynet test on magisk it gives "safetynet API Error"
When I try to do the test with the "SafetyNet Helper Sample" app it gives "SafetyNet request: success
Response validation: fail
Error Msg:
ApException [17]: API: SafetyNet .API is not
available on this device. Connection failed with:
ConnectionResult {statusCode = SERVICE_INVALID,
resolution = null, message = null}
And the "SafetyNet Test" app gives me "fail (Google Play services not available)"
I am aware of the new problem with the safetynet:
(sometimes people are still able to pass the test probably because it is still in maintenance or something)
https :// www . androidpolice . com /2020/03/11/safetynet-improvements-kill-magisk-hide
https :// twitter . com /topjohnwu/status/1237656703929180160
https :// twitter . com /topjohnwu/status/1238514375150850048
https :// twitter . com /topjohnwu/status/1237830555523149824
But even so I should be able to run the test even if it give both negative should run instead of showing those errors
2: The contacts I had on the SIM card and Google account do not appear in the contacts.
So I went on WhatsApp to save the ones I wanted to save, but after a few days and a few restarts the contacts are still saved, but on WhatsApp it shows that they are not saved even appearing in the contacts, to appear again saved on WhatsApp, I have to save them all again
3: Cant login in Clash Royale with google play games account, can i flash the rom and gapps to work or the microg and google play services will create some conflict, is there a way to unninstall microg completly and reflash the rom without microg and flash gapps?
4: Error when login in pokemon go: unable to authenticate, I researched it and it seems to be because the safetynet is negative but I can't even run the test (only after I became aware of the new safetynet problem) even with this new problem I would like to try to run the test to see if it passed since some people still are successfully passing the test
5: in the microg settings in self-check an option is not checked in the box "UnifiedNlp do not have location to test geocoder" I already researched to see if it solved something but I couldn't
edit: I solved it using the "Apple WI-FI" backend instead of the "Déjà Vu Location Service"
BUT NOW ITS GIVE ME AN UNCHECKED BOX
"Network-based location enabled:
you either disabled network-based location
(in system settings) or the system is not
supported"
6: some times in the time widget just appear "loading widget..."
and these are all the problems that I encountered, pls help me
solving these problems, thx!:good:
sorry for some mistakes i translated from portuguese to english with google translator and my knowledge of english

CooperTUGA, thanks for writing. And I want to apologize for letting you wait for so long. In fact, at the moment i do not actively develop this ROM (due to data loss on my virtual machine).
Anyways, i will try to address your issues as good as i can, though i must admit, none of these issues happened on my device.
ad 1: The only thing that comes to my mind is, that something went wrong when registering your device with the Android-ID. (see OP activation instructions). The SafetyNet-API itself should be working, atleast I had no similar issues (after Registering the device it takes some time - around 5 minutes - for Android to reflect the registered state).
But if someone happened to have this issue and knows another solution, you are welcome to tell!
ad 2: Does it help when you try to import the Files from the SIM card? As for Google contacts, it is - from my POV - stringent, that, if the SafetyNet API doesn't work properly, you will be unable to access Google Services (as Google Contacts) which would explain the missing Google Contacts.
ad 3: GApps and microG are two different things. GApps install a version (open-source fork, contains proprietary binaries) of the Official Google Apps, that is, they provide full functionality towards google services, provided you registered your device correctly.
microG is a pure Open Source fork of that, providing but the Framework with which Google Apps can be run. It does not provide Google Apps (like PlayStore etc.) by itself but merely allows them to run, given the configuration is right. This microG-ROM is not built to work with GoogleApps like PlayStore, but instead relies on the microG Services to get Apps, providing same or similar services, running (like Aurora Store etc.). To address your question, it is possible, to change the source code which was used to build this ROM, so it builds with Gapps or completely free of any such services, in fact it would mean to exclude certain patches, but such projects (Treble-enabled) are covered by others and because of above stated reasons i will not be able to provide such in near future.
Short but clear: No, there is no way to "uninstall" microG as it is built together with the ROM and the source used was especially prepared to use microG. But if configured right, you should be able to use your Google-Account in combination with Google-Services-Apps or Games despite using microG.
ad 4: See above. If everything's configured right, you should be able to play Pokemon GO, although i don't use any of these Apps (Clash Royale, Pokemon GO, WhatsApp). I never encountered any Problems along using Google Apps with this ROM.
ad 5: Well, the error says it all. I have Mozilla Location Service installed, which works like a charm. Maybe try this one? You can get it from FDroid, search for "MozillaNlpBackend" and see if it helps to sort this out? This works for me, after all.
ad6: as this is very unspecific, i cannot really tell what's the problem, but i would guess it has to do with the SafetyNet API not doing what it should or even the Location Backend not reporting position in time...
Did you clean your cache and data partitions while installing this ROM? I really am not sure what could create the behaviour you describe. Maybe there was a change in the SafetyNet/Device Certification process since this ROM-Build, maybe theres someone in those boards who could answer this, but i unfortunately can't...
I'm sorry that i cant give you more positive news, but hopefully it helps you in orienting what some common problems could be caused by.
Let me know about your success in trying to get the ROM working.
Best regards and greetings to portugal!
ivelischt

additionally: if you are interested in porting the Lineage Source for GSI/Lenny 5, you might be interested in this Thread: https://forum.xda-developers.com/android/help/how-to-root-wiko-lenny-5-t3819469
specifically, i wrote a guide there on how to build Android/Lineage Source for Treble devices. Maybe this helps you in getting your own build environment, enabling you to build to your disguise.

Images are not available anymore. Anyone here?

Question attempt at learning how to compile TWRP for our device.

I am not an experienced dev, and only know enough to be dangerous. that said, i used twrpdtgen from https://github.com/twrpdtgen/twrpdtgen to generate what ought to be the berlna device tree with the necessary board files etc.
what do i have to do, specifically, to clone the twrp source via git/repo? can anybody here explain it like you realize i don't know what i am doing i'll figure git and repo out eventually, but this will go quicker if someone would enlighten me
which android version do i want to build twrp with? apparently 12.1 support isn't finished yet, so i should use 11 with aosp source?
note, for our deivce you need to use the script on upon boot.img as we've a/b format, grab from latest stock rom to gen yourself, or see attached. also, necessary to use WSL on windows with a linux distro, or a linux vm, python on windows will not work.
please feel free to use these if it furthers the cause of compiling twrp before i learn how to use git and repo and compile it.. hehe

I wanted to try my hand at this and start digging into git and repo. I got as far as getting all the files ready, setting up the tree where it needed to be, used ". build/envsetup.sh", then lunched with option 5, which is omni-berlna_eng, which is closest to the twrp minimal manifest build option.
After I lunch, the issue arrives with the fact that omni-berlna_eng uses a depreciated PRODUCT_STATIC_BOOT_CONTROL_HAL, whatever that means. So I tried using lunch option 2, which would be an aosp-arm64_eng, but that just gives me the error "#### failed to build some targets (1 seconds) ####".
As of now, I'm at a loss. I don't have the extra time to spend working on this to make it function, and I only get a few hours at a time to get a crack at it, but nothing seems to work.
Edit:
I should mention, this is my first attempt at anything android development. I got this phone as a secondary carry on and I've dirtyflashed Pixel Experience onto it using a method found for Moto G Power TONGA. Wanted to see if I could get TWRP running since dirty flashing killed my mms and calling services.