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.
Related
As everyone knew that on June,UK will publish SGS2 which contain NFC function, I'm afraid that CM ROM available "ONLY" on NFC version, will it becomes true?Can anyone answer me this "stupid" question?
No one can answer your question because cm7 doesn't exist on the sgs2.
A couple of developer types commented that it should be modular and so very easy to make two versions. As there is already north of a million non nfc phones out there and climbing I doubt that the non nfc phones will become ophans assuming that their intial thought that it would be easy to build two versions proves true. They did allow as to how sometimes things come up that were unforseen. Even so my bet would be considering the number of devices out there support for both versions is likely. All this presumes that there will be a CM mod for the sgs2 which is another question, one reputable developer has said he will begin working on it after exams in early june. Right now there is nothing. There is no source code for the hardware acceleration so the device would not have it until that happens (samsung releases or drops to asop) and considering this is one of the things that makes the phone so smooth it is not a small consideration. My own thought would be that this lack of source code is probably somewhat of an impediment to interest in developing this as the rom would be partially kneecapped from the start.
Thank you very much!!
Now just waiting for the first CM rom on SGS2!!
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!
Hi guys
I'm aware of CyanogenMod, but is it possible to have a completely stock JB ROM with no mods (other than busybox, deodexing, etc..) or custom apps installed? I can't seem to find one
Cheers
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
djmatt604 said:
The community will correct me if I'm wrong, but I believe you'd have to build from source (AOSP) if you wanted something that is super-vanilla and hasn't been touched by a manufacturer outside of CM, AOKP, etc.
That said I also believe this particular question should be posted in the General or Q&A sections, for future reference.
Click to expand...
Click to collapse
Thanks for the reply
I mean Android was made to work on all devices right, but does CM do something like adding "drivers" (or the equivelent)? Is that what developers do when they "port" something like a new ROM that has been released on a similar device?
If multiple devices have a stock Android JB ROM, and they're also using a Tegra 2 CPU (and I'm guessing they all use the same type of RAM) etc.. is it quite easy to port? Do you have any idea how difficult it would be to compile it from source/getting it to run on a device?
I'm into technology, but without some serious research, I wouldn't have a clue where to start unfortunately
P.S. Yeah I realised after, already reported it to be moved
I've never ported between devices, but I've read enough to say confidently that things can be tough if you are porting between devices that are too different. At the very least you should stick between manufacturers...like it would be easier to port from Galaxy S2 Hercules to S2 Skyrocket for example than it would be from S2 to HTC xxx. There are quite a few good guides that explain how to port safely as long as the board configs and other important stuff are the same. If you aren't sure, don't do it.
For compiling from source, do a search on XDA here for shenye's guide "Compile JB on Ubuntu" - it was also featured on XDA TV. It's very helpful. Compiling isn't all that hard, but takes time and patience especially if you are working on a non-flagship device. It will likely take much research to find the right repositories for your device and vendor config, plus time to fix any errors the compiler reports.
Good luck!!
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