Related
Yes yes, you may think that I'm crazy for attempting to compile AOSP, but in fact im just obsessed with getting AOSP to work (on my previous device I spent a full year on it without success), thanks to the experience I know much more know about the environment.
I've done several pure aosp builds so far, and they result in a ~280mb system folder, which is kinda the size of aosp I guess (atleast for xxhdpi)
But they end with errors of course, anyways. I used the devices specs with updated overlays,and added dependencies (such as hardware) to the environment.
But since the aosp environment is very mean to new devices its once again a real struggle. as expected, but I like the challenge.
Anyways, Im currently trying out this hybrid-ish environment. which contains the items listed above but with several elements of the AOKP environment added (only the essential ones for compatibility).
Compiling goes so far so good. hope I will get a working build. (don't expect this to happen tho)
Oh and since samsung is releasing the S4 Google Edition (AOSP) soon it must be possible. (the google edition is the qualcomm varian afaik)
More info soon!
I'm going to drop this here for now until I have time to mess with it more.
https://groups.google.com/forum/?hl=en#!topic/android-building/_F67iLDcVzQ
Note: This leads me back to my previous question as to how we are supposed to build with this.
At face value it seems we're only getting fairly close to what we were with other OSRC releases.
Going to look at more later tonight.
Skilled devs can get pure aosp to work properly. It was done for sprints gs3 without using CM code.
Sent from my SPH-L720 using Tapatalk 2
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
drewX2 said:
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
Click to expand...
Click to collapse
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
broodplank1337 said:
(edit)...I'm crazy for attempting to compile AOSP...
Click to expand...
Click to collapse
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
oOo B0XeR oOo said:
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries and I have handled every step in porting; from display, audio, to calling, wifi, bt, etc. Released means the manufacturer provides a nice little package for you. I had to in many cases, figure out which libs from a stock rom were needed. Additionally, you can utilize libs from completely different devices as a temporary patch. I am very comfortable with kernel development and the android framework. If you were too, you would know what I am saying is true. Here is one tip, nearly every board is like another (within the same class; eg. MSM8960, APQ8064) with only slight variations (e.g. modem). Once you understand that, it becomes easier.
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
I agree with you on some points about CM code, however, you're group has been porting devices that were working or nearly working with base android code. Talk about an easy route. I can see you haven't had to do any hard work yet. Going from 4.1 -> 4.2 on a non google AOSP supported device or a device that has no CM build available for it is a whole different story. How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
Lastly, although I agree with you on some points about CM code, you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them), but you should give respect and credit to those who make what you do possible.
Click to expand...
Click to collapse
See Above.
drewX2 said:
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries...
...How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
[/QUOTE
Great, hi-five to you, but before making bold assumptions...
http://www.xda-developers.com/android/aosp-jellybean-build-for-the-t-mobile-g2x/
drewX2 said:
...(CM) you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them),....
See Above.
[/QUOTE
I never suggested anything about CM, they are top-notch. I said we dont use their base code like "every other dev". Sorry you have had quarrels; and there is nothing "probably based off them" as I just told you our repo is straight AOSP & EB.
Likewise you should "know what you're talking about", prior to making assumptions and speculations.
^read above
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Im currently working on this as well...anyone have anymore success? Im currently fighting my way through compile errors...but I would love to be able to atleast get a bootable pure aosp from source...ill keep at it...but if anyone has gotten it yet please help speed up my process and enlighten me on what you did to compile a working aosp
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2
I guess we all are I'm working on one too. Lots of research on correcting errors
Cm10.2 anyone??
Sent from my GT-I9505G using Tapatalk 2
deleted
Wrong post
I did it successfully with help of some external repos
forum.xda-developers.com/showthread.php?t=2397511
I know this is yesterday's news but I felt compelled to post this and get other users input on this topic.
http://www.cyanogenmod.org/blog/releases-11-12-final
What I don't understand is Cyanogen's priorities when it comes to which devices get 11, 12 or 12.1. I completely understand about phasing out CM11/KitKat as that is now a rather "old" version of android. However what I don't understand is why a device as new/old as ours (Aug 2013 is not THAT old) is stuck on CM12 (and now a final Snapshot build as of 6/25)? I mean, the Galaxy S3 is even getting 12.1 builds. I'm wondering if its because that was a far more popular device than the G2 was?
Just wanted to put this out there and see what other people think and find out what they're running currently on their G2 variant. I own the US T-Mobile D801 variant and do NOT want to run stock (LG) Lollipop since my device tends to run extremely HOT on it. I know not everyone was complaining about their G2 overheating on stock LP but I notice a considerable difference running CM12.
So, how do you guys feel about this? Do you even care or what?
t3chn0s1s said:
I know this is yesterday's news but I felt compelled to post this and get other users input on this topic.
http://www.cyanogenmod.org/blog/releases-11-12-final
What I don't understand is Cyanogen's priorities when it comes to which devices get 11, 12 or 12.1. I completely understand about phasing out CM11/KitKat as that is now a rather "old" version of android. However what I don't understand is why a device as new/old as ours (Aug 2013 is not THAT old) is stuck on CM12 (and now a final Snapshot build as of 6/25)? I mean, the Galaxy S3 is even getting 12.1 builds. I'm wondering if its because that was a far more popular device than the G2 was?
Just wanted to put this out there and see what other people think and find out what they're running currently on their G2 variant. I own the US T-Mobile D801 variant and do NOT want to run stock (LG) Lollipop since my device tends to run extremely HOT on it. I know not everyone was complaining about their G2 overheating on stock LP but I notice a considerable difference running CM12.
So, how do you guys feel about this? Do you even care or what?
Click to expand...
Click to collapse
We haven't had nightlies for a while now. What you see as nightlies aren't really worthwhile builds, they didn't have any device or kernel fixes for the g2.
A new 11 build is coming probably because half the android userbase relies on kitkat at the moment.
As for the s3, it's not getting CM12 nor 12.1, not the international version at the least. Archi is maintaining an unofficial version, but it still carries the bugs from 10.0/10.1.
Lastly, this is the commit that requires to be merged in order for the builds to even be considered started:
http://review.cyanogenmod.org/#/c/93181/
Without it, nothing CAF related can be merged, and as such, no CM12.1 builds can be had for our device. I believe the reason it's not merged because not all of the variants have a lollipop release, if they ever will get one. Also the whole bootstack/amount of users who don't reed is astonishingly dangerous to handle, so rashed simply preferred to skip building for now.
Finally, it's not that popular of a device. It's a nexus without being a nexus with a locked bootloader, which is a pain in the ass and not too many maintainers have it left (they either went with G3 or skipped LG entirely, as did a whole bunch from the exynos team back in the day).
t3chn0s1s said:
I saw you responded to my post about CM12 nightlies not continuing for the G2. Wanted to ask you (since you didn't mention) what 5.1 (CAF source) ROM you're running? What would you suggest for a stable AOSP ROM that has device/kernel specific updates for our G2s?
Click to expand...
Click to collapse
Why not reply to me in this thread then?
I'm running official euphoria builds. Any caf roms run fine. They are all based on the same LG-devs CAF device source + kernel source. Some roms have specific tweaks, but as far as functionality, they all work the same way (ie: if bluetooth deep sleep is broken, it's most likely broken in every rom).
Choristav said:
Why not reply to me in this thread then?
I'm running official euphoria builds. Any caf roms run fine. They are all based on the same LG-devs CAF device source + kernel source. Some roms have specific tweaks, but as far as functionality, they all work the same way (ie: if bluetooth deep sleep is broken, it's most likely broken in every rom).
Click to expand...
Click to collapse
Sorry - was on my phone when I saw your replies and it was just easier for me to respond in the other thread.
Anyways.. thanks for the info. I've done some research and I'm a bit more informed about CAF and what it means to device specific sources, ROMs, etc. Are you just using the stock Euphoria kernel or something else?
On this forum @varund7726 builds his rather excellent ResurrectionRom from the latest CM code release. I suggest you use that. For the D803, @zr239 has beaten all odds including LG not releasing CAF code, to build a fully functional pure CM 12.1 ROM that closely tracks official CM repos.
Lg G2 has it pretty good !
@Choristav
I wanted to clarify something you said in your initial response to my OP. You said the S3 wasn't going to get CM12 or 12.1 but when I navigate to the CM downloads page for ANY S3 variant - they ALL have CM12.1 nightlies still being generated. What exactly did you mean?
t3chn0s1s said:
@Choristav
I wanted to clarify something you said in your initial response to my OP. You said the S3 wasn't going to get CM12 or 12.1 but when I navigate to the CM downloads page for ANY S3 variant - they ALL have CM12.1 nightlies still being generated. What exactly did you mean?
Click to expand...
Click to collapse
I checked, you are right, several of the qualcomm variants have cyanogenmod support. This means that they have active maintainers, but they also don't have to deal with locked bootloader crap, which is why the bump commit is so important for our device.
I only mentioned the international version, which support was dropped because it had a lot of issues thanks to its closed source exynos processor (it requires extra work, and some stuff doesn't end up working anyway).
Not really much to say, the commit is already in CM's gerrit, it's just waiting for review. Maybe it's a CTS-side issue?
Aside from that, being a maintainer doesn't really require much, just effort and presence. It's not an easy task, I'm just saying anyone can apply to be a maintainer and get nighties rolling for a device you might not even have heard of.
@Rashed97 is the man for our G2 when it comes to CM. Dont mind nightlies as long as Rashed is around
Note: he is currently busy with the One M9 but we will hopefully see some cool stuff from him in the future.
Not really a big deal, last I remember those nightlies were still using outdated jellybean components. I wouldn't use them, I would use something on the G2 forums like Rashed97 builds like someone else said.
I don't think that the availability of nightlies has to do with the device itself so much as it has to do with someone maintaining the g2 and building roms, so nightlies could come back at any time if someone steps up and does it.
Ploxorz said:
Not really a big deal, last I remember those nightlies were still using outdated jellybean components. I wouldn't use them, I would use something on the G2 forums like Rashed97 builds like someone else said.
I don't think that the availability of nightlies has to do with the device itself so much as it has to do with someone maintaining the g2 and building roms, so nightlies could come back at any time if someone steps up and does it.
Click to expand...
Click to collapse
And it appears you're correct as there is another nightly build up with today's date. I apparently posted this thread prematurely.
Guys I wouldnt worry to much about CM, its not like they are the only (or even best) option in the forums. If you guys want development then dig in and make some for it.
zelendel said:
Guys I wouldnt worry to much about CM, its not like they are the only (or even best) option in the forums. If you guys want development then dig in and make some for it.
Click to expand...
Click to collapse
You are absolutely right. I had no idea until I posted this thread that CM nightlies did not contain any device specific updates. I honestly NEVER used to like CM at all. I honestly hated it... until owning a OnePlus One. I originally had the G2 right when it came out in 2013 and sold it off long ago & moved on to better devices - but when my OPO got stolen about 2 months back or so - I had to find a relatively cheap, but decent device and the G2 was the best bang for the buck (5.2" display, quick charge 2.0, 3000 mAh battery) and no other phones in 2013 came close to the specs the G2 had at the time.
So, now that I know CM is basically a sh*t ROM for this device I'll be moving on to a ROM that is compiled using CAF sources. Thanks everyone for your input!
Somehow doesn't look too good so far:
https://jira.cyanogenmod.org/browse/CYAN-6556
But why oh why?
The LG G2 still is such a modern and powerful device. It might be almost two years "old", but it's way better than a lot of other current devices.
I am using AICP on my g2. It is based on CM(5.1.1).
What's the best place to follow updates / changes to the CAF stuff?
I know there's a handful of ROMs based on CAF sources, I'm not too interested in the changelogs of those ROMs, more following the progress of CAF before it eventually all gets merged into CM12.1.
Is this it? https://github.com/lg-devs/android_device_lge_g2-common/commits/cm-12.1-caf
seanp25 said:
What's the best place to follow updates / changes to the CAF stuff?
I know there's a handful of ROMs based on CAF sources, I'm not too interested in the changelogs of those ROMs, more following the progress of CAF before it eventually all gets merged into CM12.1.
Is this it? https://github.com/lg-devs/android_device_lge_g2-common/commits/cm-12.1-caf
Click to expand...
Click to collapse
I would watch the Code Aurora forums where CAF comes from.
zelendel said:
I would watch the Code Aurora forums where CAF comes from.
Click to expand...
Click to collapse
It's better to watch public activity on Rashed97's github. He is CM maintainer for LG G2 and he brought up CAF sources for our devices.
adamz667 said:
It's better to watch public activity on Rashed97's github. He is CM maintainer for LG G2 and he brought up CAF sources for our devices.
Click to expand...
Click to collapse
No. It's far better to watch the main code base. Cm messes too much up by not testing code before merging.
zelendel said:
No. It's far better to watch the main code base. Cm messes too much up by not testing code before merging.
Click to expand...
Click to collapse
Okay, but @seanp25 probably want to follow source changes for our device, not common CAF source.
Just saw this:
Çetin ÇÖNE wrote on Jul 26 11:18 AM:
Why there is no nighlies it's really stable. Merge it please
Seth Shelnutt wrote on Jul 26 1:26 PM:
There are no nightlies because SELinux is not enabled. Sensors break with it enabled and I don't have time to address it yet.
Click to expand...
Click to collapse
Source:
http://review.cyanogenmod.org/#/c/103673/
Some days after that there came this:
http://review.cyanogenmod.org/#/c/103674/
So maybe there soon will be 12.1 nightlies?
I've built cyanogenmod a few times back in 2012 when I had an HTC Sensation. Never ported it to a new device.
I bought a Samsung Tab 4 (T230NU) a year and a half ago. It stopped working, wouldn't boot, I tried a bunch of different cords, it was non working for over a year, and I suddenyl had the idea to try a new cord again and bang, it works. I feel silly about that. It turns out I had also rooted it prior to it not working.
I've been looking for roms, and they're all kit kat, so I'm going to port CM13 to the t230nu. I think the process will be pretty straightforward, but if anyone has any tips or advice, I'm glad to hear it.
A bit of background, I'm a professional software engineer, use Arch linux, not unfamiliar with building software from source. I write in a bunch of different programming languages, and am part of the Liri Project, working on Liri Music. I'm hoping the experience I have will help me out here.
So CM13 is Android 6. Will there be any incompatibilities with kernels or vendor sw?
Hi,
When I read the questions and guides, it seems the Surface Duo can be unlocked and rooted pretty easily.
So I was wondering why there is no custom ROM for this device which is, by all means, not perfect (it has a lot of flaws) but that I consider as at least a refreshing attempt to dig out of the "one glass rectangle touch screen" that we're now used to for years.
Is it beacause there's no love for the device ?
Or is it because Microsoft released absolutely no sources for the internal hardware ?
If there's anyone willing to try, I can offer build server to do it...
And contacts in a community to help iron out problems...
Regards.
Microsoft has indeed released the sources of the internal hardware, or, at the very least, some of it. I don't really know how to determine whether or not all of the drivers are included with the kernel source code. But they do have this kernel source code hosted on GitHub, under a combination of MIT, Apache, and GPL licensing, as well as full instructions on how to build the kernel. The instructions are located at microsoft/surface-duo-oss, and the scripts end up downloading from other microsoft/surface-duo-oss-* repositories. I've not actually tried to build this myself, and I'm not sure what you actually end up with afterwards, whether it is just a kernel, or if it also includes AOSP, and whether or not this can be included in the process of generating another distribution such as Lineage. But, I think this should at least be some information that can be used to at least start the process assuming anyone with existing experience is interested in starting this.
I have seen it expressed elsewhere that one reason people have not created a custom ROM is that android 10 does not have native support for multiscreen devices, while android 11 does. Meanwhile, Microsoft has only released android 10 for the device, and this includes the surface-duo-oss scripts as well, but that there is plans here soon (late September) by Microsoft release android 11 for the Surface Duo.
Fingers crossed! Looking forward to a robust desktop mode and multiple external monitor support like the regular Surface Pro does
Basically a phone that acts like a Surface PC when you dock at home or at work so you can actually work from the device like a normal Surface laptop and then fold and put it in our pockets when we're done working
I know this is an older post but I sure wish someone would go ahead and give me the dummy guide to flash their custom rom!! If anyone needs a duo that thinks they can make it happen I have a spare one..... The left screen is glitching in and out tho.
So, I've got the Blackview BV9900Pro which as you probably know if you are reading this, is a wonderfully well priced, rugged phone with the Lepton FLIR camera built in. Being a Treble device, it is possible to install most GSI ROMs to it, however there is currently no build of TWRP, and thus far, nobody seems to have been able to get the FLIR working on the GSIs. This presents two problems. First, recovery is a wonderfully useful tool to have, and the stock recovery leaves a lot to be desired, Second, the FLIR is the main reason for buying the pro model of this phone, rendering custom ROMs virtually useless.
That being said, I love this phone, and want to start to work on both. This will be a major learning curve as a) I'm not a developer by trade (I'm a marine engineer and environmental officer on a cruise line) and b) My job takes 10+ hours a day, 7 days a week when I am on board leaving me with limited time to put into it. I've built Linux from scratch (LFS back a number of years ago) which gave me good experience with the build environment and with compiling code / troubleshooting issues so I am confident I can pull it off, but I'm intersted in gauging if there is interest in publishing my work for others ot use.
If you have the 9900Pro phone, and are intersted in either TWRP and/or custom ROMs that support the FLIR, drop me a reply here and let me know. If you have any experience with modifying custom ROMs to work with vendor hardware, I would LOVE to hear about it - it will perhaps help guide me in my efforts. One of my biggest peeves with the phone is the lack of support for basic features (ie, SIP calling is not natively supported in the vendor's ROM) and the bugginess of the OS (apps being closed int he background, widgets not loading on boot etc). The GSI I am running now (Lineage) solves these issues, but the lack of IR camera really devalues the phone, so I'm hopeful that I can resolve the issue, and make this phone worth having.
Also, if anyone knows how to go about adding a new device to the forum tree, please chime in. I'm completely new to this whole developer support thing but comitted to making it work!
Cheers everyone!