Related
So, let me start off by saying that I have searched, read and spent time trying to understand this... but still don't. Which answers why I'm posting this question.
First, what exactly is the reason that an AOSP rom is being developed and a Vanilla Froyo ROM is being developed?
Is the AOSP rom the important one here? Does the working AOSP rom with working kernel mean that we would have 2.2, 2.3.... and so on supported regardless of Samsung?
I understand that Samsung has not supported tremendously up to this point, I understand 2.2 has not been released for the CDMA version yet, and I understand the code they have released is "crappy." When I hear everyone talk about the great work the devs are doing, are they referring to mainly working on the AOSP? If this rom is built, will we be able to just keep developing it for the new versions of Android?
Sorta like in Back to the future when they break off the real timeline and go into the alternate 1985?
Samsungs Android - 2.1, 2.2.... EOL
Dev's Android - 2.1, AOSP, 2.2, 2.3?
Is this how it works? Basically just trying to understand what needs to happen for the Fascinate to get to at least 2.3... not WHEN or even IF it'll get to 2.3.
Thanks
AOSP means Android Open Source Platform.
It's a version of Android built entirely from sources provided by Google. It's completely Vanilla and comes with zero customer or manufacturer customizations. It's easily root-able, and able to be customized completely by the user if desired.
AOSP ROMs are desirable because they tend to be a bit faster and lighter due to their lack of crapification.
AOSP builds are only distributed in their complete and compiled form by Google for their developer handsets (Currently the Nexus One and Nexus S), and not by any carrier or manufacturer.
Okay, I appreciate that definition... I think I've gotten what AOSP is exactly... but I guess my question is does AOSP have any involvement in a future for this phone if Samsung decides to close its doors. Is a working AOSP, radio, kernel... whatever basically devs developing a future of this phone parallel to whatever Samsung does for it?
Like, I see from other threads that the ROM for Froyo and Gingerbread isn't necessarily the problem, its the radio and the RIL? If that is the case, what needs to happen for everything to figured out and for us to have a bright future for the Fascinate? Samsung has to release code for the RIL and radio? Are we SOL without Samsung helping here or will the devs definitely figure something out to get 2.2, 2.3... and so on for the Fascinate?
Bwangster12 said:
Okay, I appreciate that definition... I think I've gotten what AOSP is exactly... but I guess my question is does AOSP have any involvement in a future for this phone if Samsung decides to close its doors. Is a working AOSP, radio, kernel... whatever basically devs developing a future of this phone parallel to whatever Samsung does for it?
Like, I see from other threads that the ROM for Froyo and Gingerbread isn't necessarily the problem, its the radio and the RIL? If that is the case, what needs to happen for everything to figured out and for us to have a bright future for the Fascinate? Samsung has to release code for the RIL and radio? Are we SOL without Samsung helping here or will the devs definitely figure something out to get 2.2, 2.3... and so on for the Fascinate?
Click to expand...
Click to collapse
It's kinda like building an office park, or strip mall or something. You toss up the basic vanilla buildings, and when it's finally done, companies move in and tweak it how they deem fit.
With a working ASOP build, it'll remove some of the shackles of Samsungs bs code.
So... the AOSP build IS THE KEY here? I understand it isn't working yet, but if the devs get AOSP working, does that mean we will get a 2.2, 2.3 and so on regardless of what is released by Samsung?
I'm just trying to figure out what is happening to keep the G1, Droid, Droid 2... supported by ROMs like Cyanogenmod and others, that hasn't happened yet for the Samsung Fascinate.
I'd like to get the Fascinate, but am sorta waiting because I don't wanna be stuck with a phone for the next 2 years that will max out at MAYBE 2.2 if we are lucky.
I don't know where to start with your confusion.
Samsung has not given 2.2 to us. This means that we do not have froyo...
The RIL is an interface layer between the os and the radio. I'm not too sure about it, but anyways...
The developers are working around the fact that samsung has not given further tools that they need to get froyo ported over. Currently they are working on a 1.6 RIL to get froyo working. On another note, vanilla aosp is a good thing because it gives developers more freedom to customize the roms. It also allows for them to be able to port over other roms.
I really don't understand your confusion. If you want a better explanation , I recommend getting on irc.
If I were you, I'd wait. Next gen phones are coming from vzw in the next few months which will essentially blow the existing tech soon.
Bwangster12 said:
So... the AOSP build IS THE KEY here? I understand it isn't working yet, but if the devs get AOSP working, does that mean we will get a 2.2, 2.3 and so on regardless of what is released by Samsung?
I'm just trying to figure out what is happening to keep the G1, Droid, Droid 2... supported by ROMs like Cyanogenmod and others, that hasn't happened yet for the Samsung Fascinate.
I'd like to get the Fascinate, but am sorta waiting because I don't wanna be stuck with a phone for the next 2 years that will max out at MAYBE 2.2 if we are lucky.
Click to expand...
Click to collapse
Basically, that's the hope at least. If there are changes in say, 2.4 that require something that couldn't be hacked around with ASOP, we'll be stuck waiting for Samsung. But with a working ASOP, the groundwork is laid for updates to be ported over a bit more quickly by the devs.
Regardless of the future of this device, the Fascinate is one of the better Android handsets on the market. The screen is brilliant, it's the perfect size, and it's damn fast. The only thing that drags it down is the factory setup (although I personally think it's idiotic to ding the phone because of the inclusion of Bing like some people/reviewers have.)
I'm trying to understand what is going on instead of being one of the millions to ask about updates for this phone. I see phones like the droid series and read that they basically are being supported forever and then I see the Samsung Fascinate, and while I understand that the code is crappy/not released to community... I'm trying to figure out what needs to happen for it to be a supported device like the droids have been.
Bottom line, nothing at all is going to happen unless Samsung releases more than just a 2.2 update? If I see 2.2 drop like tomorrow, does that mean anything for a future, or is it just 2.2 update and we will just get devs releasing their versions of 2.2 roms?
RacerXFD said:
I really don't understand your confusion. If you want a better explanation , I recommend getting on irc.
Click to expand...
Click to collapse
I read his questions as:
"Will a working ASOP build mean better developer support/faster developer released updates?"
I did skim them though.
RacerXFD said:
If I were you, I'd wait. Next gen phones are coming from vzw in the next few months which will essentially blow the existing tech soon.
Click to expand...
Click to collapse
This is a good point. There's an LTE Samsung handset coming out soon, so it might be worth holding out for a little.
Although the Fascinate is no slouch.
Pretty much what I am asking. Like of everything that could possibly happen, Samsung releasing 2.2, AOSP being finished, blah blah what is the key that a consumer should look for to say...
"Well, now the Fascinate has no negatives to it and I have no fear that in a year, we won't still be stuck on 2.1 or 2.2 because Samsung screwed us."
Doesn't necessarily seem like Samsung needs to do MUCH to future this phones life and turn over the keys to the devs (like HTC seemingly has done), but I'm trying to understand what that thing is they need to do. Release a newer kernel, RIL, 2.2 ROM, some code that magically allows devs to port over future roms eternally...
I don't think I care if the phone has LTE capability. I won't get LTE and a regular 3G phone is beyond enough for me. LTE is zero impact for me.
Bwangster12 said:
Pretty much what I am asking. Like of everything that could possibly happen, Samsung releasing 2.2, AOSP being finished, blah blah what is the key that a consumer should look for to say...
"Well, now the Fascinate has no negatives to it and I have no fear that in a year, we won't still be stuck on 2.1 or 2.2 because Samsung screwed us."
Doesn't necessarily seem like Samsung needs to do MUCH to future this phones life and turn over the keys to the devs, but I'm trying to understand what that thing is they need to do. Release a newer kernel, RIL, 2.2 ROM, some code that magically allows devs to port over future roms eternally...
I don't think I care if the phone has LTE capability. I won't get LTE and a regular 3G phone is beyond enough for me. LTE is zero impact for me.
Click to expand...
Click to collapse
What does SAMSUNG need to do? Release their source code, and not just incomplete parts of it.
Will that happen? I doubt it, but it might. Clearly the companies ears are perking up with all the yelling by the consumers.
What can we do in the meantime? Support the devs and wait for them to crank out a working ASOP build and Froyo.
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Basically... AOSP will only be updated to whatever version Samsung has released?
Bwangster12 said:
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
Click to expand...
Click to collapse
No. Android Open Source Project means "Android" in general. It can be 2.1, 1.6, 2.3, whatever. The devs elected to start with 2.1.
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Click to expand...
Click to collapse
If you've followed anything in the dev folders, clearly not. JT's "Vanilla" Froyo looks like an AOSP build.
Basically... AOSP will only be updated to whatever version Samsung has released?
Click to expand...
Click to collapse
No. At least not our version.
Bwangster12 said:
Yes, would be nice to have a fully working AOSP build, and then Froyo... but they are seperate from each other right?
Click to expand...
Click to collapse
It's hard to answer your question because AOSP and Froyo refer to two completely different things, which can be the same or separate.
AOSP is basically Android, built from clean, unmodified source code directly from Google, without any changes by carriers or manufacturer.
Froyo is simply the 2.2 version of Android.
So, you can have Froyo that's modified by a carrier and/or manufacturer. This wouldn't be AOSP. And you can have Froyo, built directly from Google code. This would be AOSP. You can also have Eclair (Android 2.1), or any other version of Android that's AOSP or not AOSP depending on whether it was built directly from Google code, or modified by a carrier or manufacturer.
AOSP doesn't refer to a single, particular version of Android, but the state of the code that was used to compile whatever version you want to talk about.
Bwangster12 said:
AOSP build is being done for 2.1? It can't just be magically updated to 2.2 can it? Does Froyo have to be officially released for them to update it to AOSP 2.2?
Click to expand...
Click to collapse
A lot of the issue surrounds the kernel. When Google releases a new version of Android, it runs on a particular version of the kernel, which supports it's particular features. Manufacturers have to modify the kernel to support their particular hardware. So, since Samsung has only released source code for the kernel for Android 2.1, we're stuck on 2.1.
The versions of 2.2 from Kaos and JT are running on the Android 2.1 kernel that's been hacked to enable 2.2 to boot and run correctly. It works, but it's far, far from ideal. It doubles (if not more) the amount of work necessary to get 2.2 running, which is the reason for the rather slow pace of development.
So for your question, once Samsung releases 2.2 (the system and kernel), it'll be much easier to get an AOSP build of Android running, since the devs will only need to worry about the system instead of hacking together a kernel and RIL (radio interface layer) as well.
At least this is my understanding of the situation. I'm sure people with more knowledge and experience can correct me where I'm wrong, but I think this is the basic gist of it.
ChrisDDD said:
It's hard to answer your question because AOSP and Froyo refer to two completely different things, which can be the same or separate.
AOSP is basically Android, built from clean, unmodified source code directly from Google, without any changes by carriers or manufacturer.
Froyo is simply the 2.2 version of Android.
So, you can have Froyo that's modified by a carrier and/or manufacturer. This wouldn't be AOSP. And you can have Froyo, built directly from Google code. This would be AOSP. You can also have Eclair (Android 2.1), or any other version of Android that's AOSP or not AOSP depending on whether it was built directly from Google code, or modified by a carrier or manufacturer.
AOSP doesn't refer to a single, particular version of Android, but the state of the code that was used to compile whatever version you want to talk about.
A lot of the issue surrounds the kernel. When Google releases a new version of Android, it runs on a particular version of the kernel, which supports it's particular features. Manufacturers have to modify the kernel to support their particular hardware. So, since Samsung has only released source code for the kernel for Android 2.1, we're stuck on 2.1.
The versions of 2.2 from Kaos and JT are running on the Android 2.1 kernel that's been hacked to enable 2.2 to boot and run correctly. It works, but it's far, far from ideal. It doubles (if not more) the amount of work necessary to get 2.2 running, which is the reason for the rather slow pace of development.
So for your question, once Samsung releases 2.2 (the system and kernel), it'll be much easier to get an AOSP build of Android running, since the devs will only need to worry about the system instead of hacking together a kernel and RIL (radio interface layer) as well.
At least this is my understanding of the situation. I'm sure people with more knowledge and experience can correct me where I'm wrong, but I think this is the basic gist of it.
Click to expand...
Click to collapse
Okay, thank you for this answer... this makes sense to me.
So, have HTC and Motorola released newer kernels for the devs of roms like Cyanogemod to update their ROMs, despite HTC and Motorola not actually releasing newer versions? I mean, how is the G1 updated as far as it has. Did HTC release a 2.2 kernel to allow devs to put 2.2 on it?
That's were I'm start confused as well.
I understand that Samsung has some proprietary kernel level code and drivers.
But, I'm curious what is the difference between Linux kernel versions used for different versions of Android. It doesn't sound like major version change and hence should not change anything dramatically. It should be mostly bug fixes. That's why jt was able to get kernel work.
As in relation to ASOP for SF, I see it like attempt to adapt Samsung code to current android interfaces. Once again, these interfaces should not change dramatically between versions, because these are evolutionary. So, I assume when done it is pretty much paved road up to 3.0 at least. That said some new features might not work at all, because we do not have working initial binaries from Samsung.
By the way mrbirdman has GB in progress.
Alright... so this may sound like I'm oversimplifying it, but I don't mean to.
Why can't the dev community just create a "custom" kernel to work with their versions of 2.2, 2.3 and so on? You say that they are working to hack the 2.1 kernel Samsung has released so it allows 2.2 to run on the Fascinate... but why can't they just make a 2.2 kernel? Is that sorta what Cyanogenmod is doing to get a 2.2 Froyo build to work on a G1?
Based on the amazing things I've seen the dev community do, building ROMs from scratch, I guess I don't understand how the kernel can't be built specifically for each new version... forgetting about what Samsung releases.
Bwangster12 said:
Why can't the dev community just create a "custom" kernel to work with their versions of 2.2, 2.3 and so on?
Click to expand...
Click to collapse
Theoretically they could, it would just be a lot of work. Hardware drivers might not be compatible with the kernel version designed for 2.2 or 2.3. I don't think manufacturers are required to release the code for their drivers, so if a driver wouldn't work, one would need to be written from scratch, and without the detailed knowledge of the hardware itself, that is very difficult.
Hardware support is very integral to the kernel, so a kernel for one phone wouldn't run at all on another. So in addition to the difficulty of putting together a totally independent kernel, it would need to be done separately for each and every phone out there, and how many versions of the Galaxy S alone are there? How many HTC phones, how many Motorola and LG and Sony and so on.
It's just not realistic for people doing this, essentially, in their spare time.
So, what the devs generally do is wait until a carrier releases a version of Android (System, kernel, radio, etc.), and with all the hardware support in place and working, they can focus on building custom or AOSP versions of the system.
It's not that they couldn't build their own kernel, it's just a matter of practicality, audience and the shelf live of the particular phone. As it is, a new generation of phones are already either coming out or on the near horizon... and our phone is what, 4 to 5 months old?
Bwangster12 said:
Based on the amazing things I've seen the dev community do, building ROMs from scratch, I guess I don't understand how the kernel can't be built specifically for each new version... forgetting about what Samsung releases.
Click to expand...
Click to collapse
The misunderstanding is in the complexity of compiling a custom system, and developing a custom kernel. They are hugely different in terms of complexity.
Think of a ROM as taking Windows 3.1 and simply tweaking the components that are installed by default - what accessories are installed, what wallpaper is selected, the color scheme of the windows. Not terribly complicated.
Think of the kernel as having to compile DOS, complete with custom drivers for all the hardware - CPU, graphics, memory, storage, multitouch, sound, radio, modem, WiFi, networking, power management, USB support, file system support, etc. all by hand.
Hello there,
I have this theory... I want to hear your opinions to see if I'm just crazy or I'm correct in thinking this.
After seeing how the unmodified Acer Iconia Galaxy ROM + modified ASUS Transformer kernel (Clemsyn's) worked on a Transformer I started to think that this could be because of all the Honeycomb tablets are running a pretty similar OS configuration ("stock-like" Honeycomb).
Am I right in thinking this (I haven't actually used any other HC tablet except the Iconia)?
If this is right, it kind of explains why an unmodified ROM developed for the Iconia works with our device, as they are using pretty similar systems. The main difference, of course, is the hardware. This explains the wifi, battery and other issues in this example. This was partly corrected from the use of an ASUS TF kernel (Clemsyns) with the same ROM since the kernel provides the needed interfaces, modules, whatever for the respective hardware.
Of course, the kernels between the devices, I'm assuming as I haven't actually compared the source, are pretty similar aside from certain hardware modules that have been left out during compilation, as they are both just modified Linux kernel. This explains why the Iconia ROM worked (mostly) even when using an Iconia kernel.
So am I right with all the above, or am I missing something obvious, or am I just crazy (2am and my PC's made my room very hot afterall)?
Okay, so if the above is correct, couldn't/shouldn't we be doing some cooperative developement with other Honeycomb device developers? Or at least the Iconia developers, as I'm not sure about other devices. I mean, if the ROMs are pretty much compatible, all that would need to be done is have a respective kernel for the respective device flashed on-top of the ROM, right?
Anyway, laugh at me, flame me, tell me to go to bed, whatever, but I'd like to know what your thoughts are.
And on a related note:
Has anyone actually tried flashing any other "other-device ROMs" onto a TF with a TF kernel and got it working?
I'd love to try, but my internet is terrible... I swear someone else on the network constantly has their BT speeds uncapped 24/7 (share-house's are ****ty).
I think that's pretty much the goal of the CyanogenMod project. Only reason they haven't begun on a Honeycomb version is because Google never released the AOSP. Hopefully this will change with ICS.
Yes, the OEMs are working together with google behind the scenes.
More than likely Google has "forced" them to contribute code in order to participate and enjoy early code.
Unified code at the OS level would be a godsend and allow for Windows - style updates.
poltak11 said:
After seeing how the unmodified Acer Iconia Galaxy ROM + modified ASUS Transformer kernel (Clemsyn's) worked on a Transformer I started to think that this could be because of all the Honeycomb tablets are running a pretty similar OS configuration ("stock-like" Honeycomb).
Click to expand...
Click to collapse
As far as I'm aware, pretty much all the current crop of Honeycomb tablets are all based on the Nvidia Ventana reference platform, so it's not too surprising that they are all very, very, similar software-wise.
Regards,
Dave
JCopernicus said:
Yes, the OEMs are working together with google behind the scenes.
More than likely Google has "forced" them to contribute code in order to participate and enjoy early code.
Unified code at the OS level would be a godsend and allow for Windows - style updates.
Click to expand...
Click to collapse
But as the OEMs are working together, why aren't independant developers here on xda? I mean, I'm just thinking that a lot more nice work would get done if there was unified developement going on between the HC devices instead of seperate forums, and seperate ROMs that seem to be very similar.
And yes, I do agree about the closed source problem. But Google said this is just a temporary thing, right?
It's hard to write too much code when you don't have the original to start with.
No one really wants to write Honeycomb from scratch.
sassafras
sassafras_ said:
It's hard to write too much code when you don't have the original to start with.
No one really wants to write Honeycomb from scratch.
sassafras
Click to expand...
Click to collapse
I understand this, of course, but excuse my ignorance when it comes to Android Developement, but what are the developers of PRIME and Clemsyn's ROM and all the other HC ROMs working with at the moment, as there is no source other than the GPL'd kernel?
poltak11 said:
I understand this, of course, but excuse my ignorance when it comes to Android Developement, but what are the developers of PRIME and Clemsyn's ROM and all the other HC ROMs working with at the moment, as there is no source other than the GPL'd kernel?
Click to expand...
Click to collapse
They are working with the OTA. It is all compiled things. They can add things on top of it, but they can't do modifications to it because its already compiled (source code not provided).
zephiK said:
They are working with the OTA. It is all compiled things. They can add things on top of it, but they can't do modifications to it because its already compiled (source code not provided).
Click to expand...
Click to collapse
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.
poltak11 said:
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.
Click to expand...
Click to collapse
Chances are there will be a CyanogenMod type project once Android tablet sources are released.
However, there will always be developers who are primarily interested in doing their own thing, which is perfectly acceptable too.
Regards,
Dave
poltak11 said:
Ah, fair enough. Well assuming that Google actually does release the source-code sometime, will this sort of thing be happening? As in co-developement between devices?
It just seems like the sensible thing to be happening, as opposed to a greatly splintered "fork" style of developement.
Click to expand...
Click to collapse
There's a reason CM hasn't officially touched any Honeycomb tablet. There's no source. Once they open up the source with ICS then everyone will be working on it through github.
Ahoy mateys. I've been a longtime Android user (October 2009) and have never been much for running the stock OS on my devices.
Currently I've been running CM7 and loving it on the KF. Been keeping tabs on the ICS port over, just waiting for the sound issues to be hammered out as I use the device mostly for watching videos via RockPlayer.
Lately I've been thinking about trying to port over Honeycomb to the KF, as it might be simpler given that it's been around longer. I know that it's somewhat futile given the state of the 3.0 kernel being needed for HW acceleration. But it seems like it could be worthwhile just to test it and see what might happen. Give it more tablety goodness if anything!
I'm a programmer by trade and am majoring in CS. Not much dev experience on Android aside from writing games. But I've built Gentoo for my machines, so I've got some kernel knowledge. What do you guys think?
Regards,
-Free
P.S. I don't have 10 posts so this is in General.
freeqaz said:
Ahoy mateys. I've been a longtime Android user (October 2009) and have never been much for running the stock OS on my devices.
Currently I've been running CM7 and loving it on the KF. Been keeping tabs on the ICS port over, just waiting for the sound issues to be hammered out as I use the device mostly for watching videos via RockPlayer.
Lately I've been thinking about trying to port over Honeycomb to the KF, as it might be simpler given that it's been around longer. I know that it's somewhat futile given the state of the 3.0 kernel being needed for HW acceleration. But it seems like it could be worthwhile just to test it and see what might happen. Give it more tablety goodness if anything!
I'm a programmer by trade and am majoring in CS. Not much dev experience on Android aside from writing games. But I've built Gentoo for my machines, so I've got some kernel knowledge. What do you guys think?
Regards,
-Free
P.S. I don't have 10 posts so this is in General.
Click to expand...
Click to collapse
Personally, I think it's a good idea, and that you should do it. You'll probably get a lot of people saying there's no point cause ICS is what honeycomb should've been. I've never used honeycomb before, so I don't know how different it is from ICS but I'm sure there are some.
I think you should do it to give this device and its users another ROM choice, with a different android version. Or even just for the fact that you might want to use it, do it for yourself and post it here just to see if people want it. I'd try it out, even if ICS is out and stable haha
Sent from my HTC Glacier using Tapatalk
Personally, I think it's a good idea, .... I've never used honeycomb before...
Click to expand...
Click to collapse
Huh?
Why would you encourage someone to work on something when you yourself don't know what the differences are between them??
ICS is Honeycomb just taking to what was its planned completion. With many Honeycomb devices moving to ICS I don't see the point.
That would be doing a lot of work, just to end up with an in between OS with all the new support going to ICS which is what everyone that can get it wants.
Also, for someone with no Android programming experience, you most likely would be a lot better of working with apps before tackling a whole OS.
krelvinaz said:
Huh?
Why would you encourage someone to work on something when you yourself don't know what the differences are between them??
ICS is Honeycomb just taking to what was its planned completion. With many Honeycomb devices moving to ICS I don't see the point.
That would be doing a lot of work, just to end up with an in between OS with all the new support going to ICS which is what everyone that can get it wants.
Also, for someone with no Android programming experience, you most likely would be a lot better of working with apps before tackling a whole OS.
Click to expand...
Click to collapse
I'd like to check it out. It's not like I'm telling him that he needs to do this, he asked what people thought of the idea because he was interested in doing it, and I voiced my opinion.
Though I do agree that it might be easier to work with apps and then maybe work on a ROM, but hey, if he's willing to attempt it and learn how everything works, why stop him? The more devs, the merrier lol
Isn't the problem with porting honeycomb is that it was never truly open source?
My understanding is there was never a source release for honeycomb
Sent from my SPH-D700 using xda premium
[email protected] said:
Isn't the problem with porting honeycomb is that it was never truly open source?
Click to expand...
Click to collapse
Yea, that is, AFAIK, why there was never a CM8. I don't think it would be worth OP's time to try to reverse-engineer a Honeycomb tablet and shoehorning it into the KF.
However, the OP might want to donate some of their time to the ICS port
It is open source after all...
[email protected] said:
Isn't the problem with porting honeycomb is that it was never truly open source?
Click to expand...
Click to collapse
I believe Google released the source for Honeycomb when they released the source for ICS
Sent from my Kindle Fire using Tapatalk
Hit up this Google announcement, they did indeed release the source.
This release includes the full history of the Android source code
tree, which naturally includes all the source code for the Honeycomb
releases. However, since Honeycomb was a little incomplete, we want
everyone to focus on Ice Cream Sandwich. So, we haven't created any
tags that correspond to the Honeycomb releases (even though the
changes are present in the history.)
Click to expand...
Click to collapse
groups.google dot com/forum/#!topic/android-building/T4XZJCZnqF8
The only thing that I really want to know is if there is a significant driver difference between ICS and Honeycomb. If there is, then there is a reason to try to port 3.0 over because it would have more driver support. There are 3.0 devices out in the wild. If there isn't a driver difference between 3.0 and 4.0, then it's futile and all efforts should be spent on 4.0.
theholyfork said:
I believe Google released the source for Honeycomb when they released the source for ICS
Sent from my Kindle Fire using Tapatalk
Click to expand...
Click to collapse
Indeed.
And when they released the source for ICS, they elaborated on why they included Honeycomb in the Source tree: To essentially display the hacks they were forced to use to push Honeycomb to market. Honeycomb was never AOSP'd because it wasn't reliable for wider use.
Based upon the fact that Google was basically too ashamed to release Honeycomb to AOSP, I don't think it would make much sense to target a broken platform (Honeycomb).
IMO, if you're going to spend time trying to work on getting a more tablet-oriented version of Android running, it's probably going to be *easier* to work with ICS than Honeycomb. Moreover your contributions could assist the greater KF community in getting a stable base of ICS for all.
Last night, +Steve Kondik took to twitter to vent a little bit:
"CM has been getting a lot of crap lately for taking so long with a release. Guess what? It's not that easy. We don't just call something stable unless we mean it. *Also, RC1 is soon!* The most stable devices will get the RC first. The system we've put in place should allow other devices to catch up quickly. More details later this week "
Now to combat the obvious questions:
# As Steve stated, this will not be for all CM9 supported devices. The Nexus S and Galaxy Nexus can be considered safe bets, but the final list won't be available until release day.
# As always, the proper day of release is difficult/impossible to predict, but we anticipate a code freeze going in place tomorrow at the earliest.
# Yes, this means we will actively be running two separate RC phases (CM7 and CM9). Bug's should be reported to the issue tracker once the release is made, not in the comments on our posts.
# There has been a lot of talk surrounding Linaro in CM. While CM 9.0 won't ship with all the patches on gerrit, quite a few of them are already incorporated and others are sane enough that they will likely be there. There are still some issues surrounding the updated gcc used for the Linaro patches that don't play nice with AOSP.
# Nexus One: For the time being, the N1 will not be supported. We can get it to build/boot/run, but the hacks required break Google's CTS, so until that is rectified, you won't see any build with CM's official stamp of approval.
CM9 News
And from a followup a few hours later:
******
+Ricardo Cerqueira sat down with XDA recently for a developer interview
To piggy back on our comment about the N1 and CTS, Ricardo describes why we don't just shrug off that requirement.
Because it opened a can of worms that can’t be closed again. Getting it to work needed some very ugly workarounds that directly go against Google’s compatibility document for ICS. An app developer targeting ICS as a minimal version for his apps has the right to expect some functionality to be guaranteed on a device that claims to be ICS, that wasn’t (and isn’t) true for ICS builds with these hacks. That’s one the main reasons CM9 does not officially include a bunch of devices that are “working.”
...and some users understand that, but a lot don’t, and they’ll submit error reports on those apps, or they’ll rate it badly at the Play store. This is not a hypothetical scenario, it has happened whether we like it or not, asked for it or not, CM’s userbase is large enough to matter, even if you don’t count derivatives. We have a responsibility not to cause that kind of grief to app developers and we did. With all the mostly bull**** talk about fragmentation, we actively contributed to a break in the platform, no matter how small. That’s not a good thing :X People SHOULD know these builds contain hacks, but you’ve surely realized by now that they don’t
******
dookie23 said:
....so until that is rectified, you won't see any build with CM's official stamp of approval.
Click to expand...
Click to collapse
so.... is that ever gonna get rectified
charlie_su1986 said:
so.... is that ever gonna get rectified
Click to expand...
Click to collapse
I wonder what are the hacks he mentioned in the post. Was it the hboot hack, m2sd hack or swap partition...etc?
what is all the fuss about CM9 not releasing a rom officially when we have quite a few talented devs that have already given us the choice of running a near perfect ICS Rom on our nexus one?
EDIT: BCM offers CM9 features, AOKP offers us users the choice of AOKP features and texasice rom has a twist of its own features to. I do not see a problem with CM not releasing an official rom
Kannibalism said:
what is all the fuss about CM9 not releasing a rom officially when we have quite a few talented devs that have already given us the choice of running a near perfect ICS Rom on our nexus one?
EDIT: BCM offers CM9 features, AOKP offers us users the choice of AOKP features and texasice rom has a twist of its own features to. I do not see a problem with CM not releasing an official rom
Click to expand...
Click to collapse
Don't get me wrong, I love seeing the talented devs make awesome progress on kang'ing CM9 and things are coming together nicely. What I am getting at is not whether Cyanogenmod is releasing a CM9 rom officially for the Nexus One, but it's what Ricardo Cerqueira said about the hacks breaking Google CTS. This could mean that apps might not run or worse yet, FC's for no reason.
Now, the real questions are, what are these hacks Ricardo was talking about and is that gonna get rectified?
the hacks they talk about could be small stuff like ta camera fix etc since vendors do not always release new drivers.I would say that the nexus one is using a few hacks for drivers in order to make everything work better
I suspect it's a combination, both messing with HBOOT partition sizes (which is not a *bad* thing, but involves a lot more risk than just flashing a new ROM) and the nasty driver hacks that the poor dev's have had to do to try to working around the lack of a Broadcom driver, since they saw fit to release neither a driver nor sufficient documentation. It's hard to see how either could be overcome for an "official" CM9 release. I feel like it's a bit of a chicken and egg problem; with sufficient dev attention things could probably be brought into acceptable shape, but unofficial ports will never have sufficient dev attention.
Disclaimer: I really appreciate all the work that's been done by everyone on all the community ROMs. It's a hard, often thankless job, whether you're debugging mystery driver issues on an older phone or trying to coordinate a release for dozens of different devices with angry, impatient fans. While I'd love to have an official, flawless ICS ROM, at least we get more love from the community than we did from Google
decoherent said:
I suspect it's a combination, both messing with HBOOT partition sizes (which is not a *bad* thing, but involves a lot more risk than just flashing a new ROM) and the nasty driver hacks that the poor dev's have had to do to try to working around the lack of a Broadcom driver, since they saw fit to release neither a driver nor sufficient documentation. It's hard to see how either could be overcome for an "official" CM9 release. I feel like it's a bit of a chicken and egg problem; with sufficient dev attention things could probably be brought into acceptable shape, but unofficial ports will never have sufficient dev attention.
Disclaimer: I really appreciate all the work that's been done by everyone on all the community ROMs. It's a hard, often thankless job, whether you're debugging mystery driver issues on an older phone or trying to coordinate a release for dozens of different devices with angry, impatient fans. While I'd love to have an official, flawless ICS ROM, at least we get more love from the community than we did from Google
Click to expand...
Click to collapse
I agree with this post i would put the blame on google for not pushing the vendors for the broadcom drivers since android is open source after all but once again great works by our devs and thanks for letting us experience the latest versions of android on our devices
EDIT: i must admit that i have better devices to use than the nexus one but the community keeps me coming back for more
Sent from my Nexus One using xda premium
Will this help development of ICS and JB ROMS? http://www.engadget.com/2012/09/23/nvidia-to-offer-up-documentation-for-tegra-graphics-core/
This should solve the video camera issues and other issues I think.
It's the documentation for the Tegra chips.
Looks like a good news and a bit of light for ICS+JB for our Atrix. Lets keep waiting...
No idea, but good find nevertheless.
Assuming this is released, what else will be needed to release a stable CM9?
It really depends on whats is going to be released. We don't know if its going to be useful yet.
Sent from my MB860 using xda app-developers app
Yeah it will help even to make better kernels, is a shame that my Atrix touchscreen died totally two days ago (thread reported will move soon, does not belong here).
RAFAMP said:
Assuming this is released, what else will be needed to release a stable CM9?
Click to expand...
Click to collapse
Once Tegra2 graphic driver source is released, Atrix devs then just simply update and compile the expecting module (.ko file) to put into the kernel of their roms
hainguyen273 said:
Once Tegra2 graphic driver source is released, Atrix devs then just simply update and compile the expecting module (.ko file) to put into the kernel of their roms
Click to expand...
Click to collapse
Thank you for your replies, guys!
So, with the graphics drivers into the kernel we would get 100% working roms?
RAFAMP said:
Thank you for your replies, guys!
So, with the graphics drivers into the kernel we would get 100% working roms?
Click to expand...
Click to collapse
Yes.
fviero said:
Yes.
Click to expand...
Click to collapse
I hope it's soon then!
hainguyen273 said:
Once Tegra2 graphic driver source is released, Atrix devs then just simply update and compile the expecting module (.ko file) to put into the kernel of their roms
Click to expand...
Click to collapse
I'm not particularly knowledgable about the ins and outs of Nvidia's modules so I might be wrong here, but I seem to recall a dev on this forum saying that is wasn't just a matter of the binaries being compiled against a different kernel (which could be worked around if it was just version checking), but that it depends upon functionality that only exists in newer kernel versions.
If somebody on this forum were skilled enough/had the time to donate to port the Nvidia 3.1.10 sources to the Atrix, we could have fully functional ICS/JB today. But it's not reasonable to expect the few skilled kernel devs here to make up for Motorola's slack.
Over in the One X forum, richardtrip has ported the reference 3.1.10 kernel using only a few bits of hTC code for the camera, so it is certainly possible for somebody without 'inside knowledge' to do, but it has taken him months of hard work. (we're on 2.6.39 'till hTC's official jellybean drops, which uses a 3.1.10 kernel anyway)
Well.. there is still the matter of the fingerprint scanner beyond the kernel. But we can't get too greedy now can we?
thantos said:
Well.. there is still the matter of the fingerprint scanner beyond the kernel. But we can't get too greedy now can we?
Click to expand...
Click to collapse
The phone would probably be functional without a fingerprint driver, though.
This is not kernel module source they are releasing; they are just saying they are willing to provide more information to the opensource community. NVIDIA has recently indicated they may provide documentation to those working on the nouveau drivers (opensource NVIDIA PC drivers); under an NDA. Meaning that they will provide the documentation to those that work on the opensource driver but not allow the information to be shared. For this to be helpful we would need the documentation provided to someone who is working on opensource Tegra drivers; which I do not believe there is anyone. So this would probably be picked up by those working on the nouveau drivers. Best case if all the information is provided and they decide to work on it it would probably be at least a year before we would have anything stable for use.
thantos said:
Well.. there is still the matter of the fingerprint scanner beyond the kernel. But we can't get too greedy now can we?
Click to expand...
Click to collapse
Yeah, same for the lapdock.
Enviado desde mi MB860 usando Tapatalk 2