Since there's no tagged release here: https://android.googlesource.com/device/lge/mako/ for 4.2.2 yet, I was trying to use the device/lge/mako files in a checked out 4.2.2_r1 branch to build, but it's not working. I've already successfully built 4.2.1_r1 numerous times. Is this the correct way to go about it?
I'm new to building aosp so I was hoping someone could point me in the right direction on this. I'd like to get a working 4.2.2 aosp rom and then start cherry picking stuff from CM and AOKP.
Thanks :good:
Well, I never messed with aosp much, but it would probably be easier to pull the cm10.1 tree for 4.2.2
Sent from my Nexus 4 @1.5 GHz on Stock 4.2.1
inh said:
Since there's no tagged release here: https://android.googlesource.com/device/lge/mako/ for 4.2.2 yet, I was trying to use the device/lge/mako files in a checked out 4.2.2_r1 branch to build, but it's not working. I've already successfully built 4.2.1_r1 numerous times. Is this the correct way to go about it?
I'm new to building aosp so I was hoping someone could point me in the right direction on this. I'd like to get a working 4.2.2 aosp rom and then start cherry picking stuff from CM and AOKP.
Thanks :good:
Click to expand...
Click to collapse
honestly, IMHO you're better off waiting a few days. In my experience, you'll get it ported over after spending countless hours working on it, then within 6 hours the updated source will be pushed lol
I'd love a nice pure aosp 4.2.2 to check out too, but I really think it's better to wait
hp420 said:
honestly, IMHO you're better off waiting a few days. In my experience, you'll get it ported over after spending countless hours working on it, then within 6 hours the updated source will be pushed lol
I'd love a nice pure aosp 4.2.2 to check out too, but I really think it's better to wait
Click to expand...
Click to collapse
I mainly just want to do it for the experience. Having a clean AOSP 4.2.1 image was nice, and a 4.2.2 one would be better, but I'm still trying to learn my way around the android build system. I'm sure 30 minutes after I get it working google will push the source but that's ok because I'll know what the differences are by then
easiest way is to add the hardware and device paths back to the manifest here's an example of the syntax
<project path="hardware/qcom/camera" name="platform/hardware/qcom/camera" groups="qcom" revision="jb-mr1-release" />
"revision=jb-mr1-release" is one of the tags you can use to checkout the last working aosp branch
this will build you a "franken-ROM" like what the rest of us are building right now but like someone mentioned its better to just wait for aosp to add the source back if you are not to familiar with the build system
if you choose to go ahead and build anyway which you probably will you will need to hack the qcom/display/libexternal/external.cpp file to get past a compiler error in that file lines 449-456 need to read like
if(mFd == -1)
return false;
struct mdp_display_commit ext_commit;
memset(&ext_commit, 0, sizeof(struct mdp_display_commit));
ext_commit.flags = MDP_DISPLAY_COMMIT_OVERLAY;
if (ioctl(mFd, MSMFB_DISPLAY_COMMIT, &ext_commit) == -1) {
ALOGE("%s: MSMFB_DISPLAY_COMMIT for external failed, str: %s",
__FUNCTION__, strerror(errno));
hope this helps .........
It does, thank you!
Related
im trying to learn how to build i am a complete noob to linux but i learn quick already installed ubuntu 11.04 and have jdk 5 already installed for froyo as i would like to make a 100% working froyo build. the repo sync is still running and after that i am installing sdk for linux i just need a starting point to making the roms and kernels into a flashable.zip and other pointers that would be helpful. any advice is welcomed thanks in advance
host Executable: acp (out/host/linux-x86/obj/EXECUTABLES/acp_intermediates/acp)
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make: *** [out/host/linux-x86/obj/EXECUTABLES/acp_intermediates/acp] Error 1
i get this error when trying to "make"
fixed it have to use this sudo apt-get install gcc-multilib g++-multilib zlib1g-dev lib32z1-dev lib32ncurses5-dev gperf
compiling now
skater4690 said:
all the stuff you said...
Click to expand...
Click to collapse
You're trying to build an aosp rom for the vibrant with 2.2 code? You do know there's a reason we don't have a build like that, correct?
The closest aosp 2.2 we got was CM6 partially functioning. Besides, gingerbread is what people want.
Sent from my SGH-T959 using XDA App
geoffcorey said:
You're trying to build an aosp rom for the vibrant with 2.2 code? You do know there's a reason we don't have a build like that, correct?
The closest aosp 2.2 we got was CM6 partially functioning. Besides, gingerbread is what people want.
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Yes that's what I'm gonna try to do whether everyone wants gb doesn't matter to me I'm doing it for myself and to learn
This is a great reference that got me started. A lot of basics are covered in rom building, and it might answer some questions you don't even know you have yet.
Good luck.
http://forum.androidcentral.com/hacking/6037-general-rom-faq.html
Br1cK'd said:
This is a great reference that got me started. A lot of basics are covered in rom building, and it might answer some questions you don't even know you have yet.
Good luck.
http://forum.androidcentral.com/hacking/6037-general-rom-faq.html
Click to expand...
Click to collapse
Thanks ill take a look at it when I get home I have a 15 page guide lol but ill look through that too never too much info
You might want to start with the CM7 source. Far as I know, that's the most stable code tree you can find for the Vibrant - the raw AOSP code will not work out of the box.
Starting from 2.2 AOSP you won't even know if it's a missing driver, bad compile, bug you introduced, bad build environment, etc when it doesn't work. Start with something that does work, and you can learn and try things out in a more controlled environment.
Saiboogu said:
You might want to start with the CM7 source. Far as I know, that's the most stable code tree you can find for the Vibrant - the raw AOSP code will not work out of the box.
Starting from 2.2 AOSP you won't even know if it's a missing driver, bad compile, bug you introduced, bad build environment, etc when it doesn't work. Start with something that does work, and you can learn and try things out in a more controlled environment.
Click to expand...
Click to collapse
Well I wanted to do a froyo build and I don't think there was much for cm6 on the vibrant
But if you wanna toss me a link for cm6 then ill give that a shot
Side note this is my 666 post lol
skater4690 said:
Well I wanted to do a froyo build and I don't think there was much for cm6 on the vibrant
But if you wanna toss me a link for cm6 then ill give that a shot
Side note this is my 666 post lol
Click to expand...
Click to collapse
I suggested CM7 because it works. Don't think CM6 ever did, very well, so it doesn't really tie in with my suggestion to start from a functional build..
Here's CM7 code checkout and build instructions: http://cmsgs.com/mediawiki/index.php?title=Building_and_Installing_Gingerbread_from_Source_vibrant
I can't find the CM6 code in my quick search, sorry.
Saiboogu said:
I suggested CM7 because it works. Don't think CM6 ever did, very well, so it doesn't really tie in with my suggestion to start from a functional build..
Here's CM7 code checkout and build instructions: http://cmsgs.com/mediawiki/index.php?title=Building_and_Installing_Gingerbread_from_Source_vibrant
I can't find the CM6 code in my quick search, sorry.
Click to expand...
Click to collapse
Its cool Eugene has a nice cm6 rom but its not finished ill ask whoever made a aosp froyo rom for the fascinate for some pointers and cant do gb cause I set my jdk for froyo which uses jdk 5 I'm trying to learn everything all at once lol Linux and building Roms lol I'm familiar with how android works system files and such just needs tobhurry up so I can get out of work and get on doing some things
If you are trying to build a 100% working AOSP ROM for the vibrant you are waiting your time. Without source code for the drivers is not possible. Unless you know somebody that works in the development team in Samsung that can give you access to the source code you are out of luck...If you just want to mess around to learn then go for it...
I haven't ported anything before and haven't messed around too much with ROMs, besides some mild tinkering and a whole lot of flashing. I've got a spare Droid X laying around I thought I'd use as a guinea pig for some learning. Flashed Paranoid Android to my Nexus 7 and saw a link to porting it to other devices. So I figured it'd be a starting point for me.
I've been looking at this tutorial http://forum.xda-developers.com/showpost.php?p=27602914&postcount=24
I'm running Ubuntu 12.04, I've got Eclipse with the ADT plugin, android SDK, Meld for comparison/merging, and apktool/aapt.
Is this possible? Is the tutorial "valid"? I've got a verizon ICS Paranoid Android ROM and CM9 for the DX. What else do I need? Just looking for a little guidance.
No one?
I don't know a whole lot about porting or Java.
But I can recommend that you take the most stable build of Ice Cream Sandwich the Droid X can run and use it as a base for Ice Cream Sandwich Paranoid Android.
Good luck to you!
Sent from my Galaxy Nexus using Tapatalk 2
+1
infazzdar said:
But I can recommend that you take the most stable build of Ice Cream Sandwich the Droid X can run and use it as a base for Ice Cream Sandwich Paranoid Android.
Click to expand...
Click to collapse
I believe the most stable is MIUI v4, but I would recommend using CM9 or Gummy as a base. From about 20 minutes of Google searching, I can only find builds of PA that include CM10 base
Äptiva said:
I believe the most stable is MIUI v4, but I would recommend using CM9 or Gummy as a base. From about 20 minutes of Google searching, I can only find builds of PA that include CM10 base
Click to expand...
Click to collapse
I've got 3 different 1.5 (ICS) based PA. Can't get passed bootlooping though. Got logcats, but not sure what's going on there.
This is where it stops and loops.
Code:
D/AndroidRuntime( 1813): CheckJNI is OFF
E/dalvikvm( 1813): ERROR: couldn't find native method
E/dalvikvm( 1813): Requested: Landroid/graphics/SurfaceTexture;.nativeInit:(ILjava/lang/Object;ZI)V
E/dalvikvm( 1813): Candidate: Landroid/graphics/SurfaceTexture;.nativeInit:(ILjava/lang/Object;Z)V
E/JNIHelp ( 1813): RegisterNatives failed for 'android/graphics/SurfaceTexture', aborting
F/libc ( 1813): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
I'm attaching my logcat if anyone would like to help my out and take a look at it.
could you possibly put the more recent PA 1.5 in a DB so I can grab it or provide a link?
I'm more of a tinkering fixer than logs personally, but maybe it's just something in your port?
Äptiva said:
could you possibly put the more recent PA 1.5 in a DB so I can grab it or provide a link?
I'm more of a tinkering fixer than logs personally, but maybe it's just something in your port?
Click to expand...
Click to collapse
I'm uploading it now. Both my port and the 1.5 PA.
http://dl.dropbox.com/u/74325646/%5BParanoidAndroid%5D%5B1.5a%5D%5BLegend%5Dv2.zip Legacy PA 1.5
http://dl.dropbox.com/u/74325646/PADXport3.zip My bootlooping port.
danjull said:
http://dl.dropbox.com/u/74325646/%5BParanoidAndroid%5D%5B1.5a%5D%5BLegend%5Dv2.zip Legacy PA 1.5
http://dl.dropbox.com/u/74325646/PADXport3.zip My bootlooping port.
Click to expand...
Click to collapse
Downloading these now. Probably won't be able to do much till later tonight.
Cool, let me know what you find out.
danjull said:
Cool, let me know what you find out.
Click to expand...
Click to collapse
Did someone figure out why it wont boot because if have experienced the same problem multiple times and im wondering why i followed many guides done research but nothing and if it has been done can i get a link
I haven't had a chance to look any more at it. Got a non working port from a guy over at rootz who gets past the little vibrate point at boot. But no launch. Got a logcat from the boot...
Hello friends.
As all of us see, LG released their KitKat sources long time ago. Our great developers like @dr87 @Savoca @houstonn and others made it with Their hard work to merge them so we have two stable / nearly stable roms: Mahdi and PA. But what with other roms? Most of the roms are based on CM, so they still have bugs.. During months, CM doesn't seem to have done ANYTHING.
So my question is, how about to send a message (or spam, in any way u name it) by all of us to CM, to the maintainer? We have official support, but in fact it's "support without support" in my opinion. Maybe after these messages they would finally start to do something, because it's like they forgot about G2...
Regards.
EDIT: so we have a way to contact => https://jira.cyanogenmod.org/secure/Dashboard.jspa
now we should make a well, polite message so everyone would copy it and drop there.
Another way it would be to ask the maintainer directly https://plus.google.com/+RicardoCerqueira
EDIT2: I gave a comment to Ricardo on Google+ here https://plus.google.com/+RicardoCerqueira/posts/4dc8kVBYuTq feel free to do it as well
The best bet would be to create an improvement note at their so called "Bug Tracker" considering that they are doing this for free, this would be the most polite form.
I support this initiative, but today be entirely honest M6 for me is almost bug free, fast and battery efficient.
Up to date sources is great, but if a rom is working well, I don't care if the sources are old!
Inviato dal mio LG-D802 utilizzando Tapatalk
Airidas said:
The best bet would be to create an improvement note at their so called "Bug Tracker" considering that they are doing this for free, this would be the most polite form.
Click to expand...
Click to collapse
could u give a link please? so we could prepare a message and then everyone would leave it there
vittogn said:
I support this initiative, but today be entirely honest M6 for me is almost bug free, fast and battery efficient.
Up to date sources is great, but if a rom is working well, I don't care if the sources are old!
Click to expand...
Click to collapse
I personally had CM for some time, and it never was so stable as Mahdi R1 which i have now. Besides that, a lot of roms like Carbon or Slim can't be simply updated from CM sources, so they still have bugs.
reas0n said:
could u give a link please? so we could prepare a message and then everyone would leave it there
I personally had CM for some time, and it never was so stable as Mahdi R1 which i have now. Besides that, a lot of roms like Carbon or Slim can't be simply updated from CM sources, so they still have bugs.
Click to expand...
Click to collapse
Here: jira.cyanogenmod.org
Thanks, so anyone is, i would say, good in kind speaking to prepare a message?
Oh and we could also use Google+ and ask the maintainer directly https://plus.google.com/+RicardoCerqueira
Replyed 2 times to posts in his google + account with message " When LG G2 is going to have updated KK sources? A lot of people are waiting for bug-free CM and CM-based 4.4 ROMs ". I hope that all you guys do the same.Cheers
Sent from my LG-D802 using XDA Premium 4 mobile app
Just to clarify, roms that are based on CM do not need CM to upgrade to 4.4.2 sources. The upgrade is done in the device tree / vendor files and kernel. The rom source does not need any changes and each rom maintainer for the G2 has the power to upgrade their rom to 4.4.2 G2 sources without CM doing anything, they just need to figure out the specific device tree bugs for each rom and fix them.
I am under the impression you think CM needs to upgrade in order for CM based roms to upgrade, feel free to correct me if I'm wrong :good:
dr87 said:
Just to clarify, roms that are based on CM do not need CM to upgrade to 4.4.2 sources. The upgrade is done in the device tree / vendor files and kernel. The rom source does not need any changes and each rom maintainer for the G2 has the power to upgrade their rom to 4.4.2 G2 sources without CM doing anything, they just need to figure out the specific device tree bugs for each rom and fix them.
I am under the impression you think CM needs to upgrade in order for CM based roms to upgrade, feel free to correct me if I'm wrong :good:
Click to expand...
Click to collapse
apparently theres a bit of confusion, there was some one nightly where the rotation wasnt working with the jb baseband, (im gussing on that nightly he used the kk source ) because flashing the kk baseband on that build fixed the rotation issue, but im not quiet aware of what the situation is ince im back on stock. anyways ill be swinging it on the latest nightly just to clarify my doubts. and im pretty sure they just want the maintainer to switch to kk source , btw nice to see you here hope your cooking something great for us
dr87 said:
Just to clarify, roms that are based on CM do not need CM to upgrade to 4.4.2 sources. The upgrade is done in the device tree / vendor files and kernel. The rom source does not need any changes and each rom maintainer for the G2 has the power to upgrade their rom to 4.4.2 G2 sources without CM doing anything, they just need to figure out the specific device tree bugs for each rom and fix them.
I am under the impression you think CM needs to upgrade in order for CM based roms to upgrade, feel free to correct me if I'm wrong :good:
Click to expand...
Click to collapse
Well, in the past I had some Android phones, and CyanogenMod was always first with upgrading everything, and then other developers were basing their ROMs on these updates. I mean, they updated everything, end other ROMs were updated fast. They're not giving support which they were giving in the past, that's all.
reas0n said:
Well, in the past I had some Android phones, and CyanogenMod was always first with upgrading everything, and then other developers were basing their ROMs on these updates. I mean, they updated everything, end other ROMs were updated fast. They're not giving support which they were giving in the past, that's all.
Click to expand...
Click to collapse
Did you get a response from Ricardo?
LenAsh said:
Did you get a response from Ricardo?
Click to expand...
Click to collapse
Nope, i saw i got some 1+ on my comment, i shared second comment today. nothing..
reas0n said:
Nope, i saw i got some 1+ on my comment, i shared second comment today. nothing..
Click to expand...
Click to collapse
Oh
Guys,
Naturally, as the title states, its a general discussion thread for huashan LBL users. I want to discuss some things with like-minded people and hopefully once the momentum builds, we can try to achieve something.
Android L official release is just around the corner and our official fate is sealed by Sony @ 4.3.
But i plan on trying to port L using existing 4.3 kernel and make it at least boot so we know later on its a possibility for Locked Bootloader to have Android L.
Unlocked Bootloader guys are advised to stay away, as sooner or later, they will get proper AOSP 5.0.
Some points i want to make important.
1. This is NOT a cheer thread. Dont just post to show your excitement. It blocks the purpose of healthy discussion.
2. This is not for people who want new android. Have some sense, it isnt going to come anytime soon.
3. This is strictly for Locked Bootloader guys. So any other person coming and commenting might just be wasting his time.
Although, if you really have some positive thing to contribute, than whatever you have, LBL or UBL, please do share with all.
This is a good starting place to study.
https://github.com/Android-L-Porting-Team/Android-L-Mako/commits/master?page=3
Lets begin !
Im not sure how much id be able to contribute but ill be willing to help any way I can do. Do we even have a vague idea of what kernel modules would be needed for L? Im assuming thats what we'd need as I remember Bagyusz saying thats what he had to do for KK.
Has any of the freexperia team looked at L yet to your knowledge? Perhaps they may be able to give some small insight into drivers etc for LBL/UBL.
Will PA still be updated while this is being looked at? I'm assuming PAC wont need anything now unless problems occur as its all automated. Until L is working PA is a good thing for those wanting L due to them implementing features from L in KK such as recents and tinted bars (if they ever release them to legacy!!).
Oblox said:
Im not sure how much id be able to contribute but ill be willing to help any way I can do. Do we even have a vague idea of what kernel modules would be needed for L? Im assuming thats what we'd need as I remember Bagyusz saying thats what he had to do for KK.
Has any of the freexperia team looked at L yet to your knowledge? Perhaps they may be able to give some small insight into drivers etc for LBL/UBL.
Will PA still be updated while this is being looked at? I'm assuming PAC wont need anything now unless problems occur as its all automated. Until L is working PA is a good thing for those wanting L due to them implementing features from L in KK such as recents and tinted bars (if they ever release them to legacy!!).
Click to expand...
Click to collapse
Dont worry so much. PA is at a stage that if u have linux, u can just compile it right away and all is on Auto.
I will release milestone builds... No point pushing weekly updates if there arent any major changes.
For PAC, i have even taken that burden off and compiling and uploading is not my headache now.
And apart from above, i dont use PA personally. PAC suits me best.
As you stated the main concern is how well "the sealed by Sony @ 4.3. bootloader" will be able to cope with android L?
I really appreciate your enthusiasm. And yes there is only one way to find out. And that is to actually try porting it.
mmfh said:
As you stated the main concern is how well "the sealed by Sony @ 4.3. bootloader" will be able to cope with android L?
I really appreciate your enthusiasm. And yes there is only one way to find out. And that is to actually try porting it.
Click to expand...
Click to collapse
Porting is not an issue. We need a team. Not a band, but maybe 3 people. One compiler, One to tinker with trees and files, One tester. Just my suggestion.
One person cannot do it alone, unless he is an expert dev.
And about coping with L, all current devices having L port are using 4.4 kernel. And our 4.3 copes with 4.4. Technically there are not much issues compatibility wise. Just ramdisk and correct blobs.
I may be wrong, but thats why this discussion is goign on, if someone wants to correct me, please do.
I think this is an interesting project, XDA needs ppl like U
you think is easy port L with 4.3 kernel? I mean I'm just talking w/o reference, but Sony is just (until now) ignoring ART which is the biggest change for L (since 4.4 but well, now is not optional), and I think that could be a barrier to port new android for older phones (like SP)... what do you think about?
I hope this thread came with great news in the near future, :good:
This can be either hard or easy, hell or heaven, depending on the changes in L official release. Up until now, the changes are lying in ramdisk, but some features aren't available in the beta release.
But here are a few things that I noticed right now, before the official release:
1. UBL and LBL are stuck with 4.3 blobs. We are already using patched libraries, I guess it will get worse later, even on UBL.
2. I think we should wait until the CM12(?) will be working on UBL, while helping with bringing it up. If it works on UBL, then we should tinker with the LBL version. Actually, we have the hijack part, and we have the patches needed. I think it will be easy to get it to boot.
3. I think when @delewer finishes his kexec modules, some people that are experienced with kernel development could port it to SP, and then we could use it on forever locked phones. It will take some time, but will be the best for our phones.
So overall, if we have some luck, we would only have to kang CM trees, add the patches for hwcomposer, etc., add hijack and maybe some kernel modules. But we can be extremely unlucky and... I don't even want to imagine the worst case scenario.
Dont worry, the ground work is there. bagyusz gave us a great gift. I am sure Final release wont have boot-related changes. Maybe framework and libs, but not more.
The best thing is, 4.3 SONY rom DID NOT support ART. Bagyusz made it work even on LBL. and as Android L only supports ART, so thats the most important point i think.
Hmm, is ART even kernel-dependent?
I think that's not the case, and it's just great for us. So, bagyusz did a great work(it's just amazing), but I don't think he made any change to support ART.
And yeah, maybe there are just changes in frameworks and libs, but I'm still paranoid about this.
Anyway, I think that we are going to make it. That's what I feel, and I hope it comes true
neXus PRIME said:
Porting is not an issue. We need a team. Not a band, but maybe 3 people. One compiler, One to tinker with trees and files, One tester. Just my suggestion.
One person cannot do it alone, unless he is an expert dev.
And about coping with L, all current devices having L port are using 4.4 kernel. And our 4.3 copes with 4.4. Technically there are not much issues compatibility wise. Just ramdisk and correct blobs.
I may be wrong, but thats why this discussion is goign on, if someone wants to correct me, please do.
Click to expand...
Click to collapse
As I'm far from developer, I'm afraid cannot be of big help to you.
But I'm willing to contribute by testing builds and discovering bugs.
MrSteve555 said:
Hmm, is ART even kernel-dependent?
I think that's not the case, and it's just great for us. So, bagyusz did a great work(it's just amazing), but I don't think he made any change to support ART.
And yeah, maybe there are just changes in frameworks and libs, but I'm still paranoid about this.
Anyway, I think that we are going to make it. That's what I feel, and I hope it comes true
Click to expand...
Click to collapse
Not kernel dependant, i know, but you know what, booting a new android version using old kernel with just hijack n scripts is one HELL of a job.
And ART even didnt work for a long time on AOSP CM for huashan on UBL.
My point was, what we have here is a 4.3 kernel and blobs which might or might not be enough for android L. But before official release, we can try to port L from mako, by replacing blobs and ramdisk and boot, so that we have at least a proof of concept that LBL CAN boot L. Just boot. Nothing else.
neXus PRIME said:
Not kernel dependant, i know, but you know what, booting a new android version using old kernel with just hijack n scripts is one HELL of a job.
And ART even didnt work for a long time on AOSP CM for huashan on UBL.
My point was, what we have here is a 4.3 kernel and blobs which might or might not be enough for android L. But before official release, we can try to port L from mako, by replacing blobs and ramdisk and boot, so that we have at least a proof of concept that LBL CAN boot L. Just boot. Nothing else.
Click to expand...
Click to collapse
"Just" hijack? Bagyusz gave us an excellent base(hijack), and I bet we can boot FFOS or Ubuntu on that.
I didn't even know that ART didn't work on huashan before. Wasn't it a Gapps problem?
And yeah, these maybe aren't enough, as we are already patching some libs.
Ans one thing - I don't think we could port that from mako. It uses a little different base, and it isn't a CAF base. I think we should just wait
MrSteve555 said:
"Just" hijack? Bagyusz gave us an excellent base(hijack), and I bet we can boot FFOS or Ubuntu on that.
I didn't even know that ART didn't work on huashan before. Wasn't it a Gapps problem?
And yeah, these maybe aren't enough, as we are already patching some libs.
Ans one thing - I don't think we could port that from mako. It uses a little different base, and it isn't a CAF base. I think we should just wait
Click to expand...
Click to collapse
Just hijack meant different in a positive sense. But maybe it came out wrong.
And I'm talking about porting. Framework. Not building from source. They are actually doing same thing. I'll have to give it some time though.
neXus PRIME said:
Just hijack meant different in a positive sense. But maybe it came out wrong.
And I'm talking about porting. Framework. Not building from source. They are actually doing same thing. I'll have to give it some time though.
Click to expand...
Click to collapse
Yes, I know what you are trying to say with porting L. Actually, there would be a few things that would break:
1. The YUV color palette support (fixable with our hwcomposer, gralloc etc)
2. GPU drivers - this is the "best" part. L is precompiled, and I think it uses the libRS override, which doesn't work on our huashan because of a kernel difference (if we could build from source, we could just not enable it). There are a few other things that aren't compatible. So even if we got it to boot, it would just show black screen, and I assume by "just booting" you mean actually seeing the effort
3. The whole "thing" is built off AOSP repos, not CAF ones. Idk if SP's stock kernel would play nicely with the whole different stuff.
These are just my assumptions, in the end everything could work just fine. If you have the sufficient time, it's nice to try. Just deleting the mako proprietary stuff, and adding the needed huashan blobs + adding correct ramdisk would get it to the bootable/half working state (or there is a chance that the "build" wouldn't even boot.). I guess it's not done yet for a reason.
Anyway, I have to squash one last bug in my CM builds. If it will work, I could also try porting the magical "L".
Dear friends the account of CyanogenMod show an early source of the CM12,
hope that some one build a CM12 for us, till i get new laptop to do that.
https://github.com/CyanogenMod/android_system_core/tree/cm-12.0
https://github.com/CyanogenMod/android_vendor_cm/tree/cm-12.0
sycolon said:
Dear friends the account of CyanogenMod show an early source of the CM12,
hope that some one build a CM12 for us, till i get new laptop to do that.
https://github.com/CyanogenMod/android_system_core/tree/cm-12.0
https://github.com/CyanogenMod/android_vendor_cm/tree/cm-12.0
Click to expand...
Click to collapse
trying to build now..fetching repos at the moment. I dont think this will work out but we'll see
Edit: didnt work out. what a surprise
@hutilicious sadly that it didn't work!
sycolon said:
@hutilicious sadly that it didn't work!
Click to expand...
Click to collapse
cyanogenmod hasnt any working device specific configuration and code for yuga in cm12 at the moment.
i tried using pabx yuga.xml and TheMuppets blobs, but got errors with conflicting repos I couldnt resolve, may be due to that I have only basic knowledge about all of that.
I guess as for now, we have to wait until CM starts building nightlies (a leaked document says dez. first) or use pabx/thomas AOSP port for yuga, which can be used as a daily driver already.
@hutilicious i'm already using @pabx ASOP port
you seems to be crazy over lollipop anyway for CM12 as far as I know the popping sound will be finally be fixed it was due to qcom introducing of deep buffer, anyway as far as I know that's all but you can expect nightly before 2015