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
Related
Here's an idea, maybe something else can contribute or confirm it might works..
the Nook honeycomb image is actually running on top of a 2.6.29-omap kernel, which indicate that only some parts might require 2.6.36.3 functions.
I know that the main problem for me porting it, was the libc.so which uses kernel calls not found in our existing 2.6.32.9 kernel. so it crashed due to some cache functions not implemented.
- could the missing cache functions be implemented into our 2.6.32 kernel?
- can the Nook edition with a working libc.so (hopefully without FPU function compiled) be used to replace our xoom image libc.so which crashes?
So to make an early edition can we merge the ARMv5 libs (i assume it is from the emu) and use this with xoom edition and then keep our libnv* environment which is compatible without our nvrm_daemon (which no one can fix, although a proper kernel work for booting 2.6.36.3)
ideas.. but if its possible to put into "real life" is another story.
and how many can do experiments?
Artem wrote he is on the 2.6.36.3 kernel, but since we might have an option to go around, maybe also worth considering, if display driver lacks nvrm_daemon support.
re
I'm not a developer but I can do some beta tests for you if you want.
julio77 said:
I'm not a developer but I can do some beta tests for you if you want.
Click to expand...
Click to collapse
obviously...same here...;-)
I am able to write basic scripts, xml etc.. and have a brain...
Jp
i tries all this out now.. and got passed some link references between libs but the "libc.so" issue came coming back..
so it did not work..
im closing the idea here :-( not worth spending time on, so only the solution with updating kernel and rewriting drivers must be the way forward.
May be I should wait for ubuntu 11.04 or some other linux OS for folio 100
Toshiba &Google is not so kindness. Are they only want to earn more money, right?
Dexter_nlb said:
i tries all this out now.. and got passed some link references between libs but the "libc.so" issue came coming back..
so it did not work..
im closing the idea here :-( not worth spending time on, so only the solution with updating kernel and rewriting drivers must be the way forward.
Click to expand...
Click to collapse
Yup, I also think that waiting for updated kernel + drivers from the new Toshiba folio 200 is a more feasible approach...
xitrumch said:
Yup, I also think that waiting for updated kernel + drivers from the new Toshiba folio 200 is a more feasible approach...
Click to expand...
Click to collapse
If, and its a big if, the 200 has the same hardware.
ma1999 said:
If, and its a big if, the 200 has the same hardware.
Click to expand...
Click to collapse
correct,
we already know it has different resolution . and probably better display now, and no hardware buttons on the side, so no I2C used for this..
i think its very different, as it probably also got 802.11n wifi now, which we dont have and need different ar6000 driver.
i think its a long road downhill for folio100 if the 200 edition should be anything close as source for porting.
Dexter_nlb said:
correct,
we already know it has different resolution . and probably better display now, and no hardware buttons on the side, so no I2C used for this..
i think its very different, as it probably also got 802.11n wifi now, which we dont have and need different ar6000 driver.
i think its a long road downhill for folio100 if the 200 edition should be anything close as source for porting.
Click to expand...
Click to collapse
Please, I'm no expert in this, so bare with me for asking questions.
Honeycomb uses a different kernel than Froyo ok.
For Froyo we have the source for all (hardware) drivers ?
Can the "android" part of Honeycomb (from for example Xoom) be put on
a kernel with required hardware drivers or are there stuff in the "android"
stuff that is hardware dependant ?
Is it hard to port drivers between kernel versions ?
Just trying to understand the many tasks need to get Honeycomb on Folio.
/Martin
The problem in this case is there is no honeycomb kernel sources out there.
Sent from my GT-I9000 using XDA App
Cpasjuste said:
The problem in this case is there is no honeycomb kernel sources out there.
Click to expand...
Click to collapse
xoom kernel source is available, koush used it to make his clockworkmod work , and it works fine, and its also used for oc'ing.
but its pretty much the tegra2 source we can get from nvidia. but alot of porting to do.
So, What we are still missing is?
ibila said:
So, What we are still missing is?
Click to expand...
Click to collapse
all of it!
Lol, guess all we can do now is wait for some ice-cream or get us a native honeycomb tablet.
Sent from my HTC Desire using XDA App
Hey, Asus just released his kernel honeycomb version:
http://www.asus.com/product.aspx?P_ID=gHh4q7I8dvWJzhdV
Choose Download and then Android.
I have started porting the kernel:
https://github.com/DerArtem/android-tegra-2.6.36-honeycomb-folio-nvidia
great news
i dont know how to compile or port stuff but i can say that i love my folio and i love all the devs that are working hard to port honeycomb on our device! THANK YOU SO MUCH!!!
DerArtem said:
I have started porting the kernel:
https://github.com/DerArtem/android-tegra-2.6.36-honeycomb-folio-nvidia
Click to expand...
Click to collapse
really great news!!!
thank you!!!
Thanks a lot!
Thank you a lot !!!
I hope you do 3G Modem Support to !
Just thought some might be interested in this (so sue me, i had to ask it):
http://nookdeveloper.zendesk.com/en...-updated-1-2-source-code?page=1#post_20056491
We will be publishing the updated source in the coming weeks. Thanks for your patience.
Click to expand...
Click to collapse
It will be interesting to see what their new source brings, and what we can use from it. Here is hoping that it is sooner rather than later...
EDIT: Well, i am happy to say it didn't take long.. have at it here: http://images.barnesandnoble.com/PResources/download/Nook/source-code/nookcolor-source-code.zip
Awesome news! The faster we can get dalingrin the updated kernel source the better!
Does complying with the gpl allow for a reasonable delay? Because once you get into grey areas like that, what's reasonable? 2 weeks? 3 months?
Obviously they have the source already, so I don't understand when companies release it some time afterwards.
Aye. I hate the "weeks" portion.. given that its out, i dont think its unfair to demand it now. As it is though, i think the GPL gives 60 days (??) for them to publish the code though, so it may be a while.
Not sure if I don't understand the complexities or everything all the devs here do, but what are the possibilities of the deeper-blue Honeycomb ROM being updated to use a modified version of the 2.2 Nook Color kernel instead of the current 2.1 Nook Color kernel? I assume this would help in getting some items like Flash video etc working properly in the Honeycomb ROM.
Or is the goal still to wait for whenever the 3.0 honeycomb full source is released? Just thinking out loud. Interested to see what others have to say.
ArmitageID said:
Not sure if I don't understand the complexities or everything all the devs here do, but what are the possibilities of the deeper-blue Honeycomb ROM being updated to use a modified version of the 2.2 Nook Color kernel instead of the current 2.1 Nook Color kernel? I assume this would help in getting some items like Flash video etc working properly in the Honeycomb ROM.
Or is the goal still to wait for whenever the 3.0 honeycomb full source is released? Just thinking out loud. Interested to see what others have to say.
Click to expand...
Click to collapse
There isn't much an updated kernel will do to help the Honeycomb SDK.
I don't see any schedules mentioned in the GPL http://www.gnu.org/licenses/gpl.html.
bigbob23 said:
I don't see any schedules mentioned in the GPL http://www.gnu.org/licenses/gpl.html.
Click to expand...
Click to collapse
They will do whatever they want until someone sues. What if we lost?
bigbob23 said:
I don't see any schedules mentioned in the GPL http://www.gnu.org/licenses/gpl.html.
Click to expand...
Click to collapse
I may have been wrong (and will happily say its not the first time); but i did do some reading and found this: http://gplv3.fsf.org/wiki/index.php/User:ashawley/Making_copyleft_work_with_implied_compliance
Not sure if it is totally relevant though..
Source Code
I got this:
Dear Brandon Bennett,
Thank you for your inquiry.
Barnes and Noble will post the updated source code in the near future.
There is still no specific date yet. The link will be posted under terms
of service on the website.
Please accept our sincere apologies for any inconvenience this may have
caused and we look forward to hearing from you.
Sincerely,
Ella
Customer Service Representative - Digital Support
Barnes & Noble
http://www.bn.com/
Visit our NOOK Support site for the latest updates and downloads at:
http://www.barnesandnoble.com/nook/support/
Click to expand...
Click to collapse
Hopefully the source will help dalingrin, verygreen and fattire cut through the current mysteries with the .32 development kernel for CM7.
Seems like a lot of progress was made without B&N's help (smart developers), but even if only a few optimized drivers can be poached that is better than nothing.
nemith said:
I got this:
Click to expand...
Click to collapse
Thanks for the info. The nook dev board had another update:
Well, if history is a guide, we released source of 1.0 about 2-3 weeks after launch...
Click to expand...
Click to collapse
As i replied, the anxious part of me does not understand any delay really, other than trying to keep the source code away from us "hackers" for as long as possible. The code is obviously in use, so why not release it?
Ah well..
There are probably lawyers hemming and hawing over them releasing it. They probably are trying to ensure that they haven't violated some other patent/copyright in their code which they actually might get sued over.
chadamir said:
There are probably lawyers hemming and hawing over them releasing it. They probably are trying to ensure that they haven't violated some other patent/copyright in their code which they actually might get sued over.
Click to expand...
Click to collapse
Perhaps, but the code is already shipping - its not to say an update can't get pushed out, but just because we can't see the source, doesn't mean current violations are excused.
As it is, the linux kernel is GPL; they can't not release it. So again, i am still frustrated at the hold up...
Probably just the usual corporate speed. They don't like to publish anything before they have to, if only for liability and exposure. Probably the last thing on the rollout list, too.
poofyhairguy said:
Hopefully the source will help dalingrin, verygreen and fattire cut through the current mysteries with the .32 development kernel for CM7.
Seems like a lot of progress was made without B&N's help (smart developers), but even if only a few optimized drivers can be poached that is better than nothing.
Click to expand...
Click to collapse
We are actually very close to having a good .32 kernel already. Some of us have been using .32 full time I think. Verygreen did most of the work on the port. He scrapped my .32 work and started over.
We only need a few updated drivers from them and we'll be good. So I expect a prompt release once we have B&N source.
dalingrin said:
We are actually very close to having a good .32 kernel already. Some of us have been using .32 full time I think. Verygreen did most of the work on the port. He scrapped my .32 work and started over.
We only need a few updated drivers from them and we'll be good. So I expect a prompt release once we have B&N source.
Click to expand...
Click to collapse
Rock on good sir.. That sounds most exciting indeed!
Perhaps a silly question, but to the end user- what will the difference be between the current and .32 kernel? Faster/better/stronger/able to make cappuccinos?
dalingrin said:
We are actually very close to having a good .32 kernel already. Some of us have been using .32 full time I think. Verygreen did most of the work on the port. He scrapped my .32 work and started over.
We only need a few updated drivers from them and we'll be good. So I expect a prompt release once we have B&N source.
Click to expand...
Click to collapse
I was actually using it for a while. Just needed more clock/governor steppings and the weird "broken SD" and battery fixed, as you already know. It is flying though.
Edit: forgot about sound
Nburnes said:
I was actually using it for a while. Just needed more clock/governor steppings and the weird "broken SD" and battery fixed, as you already know. It is flying though.
Edit: forgot about sound
Click to expand...
Click to collapse
The clock/governor issue is because only the performance governor is compiled into the kernel right now. The broken SD warning is mostly fixed and I believe the same for the battery.
Hello All,
As you all know I've been part of Xda and assiting in a positive resolution from HTC in requests from Bootloaders to source codes. Well seeing we have a great device that seemed to be given EOL to early in its game.. in my opinion due to lack of marketing skills. Well I will be posting in HTC FB to get our voice out to them for the Source Code release for our device.
Please comment "Like" and comment to request this so we can continue development for the Flyer.
https://www.facebook.com/photo.php?fbid=10151213297764443&set=o.165420456859572&type=1&ref=nf
And Here:
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Um, source code of what? They release sources of Honeycomb, and there are no sources of ICS or Jelly Bean, so what's the whole point?
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
kayoma said:
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
Click to expand...
Click to collapse
Then we would need not just the drivers, but the whole 3.x kernel. I believe it's much harder to adapt ICS/JB drivers to GB/HC kernels
kayoma said:
Source code for drivers which can be ported to ICS and JB. Anyway it helps coders make their own drivers for Camera/Front camera and for video
Click to expand...
Click to collapse
Then we're asking the wrong ppl, it's not HTC. to understand this first you need to understand what makes up a ROM.
There is the kernel which is low level device specific, the kernel is mostly based on open source linux code, htc adds some board and device specific configuration on top of that.
Then there is the aosp which is also open source, an operating system provided by google that makes up most part of any ROM.
Then you have your aosp derivative like CM or AOKP, which provides board specific fixes and some customization. HTC's ROM is also based on aosp, but they add their own sense look and feel to it.
And finally and most importantly you have your close source proprietary drivers provided by chip manufactures like Qualcomm and TI. They control cameras, wifi, BT...etc. So in reality there is very little HTC could do as they don't have the rights to release these code. And that's is where most ppl run into issues.
So to create a ROM is not hard at all, anybody can download the source code and compile it to generate a ROM as most of the source code are all open source. What will be helpful is if Qualcomm releases the source code for their drivers, which I doubt they will ever do, otherwise they wouldn't be close source in the first place. The only thing we could do is try to reverse engineer the device base on logs and understanding of how each component should work and make educated guesses.
Due to HTC lack of effort on this device (No ICS - HC was slow joke) I will never buy another HTC product again, same goes for sony, though they did eventually update xperia x10i it was only due to huge pressure not because they wanted to.
I want to buy an electronic product that potentially remains relevant at least a year later otherwise forget it.
so i sent this letter to HTC
after reading this page where HTC discusses 4.1 upgrades i decided to drop them a line "
DIRECTLY FROM YOUR WEBSITE:
When will additional devices receive Android 4.1?
In addition to the HTC One X and HTC One S, we are actively reviewing our product portfolio to identify candidates to receive Jelly Bean. Our goal is to prioritize review for devices launched in 2012 with our numerous carrier partners across multiple regions and then consider our ability to provide updates to products from 2011.
What devices will not get Android 4.1?
We work hard to ensure each of our products has the optimal user experience and therefore some products will remain at their current version of Android. In general, devices with 512MB RAM or less will not be upgraded to Android 4.1. At present, these devices include the HTC One V and the HTC Desire C. As we identify other devices that will not be upgraded, we'll provide updated information.
What about a development version of Android 4.1?
For our developer community, we plan to make generic development ROMs of Jelly Bean available for both the HTC One X and HTC One S. As soon as the ROMs are ready, they will be posted to our HTCdev site (www.htcdev.com). We strongly recommend customers take the time to understand the limitations of the development software along with the terms and conditions on the site before downloading to their device.
REALLY!? have you listened to what your customers have asked/said about the HTC flyer at all?! where is OUR 4.1 DEVELOPMENT ROM! wtf! where are you for us!? I can tell you where... you are giving us 3.2 HC that takes away two very important features i bought the device for #1 GPS! completely broken by your newest update to HC. #2. Hardware Keys.... WHY?! i understand that HC introduced soft keys. so you say you "We work hard to ensure each of our products has the optimal user experience" BULL! you clearly weren't thinking about the end user when you pushed out that HC update for the flyer. Would have been smarter for you to leave us on working GB and go straight to ICS or JB when it was ready! this is lunacy! who ever is making decisions in your company needs fired. you are bleeding money from everywhere. why don't you bring it back to the old school HTC that CARED! ABOUT! IT'S CUSTOMERS! listen to what we are saying! hear our voice! we have signed petitions. we have pleaded on multiple forums. WE have poured over your FB and twitter pages asking for you to throw us a freaking bone here.... when is it gonna happen? ever?!
I still have my flyer and i love it dearly. but without updates it's falling behind the pack. I recently bought a 10.1 galaxy note. while i'm happy with it's speed and what not. it's not the form factor i want. which is what the flyer is for me. perfect. PLEASE DON'T GIVE UP ON US OR THIS DEVICE! PLEASE RELEASE A DEVELOPER ROM FOR OUR FLYER! "
this was their reply (you will want to read it for sure)
Dear Matt,
Thanks for contacting HTC!
We completely understand your concern and I thank you for your patience and am deeply sorry if this issue has caused you any dissatisfaction with HTC or its phones. I hope that it will not detract from your overall perspective of the device or the company. You are the most important part of the HTC Family.
We listen to our community and feedbacks like yours are the ones that make us revise our decisions, and try to find the correct balance between the device’s performance and usability. We cannot announce or say anything about the Flyer right now but what I can tell you is that we are, indeed, paying attention to the community´s feedback and opinions.
Should you require further assistance, please do not hesitate to contact us through http://www.htc.com/us/support/email-support or call us at +1-866-449-8358 from 6AM to 1AM EST, 7 days a week.
Have a great day!
Let me know if I have successfully answered your question, please click here to complete this.
To send a reply to this message, please click here.
Sincerely,
Carlos
HTC
I appreciate the passion here, but HTC left this device for dead along with the Jetstream and View shortly after releasing it. We received what would amounted to a Beta of Honeycomb then they closed up shop. You live and learn, and although I still use my Flyer and enjoy it I will not buy another HTC device
I completely agree with you .. HTC should give us ICS or JB for our Flyer as a good faith. We must keep GB because honeycomb is a joke..
I use my Flyer and i try as much as possible with the optimized news on GB .. and share with you.
Hoping for a good action on their part for JB!!
Fatal1ty_18_RUS said:
Then we would need not just the drivers, but the whole 3.x kernel. I believe it's much harder to adapt ICS/JB drivers to GB/HC kernels
Click to expand...
Click to collapse
so the kernel source for HC 3.2 that's in HTCDev,,that is NOT the entire kernel sourcecode?
i know it's an old thread but i am wondering...
gersto said:
so the kernel source for HC 3.2 that's in HTCDev,,that is NOT the entire kernel sourcecode?
i know it's an old thread but i am wondering...
Click to expand...
Click to collapse
that the honeycomb kernel .
doesn't do you much good for ICS or JB
yncconsulting said:
Then we're asking the wrong ppl, it's not HTC. to understand this first you need to understand what makes up a ROM.
.
.
.
Click to expand...
Click to collapse
You didn't understand I think. The drivers are part of the kernel. May they be compiled into the kernel itself or in form of modules. Drivers can be binary objects to be linked (already compiled) or source code which will be compiled when the kernel is built.
If you have the drivers source code there is a fairly good chance to get them running in newer kernels with some minor changes.
So from my point of view you will have a good chance to even get 4.2 up and running as long as you have the drivers source code.
Sent from my GT-I9100G using xda app-developers app
ktp1976 said:
You didn't understand I think. The drivers are part of the kernel. May they be compiled into the kernel itself or in form of modules. Drivers can be binary objects to be linked (already compiled) or source code which will be compiled when the kernel is built.
If you have the drivers source code there is a fairly good chance to get them running in newer kernels with some minor changes.
So from my point of view you will have a good chance to even get 4.2 up and running as long as you have the drivers source code.
Sent from my GT-I9100G using xda app-developers app
Click to expand...
Click to collapse
yeah, so my point is HTC publishes kernel source code, not drivers, they don't even own some of the drivers .,so you will never get that. You get a HC kernel ,that works with a HC blob set and you cannot build a working 4.xx kernel because you don;t have a 4.xxx blob set and HTC won't give you one because they have never written one and never will
DigitalMD said:
that the honeycomb kernel .
doesn't do you much good for ICS or JB
Click to expand...
Click to collapse
well they must be of some good since we have ICS/JB ROMs out there that are "mostly" complete, slick and usable, although slightly buggy, so obviously yeah i get that it doesn't solve all the issues we have, since some drivers are missing: as evident by the non-working FC, no hardware decoding for video, and semi-working BT
DigitalMD said:
yeah, so my point is HTC publishes kernel source code, not drivers, they don't even own some of the drivers .,so you will never get that. You get a HC kernel ,that works with a HC blob set and you cannot build a working 4.xx kernel because you don;t have a 4.xxx blob set and HTC won't give you one because they have never written one and never will
Click to expand...
Click to collapse
Not exactly. The kernel is also part of AOSP. And even if HTC does not supply the driver sources there is a slight chance to use old driver binaries or to have them reverse engineered by some genius dev. Hope is the last to die
Sent from my GT-I9100G using xda app-developers app
ktp1976 said:
Not exactly. The kernel is also part of AOSP. And even if HTC does not supply the driver sources there is a slight chance to use old driver binaries or to have them reverse engineered by some genius dev. Hope is the last to die
Sent from my GT-I9100G using xda app-developers app
Click to expand...
Click to collapse
Keep dreaming. Some of the best around have tried that path.
No the device kernel is not in AOSP, the base linux (ANdorid) kernel source resides there, but if you look at the build, it calls in device , vendor, OS verson and board specific components to make a complete build. All that hooks into the blobs (drivers and libs) to make up the device specific environment that allows Android version X.XX to run
DigitalMD said:
Keep dreaming. Some of the best around have tried that path.
No the device kernel is not in AOSP, the base linux (ANdorid) kernel source resides there, but if you look at the build, it calls in device , vendor, OS verson and board specific components to make a complete build. All that hooks into the blobs (drivers and libs) to make up the device specific environment that allows Android version X.XX to run
Click to expand...
Click to collapse
Thanks for clarification. So I was not wrong about the drivers, which are the device and vendor specific components. In other words if you can get the vendor to release their sources or make their chip/board manufacturers to release their sources is the only way to go. Seems a bit unrealistic though but who knows...
Sent from my GT-I9100G using xda app-developers app
All should email the HTCDev
Use this link http://www.htcdev.com/contact
They themselves posted on that link
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Takes just f**kin 5 seconds
May be they will listen some day
freworld said:
All should email the HTCDev
Use this link http://www.htcdev.com/contact
They themselves posted on that link
https://www.facebook.com/photo.php?fbid=10151213304969443&set=o.101063233083&type=1&relevant_count=1
Takes just f**kin 5 seconds
May be they will listen some day
Click to expand...
Click to collapse
+1
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
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
furchtlos76 said:
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
Click to expand...
Click to collapse
Development for this device is far from dead, we have a stable device tree for building custom ROM's, CM and RR ROM's already released, a fully source built TWRP and work on custom kernels is just beginning. That's a lot more development already than an awful lot of devices see in their entire lifetime.
I would rather say it has just begun. Development for this MTK chip is not a matter of course and the outcome so far is pretty exciting. This opens the way for other devs who work on other devices with the same chipset. It's just that many devs simply prefer Snapdragon which leads to higher dev count on those devices, faster bug fixing etc. I am pretty excited what the future brings not only for our P9000 but MTK devices in general as far as flashing and development goes.
Development is dead? What gave you that impression? For starter this phone already has a working twrp recovery. That is more then some Chinese phones get in their whole lifetime. Kernels is the area of development next and elephone has been kind to release the source code for the phone. Again more then most developers even bother with.
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
It is also getting nougat in November hopefully
mangoman said:
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
Click to expand...
Click to collapse
That's because Nexus 4 is an officially supported device by CM.
It's very difficult for MTK devices in general to get official CM support because we have to patch some things in the framework to make camera, RIL (mobile data) etc working.
The official stance is that these things should be done in device tree as no proprietary code is allowed in CM framework.
Initially when our patches were submitted to CM Gerrit they were rejected because of this, Leskal is working on minimising the patch work needed and getting more of the generic MTK code accepted on Gerrit.
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Android-UK said:
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Click to expand...
Click to collapse
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest it, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Jonny said:
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest ot, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Click to expand...
Click to collapse
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Android-UK said:
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Click to expand...
Click to collapse
Why do they need to? There's already great tools around for that, I know Qualcomm certainly used to provide a package for debugging the lower system levels but it wasn't widely available as the lower levels of the device booting process are not needed to be modified outside of OEM labs and manufacturing.
The lowest level we need is kernel debugging and the kernel already provides that via last_kmsg and desmsg etc, all other tools are already available as part of ADB, logcat etc. There are also a plethora of other tools readily available.
I would call it pretty dead now Well, if not dead then dying.
Let's hope for a Christmas special