Fellow Members
Just wanted to get some advice or material that I can read, in regards to building ROM and compiling. Maybe a few websites that you would recommend? I have been a long time lurker and finally wanting to start trying some dev work for our gtablet community. Any input would help significantly
Thanks,
Thanks for asking
I too am very curious and I wonder how the current devs learned how to do what they do. I hope someone answers this question so those of us that are curious can find a place to start poking around a bit.
yes can anyone comment, would like to know aswell. thanks
I can only assume (since I'm just as clueless) that it requires knowledge of linux programming, or at least, how linux files are set up.
A lot of roms are ports of other roms, or stock firmware. For instance, VEGAn 5.1.1 is a port of the Advent Vega firmware. The Vega, and Notion Ink Adam are all tablets with the same, or mostly similar hardware as the G-Tablet. If one can get their hands on the firmware for those, then tweaks and adjustments can be made to make it work on the G-Tablet. That's what's heppening with the HC ports right now. They are not originating with Roebeet, Linuxbossolutions, et al. They are ports of the roms based on the work being done with the Vega, Acer, and Asus tablets...
REally all that is needed is the source code for the rom you're thinking of emulating, then the knowledge of where to look for the files that need altered to make it functional on the device you want it on.
That's the beauty of the G-Tablet, it's relative unbrickableness (is that a word, well, it is now) Once you have a rom, you can open revise it to your heart's content, NVFlash it to your device and see if it works, if it doesn't, change somethign else, change it back, edit this, edit that, reflash it and see what happens. The HC roms are all in Alpha mode right now because they need tested. A developer can only do so much in testing...having 50 people testing a rom, for an hour each is a lot better than testing it yourself for 50 hours.
I was able to find a few "how to" books for creating android .apk files, so I wouldn't be surprised if there was a source for reading how to hack, edit, and revise android firmware source.
If you are wanting to build from source, Google "how to build AOSP" or such.
You'll also have to look towards cyanogenmod for some tips and/or at least forking the repository they have for the gtablet device.
You pull the source code to Android down to your linux workstation (or linux running in a virtual box) and you have to add in the source repo for your device as well as fork off the repo's you plan to edit.
I went through this around this time last year. Froyo was coming out in leaks for the original Motorola Droid and I wanted to learn how to compile the AOSP that Google/Android provides (Android Open Source Project).
It was a difficult learning experience because no one wanted to share any information except Cyanogenmod Team and I was trying to build as straight AOSP as possible.
To really do it right.......
Setup a Linux workstation (or virtual, I did it this way).
Learn as much as you can about git and github.com (learn about forking, creating repos, syncing, editing and pushing your edits, etc..).
Be prepared to spend many hours/days/weeks/months editing, re-editing, reverting and cussing as you run successful "makes" against your source only to have it lock your device.
I eventually wrote a guide on how to build for AOSP but it is tailored to the motorola droid. Most of the steps are identical though you would need the device repo for the gtablet (smb_a1002) instead of the Droid (sholes).
If you want a brief look at it http://android.snkbitten.com/ and look at the AOSP source building guide.
Other than that...you can take other's ROMs, open them up (on your PC), replace files, edit the framework files etc... and then repackage it. Find the pieces that work best together (in your opinion) and roll with it. Change the build.prop to have your device name, etc...
During my learning experience I borrowed a lot from cvpcs, cyanogenmod, koush and a few others. Pouring through their github accounts to see what they were doing, sometimes manually pulling in certain aspects I liked but not wanting a copy of what they were doing..... It was time consuming and some times hair pulling out frustrating!!! However...I have a ROM in ROM Manager for the original Droid that I've been running ever since.
I thought about modifying my setup to allow multiple device building and doing a Gtablet SnkBitten ROM....but just never put any effort towards it.
Related
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice for those looking to make their own Android ROMs.. Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works (the links below have almost everything you could possibly want to know). Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that **** on your resume. There is a *ton* of information out there but any kind of "step-by-step rom cooking guide" is going to be a complete fail- it's too broad of a subject.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
I cannot agree more. Learning the in's and out's of the Android framework will benefit newcomers SIGNIFICANTLY.
Building ROMs is easy, fixing bugs and adding new functionality is the fun stuff, and having a solid understanding of the Android framework helps with this. The best way to learn is to pick up the Android SDK and whip up some apps, there are great tutorials out there.
Awesome information! It is good to see I have been reading the right literature... There are also a few that I missed... Thanks again for the links!
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice for those looking to make their own Android ROMs.. Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works (the links below have almost everything you could possibly want to know). Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that **** on your resume. There is a *ton* of information out there but any kind of "step-by-step rom cooking guide" is going to be a complete fail- it's too broad of a subject.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
I completely agree. But it's cyan saying it, who wouldn't
I am ok with "chef" terms because they were born on XDA, which makes them kinda cool, but I agree that the file-pusher mentality/stereotype is quite derogatory.
I hope this section goes places.
P.S. Hearing a diehard android dev like you (cyanogen) say that you are biased against sense really made me think about how good plain old android really is... so clean and functional. Good stuff bro.
very nice thanks for the info was looking into this...now to fill the brain.
Weird how this is exactly what i was looking for. Time to read. Thank you cyanogen.
I'm with Cyanogen on the bias against pre-built, proprietary code blobs. Even the non-free, basic parts to get AOSP to build for dream give me the hivie-jivies, mostly because the reason we're in such a pit now with further versions of Android is because we have no source to maintain working basic functionality (yeah, video in a device capable of recording/playback is basic).
I'll try to work a couple basic tutorials based on my rom-building exploits covering things from getting android built from source, to actual troubleshooting possible problems, to having a hand at modifying the source so you can make the built your own. I really want to see somebody come up with a real custom rom on the android part of the OS and leave the linux part rest for a while.
Oh man! PDK! Never seen it! Thanks a lot
Great job
As always, my hat is off to you Cyanogen. This is exactly what i was looking for. Once again thanks for your hard work and dedication to the project.
This is awesome. I am going to be learning this stuff over summer. But there seems to be a gap of information between learning the android stuff, and learning the linux stuff.
Hi do you know some guides online to build Overclocked Kernels ???
PDK website
Odd that the PDK website does not function. Anyone know who owns it?
mistere372002 said:
Odd that the PDK website does not function. Anyone know who owns it?
Click to expand...
Click to collapse
Works fine for me. What issues are you having?
I guess I'll be the first in the thread to ask the extreme newbie questions.
Are the links in the OP in a particular reading order, or is there a recommended order?
Since the entirety of my programming experience is some simple VB type stuff, will I be able to learn from the ground up via those links, or will it be more like trying to figure out the words in a Chinese book with no knowledge of the language?
At one point I had managed to cobble together a web front end on my Droid for wowhead.com (all it did was bring up a screen with a search box, which would then pop open the browser with the results of whatever you searched for), but to say I had a firm grasp of what I was doing in my tinkering would be a gross overstatement.
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice for those looking to make their own Android ROMs.. Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works (the links below have almost everything you could possibly want to know). Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that **** on your resume. There is a *ton* of information out there but any kind of "step-by-step rom cooking guide" is going to be a complete fail- it's too broad of a subject.
Click to expand...
Click to collapse
So, firstly thanks for the websites. Personally, I already knew about most of those. But that is beside the point right now.
Why would someone want to learn how to program anything when they are just building a rom? I just don't understand what is wrong with someone only tweaking and slimming a rom down. What point would it be for a website like this to make everybody just go out and learn on their own EVERYTHING, and then what would this site be for? Posting only in the development forums? This is a support website. Plain and simple. Who cares if someone asks a question? If they searched and couldn't find something, let it go.
In your same thought process, very FEW WM chefs could call themselves chefs. And before you ask yes, I could call myself a chef because I have written quite a few apps to assist in building a rom or actual tool for WM. Maybe not the best chef, but one nonetheless.
I just think this is basically discouragement of any new developers/chefs from posting something in fear of being chastised. I am absolutely still learning android. If it wasn't for the people of SDX, particularily joeykrim, I wouldn't be so close to a final product of my Android kitchen.
This being said, maybe I am just full of crap and the only one that will go against your POV. Mainly because I am not afraid to state my opinion. And this POV is wide across the forum and this is why I don't contribute much here anymore
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice for those looking to make their own Android ROMs.. Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works (the links below have almost everything you could possibly want to know). Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that **** on your resume. There is a *ton* of information out there but any kind of "step-by-step rom cooking guide" is going to be a complete fail- it's too broad of a subject.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
Thank you.
cyanogen said:
I really dislike the "chef" moniker when it comes to Android, since we are more of an open-source community. I think it implies a "file pusher" mentality. But then again, I am biased against proprietary versions of Android like Sense, so feel free to disregard all of this.
Here's my advice for those looking to make their own Android ROMs.. Stop. Write an app or two first, learn how the system works from a developer standpoint. Learn some Java. Read the developer documentation. Learn how to use Git. Then learn how to build AOSP from source. Read the porting guides, and learn how the build system works (the links below have almost everything you could possibly want to know). Now try to put your new found skills to work on enhancing the platform by writing code or making theme overlays. And share! And put that **** on your resume. There is a *ton* of information out there but any kind of "step-by-step rom cooking guide" is going to be a complete fail- it's too broad of a subject.
Android Developer Guides: http://d.android.com
Working with AOSP source: http://source.android.com
Platform Developer Guide: http://pdk.android.com
Android Gitweb: http://android.git.kernel.org
Git Ready (Git tips and tricks): http://www.gitready.com/
Building CyanogenMod: http://wiki.cyanogenmod.com/index.php/Building_from_source
How Dexopt works and what are those odex files: http://android.git.kernel.org/?p=pl...bcd225e47b2cc7abb2a366112d3aeb45936;hb=master
The PDK site is absolutely vital if you are going to work on custom ROMs. Read every single page. Twice. Some of the info isn't up to date, but you'll get a really good idea about what goes into actually configuring Android to work on a real device.
Click to expand...
Click to collapse
Thanks for your support/advice,
I'm trying to understand all the stuff in order to create a new ROM for Tattoo from 0, and I will take your info in order to. Crate this ROM and make a step by step manual to help people to understand how to modify their Tattoo's. I will like to see this cooperative knoledge share for this phone. As more peoople understands all this stuff, and all this work done by the comunity, more people will join and share to have better phones every day.
Tanks
java version
hi all,
Working 100%. Thanks for this great work. Now runing this 2.6.34 kernel on tattoo. Just now ajusting the kernel configuration.
Cheers
great advice
Cyanogen
Thanks for your support & advice
Time to start reading....
trying to understand all that is needed ==
TO BE A DEVELOPER..
IF ANY BODY HAS MORE INFO OR VIDEOS ..
PLEASE POST
----------------------------------
Currently own a Sprint EVO 4g > and plan on making great things for it..
Cyanogen you are so damned right. Building a Rom should implicitly mean that you know git, Android, dev and... read api and docs
I'm thinking about dsixda Rom kitchen.
I use its scripts to unpack kernel and zip everything, but largely customized the scripts and added some. In fact I love shell scripts.
I just wish you could also post a link to a toolchain tutorial for those willing to compile binaries from sources on x86 for an ARM architecture. And also to add shared libraries.
Have a nice day.
Hey there, everyone.
I'm just looking for some advice. I've been using my Verizon Samsung Fascinate since November, and for the most part have been a very happy user. Ever since I installed a Gingerbread-based ROM, I have been extremely happy with both the device's performance and new features (nothing says cool like the Old TV Shutoff animation). Lately, I have been wanting to try my hand at modifying and packaging my own Android ROMs for the Fascinate. Obviously, I have never done something like this before, so I'm looking for some advice.
I've been programming in Java for over a year now and I'm very familiar with the language as a whole. I've used it in various programming competitions through school along with building some applications and tools for the company I'm currently interning with. Right now, I feel that I have the basic programming skills required to look through code and understand what the logic behind it is (at least I hope).
My question for you all is this: should I jump right in and start poking through the AOSP code, or would it be more beneficial for me to start off as an Android App Developer, slowly working my way into Android hacking? I have some ideas for potential apps (which I'll probably end up developing regardless, but at a later date), so if it would be more beneficial to just develop apps, I certainly have a basis for my ideas.
Any personal stories/recommendations would be excellent. Thanks in advance for any/all answers!
hey everyone. ive been googleing and googleing for weeks and weeks trying to educate myself on how the android build process works and how a device tree works. what i have been able to figure out is the device configuration has been moved form /vendor to /device between eclair and froyo. although i am very lost and confused. i have gone through source.android.com several times, and i have also gone through the very outdated platform developers guide. right now i am trying to teach myself how to set up a build environment for a real device. im doing this purely out of learning experience so i can apply it to something useful in the future. i have several devices at my disposal (epic 4g, droid1, atrix 4g, acer iconia a500) any of which i would be willing to use for learning. does anyone have any recommendations on reading material im missing? any good place to ask stupid questions? there is lots of documentation out there but i just cant seem to find it. where should i go from here? i wish i could just take a class on this. because there is so much information out there i have no idea where to go from here.
I was actually going to make a post along the same lines as yours. From what I have found the pinned post in this forum from cyanogen about cooking is probably the most useful information to get started.
The issue I have is a forum just on this topic alone. It would be nice to have a forum that only discussed merging manufacturers released code into AOSP. By googling I have found the Atrix source code that Motorola has released and also the AOSP itself. By reading cyanogens post and mucking around with the source this should give you a good start.
Good luck and if you come across a forum with just this topic discussed post a link.
Also for setting up an environment this post is good for getting everything setup to compile what you need. It is a post to compile CM7 but it can be used for what you are looking for.
gh123man said:
hey everyone. ive been googleing and googleing for weeks and weeks trying to educate myself on how the android build process works and how a device tree works. what i have been able to figure out is the device configuration has been moved form /vendor to /device between eclair and froyo. although i am very lost and confused. i have gone through source.android.com several times, and i have also gone through the very outdated platform developers guide. right now i am trying to teach myself how to set up a build environment for a real device. im doing this purely out of learning experience so i can apply it to something useful in the future. i have several devices at my disposal (epic 4g, droid1, atrix 4g, acer iconia a500) any of which i would be willing to use for learning. does anyone have any recommendations on reading material im missing? any good place to ask stupid questions? there is lots of documentation out there but i just cant seem to find it. where should i go from here? i wish i could just take a class on this. because there is so much information out there i have no idea where to go from here.
Click to expand...
Click to collapse
2nd hit googling android porting.
http://www.netmite.com/android/mydroid/development/pdk/docs/
Nothing is truly "update-to-date" there are somethings that your going to have to do your homework on. That is a very detailed guide on the basics of getting a port going and working towards the "device tree"
Unless the device tree is from a google nexus phone, then most likely the trees are not perfect. Cyanogenmod for example, the devs that work hard on creating those device trees don't just know what will and won't work. Each phone is different alot of trial and error. Do you build a binary from source, or do you use prop files already on the phone, that is all based on what is trying to be done and how much you know. Eventually you figure it out. It hard to just say what creates the device tree. Its just like someone asking for tips on how to write Java.
Bottom line, just do it and have fun.
lithid-cm said:
2nd hit googling android porting.
http://www.netmite.com/android/mydroid/development/pdk/docs/
Nothing is truly "update-to-date" there are somethings that your going to have to do your homework on. That is a very detailed guide on the basics of getting a port going and working towards the "device tree"
Unless the device tree is from a google nexus phone, then most likely the trees are not perfect. Cyanogenmod for example, the devs that work hard on creating those device trees don't just know what will and won't work. Each phone is different alot of trial and error. Do you build a binary from source, or do you use prop files already on the phone, that is all based on what is trying to be done and how much you know. Eventually you figure it out. It hard to just say what creates the device tree. Its just like someone asking for tips on how to write Java.
Bottom line, just do it and have fun.
Click to expand...
Click to collapse
thanks for the response. maybe im just searching for the wrong things... that and its not sinking in to my thick skull lol.. ill keep reading. im just trying to learn how it all works. some of the things i read either dont make sense or are really vague. i am currently cramming java into my head for app development. i suppose thats a good place to start. my end goal is to contribute.
gh123man said:
hey everyone. ive been googleing and googleing for weeks and weeks trying to educate myself on how the android build process works and how a device tree works. what i have been able to figure out is the device configuration has been moved form /vendor to /device between eclair and froyo.
Click to expand...
Click to collapse
I am trying to figure out how to build/port ROMs too. It has been a nightmare trying to study that. Not enough material, or the material is incomplete. Most of the tutorials are meant to be done with nexus devices wich has a native suport from android. No such a help for someone who is seeking a way to build for a new, unusual device (like me).
I didn't get this "three" thing. And, In my case, it is a little bit weirder because I am trying to build for a MTK6577 processor. (Some may say I am screwed).
although i am very lost and confused. i have gone through source.android.com several times, and i have also gone through the very outdated platform developers guide.
Click to expand...
Click to collapse
Many years ago I said: there will be a Time when people will know the "internet junkyard" or the "virtual online trash can".
I was reffering to outdated information. This information is available now and is not completely reliable because it is old and no one got rid of it.
It is something that is new (although the information is old, the event is pretty new) and we must learn how to deal with it. Unfortunally.
To de development point of view, I've been facing an incredible hard time just to find new information about building a custom rom from the source or porting an existent one.
I know i didn't help at all, but, I felt I must say that.
Anyway, knowing about anything, let me know.
Best regards!
gh123man said:
hey everyone. ive been googleing and googleing for weeks and weeks trying to educate myself on how the android build process works and how a device tree works. what i have been able to figure out is the device configuration has been moved form /vendor to /device between eclair and froyo. although i am very lost and confused. i have gone through source.android.com several times, and i have also gone through the very outdated platform developers guide. right now i am trying to teach myself how to set up a build environment for a real device. im doing this purely out of learning experience so i can apply it to something useful in the future. i have several devices at my disposal (epic 4g, droid1, atrix 4g, acer iconia a500) any of which i would be willing to use for learning. does anyone have any recommendations on reading material im missing? any good place to ask stupid questions? there is lots of documentation out there but i just cant seem to find it. where should i go from here? i wish i could just take a class on this. because there is so much information out there i have no idea where to go from here.
Click to expand...
Click to collapse
Here is the Small Guide Made to Begin from scratch for Android Device Tree Building
Hey all
After about 4 years with IOS phones ( primarily for game development) ; I finally hopped back on a phone I could stomache and enjoy tweaking.
My apologies in advance if this is obvious somewhere in the sub-forums (but I couldnt find the answer) .
After testing a few ROMS I settled into Jedi XV12 w/ Perseus Kernel and love it with the Nova Prime Launcher.
I would love to start working from this base ROM to try my hand at a GSM (with working data/4G/LTE) version that incorporates APN and other radio/network specific tweakability. The idea of a single device that I could use on TMO/ATT/VZW/SimMo/Straight Talk & **maybe Sprint ughhh* is too tempting after living in the Apple Walled Garden of Pain.
I have my environment setup on a MacAir (Ubuntu 64Bit in Fusion) and also a Desktop native Ubuntu 64Bit with Eclipse/SVN/GIT etc etc along with the Samsung source and Vanilla 4.2.1.
Does anyone know if JediXV12 has a repo I can pull/merge against? Or even JellyBeans B13? Ideally a full source tree pre-merged would be fantastic to jump right in.
As some background on me: I have been doing everything from C,C++, Objective C , Python & RoR for over a decade.... pushing 15 years now Mobile games development since 2007 ..........
Would love some feedback or help as I havent dug into android other then just 2 games a few years ago.
BTW: This is simply the best multipurpose device I have used in ages. From speed to the AMAZING black levels AMOLED gives !
Anyone... Anyone... Bueller... Bueller...? Lol
Sent from my SCH-I605 using Tapatalk 2
The only ones with full repos are going to be the AOSP ROMs. The others are primarily made through decompiling the Samsung code, editing the smali, and recompiling, and they aren't required to publish the source for their development since the only part of Android that's actually covered by the GPL is the kernel.
shrike1978 said:
The only ones with full repos are going to be the AOSP ROMs. The others are primarily made through decompiling the Samsung code, editing the smali, and recompiling, and they aren't required to publish the source for their development since the only part of Android that's actually covered by the GPL is the kernel.
Click to expand...
Click to collapse
Thanks for the reply Shrike. That's what i figured as well, but was hopeful that a full source code tarball or zip would give me a leg up to ensure a stable codebase merge with the current Jedi XV12 to add support for Domestic APN's and the such via updates from one of my servers to mitigate APN changes /updates/variances for specific carriers 3G/4G/HSPA+/LTE settings.
I'll hit up Jedi devs and see if they are interested in a hand with adding these features I suppose.
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