Hi all,
I am noob at XDA. (About myself: I am a software engineer aged 30. I have been hacking computers since I was 10.)
I am here because I am planning to buy a new Android device soon. (And unless something really revolutionary happens, I don't plan to upgrade it in the next 2 years or so, so it's a long-term decision.)
My short-list is:
- HTC One S
- Sony Xperia S
or, if everything else fails:
- Samsung Galaxy Nexus
The hardware of the One S and the Xperia S is obviously more powerful than the Galaxy Nexus; my only concern is the software side of things.
The thing is, I really don't like the customization the hardware vendors do with the software, so I want to run raw vanilla AOSP, or something very close to it.
(CM definitely qualifies.)
Also, I am sick of waiting for ages for new android versions to be ported to my device.
Obviously, Galaxy Nexus is guaranteed to be get Android upgrades first, so that's a safe choice in this respect, but since I like the hardware of Xperia S (and One S) so much, I would like to gain a better understanding the software situation of them, so I can make an informed decision about my purchase.
I am aware of the fact that Sony is actively supporting the Free Xperia Team, which is bringing CM9 to Nozomi (among other devices), but I have no information about the details of the project, or it's limitations.
So, my questions are the following:
1. What is the exact nature of the support Sony is providing to the FXP team? (HW? HW docs? Binary drivers? Driver source? Consultation?) Has this changed in any way, now that Sony Ericsson has become Sony? Was this a one-time action, or have they made any commitment about the future?
2. What does one need to build a vanilla android ROM for the S, using the AOSP sources? (Let's forget Cyanogenmod for now.) What is the status of the required device drivers?
3. What are the current obstacles, hindering the release of CM9 (or any other derivative of AOSP) for this device? As far as I know, Nozomi was released in 2012.02, ~4 months ago. ICS was released in 2011.10, ~8 months ago. Official ICS (Sony's version, with Timescape) is rolling out about now; CM9 is not yet released. I wonder what is taking so long?
(Please understand that I really, literally wonder: I am not demanding anything, and I am not trying to offend or accuse anyone; I am totally aware that I don't understand the process; I would like to have more information to understand what needs to be done. And since I am software engineer, and I am not afraid of getting my hand dirty, so eventually, I might end up helping with it...)
4. Do we have any information about Sony's plan for this device beyond ICS? Jelly Bean is coming up soon. Regardless of Sony's decision, when JB is released, I would like to run it on my device, as soon as possible. What are our prospects for porting JB to Nozomi? Is Sony going to help with porting the device drivers to the new kernel, is something like that would come up?
* * *
Thank you for explaining this:
Csillag
1) No one knows for sure, but I'm pretty sure that it's not game changing, judging by the progress me and Doomlord made on AOKP without any help from Sony (obviously).
2) You can try building Gingerbread, but no one cares, right? For ICS, see the next answer.
3) The most important problem is that we don't have the drivers/kernel sources, and there's not much motivation for building it from scratch considering the soon(ish) ICS release. There are leaks with files for so called 'brown' or developer devices, but they also don't give much because of different low-level software. So the state of things is that almost everything but wireless is working, but wireless doesn't work at all. That means data, calls and WiFi.
4) JellyBean will likely be a minor upgrade (4.1 that is) and there's nothing stopping Sony from releasing anything on the 4.x branch. When 5.0 comes, it will depend on the hardware requirements but I'd guess we're getting it too.
K900 said:
1) No one knows for sure,
Click to expand...
Click to collapse
How is that possible?
The FXP guys (bin4ry, jerpelea, etc) are here on these forums...
... did they have to swear secrecy, even about the circumstances?
but I'm pretty sure that it's not game changing, judging by the progress me and Doomlord made on AOKP without any help from Sony (obviously).
2) You can try building Gingerbread, but no one cares, right? For ICS, see the next answer.
3) The most important problem is that we don't have the drivers/kernel sources,
Click to expand...
Click to collapse
You mean we don't have the kernel sources for ICS, right? Because for GB, we do have something, in this thread... I guess I should ask this in the relevant thread, but has anybody determined the exact differences between this source and the stock ( 2.6.35 ? ) kernel this is based on? How many non-standard drivers are there? Do they come from Sony directly, or do they come from 3rd parties? I will need to look into this...
and there's not much motivation for building it from scratch considering the soon(ish) ICS release.
Click to expand...
Click to collapse
And according to past experience, how long does it take Sony to release the kernel for ICS, after the imminent official ICS release?
There are leaks with files for so called 'brown' or developer devices, but they also don't give much because of different low-level software. So the state of things is that almost everything but wireless is working, but wireless doesn't work at all. That means data, calls and WiFi.
4) JellyBean will likely be a minor upgrade (4.1 that is) and there's nothing stopping Sony from releasing anything on the 4.x branch. When 5.0 comes, it will depend on the hardware requirements but I'd guess we're getting it too.
Click to expand...
Click to collapse
OK, that part sound good.
* * *
Thank you for explaining:
Csillag
csillag said:
How is that possible?
The FXP guys (bin4ry, jerpelea, etc) are here on these forums...
... did they have to swear secrecy, even about the circumstances?
Click to expand...
Click to collapse
I haven't seen them tell anyone, and I've never seen them do anything that's not available for everyone else (thankfully).
csillag said:
You mean we don't have the kernel sources for ICS, right? Because for GB, we do have something, in this thread... I guess I should ask this in the relevant thread, but has anybody determined the exact differences between this source and the stock ( 2.6.35 ? ) kernel this is based on? How many non-standard drivers are there? Do they come from Sony directly, or do they come from 3rd parties? I will need to look into this...
Click to expand...
Click to collapse
There are kernel sources for GB, the same ones from which the stock kernel was built. If you mean the upstream Linux kernel, it'll be a huge diff that's not so easy to port without datasheets (which we don't have) and actual understanding of how the hardware works. Speaking of drivers, I'm pretty sure you misunderstand the way Linux / Android 'drivers' work. Kernel-space drivers (modules) and userspace drivers (libraries and daemons) are two different things. They have to open source their kernels because Linus's tree ('official' Linux) is GPL, but the userspace parts are proprietary. ICS also brought many ABI changes, so just taking old libs and placing them in a new ROM often doesn't suffice.
csillag said:
And according to past experience, how long does it take Sony to release the kernel for ICS, after the imminent official ICS release?
Click to expand...
Click to collapse
It takes time, can't say how long really, but it shouldn't take too long because they know we want those sources.
K900 said:
I haven't seen them tell anyone, and I've never seen them do anything that's not available for everyone else (thankfully).
Click to expand...
Click to collapse
Have you seen them being explicitly asked about this?
(Because not saying anything because not being asked is completely different that refusing to reveal this info....)
There are kernel sources for GB, the same ones from which the stock kernel was built. If you mean the upstream Linux kernel,
Click to expand...
Click to collapse
Yes, that was what I have meant when I wrote "stock". Now I see that it was ambiguous wording...
it'll be a huge diff
Click to expand...
Click to collapse
That's sad.
I was hoping for finding only some added drivers, plus some small configuration changes elsewhere.
that's not so easy to port without datasheets
Click to expand...
Click to collapse
obviously
(which we don't have)
Click to expand...
Click to collapse
We don't have it, but the "official" FreeXperia team might, or they might be able to ask for it. This is exactly the kind of information I am trying to find about their collaboration with Sony...
and actual understanding of how the hardware works. Speaking of drivers, I'm pretty sure you misunderstand the way Linux / Android 'drivers' work.
Click to expand...
Click to collapse
No, actually I get that part. (I am exclusively using Linux for about 13 years now, and I have also done some kernel hacks earlier.) But maybe my wording was ambiguous again...
Kernel-space drivers (modules) and userspace drivers (libraries and daemons) are two different things. They have to open source their kernels because Linus's tree ('official' Linux) is GPL,
Click to expand...
Click to collapse
Well, that does not stop some vendors (like NVidia) to ship binary kernel modules, so I would not be too surprised to find even binary kernel modules bundled with the code. But if they are open source, that that's great.
but the userspace parts are proprietary.
Click to expand...
Click to collapse
I did not know the devices require userspace parts. I was assuming that the kernel modules implement standard linux device interfaces; for example cameras are simply accessible via v4l[2], the modem is a character device, etc...
...so you say this is not the situation, and besides the kernel modules, they require custom user-space parts for operation, right?
ICS also brought many ABI changes, so just taking old libs and placing them in a new ROM often doesn't suffice.
Click to expand...
Click to collapse
Yes, that part is clean.
It takes time, can't say how long really, but it shouldn't take too long because they know we want those sources.
Click to expand...
Click to collapse
So, you say that it's a totally possible situation that we need to wait for several further months until we can get access to the kernel sources, and build proper CM9, right?
Unfortunately, this is exactly what I would like to avoid.
Maybe I should just stick to Galaxy Nexus, in spite of the older hardware...
Thank you for explaining:
Csillag
csillag said:
Have you seen them being explicitly asked about this?
(Because not saying anything because not being asked is completely different that refusing to reveal this info....)
Click to expand...
Click to collapse
They tend to ignore such questions. PM me if you want my personal opinion, I'll try to stick to the facts here.
csillag said:
Yes, that was what I have meant when I wrote "stock". Now I see that it was ambiguous wording...
Click to expand...
Click to collapse
Nevermind.
csillag said:
That's sad.
I was hoping for finding only some added drivers, plus some small configuration changes elsewhere.
Click to expand...
Click to collapse
They add some stuff, but they also change stuff internally. Tweaks and patches and many different things to get the best performance on this specific board. CAF has a generic msm-3.0 kernel, but that's not as customized. And we're not really waiting for the kernelspace here.
csillag said:
We don't have it, but the "official" FreeXperia team might, or they might be able to ask for it. This is exactly the kind of information I am trying to find about their collaboration with Sony...
Click to expand...
Click to collapse
Such things are very, very strongly NDA protected. That's Qualcomm's secret sauce, and it wouldn't be secret any more if they gave datasheets to the community.
csillag said:
No, actually I get that part. (I am exclusively using Linux for about 13 years now, and I have also done some kernel hacks earlier.) But maybe my wording was ambiguous again...
Click to expand...
Click to collapse
Nevermind
csillag said:
Well, that does not stop some vendors (like NVidia) to ship binary kernel modules, so I would not be too surprised to find even binary kernel modules bundled with the code. But if they are open source, that that's great.
Click to expand...
Click to collapse
Actually what NVIDIA does is ship a GPL'ed kernel module whose only function is to set up an interface through which the userspace (libGL) can talk to the hardware. So their kernel module is open source, but all the magic happens in the proprietary userspace.
csillag said:
I did not know the devices require userspace parts. I was assuming that the kernel modules implement standard linux device interfaces; for example cameras are simply accessible via v4l[2], the modem is a character device, etc...
...so you say this is not the situation, and besides the kernel modules, they require custom user-space parts for operation, right?
Click to expand...
Click to collapse
Android has a HAL of its own, so mostly it's about HAL modules, libGL and libril (Radio Interface Layer) to talk to the modem. And here is where many hardware vendors pull an NVIDIA.
csillag said:
So, you say that it's a totally possible situation that we need to wait for several further months until we can get access to the kernel sources, and build proper CM9, right?
Click to expand...
Click to collapse
No, the kernel isn't that much of a problem. If we have to wait for too long, we'll just take CodeAurora msm-3.0 and port it which shouldn't be too hard cause it's as generic as possible.
csillag said:
Maybe I should just stick to Galaxy Nexus, in spite of the older hardware...
Click to expand...
Click to collapse
If you want AOSP now, you should go with the GNex. But the XPS is a nice phone, and the prospects with AOSP are good. Also would be nice to have someone more experienced with Linux (I'm just a student here) on the team/forums. If you get the XPS, PM me or Doomlord and I hope you'll help get AOKP running
I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
I have next to no programming/hardware/software modding experience but I believe some devs are working on the RIL (radio interface layer) for this phone before they get a working CM10 on the DNA...
I could be completely wrong but just chiming in lol
You can probably build it and get it booting without too much hassle. But you won't have any connection whatsoever. That's where the ril comes in. But it hasn't been cracked yet, beck, idk if anyone's even working on it atm.
Sent from my HTC6435LVW using xda app-developers app
drewX2 said:
I plan to build Cyanogenmod 10 from source, however I have a few questions.
When compiling the kernel from HTC sources, I get two warnings along the line of "warning: (ARCH_MSM_KRAITMP && ARCH_MSM_CORTEX_A5)." I am assuming these are safe to ignore? Other than, it builds and completes fine.
I've never built from source any roms (and for that matter have only done minor programming some time ago), however I have an extensive experience in programming and want to give it a shot.
Is there any reason why it is not possible to build an unofficial port? Wouldn't having the kernel sources from HTC make the job easier? Anyone try this yet or have experience with porting to new devices?
Click to expand...
Click to collapse
You will probably get a couple errors during the build, nothing to worry about. If you get an error and the build stops then you know you have a problem.
Also, we have the kernel source from HTC. Building custom kernels is a necessary step before we can build CM, but it doesn't really make anything easier. Like Bigandrewgold said, the RIL is the most important missing link at this point.
I wish you the best on this project, and you have a great community here of people who can help you out.
I myself would love to test out CM on this beast, ril or not. It'd be nice to have a build ready that we could just drop a kernel into.
Sent from my HTC6435LVW using Tapatalk 2
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.
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.
I know I have just asked some rather Simple Kernel Questions and honestly as stated as always worked as part of a dev team and was never the Kernel Guy but with that said have always wanted to build an AOSP Rom based on the Code Aurora source. Not caf like CM or anything with all kinds of features and what not but just pure AOSP. Thought I would ask if anyone else would be down.
The Rom would be pure AOSP based on Code Aurora repository’s only. Have always wanted to look into doing this and looking into how to go about it.
Ok, first off, some useful descriptions;
AOSP: The source code provided by Google. This is directly buildable for Nexus 6 just by following the instructions.
CAF: The source code provided by Qualcomm, which typically involves *some* degree of feature addition, but mostly HARDWARE bringup.
The odd thing about the relationship between AOSP and CAF, is that they are both each other's upstream. I think I would classify CAF as being somewhat more of "experimental" code.
CM: a complete and utter MESS. It takes bits from here, bits from there, and throws in a jumble of other bits... none of which really work well together or were intended to be merged in that way.
Basically, CM is not so much a build of CAF as they pull in certain *parts* of CAF. So if you did a build of PURE CAF, it would much more closely resemble a build of AOSP.
Now is CAF buildable for Shamu? Hmm, sortof.... maybe. They do pull in AOSP, but I don't think they actually work with Nexus devices so much as their own internal development devices, and certain specialty "dev" devices like Dragonboard 410c. What that means, is that you will probably want to start off with a *generic* apq8084 manifest from https://www.codeaurora.org/xwiki/bin/QAEP/ under the "release" branch. You will then need to mess around with the blobs and kernel, add a shamu device tree, etc., and what you end up with at the end, will strongly resemble a pure AOSP build, but probably have a few things broken or unstable.
IMO: For something like Shamu, you don't really do a pure CAF build, since google has already selected and stabilized the appropriate parts of CAF for you. But if you see some new or not-included FEATURE in CAF, then you consider pulling that specifically into an otherwise AOSP build.
doitright said:
*lots of text*.
Click to expand...
Click to collapse
It's funny... I've had people argue this with me in the past few weeks...
This is pretty much exactly my understanding of it as well.
The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.
Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.
Yoinx said:
It's funny... I've had people argue this with me in the past few weeks...
This is pretty much exactly my understanding of it as well.
The biggest difference between AOSP/GoogleSource & CAF for me, is that CAF is much more lively... typically. Google puts out source on their Public Repos, but it always reflects their latest release. I'm sure they have internal repos that are more lively... But the public ones are usually stagnant until a new release.
Click to expand...
Click to collapse
Yep, that is pretty much why I used the term "experimental".
Of Course, stock roms (even for us) include a lot of vendor blobs that AOSP don't.
Click to expand...
Click to collapse
You do know that google provides the vendor blob archives, right? That is, the parts required to make the AOSP build fully functional on Nexus hardware. Those vendor blobs don't include any of the googly bits in the userspace layer (i.e., gapps).