Database Info

Building Latest AOSP

Okay so with the help of a lot of people and hours of work I have successfully built a kernel for the sg3. I want to take the next step to roms however (I know, big step).
Using the xda-university thread I have setup a repo and am currently pulling the latest 4.3 AOSP source (will let it sit overnight, my internet isn't too amazing and I have HDD not SSD *sadface*)
As far as I understand it so far, I need to find suitable device tree sources to get AOSP sources working on the sg3 (at&t for now). I have been doing a lot of searching and reading, but as usual when you get started, its like a sea of information. If anybody could give me some reading material or direction on taking on this venture, it would be much appreciated. Feel free to be as technical or nontechnical, I will read til I get what you mean.
If this is too nooby for this thread, just move the thread.
Thanks
EDIT: so I did some reading and decided to go with cm's d2 device tree and see if it works. I created a new directory in /root/devices/samsung called android_device_samsung_d2-common
Unfortunately when I use the lunch command, it is not one of the selectable options. I read that I need to edit my .repo/manifest.xml to include it but upon examination I tried adding the following line but it didn't help
Code:
<project path="device/samsung/android_device_samsung_d2-common" name="device/samsung/android_device_samsung_d2-common" groups="device,d2" />
any ideas?

does the device tree have a vendorsetup.sh,, if not thats why it isnt showing up when u type lunch,, dw i am having troubles with aosp too,, first time i have ever tried building aosp and i am stuck at camerawapper comoing up woth a few errors,, dont know anything about coding so ill have to look around,
also with the folder name take off the android_device etc, and leave it as d2-common
---------- Post added at 10:31 PM ---------- Previous post was at 10:28 PM ----------
also with the folder name take off the android_device etc, and leave it as d2-common

its actually not that hard to build from source, but it does take alot of time and hair pulling (lol jk ) just repo sync from source. then make sure you have d2-common, d2(device), msm8960-common, and qcom-common under device/samsung (just pull these from CM github) then build

Development Questions

I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01

Steel01 said:
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Click to expand...
Click to collapse
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.

Unjustified Dev said:
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Click to expand...
Click to collapse
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01

Steel01 said:
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Click to expand...
Click to collapse
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at (removed) as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .

Unjustified Dev said:
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at https://github.com/CM-Shield as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Click to expand...
Click to collapse
Thanks, pm sent. Guess I'll fire off a full aosp build so we'll have the same trees available at that time.
Steel01
Edit: Today's just not my day. None of my builds from nvidia's aosp 4.3 r3 tree boot. A normal boot hangs at the shield logo. The recovery gives me the red triangle (not terribly surprised since nvidia's official gives me that too, only agrabren's cwm recovery works for me). I didn't think too much of it when I built off of openjdk 1.6, but now that I pulled sun's 1.6-41 and it still doesn't boot, I'm a bit miffed. Shouldn't be a reason why I can't build off CentOS. Maybe I'll load up a Debian or Mint VM and try building off that. I really don't want to touch Ubuntu which all the android docs are written for...

Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.

Steel01 said:
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Click to expand...
Click to collapse
Did you get the closed source binaries extracted?

Unjustified Dev said:
Did you get the closed source binaries extracted?
Click to expand...
Click to collapse
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01

Steel01 said:
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Click to expand...
Click to collapse
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh

Unjustified Dev said:
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Click to expand...
Click to collapse
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01

Steel01 said:
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Click to expand...
Click to collapse
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later

Unjustified Dev said:
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Click to expand...
Click to collapse
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01

Steel01 said:
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Click to expand...
Click to collapse
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow

Unjustified Dev said:
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Click to expand...
Click to collapse
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01

Steel01 said:
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Click to expand...
Click to collapse
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.

Unjustified Dev said:
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Click to expand...
Click to collapse
Alright. If you haven't got the dtb stuff straightened out by the time I get back to my dev machine tomorrow night, I'll tackle that. I've had some hobbyist experience with that on some embedded dev boards. In general, I wouldn't think the dtb would ever change. Definitely not within a kernel version. Definitely needed, though. But in the spirit of open source and building as much as possible from source, it will be good to make that build. Shouldn't be too difficult. And yes, 1:30 AM does bad things to cognizance. *passes out*
Steel01
Edit: I took a look at the tf701t kernel tree this morning. The dtb part may already be done if we base from there. A dts file already exists for roth (arch/arm/boot/dts) and the make file a dir up appears to glob the dts directory and build dtb's for each. I don't have access to a build tree to verify that atm, though. Bit if that's true, the kernel should be as simple as cloning tf701t, renaming its defconfig and modifying what little differences there are if any, then copying the dtb to the out directory.
Edit 2: A bit of googling turned up http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree which says a config flag handles building dtb's. The tf701t config already sets CONFIG_MACH_ROTH=y, so I'm wondering if that kernel won't boot on the shield out of the box. Something I'll try once I get back to my dev machine tonight.

Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01

Steel01 said:
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Click to expand...
Click to collapse
So far going to push unmodified kernel now https://github.com/CM-Shield/android_device_nvidia_roth

Progress finally. Got a cwm recovery that boots and looks like it works plus fits in the partition. Most of the buttons aren't mapped yet and the screen is rotated, but that should be the east part to fix.
Steel01

Getting closer. But still no dice. Logcat of current iteration.
Steel01

[Q] Help needed porting CM11

Since development for the Sidekick 4G has stopped I decided to try and port the CM11 M10 snapshot from the Galaxy S 4G using this guide. I used the Galaxy S 4G as port ROM since most of the specs are the same as the SK4G. The base ROM I used is ayoteddy"s KJ2 Deodexed & rooted ROM. I followed the guide and flashed the ROM I made but the phone didn't boot. It stays stuck at the tmobile startup screen and then bootloops. I took a logcat and see a lot of errors but idk how to correct them. I tried uploading the ROMs I used and the one I created but it only let me upload the logcat.

Hey,
Its awesome to see some more effort in this phone but when porting a ROM one of the main prerequisites is the base being the same android version.
So to port cm11 over you would need a kitkat kernel and ROM for the sk4g already.
What would be real helpful is to get the gingerbread kernel fully functional then any GB ROM could be ported fairly easily.
Or start with a kitkat kernel but both require a bit of work. If you want to take it on a can link a bunch of guides that may help

Thanks for that info. I don't have experience coding but I would like to be able to learn how to cook and port roms so I would really appreciate some guides. As I understand it, since there is no KitKat ROM available for the sk4g I would first need to make my own KitKat kernel and ROM before I would be able to port cm11? And how long do you think it would take to learn everything needed to be able to port and cook roms?

Hey,
On mobile right now so can't post a bunch of links but xda is filled with them
The best place to start would be http://www.xda-university.com
And be sure to check out the forum links as well!
For a quick set of links see the seventh post in this thread
http://forum.xda-developers.com/showthread.php?t=2348266
For a different device but those are all great places to start learning to develop for android
Keep me posted on your progress!

Took me a while to find some useful guides since I was searching with the term "port" and not "build/compile from source" since that is essentially what I'm doing. I used wiki.cyanogenmod.org/w/Doc:_porting_intro and wiki.cyanogenmod.org/w/Build_for_galaxysmtd (can't post links yet). I forked the galaxys4g repo and modified the files to be suited for the sidekick4g. Now I'm onto the building step, a couple of things already broke and I managed to fix them, but I ran into this error and haven't been able to fix it.
brunch sidekick4"ebtables is disabled on this build"
find: `src': No such file or directory
build/core/base_rules.mk:134: *** system/extras/ext4_utils: MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g. Stop.
I researched the MODULE.TARGET.EXECUTABLES.setup_fs already defined by device/samsung/sidekick4g issue and suggestions were to delete the setup_fs file within device/samsung/sidekick4g folder. However the setup_fs file wasn't in there, I did find a setup_fs.c file and deleted that one. Then I proceeded to try the build again and ran into the same error. Another suggestion was to use grep -R setup_fs *. This command pointed to these files,
Android.mk:LOCAL_SRC_FILES := setup_fs.c
Android.mk:LOCAL_MODULE := setup_fs
Android.mk~:LOCAL_SRC_FILES := setup_fs.c
Android.mk~:LOCAL_MODULE := setup_fs
initramfs/init.herring.rc:service setup_fs /system/bin/setup_fs /dev/block/platform/s3c-sdhci.0/by-name/userdata
sidekick4g.mk: setup_fs
But I don't know what exactly I'm supposed to delete. The device repo is located at github.com/SK4G/android_device_samsung_sidekick4g.git It is a pre-build attempt version before I made suggested changes to the local repo. I tried "git push origin master", the command went through and said everything is up to date but the remote repo still wasn't changed so I haven't been able to update it.

What are you using for the device tree? The relay is a completely different device and none of the drivers would work, did you at least pull blobs and proprietary files from a sk4g?
There is a ton of setup to be done in order to build from source, you can use the cm11 source but need to make a specific device tree for the sidekick to get a working build, not to mention a ton of kernel work will be needed

For the device tree I forked the galaxys4g repo (not the galaxy s relay 4g) and then modified the files to build the sidekick4g specific device tree. When pulling the blobs and proprietary files the guide said " Your device should already be running a build of CyanogenMod for the branch you wish to build for the extract-files.sh script to function properly". Not sure if that's relevant to the errors but I was still able to pull the blobs towards the correct ~/android/system/vendor/samsung directory. As far as the kernel I downloaded the stock kernel from the samsung source website and then put it in the kernel/samsung/sidekick4g directory. The guide said that the kernel and kernel modules would be built automatically as long as I made appropritate changes to the BoardConfig.mk and I did so. I have done every step in the guide and now I'm into building but I can't get past the previously mentioned error. Should I delete the whole part of the files mentioned by the grep -R setup_fs * command or just the red part or is there another solution?

Well the blobs that were pulled and the kernel that was used was for froyo, that won't work for kitkat without a weeks worth of modification
Also the s4 is even more different than the relay and would be much harder to use anything from there
What you need at this point is to create your own device tree on github and add this to your local manifest, then the hard part is to adapt the sk4g kernel into something that will work with kitkat, once this steps are complete you can build and then fix the errors that come up, fixing any errors at this point won't help much as the files used are incompatible from the start

I should have been more specific, I used the T-Mobile Galaxy S 4G which is one the first galaxy phones. It has the same hummingbird chipset, architecture, ram/rom size, resolution, and both originally ran froyo. The guide states that the cm buildbots build a compatible kernel for me. I didn't just fork the galaxys4g repo and leave it as is. I went through the files and substituted anything that was galaxys4g device specific to fit the sidekick4g.

No problem, should have read more clearly, yes the galaxy s is very similar minus the keyboard but you can look at the work that was done to get a GB ROM booting here
http://forum.xda-developers.com/showthread.php?t=2323617
This was done on the exhibit, another very similar phone,
Even after the kernel was adapted the keyboard never worked, you check the link to his github to see what was put into it to work
The kernel built by the bot won't adapt it to work between different versions of android so you need to build this manually first then you can use it, but even then there will be a lot to do in order to get the keyboard working

Now I'm beginning to understand what you have been trying to tell me. It was hard to grasp at fist because I never really looked into building a kernel since I usually just use the stock kernel or the cm built in kernel on my devices. Now I shall redirect my efforts into building a kernel

Hi I just wanted to know if you're still building port for the sidekick 4G I still have mine and I would like to use if you have kitkat to work. I miss my sidekick 4G
Sent from my Nexus 6 using XDA Free mobile app

"Vanilla" device tree

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!

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