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.
Related
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.
I'm curious about something. Are there any roms for the photon that's built from the ground up by the dev and not based on anyone else's work? I've noticed that most of the roms for the photon are in some way based off another devs work on another phone just with minor tweaks here and there. Joker seems to be the only dev I've noticed that has done most of his own work.
Sent from my MB855 using XDA
Looks like you missed the point
This all here is the Android community and everyone uses others work, when making roms.
Even Joker uses others work. ;-)
Do not say anything about something,if you know nothing. ;-)
Except for pure AOSP builds, ALL ROM's are based off of either CM or stock (ports fall under one of these two groups as well). Pure AOSP builds are very rare as the dev has to write a lot of the drivers, framework and such from scratch. This applies to all android devices.
Pure AOSP builds on devices without full sourcecode from the component manufacturers are considered so time consuming that most devs never even both. A perfect example is the Tegra2 development board. Even those that have purchased the dev board do not have access to all the sourcecode as there's a lot of proprietary code that does not fall under opensource. Short of somebody risking some serious legal issues by releasing proprietary code the code is never released. At last check, nobody has all the source code for the Tegra platform.
Another example is during a conversation with agraben at the android bbq the subject of sourcecode came up. Both he and I were a little pissed the handset manufacturers are using wrappers (closed source) to get things like cameras and the like to work. In some cases the released drivers (open source) are pretty much useless as most of the functions are handled by the wrapper. Think of it as soft-drivers (proprietary) vs hard-drivers (opensource).
There is also a lot that goes on behind the scenes. It's not uncommon for devs to share fixes and such with each other. Lets say I find a way to make the mopho print money (I wish this was true). Unless I'm a complete d*ck, I'd send other devs a PM/email and give the code to any devs that want it. The most I may ask for is a mention in the credits.
Lokifish Marz said:
Except for pure AOSP builds, ALL ROM's are based off of either CM or stock (ports fall under one of these two groups as well). Pure AOSP builds are very rare as the dev has to write a lot of the drivers, framework and such from scratch. This applies to all android devices.
Pure AOSP builds on devices without full sourcecode from the component manufacturers are considered so time consuming that most devs never even both. A perfect example is the Tegra2 development board. Even those that have purchased the dev board do not have access to all the sourcecode as there's a lot of proprietary code that does not fall under opensource. Short of somebody risking some serious legal issues by releasing proprietary code the code is never released. At last check, nobody has all the source code for the Tegra platform.
Another example is during a conversation with agraben at the android bbq the subject of sourcecode came up. Both he and I were a little pissed the handset manufacturers are using wrappers (closed source) to get things like cameras and the like to work. In some cases the released drivers (open source) are pretty much useless as most of the functions are handled by the wrapper. Think of it as soft-drivers (proprietary) vs hard-drivers (opensource).
There is also a lot that goes on behind the scenes. It's not uncommon for devs to share fixes and such with each other. Lets say I find a way to make the mopho print money (I wish this was true). Unless I'm a complete d*ck, I'd send other devs a PM/email and give the code to any devs that want it. The most I may ask for is a mention in the credits.
Click to expand...
Click to collapse
The manufacturers are looking to create a competitive advantage between themselves and their "competition" (re: HTC vs. Motorola) so they proprietarize and hope to win. Where they lack foresight is that those "competitors" are the least of their problems; external forces drive the competitive market and these include Apple, RIM and Nokia. Open sourcing more of their code would leave them with many benefits and a handful of weaknesses, but the benefits would far outweigh the losses. They may not want the community to see their sloppy code or quality untested code. When everyone's watching, the audience able to poke holes in your quality is magnitudes larger than your QA folks. I've had my fair share of holes poked, but that's the joy - live and learn.
OP, the entire Android platform is based off a combination of coders' work, from the home dev up to Linus Torvalds.
I'm thankful for what those who dev on here do, because it can be a grueling and unappreciated process; but when it works >= expectations, hallelujah!
This article appeared today on the main page of XDA and I feel that it's a very important lesson for any/all new ROM devs.
Sage Advice from Cyanogen Still Valid Today
http://www.xda-developers.com/android/sage-advice-from-cyanogen-still-valid-today/
Excerpt:
He had this advice to offer 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….. 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 s**t 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.As XDA has grown right along with the meteoric rise of Android, so has a desire of users to create their own ROMs, kernels, themes, and so on. Much of this work classifies as “original development,” but there’s been a growing trend to what many are calling “derivative development.” This category covers most of ROMs based on stock releases from the manufacturers, applying patches and scripts aimed at optimization, theming and/or removing stock applications, and using “kitchens” that run a stock release through a list of scripts and then repackage as a recovery-flashable update.zip. This is what Cyanogen was expressing frustration about—shortcuts being taken to achieve a product that differs only slightly from stock (derived) and pushed out instead of building from source and delving into the core of Android and making something truly original.
XDA-Developers exists first and foremost for developers. It’s at the core of who we are; it’s in our blood; and it’s in the air we breathe. There is a place for derivative works—they provide an entry to the scene which can help to introduce people to the wonders of Android. But let’s not stop there. Don’t be satisfied with just creating yet another derivative of someone else’s work. Instead, follow Cyanogen’s sage advice and learn about Android from the ground up, and create something truly original and innovative.
Click to expand...
Click to collapse
Guess I should continue with this hello world app... haha
Op just explained 99% of our roms lol
Repackage, rename, reskin and ask for donations. Rinse lather and repeat. Now your a dev!
Ha.
True software developers understand the wisdom of code reuse.
So ,in my opinion, if a fledgling developer takes a set of code and applies addons, makes a few setting changes then calls it a ROM and provides users benefit...then they are on the path.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 2
andrawer said:
Ha.
True software developers understand the wisdom of code reuse.
So ,in my opinion, if a fledgling developer takes a set of code and applies addons, makes a few setting changes then calls it a ROM and provides users benefit...then they are on the path.
Sent from my SAMSUNG-SGH-I717 using Tapatalk 2
Click to expand...
Click to collapse
Even if they fail to write a single line of original code?
I'm with cyanogen on this one...
saddly alll this is sementic
if the world of android was perfect then this would be true .by perfect i mean everything being open source ...
but if everything was open source we woudlnt have things like arc touchwizz blurr or sense , it is my opinion and shared by many others that android would be very boring if we only had aosp .
what does a coder brings to touchwiz sense or blurr device ?
the market is filled with cool apps and launcher .. 99% of them coders will make apps for android and wont bother with anything else
that brings me to my next point . building from source means on top of aosp , or in my terms vanilla android .. many devs love vanilla and its fine but what about those who dont ?
99% of the rom on xda are just that : either source compiled with apps added or stock deodex rom with a theme and apps added ..
here is the but , and before i say it i wanna say everyone is entitled to his opinion and im not bashing anyone ,
without guys like me who just hack the code and spend countless hours looking at what the code is actually doing and port the nice stuff from sense to TW or form CM to TW and RE (reverse engineer all these nice codes) 99% percent of the android devices would be boring because lets face it there is only one aosp device / year..
so from what Cyanogen is saying we should all buy a gnex and stop supporting those that make android close source,
but wait without them , many things woudlnt be in CM in the first place , what is cm without all these kangs? a glorified aosp ?
ok maybe im pushing but you get my drift...
how many true innovations by Cyanogen vs them Proprietary UI ?
fun fact the head (or ex ) of Cyanoen now works at samsung and help make touchwiz better (close source)
what about miui , they have so many innovations , and they dont share any of there code ..
so as I said there is no black or white here
thats what android is all about make your own thing play with it call it yours and make it a hobby , and maybe just maybe others will like it ...
I have seen way to many devs get god like status on xda for deodexing a rom and injecting voodoo in there kernel (for example)
i ve seen crazy talented themers have there work taken by others be ignored by the community and then vanished , and everyday we see a kik ass true developper on here and treat him like hes a nobody , because he doesnt have or because we havent heard of his rom .....
i completely understand where cm is coming form but my opinion differs slightly ..
@op kik ass thread (as I never read the front page)
Hard to build an i717 ROM from scratch with all of the proprietary bits, Samsung framework, etc, as most of that is proprietary as DAGr8 says. AOSP/AOKP works, but lacking some SPen functions and still relying heavily on a binary kernel as there are no kernel sources for ICS yet.
Hopefully the kernel situation changes, and we're back to the normal business of everything except the proprietary blobs that have to get copied from a stock ROM......
It'd be nice if all required code was released, but for some reason such things tend to be considered proprietary. Oh well.
Thanks OP. I also don't read the frontpage near often enough.
I like what Cyanogen is saying, and agree with his points from his developer point of view. I also agree with DAGr8 and his points. The fact is that Android gives us so many choices and has so many options for exploration. I think that's why so many of us have moved to the Android ecosystem. There is enough room for everyone. Android is the most prevalent mobile OS in the world for a reason. We can all have our opinions. We can all have what we want on our devices. And there are more and more people willing and able to jump in and try to build. Call them developers, or hackers, or derivators. It doesn't matter to me. They all add value to Android.
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
garwynn said:
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
Click to expand...
Click to collapse
The stuff in platform isn't what is needed for AOSP - it is (with rare exceptions) only GPL-licensed stuff Samsung is legally obligated to release.
Occasionally little bits and pieces of it are useful (like a single GS2 or GS3 release that included libsecril-client source code), but usually not.
For example, the BT stack in all GS1 platform releases was useless for AOSP, because it was Broadcom's hacked-up version that had dependencies on a proprietary binary (I forget its name - they got around GPL by making it a separate program that communicated using sockets with the rest of the BT stack.)
All of the BT/headphone problems with Snapdragon-based GS4s are, as I understand it, issues with libcsd-client (same library that was troublesome for Note2 and CM until someone ran libcsd-client through Hex-Rays Decompile to see what Samsung mangled...)
It seems like OEMs have a bad habit of hacking up libcsd-client in undocumented ways - LOTS of Qcom devices have had miscellaneous weirdness stemming from libcsd-client lately.
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