(Caf) Code Aurora AOSP

[chairshot215]

I know I have just asked some rather Simple Kernel Questions and honestly as stated as always worked as part of a dev team and was never the Kernel Guy but with that said have always wanted to build an AOSP Rom based on the Code Aurora source. Not caf like CM or anything with all kinds of features and what not but just pure AOSP. Thought I would ask if anyone else would be down.

The Rom would be pure AOSP based on Code Aurora repository’s only. Have always wanted to look into doing this and looking into how to go about it.

 

[doitright]

Ok, first off, some useful descriptions;

AOSP: The source code provided by Google. This is directly buildable for Nexus 6 just by following the instructions.
CAF: The source code provided by Qualcomm, which typically involves *some* degree of feature addition, but mostly HARDWARE bringup.

The odd thing about the relationship between AOSP and CAF, is that they are both each other's upstream. I think I would classify CAF as being somewhat more of "experimental" code.

CM: a complete and utter MESS. It takes bits from here, bits from there, and throws in a jumble of other bits... none of which really work well together or were intended to be merged in that way.

Basically, CM is not so much a build of CAF as they pull in certain *parts* of CAF. So if you did a build of PURE CAF, it would much more closely resemble a build of AOSP.

Now is CAF buildable for Shamu? Hmm, sortof.... maybe. They do pull in AOSP, but I don't think they actually work with Nexus devices so much as their own internal development devices, and certain specialty "dev" devices like Dragonboard 410c. What that means, is that you will probably want to start off with a *generic* apq8084 manifest from https://www.codeaurora.org/xwiki/bin/QAEP/ under the "release" branch. You will then need to mess around with the blobs and kernel, add a shamu device tree, etc., and what you end up with at the end, will strongly resemble a pure AOSP build, but probably have a few things broken or unstable.

IMO: For something like Shamu, you don't really do a pure CAF build, since google has already selected and stabilized the appropriate parts of CAF for you. But if you see some new or not-included FEATURE in CAF, then you consider pulling that specifically into an otherwise AOSP build.

 

[Yoinx]

*lots of text*.

It's funny... I've had people argue this with me in the past few weeks...

This is pretty much exactly my understanding of it as well.

The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.

Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.

 

[doitright]

It's funny... I've had people argue this with me in the past few weeks...

This is pretty much exactly my understanding of it as well.

The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.

Yep, that is pretty much why I used the term "experimental".

Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.

You do know that google provides the vendor blob archives, right? That is, the parts required to make the AOSP build fully functional on Nexus hardware. Those vendor blobs don't include any of the googly bits in the userspace layer (i.e., gapps).