Related
http://www.androidcentral.com/google-not-open-sourcing-honeycomb-says-bloomberg
I actually choked up when I saw this....
starplaya93 said:
http://www.androidcentral.com/google-not-open-sourcing-honeycomb-says-bloomberg
I actually choked up when I saw this....
Click to expand...
Click to collapse
While I understand the reasons why they won't release Honeycomb code, Open means OPEN. My feelings are conflicted on this one.
They're delaying the release of the code and this has been taken way out of context.
Sent from my spaceship!
I may be exagerating my dissapointment, but this is just so taboo for google.... In all reality a closed source android is a second class ios... And when wp7 gains more momentum android wouldnt even be a consideration for me if they continued to not release source codes....
Then again, this probably is being taken out of context... Only time will tell I suppose
Sent from my PC36100 using XDA App
If they named it TabOS 1.0 instead of Android 3.0 people wouldnt have this bizarre obsession with putting it on their phones. I for one don't want a tablet OS on my phone, it a phone OS on my tablet. Apple does it but it's dumb IMHO.
Frankly I wish tablets would go away anyways.
Sent from my PC36100 using XDA App
what??? 2nd class os????
and if it is "closed".. going to wp7 will be different? how so???
this just does not make any sense
This as well as the engadget article bring up the point of google not wanting the reverse of what happened with froyo and manufacturers putting it on devices it's not meant for. Google cites they want to give the best experience to the customers; which means the 99% of users who don't come to xda. Unfortunately the lack of source code also effects us who want to put hc on our phones, optimized or not -especially since the devs here would optimize it. But a flood of smaller oem phones/small tablets that aren't designed for hc would just be crap.
Dan330 said:
what??? 2nd class os????
and if it is "closed".. going to wp7 will be different? how so???
this just does not make any sense
Click to expand...
Click to collapse
WP7 & iOS = integrated experiences. They are optimized for specific hardware releases and have controlled updates. Which is why a lot of people are drawn to the Nexus phones.
wp7 and ios are closed...
he is leaving because it is closed (if it is closed) .. to another closed os.. which has yet to prove itself as a contender to de-throne android.
android is the top os.. and he thinks it is 2nd class.
but whatever.. see ya...
WP7 is the most boring and silly looking mobile OS on the market right now imo. And I agree with whoever said they should rename honeycomb, because its really not necessary on phones. Gingerbread is fine.
Award Tour said:
WP7 & iOS = integrated experiences. They are optimized for specific hardware releases and have controlled updates. Which is why a lot of people are drawn to the Nexus phones.
Click to expand...
Click to collapse
Not to mention they each have there niche. WP7 with its integration with xbox live PLUS they have openly admitted that they are trying to workout a mutual relationship with "hackers" aka "us"....
There really isn't a need to explain what advantages ios has. I'm android all the way but i'm not arrogant enough to believe that ios isn't one hell of an os and that the iphone isn't a great piece of hardware....
matt2053 said:
If they named it TabOS 1.0 instead of Android 3.0 people wouldnt have this bizarre obsession with putting it on their phones. I for one don't want a tablet OS on my phone, it a phone OS on my tablet. Apple does it but it's dumb IMHO.
Frankly I wish tablets would go away anyways.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
my concern isn't that we won't be able to put honeycomb on our phones, didn't realize I even implied that... I'm just worried about this reoccurring in the future and possibly affecting future phone updates... I don't want a tablet os on my phone neither, but I also don't want a closed source phone (if I did i'd go to the iphone in a heart beat.)
starplaya93 said:
my concern isn't that we won't be able to put honeycomb on our phones, didn't realize I even implied that... I'm just worried about this reoccurring in the future and possibly affecting future phone updates... I don't want a tablet os on my phone neither, but I also don't want a closed source phone (if I did i'd go to the iphone in a heart beat.)
Click to expand...
Click to collapse
You didn't imply it. It's in the article. Google cited it as one of the reasons for the delay.
Sent from my PC36100 using XDA App
Dan330 said:
wp7 and ios are closed...
he is leaving because it is closed (if it is closed) .. to another closed os.. which has yet to prove itself as a contender to de-throne android.
android is the top os.. and he thinks it is 2nd class.
but whatever.. see ya...
Click to expand...
Click to collapse
lol. Where is the justification for anything you're saying? Did you actually read my post or just skim through the title?
The part about not being able to port Honeycomb to phones doesn't really bother me as it's not designed for phones and may not run properly.
However, the real slight in this is Honeycomb tablet owners. If I owned a Xoom, a supposed open Google experience device, I would be enraged at not being able to utilize custom roms by other developers.
This essentially makes the fact that Motorola and Google opted to not include a bootloader in the Xoom worthless.
Similarly, with any Honeycomb tablets, including the upcoming LG and Samsung varieties, you'll essentially be running closed-off systems with no chance of custom roms.
I wasn't planning on buying a Honeycomb tablet anytime soon, but this pretty much seals the deal.
DirtyShroomz said:
They're delaying the release of the code and this has been taken way out of context.
Sent from my spaceship!
Click to expand...
Click to collapse
+1000000000
Sent from my Evo powered by moar gees.
Dan330 said:
what??? 2nd class os????
and if it is "closed".. going to wp7 will be different? how so???
this just does not make any sense
Click to expand...
Click to collapse
The implication is that, if the open aspect is taken out of android, and all we have left to compare the three (wp7, ios, and android), for some, android would no longer make the cut. And, in some ways, I tend to agree: most of what I love about my phone depends on having root access and source code.
matt2053 said:
You didn't imply it. It's in the article. Google cited it as one of the reasons for the delay.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
yes, i'm aware of that...
I just think everybody is missing the point of Androidcentral and Engadget posting this article, as well as the purpose of this thread...
Here is my concern in bold for you guys who don't understand...
WHAT DOES THIS FORESHADOW FOR GOOGLE AND ANDROID AS AN OS? WE NEVER IN OUR WILDEST DREAMS THOUGHT THEY WOULD LOCK THE SOURCE CODE FOR ANYTHING WITH ANDROID OS. WHAT ELSE ARE THEY CAPABLE/WILLING TO DO?
That is my concern folks.... If you're viewing this thread or any android development forum then more than likely its because android is an open source project.
I'm sure this will still go over the trolls heads, but so be it.
3.0 is not closed!!! Google just doesn't want outside developers playing with their source code that they haven't had time to optimize for smart phones.
Basically Google is baking ice cream 2.4 and wants us to get that first. Why would they release 3.0 which is "supposedly " just for tablets when they have put time and money into 2.4 specifically for smartphones. They have phones planned to run on stock off of that. If Google releases 3.0 why would people want to buy "downgraded " software on a flagship phone. Its all just business.
AOSP
Android open source project
Will never ever be closed this is how android became what it is now and how it will dominate the future.
Powered by Steve Jobs' Tears and Jealousy
aray92 said:
3.0 is not closed!!! Google just doesn't want outside developers playing with their source code that they haven't had time to optimize for smart phones.
Basically Google is baking ice cream 2.4 and wants us to get that first. Why would they release 3.0 which is "supposedly " just for tablets when they have put time and money into 2.4 specifically for smartphones. They have phones planned to run on stock off of that. If Google releases 3.0 why would people want to buy "downgraded " software on a flagship phone. Its all just business.
AOSP
Android open source project
Will never ever be closed this is how android became what it is now and how it will dominate the future.
Powered by Steve Jobs' Tears and Jealousy
Click to expand...
Click to collapse
I hope what you are saying is correct... at least for our sake
There have been some indications the Galaxy Nexus would include an FM radio. Is there any conclusive evidence of FM ?
If Google ships the Nexus with an FM app, that would be a departure from previous practice.
The Nexus One shipped with the HTC Desire FM hardware intact, but no app.
The Nexus S did not have the Silicon Labs Si4709 FM chip that the Galaxy S did, and the Broadcom BCM4329 BT/WiFi/FM combination chip was not wired to allow FM.
This Galaxy Nexus apparently has a Broadcom BCM4330 BT/WiFi/FM combination chip like the Galaxy S2 has. But the S2 uses a dedicated Silicon Labs FM chip like the original "S1".
I doubt the BCM4330 will be wired for FM, so I'd guess there must be a Silicon Labs FM chip if the Galaxy Nexus supports FM.
I doubt Google would have created their own FM app, but who knows ? Would it be incorporated into the music app ? Would they use Samsung's FM app, perhaps modified ? Or have they decided their new music store sales will be improved if they neglect FM ?
And if there is an FM app in Google's Galaxy Nexus, can we presume that the source code will be open ?
Kess78 pointed me to Supercurio's doc here: https://docs.google.com/document/d/1a6808W2GwBkBX8x1YwaW3tYm3JSzkp87uQBNWY3TFmE/edit?hl=en_US&pli=1 .
He says : "FM Radio app is not present."
The only other FM reference there is for the Audio Codec:
Linux ALSA driver source code and its register definitions, describing basic audio hardware features available.
Main input/output type supported:
* Headphone
* Speaker
* Microphone
* Bluetooth
* Voice
* FM - digital
* SPDIF over HDMI
...
Click to expand...
Click to collapse
But IMO that doesn't prove anything. First, I don't think he has the exact source code for the kernel on the phone. I've heard the source code is expected to be released in about a month. But maybe I'm wrong, for the kernel code at least.
Second, there are "phantom" FM definitions for a number of Samsung Galaxy devices that don't have the FM chip: The Galaxy Tab, I think the Nexus S and the Galaxy S2 devices with no FM chip, such as AT&T and T-Mobile variants.
So my thinking now is that Google won't be releasing an FM app. Whether or not there's a Silicon Labs FM chip remains to be seen, but I suspect Google went cheap as with the Nexus S and there is no usable FM chip. But I'm just guessing for now.
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
MAYBE.
But the Galaxy S and Nexus S are almost the same phone. Yet the Galaxy S has the Silicon Labs FM chip, while the Nexus S does not.
The same is true for some variants of the Galaxy S2. The "canonical" Samsung Galaxy S2 has the Silicon Labs FM chip, while the AT&T and T-Mobile variants appear to have omitted it.
IMO, at least 2 reasons: (1) The phone is a bit cheaper if they don't install the FM chip, and (2) Carriers want us to use their expensive data plans for streaming.
I think Google also has some interest in keeping cheap, "old fashioned" airwave radio from us. Same for Apple.
blunden said:
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
Click to expand...
Click to collapse
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
so this does have an fm radio ! i seen where some say it doesn't and then I seen some that say it does, The unlocked version of the SGS2 has one but the AT&T didn't so this seems too
Technical Details:
Network
2G Network GSM 850 / 900 / 1800 / 1900
3G Network HSDPA 850 / 900 / 1700 / 1900 / 2100
Camera - 5MP
Touch Screen - Yes
Weight - 135g
External Memory - No
Memory Slot - No
Bluetooth - Yes
Vibration - Yes
3G - Yes
GPS - Yes
Connectivity
GPRS Yes
EDGE Yes
3G HSDPA, 21 Mbps; HSUPA, 5.76 Mbps; LTE
WLAN Wi-Fi 802.11 a/b/g/n, dual-band, DLNA, Wi-Fi hotspot
Bluetooth Yes, v3.0 with A2DP
USB Yes, v2.0 microUSB
Additional Features
OS Android OS, v4.0 (Ice Cream Sandwich)
CPU Dual-core 1.2GHz Cortex-A9 CPU, TI OMAP 4460 chipset
Messaging SMS(threaded view), MMS, Email, Push Mail, IM, RSS
Browser HTML
Radio Stereo FM radio with RDS
Games Yes
GPS Yes, with A-GPS support
Java Yes, via Java MIDP emulator
- NFC support
- Barometer sensor
- Digital compass
- Active noise cancellation with dedicated mic
- MP4/H.264/H.263 player
- MP3/WAV/eAAC+/AC3 player
- Organizer
- Image/video editor
- Document viewer
- Google Search, Maps, Gmail,
YouTube, Calendar, Google Talk, Picasa integration
- Adobe Flash support
- Voice memo/dial/commands
- Predictive text input
The specs you have listed are from GSMArena and "may" be wrong. The two people afaik who have the GN have said that there is no native FM radio app. At present we dont even know if the FM chip is even correctly wired inside to receive signals. If it is, then CM7 (or 8) will be able to support it.
mikereidis said:
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
Click to expand...
Click to collapse
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers. Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
I have not seen a phone that supports FM transmit, no. That would just be a bonus though. Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries. Also, I know for a fact that receiving works fine in many phones in CM so at least that functionality should be possible.
blunden said:
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers.
Click to expand...
Click to collapse
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
blunden said:
Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
Click to expand...
Click to collapse
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
blunden said:
Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries.
Click to expand...
Click to collapse
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
mikereidis said:
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
Click to expand...
Click to collapse
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself. It used to be available on the following links.
https://review.source.android.com//#change,20506
https://review.source.android.com//#change,20507
https://review.source.android.com//#change,20508
https://review.source.android.com//#change,20509
I do have a limited part of the history from 20507 on gmail but I unsubscribed after a while because it was spamming my inbox. Here is a PDF of the parts I have. Some of it is missing though.
mikereidis said:
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
Click to expand...
Click to collapse
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API. You are right though in that it was written entirely by ST-Ericsson. Also, it's not made by SE (meaning Sony Ericsson) but by ST-Ericsson, a partnership between ST-Microelectronics and Erocsson. No Sony involded.
mikereidis said:
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
Click to expand...
Click to collapse
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group. It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
mikereidis said:
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
Click to expand...
Click to collapse
You might be right about it not being wired up for transmission of FM. Receiving works on most phones with compatible chips though as shown by it actually working in CM and MIUI.
mikereidis said:
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
Click to expand...
Click to collapse
Now you at least know what I base my opinions on. Too bad Gerrit isn't up.
blunden said:
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself.
Click to expand...
Click to collapse
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
I've been working 60+ hour weeks on my Android FM app since February, and am trying to earn a meagre income from this project to keep it going indefinitely.
The reverse engineering I continue to do is VERY time consuming, generally has problems, and my app only runs on a fraction of the Android devices out there. So I am EXTREMELY interested in this API, if it has success.
I vaguely recall checking up on this API around August, probably via Gerritt. I had the impression it wasn't going anywhere very fast.
blunden said:
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API.
Click to expand...
Click to collapse
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
See my next post for more...
I had an interesting email from someone working for an org with interest in enabling OTA radio on more smartphones.
I posted the Q's and A's on my app thread for anyone interested: http://forum.xda-developers.com/showpost.php?p=19242542&postcount=1601
I think he and I agree that the biggest obstacles include the lack of usable, open APIs, the secrecy of the chip documents, and the manufacturers that specifically disable FM on many devices.
blunden said:
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group
It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
Click to expand...
Click to collapse
Yes, as soon as I read the Broadcom chip header file for the MIUI/CM FM app, I was convinced the MIUI folk had some inside info. You don't get register defines like BC_REG_SPARE0 by reverse engineering alone.
My app runs on Broadcom and TI chips using what I've learned through hard rev eng work and what I've found on the net, including that header file. I support Samsung Silicon Labs and V4L too, but those "specs" are more open.
My app also supports RDS. AFAIK, neither the CM FM app, nor the MIUI app support RDS, so I think mine is the only 3rd party Android app that does on these chips. FMTwoo works w/ RDS on Galaxy S/Silicon Labs (as does mine).
And I think my app is the only one that communicates directly through the HCI UART. I had to do that because so many devices use Broadcom proprietary Bluetooth which doesn't support normal HCI access, AFAICT.
BTW, AFAIC, the MIUI and CM FM apps are now distinct. Some call the CM app MIUI, and About still says so. The MIUI FM app for Droid X is using Motorola and TI specific libraries. OTOH, the CM TI support is based on work that I did, via hcitool and (for my app direct access to HCI).
Last I looked the ST Ericsson API was VERY rich (IMO) with a lot of potential features, including handling Audio routing, which is a big problem I deal with regularly.
And yet the only multi-chip opensource Android FM code is the CM code, which is still pretty basic. Until not that long ago it only sent commands blindly, and couldn't get values such as the end frequency from a seek command.
So I feel that unless some individual or company "champions" it, I don't see much prospect for a community API implementation that goes beyond basics anytime soon. And it's not just the FM chips, it's the audio routing system for the phone, and sometimes other things, like antenna switches.
I don't think anybody is going to retrofit current phones with this API, except perhaps on specific aftermarket ROMs like MIUI and CM. There MAY be manufacturer support for this API on future phones.
I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
mikereidis said:
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
[...]
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
Click to expand...
Click to collapse
I understand. There are a lot of uninformed posts on XDA so it can serve to be sceptical sometimes.
Gerrit seems to be relatively poorly indexed on Google, if it's indexed at all. Yes, it's still down unfortunately. It makes me kind of sad since that was the only place I've found that you see and participate in open discussions between Google and the submitter. They usually respond if you make an informed comment or ask a relevant question. Unfortunately it's very hard to get in touch with developers to discuss improvements or report mistakes made in the non-open souce apps.
mikereidis said:
[...] I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
Click to expand...
Click to collapse
I contacted both people I've spoken to at ST-Ericsson about this to ask if there has been any progress as well as if I should refer you to them. I described your interest in this and how you can potentially help out. Unfortunately one of the addresses returned a "no such user" error but one of them seems to work fine still.
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
blunden said:
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
Click to expand...
Click to collapse
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
mikereidis said:
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
Click to expand...
Click to collapse
ST-Ericsson have chips with FM, as well as complete SoCs. I think Andreas might have either changed address or company but I spoke with a guy named Ulf as well and his address worked.
Gerrit is actually the name of the review system that is written by Google and released open source. CM started using it to improve the quality of the code in the project. Usually when people refer to Gerrit it should be fairly obvious which one they are talking about based on context. I was talking about AOSP Gerrit though.
I think the plan was to get other chip manufacturers interested in writing the plugins for it as that would allow them to market yet another feature of the chip to Android phone manufacturers. The chance of a phone manufacturer including functionality that requires them to write a whole new Android hardware API is highly unlikely, unless it's something like 3D screens that is very compelling for the marketing department. For that reason it's important to get the APIs implemented.
I did not mean that you should have to do an official implementation but rather that you might help them make it easier developers to test it. As you said, the manufacturers should not expect the users to implement these plugins. I just let them know you were interested about this and might have some valuable input.
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
blunden said:
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
Click to expand...
Click to collapse
Thanks ! Yes, please let me/us know of any developments.
My first impression is that moving a project to a different country is not a good sign.
My second impression is that "not a good sign" is an understatement.
IMO, Life goes on with proprietary APIs and minor roles for ALSA and V4L.
Hi, any news about GN fm radio possibility?
bye
Multi touch bug ftl and slow multitasking.
Was really hoping Google would solve these problems earler
Sent from my Galaxy Nexus using XDA App
hurricurry said:
Multi touch bug ftl and slow multitasking.
Was really hoping Google would solve these problems earler
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
Multi touch bug is a complete killer. Really can't wait for 4.0.4 AOSP hopefully soon
The news is that not everyone is on 4.0.2 yet. If you can't wait then grab a custom rom, otherwise a whole lot of patience may be necessary.
virtualcertainty said:
The news is that not everyone is on 4.0.2 yet. If you can't wait then grab a custom rom, otherwise a whole lot of patience may be necessary.
Click to expand...
Click to collapse
Totally true.
Google is not really considering Galaxy Nexus a Nexus device it seems. Some other systems have gotten newer version of Android already.
At least my Galaxy Nexus runs bloatware-free official Android, even if the build is totally outdated by now. The only real benefit of having a Galaxy Nexus it seems.
Well, I actually don't think it is all that bad. The oldest ISC version out there is still only around 3 months old and better than 99% of Android's entire installation base.
The fact that a few manufacturers jumped on AOSP so soon is great and I'm happy for those users. I don't see the need to be 'first' and it doesn't sour my experience any. Google obviously thought the GN would re-fork with 4.0.3 by now but sometimes bugs get in the way of developer's best intentions.
virtualcertainty said:
Well, I actually don't think it is all that bad. The oldest ISC version out there is still only around 3 months old and better than 99% of Android's entire installation base.
The fact that a few manufacturers jumped on AOSP so soon is great and I'm happy for those users. I don't see the need to be 'first' and it doesn't sour my experience any. Google obviously thought the GN would re-fork with 4.0.3 by now but sometimes bugs get in the way of developer's best intentions.
Click to expand...
Click to collapse
Well yeah, but the things that annoy me are the bugs that are present in 4.0.2 and have been fixed in 4.0.4. And not only that, but also the API features of 4.0.3+ that was supposed to be the 'base' version of Android 4.0.
I don't mind how long major releases would take, but this is a small incremental update. I am just surprised that it takes so long to serve it to 'Google phone'.
kristovaher said:
Totally true.
Google is not really considering Galaxy Nexus a Nexus device it seems. Some other systems have gotten newer version of Android already.
At least my Galaxy Nexus runs bloatware-free official Android, even if the build is totally outdated by now. The only real benefit of having a Galaxy Nexus it seems.
Click to expand...
Click to collapse
Newer versions such as what? The latest aosp is 4.0.3 and not 4.0.4. It's quite obvious that 4.0.4 is not ready.
The Galaxy nexus is a Google supported device and is a nexus.
Sent from my Galaxy Nexus using xda premium
Well, if you look from it from the other side. Google might actually spare us from the still-bugged 4.0.3 version wich is AOSP. Also, JBQ already confirmed that the 4.0.4 version contained a "nasty bug" and wasn't ready for release.
If you look at it that way, new devices with 4.0.3 is still bugged in a way. And Google wants to keep those versions away from their current Nexus.
Just my way of being patient
Oddly enough, some of the tablets shown at MWC (on 4.0.3) had multi touch issues. This brings in a whole new strand of questions...
Sent from my Galaxy Nexus using xda premium
In regards to the latest os .... can anyone tell me what phone has ics update already???? And I've said phone ohh and it has to be released now announced
Sent from my Galaxy Nexus using xda premium
hurricurry said:
Multi touch bug ftl and slow multitasking.
Was really hoping Google would solve these problems earler
Sent from my Galaxy Nexus using XDA App
Click to expand...
Click to collapse
I was really hoping people would stop *****ing about OTAs.
Sorry, but you all sound like a bunch of whiney kids. You'll never be satisfied because the OTAs will never be quick enough to satisfy people. Google is not going to give you nightly builds of ICS. So just calm down and wait for it to be finished and pushed out.
martonikaj said:
I was really hoping people would stop *****ing about OTAs.
Sorry, but you all sound like a bunch of whiney kids. You'll never be satisfied because the OTAs will never be quick enough to satisfy people. Google is not going to give you nightly builds of ICS. So just calm down and wait for it to be finished and pushed out.
Click to expand...
Click to collapse
You just love calling everyone whiney kids don't you?
People are pissed because we have a Nexus that for the first time, is NOT leading the way in terms of OS version. We are pissed because of the overwhelming silence from Google.
It would take them 15 minutes to post a blog on where things are at.
Scottatron said:
You just love calling everyone whiney kids don't you?
People are pissed because we have a Nexus that for the first time, is NOT leading the way in terms of OS version.
Click to expand...
Click to collapse
Yes I do. And people deserve to be given some perspective.
What do you mean? ~1% of Android devices have ICS. How is that not leading the way in terms of OS version when we're the only phone with it? Nothing has a higher OS (and don't say "omg the NS has 4.0.3!"). The Galaxy Nexus launched Android 4.
Why are you crying about not having 4.0.3/4.0.4 over 4.0.2. If its not ready, its not ready. That's why we don't have it officially yet. For all you know Google is holding off till 4.0.5, 4.0.6, or 4.1... no one knows.
Like your phone for what it is. You're like a dog chasing his tail when you get something great and always look for the next best thing. You'll spend your entire time with the device wanting more, and you'll never enjoy what you have.
Like I said in the other thread: OTA's will never come fast enough for people. If Google started pushing one every month (regardless of how what it did or didn't include/fix), it still wouldn't be fast enough because people would prefer it was 3 weeks instead, then 2 weeks, then 1 week, then nightlies. And guess what? Google isn't going to do nightly OTAs of ICS (not even close!). If you want nightlies, go build a ROM from CM source and change things for yourself. Or better yet, build straight from AOSP source and fix the bugs yourself. Make a thread for it and let people ***** at you for not fixing them faster.
maybe this is why apple is having better success in the mobile world then google and all the others.
while all i have is an old ipod touch from apple, and have GN and ACER tablet, the fact is that google ANNOUNCED 4.0.3 as THE LASTEST STABLE release, however, even on the official supported hardware i still have 4.0.2
this is why i personally compare android to the old windows mobile system.
on the old windows mobile system, if you wanted to upgrade to the latest, you had to hack the device and upgrade yourself, and even then not all devices could be upgraded to all OSs. when i talk to people about android, i still find mayself telling them that even on the official hardware you need to hack the device to get the official upgrade.
if google and all the open source will learn a little from old mistake they will build a better test environments and stop calling any buggy version an official release, or make sure that all devices be able to get the latest version when it is announced (ipod/iphone 3rd gen can still be updated to ios5 even if it can barely work with it) .
the simple fact is, the android is repeating all of the mistakes that even microsoft with WP7 have learned, and am not showing even the slightest inclinations to make a change to this inadequate system of multiversioning....
PCHelper said:
maybe this is why apple is having better success in the mobile world then google and all the others.
while all i have is an old ipod touch from apple, and have GN and ACER tablet, the fact is that google ANNOUNCED 4.0.3 as THE LASTEST STABLE release, however, even on the official supported hardware i still have 4.0.2
this is why i personally compare android to the old windows mobile system.
on the old windows mobile system, if you wanted to upgrade to the latest, you had to hack the device and upgrade yourself, and even then not all devices could be upgraded to all OSs. when i talk to people about android, i still find mayself telling them that even on the official hardware you need to hack the device to get the official upgrade.
if google and all the open source will learn a little from old mistake they will build a better test environments and stop calling any buggy version an official release, or make sure that all devices be able to get the latest version when it is announced (ipod/iphone 3rd gen can still be updated to ios5 even if it can barely work with it) .
the simple fact is, the android is repeating all of the mistakes that even microsoft with WP7 have learned, and am not showing even the slightest inclinations to make a change to this inadequate system of multiversioning....
Click to expand...
Click to collapse
I'll tend to agree with most of what you said.... Apple has this down to a T with releasing OS versions. Everyone with the previous 2 versions of the hardware is completely guaranteed to get the update the day that it comes out. Models 3 years ago may or may not get a full update, but they'll at least get a partial update (with some features pulled). You know what you're getting and you know when you're getting it. You'll never be in limbo. When Apple announces a new iOS version, they explicitly say which models will get it. The consistency is good.
WP7 is a bit better analogy of what Android has to strive for IMO. Android covers tons of carriers, devices, etc. but still needs to be able to handle pushing OTAs to everyone in a timely matter. This is a huge logistical hurdle for MS (or Google) to try jump. MS is handling it by putting very strict guidelines on what hardware can be used and what you can/can't do to the software (which is pretty much nothing). This makes the OTA process a 1000 times easier for MS to implement. What it leads to is basically knowing that the OTA update will work on all of these different devices because they're about 90% identical in hardware, and 99% identical in software. The only hurdle for them is pretty much getting carriers to accept the terms of pushing the OTA.
While Google could implement a system like this, it'd be at least a year out. Because in order for this MS-style system to work, Android would have to have specific hardware and software guidelines. The problem being that Android is open source and free, and manufacturers can really do whatever they want. They only have to follow some very relaxed "guidelines" to get GAPPS. Even if Google wanted to push OTAs to all of these phones in their current state they couldn't. Google doesn't hold the code from Samsung, HTC, LG, Huawei, and others because they're each doing it in house. There is no unifying OTA that can be pushed. Ultimately Google has no say in what happens after they certify it for GAPPS support. At that point, its between the manufacturers and carriers what is going to happen.
Google needs to start hitting manufacturers where they can, with GAPPS. Its the only closed-source part of Android and its a really really important one. They need to start forcing UI guidelines and skinning policies that let OTAs flow smoother. On the carrier side, they need to start pushing carriers to allow manufacturers to push them when its ready. Google can only do so much to carriers though. At that point they can threaten, but again its not up to Google what happens with those devices once the licenses go out. Its not a Google sale to the carrier, its a manufacturer sale. Until every phone Google sells is a Nexus, they won't be able to tell carriers what to do. Although the market share is huge for Android, it doesn't have the same unified push to bully carriers like Apple has.
....but I've got a couple other points as well on your post. You're making it sound like the Galaxy Nexus is running 4.0.2, and the rest of devices are running/being sold with 4.0.3 (the "stable" build). This is not the case. Whether its running the most "stable" build or not, the GNex is the most up to date of all Android phones out there right now. And we'll be getting stock 4.0.3 before anyone, and all of those phones being sold from this point w/ 4.0.3 will have skins attached as well.
martonikaj said:
the GNex is the most up to date of all Android phones out there right now. And we'll be getting stock 4.0.3 before anyone
Click to expand...
Click to collapse
Why doesn't the Nexus S factor into your argument?
Evangelion01 said:
Why doesn't the Nexus S factor into your argument?
Click to expand...
Click to collapse
First off, the Nexus S update has yet to be pushed to everyone. Its still halted because of bugs (and the NS4G doesn't have it officially, either). Second, simply because it's 4.0.3 doesn't mean that it's "better" than 4.0.2 on the Galaxy Nexus. For all intents and purposes, it's the same update... look at the NS4G and NS on Gingerbread. One was on 2.3.5, the other on 2.3.7... doesn't mean one was better than the other, but simply the NS4G needed specific build # because its a different device.
If you're splitting hairs of 4.0.3 vs. 4.0.2 to try and win this argument, it's not going to work.
now here is where we can start the argument... 4.0.3 is better then 4.0.2 if only due to the codex hardware fix.
But that is not the question. The issue is it was officially released as latest stable, however only after official release somehow all of a sudden the official Google phones are full of bugs and it is not good for them. If it is not developed and tested on the official hardware, then why put the official stamp on everything? Where is Google QA? Why buy Google official devices if we cannot even get the minimum we expect from the name? Pay attention, I am not talking about vendor devices, only on official stamped device/software....
Sent from my Galaxy Nexus using xda premium
Scottatron said:
You just love calling everyone whiney kids don't you?
People are pissed because we have a Nexus that for the first time, is NOT leading the way in terms of OS version. We are pissed because of the overwhelming silence from Google.
It would take them 15 minutes to post a blog on where things are at.
Click to expand...
Click to collapse
+1
Couldn't have put it better myself. Google really needs to pull its **** together and give us some of that 4.0.4 goodness!
Thank god for unlockable bootloaders and XDA devs, huh. Oh, wait......
From my point of view (and mine only) I knew the nexus would have an unlockable boot loader, I knew there would be a root exploit before I even brought the device and I knew the devs here would provide better then Google themselves, that's why I personally, brought the phone. Fortunately you didn't choose HTC. The delays are longer and the devices more secure. What I'm trying to say is, make the most the the nexus and this community and get a custom ROM or makesure you choose devices in the future for the right reasons. Let's face it, very few of us brought it for the specs....
Sent from my Galaxy Nexus using XDA App
Ripped from /r/android. Found this to be quite interesting. Apparently the OEMs don't really control if their devices get support for new android versions or not.
http://www.reddit.com/r/Android/comments/1j13xd/how_oems_havent_announced_43_updates_for_the/
https://plus.google.com/116988351660148062102/posts/MHhMo7X1fbF
Shen Ye said:
To all the people complaining about how OEMs haven't announced 4.3 updates for the devices:
• OEMs do not get the Android source code directly from Google.
• The SoC vendors are provided the code from Google, where they make a board support package (BSP) which contains drivers and optimisations etc.
• The BSPs are then passed on to the OEMs, which they use to develop updates for their devices.
OEMs are currently waiting for the silicon vendors to decide which SoCs they will support in making a 4.3 BSP for, because their update support is heavily dependent on this.
For example, Qualcomm recently decided to drop development for a 4.2.2 BSP on their S3 SoCs, which is why HTC had turn around and say they were dropping support for the One S. This also caused Sony to drop update development for the Xperia S, SL, Acro S and ION (all S3 SoCs).
Everyone remembers the Thunderbolt and Sensation (LTE variants) which used the Scorpion MSM8655, which Qualcomm dropped support for, so OEMs had to drop future updates for.
Samsung is an exception, they're their own devices' silicon vendors when it comes to Exynos. But they also had to drop support for their S2 LTE variants which were using the Qualcomm Scorpion SoC.
Sure, it's not the perfect system, but it's how it works in the industry right now.
Click to expand...
Click to collapse
This doesn't sound right if there's people bringing unofficial 4.2.2 updates to said devices. If some guy that that doesn't even have a job with android developing can do it, I think a multimillion dollar OEM can.
Ascertion said:
This doesn't sound right if there's people bringing unofficial 4.2.2 updates to said devices. If some guy that that doesn't even have a job with android developing can do it, I think a multimillion dollar OEM can.
Click to expand...
Click to collapse
True, but none of those 4.2.2 ports have kernel source code, and therefore none of them truly work 100% with no bugs whatsoever. Correct me if I'm wrong, but I believe devs use prior kernel sources and modify them to work with newer android versions (for instance, I had ICS via CM9 on my droid incredible 2, but it never worked 100%).
Yay, time to send hate-mail to Qualcomm.
Sent from my buttered S3
User "iamadogforreal" had an interesting reply:
iamadogforreal said:
This is OEM apologia. In the real world, these OEMs are the customers and boss around the chip makers. Not the other way around, like this blogger is claiming. If OEMs cared about updates then they'd put that in their contracts and pressure the chip makers to do them. Instead, this becomes a convenient excuse (collusion?) for OEMs to stop making those expensive updates, especially when you're 4 months from launching another flagship phone.
Funny how the Nexus line doesn't have this problem. Gee, maybe google just is getting lucky with niceguy SoCs? No, google puts this in their contracts.
Honestly, if you think the SoC guys are telling the world's biggest companies like Sony or Samsung to **** off and to tell your customers to **** off, then you're incredibly naive. Android fans need to keep pressuring these companies to deliver timely updates and to commit to a two year update cycle, at least. Articles like these don't do us any service and only exist to validate that awful status quo.
Click to expand...
Click to collapse
Let's get this out of the way first, nobody here is stupid, we know the L Release is never going to come to the Galaxy Nexus officially. So let's talk about the community. I just have one basic question for our talented devs, what are the odds that a port of L will be able to come to the Gnex and if so, what kind of time frame are we looking at here?
Does the Cyanogenmod team do developers previews like this one? We might see it from them.
I'm sorry, but this post is exactly what I expected to see today.
so lets get it out of the way.
SURE
we COULD see some 5.0 aosp love(via custom development)
MAYBE.
time frame?
when.source drops, give it a few months at most I'd say
source isn't even CLOSE to ready yet though.
SOOO
let's ALSO look at the past.
which nexus devices, after Google officially dropped support, are STILL ABLE AND ARE running LATEST android version?
ALL of them right?
stability and such isn't a factor for this question, it's IF IT CAN/DOES run newest aosp in SOME FORM.
so I'd say YES gnex WILL see 5.0 in SOME usable form. but asking for ANY "time frame"at THIS POINT since SOURCE ISN'T AVAILABLE YET is kinda pointless.
maybe though, just maybe, there are ALREADY some people at work on getting those "preview" things ported. no matter WHAT, patience and not asking for timeframe/eta is key here
I don't normally do +1 style posts, but I am also greatly interested in knowing this as well.
I imagine it is largely going to depend on how much of the underlying kernel and driver interaction changes. I remember on my prior phone, a Droid X which has been and is still locked down, it was generally impossible to get past ICS because of the major underlying changes in JB and not being able to get those on the DX. Granted the Nexus doesn't have this limitation but drivers aren't likely to be further updated and if the kernel goes too far forward it is unlikely to see compatible driver versions for GNex hardware.
EDIT: I should probably say modules instead of drivers. I'm primarily a Windows person PC-side.
Put it this way my 4 year old HTC Desire can run Kitkat then i would be amazed if we didn't end up with some pretty good builds of "L".
ashclepdia said:
I'm sorry, but this post is exactly what I expected to see today.
so lets get it out of the way.
SURE
we COULD see some 5.0 aosp love(via custom development)
MAYBE.
time frame?
when.source drops, give it a few months at most I'd say
source isn't even CLOSE to ready yet though.
SOOO
let's ALSO look at the past.
which nexus devices, after Google officially dropped support, are STILL ABLE AND ARE running LATEST android version?
ALL of them right?
stability and such isn't a factor for this question, it's IF IT CAN/DOES run newest aosp in SOME FORM.
so I'd say YES gnex WILL see 5.0 in SOME usable form. but asking for ANY "time frame"at THIS POINT since SOURCE ISN'T AVAILABLE YET is kinda pointless.
maybe though, just maybe, there are ALREADY some people at work on getting those "preview" things ported. no matter WHAT, patience and not asking for timeframe/eta is key here
Click to expand...
Click to collapse
Thanks for replying! I figured since I looked pretty thoroughly and didn't see a thread for it and thought that having at least one place for Gnex owners to talk about the L release for us wouldn't be a bad thing. I in no way meant to be one of those people who constantly bugs the devs about ETA's, I just meant what were could be expecting in the general sense. Thanks for the reassurance about us getting it, I've just been burned before about support with previous devices when they got past official support. But those weren't Nexii so I didn't know what to expect.
Brettbesa said:
Thanks for replying! I figured since I looked pretty thoroughly and didn't see a thread for it and thought that having at least one place for Gnex owners to talk about the L release for us wouldn't be a bad thing. I in no way meant to be one of those people who constantly bugs the devs about ETA's, I just meant what were could be expecting in the general sense. Thanks for the reassurance about us getting it, I've just been burned before about support with previous devices when they got past official support. But those weren't Nexii so I didn't know what to expect.
Click to expand...
Click to collapse
yea sorry about my tone in that reply mostly too
I'm usually not the one to fly off ranting towards other users actions, at least not on xda(i do #AshRants elsewhere lol)
your question was a valid one, and I know where you coming from when it comes to nom nexus devices and their lack of support, I had a droid x2 that was ORIGINALLY SCHEDULED BY MOTOROLA to have ICS update. which for some reason they just didn't follow through on. Their REASON they said was that "android 4.0+ would not improve functionality of this device"...aka "we don't feel like fixing all the bugs we gave you already with shotty gingerbread releases, and we aren't going to allow you to unlock the device or give you usable kernel source so screw off",...back when moto didn't gaf about the dev communities. they have made huge strides towards mending that relationship. just couldn't believe they had the gall to say 4.0 wouldn't improve the first dual core android device running a tegra2 chipset. bah. ramblings now again from ash.
but yea reason I kinda went off in that reply was mostly cuz I hoped all the other people who were already drooling at the chance to post the exact same things would slow down and think instead first it wasnt intended as a personal attack towards you or to start any flamewar on the subject. and judging by your reply you didn't take offense to it anyways, so :thumbsup: :good: we all on the same page anyways.
personally, I haven't seen much of the IO stuff about L, I saw mostly design changes, and would like to know more details about it's new features so I'll be digging around YouTube today for recaps and such.
but I'm almost certain that if we don't get some kinda official rom like CM, OMNI, SHINY, PA, etc... building L based.roms for us, then some of our awesomely talented devs will at LEAST get us able to look like we have it, along with SOME if not z MOST functionality of L.
ashclepdia said:
I'm sorry, but this post is exactly what I expected to see today.
Click to expand...
Click to collapse
I also think you guys should be patient. Your life won't be (that limited if there won't be a port of the coming up Android L to our Galaxy Nexus. Just relax.
As some have already pointed out, we're unlikely to see Android 5 "officially" ported to our GNex, for pretty much the same reason that we don't have an official 4.4 release for our phone. From ArsTechnica:
"Our talk with Burke shed some light on some more obscure topics too, including the lack of an Android 4.4 update for the Galaxy Nexus. Google's official line was that the company only supports hardware for 18 months after release, which it still mentions in its official Nexus update support document. As was speculated at the time, though, the decision was tied to Texas Instruments' exit from the consumer SoC market (TI's OMAP chip powered the Galaxy Nexus as well as other prominent Android-based hardware like the first Kindle Fires).
"It was a really extraordinary event," he said. "You had a silicon company exit the market, there was nobody left in the building to talk to."
Click to expand...
Click to collapse
TI stopped development for the GNex SoC at Android 4.1. Google and others worked hard to support it for 4.2 and 4.3, but the official TI software was broken by 4.4. The reason that we even have 4.4 custom ROMs is because some kind-hearted person, perhaps a TI insider, released beta or engineering sample software for the SoC. But as we've found, it's not the most stable
have a great weekend,
john
You could all complain about TI stopping development and blaming them. The Google Glass uses a not to different TI SOC compared to the GNex has a 3.4 kernel and runs 4.4.2
Now please understand that Google simply ditched us for reasons other than TI stopped developing SOC bla bla bla.
akash3656 said:
You could all complain about TI stopping development and blaming them. The Google Glass uses a not to different TI SOC compared to the GNex has a 3.4 kernel and runs 4.4.2
Now please understand that Google simply ditched us for reasons other than TI stopped developing SOC bla bla bla.
Click to expand...
Click to collapse
Plus if they didn't drop support after two years android would have alot more bugs in general.
DR3W5K1 said:
Plus if they didn't drop support after two years android would have alot more bugs in general.
Click to expand...
Click to collapse
I don't get your logic. And its not like 4.3 is flawless. HD video playback on this device (GNex) lags.
+ if Google themselves show a bad example to OEMs on how long to update devices, expect OEMs to not update devices older than a year. And this makes the whole "android doesn't get timely updates" into a new issue where "android doesn't get updates after a year+ at best".
GNex will never die!
(3.5 yrs going strong bby, and thanks to vanir+dirtyv f2fs running better than ever)
latenightchameleon said:
GNex will never die!
(3.5 yrs going strong bby, and thanks to vanir+dirtyv f2fs running better than ever)
Click to expand...
Click to collapse
Indeed. There will likely be somebody out there building from the latest source for this device as long as it's possible to do so, and possibly even if it isn't.
akash3656 said:
Now please understand that Google simply ditched us for reasons other than TI stopped developing SOC
Click to expand...
Click to collapse
Out of curiosity, what would those reasons be?
jsage said:
Out of curiosity, what would those reasons be?
Click to expand...
Click to collapse
That's up for you to imagine....
Money, profit, greed? You pick which one. Or make your own reasons.
akash3656 said:
That's up for you to imagine....
Money, profit, greed? You pick which one. Or make your own reasons.
Click to expand...
Click to collapse
Well, I guess when simple facts aren't sufficient then fantasy must be more believable.
wow
some of these replies were brutal, sheesh
gray bishop said:
some of these replies were brutal, sheesh
Click to expand...
Click to collapse
Honest perhaps. It's pretty simple really. The new OS (4.4) has a new kernel. The new kernel requires new drivers. Neither TI (OMAP SoC) nor ImgTec (PowerVR GPU) will supply those drivers.
Yes, an engineer at TI "released" a blob last fall. But it was not release-quality, it was beta-quality. Not everything is a conspiracy; we've just reached the end of the official support road.
On the other hand if one is inclined to run on the bleeding edge and stability is not their primary concern, there are any number of KitKat custom ROMs in which one can indulge.
have a great evening,
john
jsage said:
Honest perhaps. It's pretty simple really. The new OS (4.4) has a new kernel. The new kernel requires new drivers. Neither TI (OMAP SoC) nor ImgTec (PowerVR GPU) will supply those drivers.
Yes, an engineer at TI "released" a blob last fall. But it was not release-quality, it was beta-quality. Not everything is a conspiracy; we've just reached the end of the official support road.
On the other hand if one is inclined to run on the bleeding edge and stability is not their primary concern, there are any number of KitKat custom ROMs in which one can indulge.
have a great evening,
john
Click to expand...
Click to collapse
Ah crap I didn't mean to thank you. Anyway, yea sure remember all those OEMs you blame and all have given everything you've said to a certain product. GOOGLE GLASS. And go and check what SOC Google Glass uses.
Now have fun.