Weekly Edition
Return to the Distributions page
| |||||||||||||
Android 4.0 source released
It has happened: the source for Android 4.0.1 ("ice cream sandwich") is being
pushed to the repositories. "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.)" Anxious
downloaders should try to wait, though, until the Android folks have
signaled that the push is complete.
(Log in to post comments)
Android 4.0 source released Posted Nov 14, 2011 23:04 UTC (Mon) by alogghe (subscriber, #6661) [Link]
Very happy to see this.
Regardless of the reasoning, not putting the correct release tags in for Honeycomb is just rude.
That being said, I also hope that noone wastes a moment with Honeycomb.
I'm very much looking forward to the awesome cyanogenmod team fixing Ice Cream Sandwich for us. Cyanogen 2.3 is a really nice Android.
Android 4.0 source released Posted Nov 14, 2011 23:23 UTC (Mon) by tbird20d (subscriber, #1901) [Link]
If you understand the rationale for not releasing the Honeycomb source, not tagging it makes sense. Google has been fighting the perception of fragmentation, and they really didn't want implementations with half-baked APIs out there (with individual vendors fixing honeycomb issues differently). So yes, there should be no good reason for anyone to use Honeycomb now that ICS is out.
Android 4.0 source released Posted Nov 14, 2011 23:27 UTC (Mon) by josh (subscriber, #17465) [Link]
At this point, with ICS published, why would anyone use Honeycomb except as a means of working with existing devices running Honeycomb without doing a full upgrade? And in that case, having the tags for Honeycomb would help.
Android 4.0 source released Posted Nov 14, 2011 23:42 UTC (Mon) by mikachu (guest, #5333) [Link]
it appears that the manifest repo has a commit with manifest files pointing to explicit sha1s in each project for 3.1 and 3.2, the files are removed again in the most recent commit.
Android 4.0 source released Posted Nov 17, 2011 2:50 UTC (Thu) by dw (subscriber, #12017) [Link]
Any chance of you tarring up the relevant files, or your manifest.git? Can't find any references in the current repo.
Android 4.0 source released Posted Nov 14, 2011 23:52 UTC (Mon) by shmerl (guest, #65921) [Link]
That rationale as well as not making tags aren't justified anyway from open source perspective, so it is rude.
Android 4.0 source released Posted Nov 15, 2011 1:57 UTC (Tue) by jcm (subscriber, #18262) [Link]
It's awesome actually. It's Google taking a leadership role in its own project. Google's code is Google's to do with as it pleases. It's Open Source, it's not GPL. They want to promote stable ABIs and compatibility and good for them. Honestly, some are never going to be satisfied until every git pull comes with a $100 Android Market gift certificate personally delivered by Page and Brin, along with a lifesize replica of the Android lawn furniture. Then the complaint will be $100 isn't enough.
Android 4.0 source released Posted Nov 15, 2011 8:35 UTC (Tue) by jbv (guest, #66170) [Link]
What? Are they only gonna give us $100 for each pull? That's
ridiculous!
Android 4.0 source released Posted Nov 15, 2011 13:05 UTC (Tue) by clump (subscriber, #27801) [Link]
An open source project that delays source release and then takes steps to make it harder to find the source (Gingerbread) is "taking leadership"?
Android 4.0 source released Posted Nov 15, 2011 13:35 UTC (Tue) by jjs (guest, #10315) [Link]
What delay? They said they would release it when the Google Nexus came out (1st device with ICS) and they did.
Even the GPL does NOT require releasing source before you distribute the binary. And most of ICS (and most of all Android) is not under the GPL, but instead the Apache license (which does NOT mandate source release).
Android 4.0 source released Posted Nov 15, 2011 14:32 UTC (Tue) by rvfh (subscriber, #31018) [Link]
I understand that you want to make things clear, but unfortunately you are fighting people who want to be right when they say Google is bad, no matter that the whole source code for all Android releases is now available from Google (Honeycomb being in Ice Cream Sandwich's history).
I do not always agree with the decisions Google takes on Android, but I fail to see how people can complain about their code releases. They are barking at the wrong tree altogether, when not biting the hand that feeds them.
I have only two words to add: Thanks Google!
Android 4.0 source released Posted Nov 15, 2011 16:40 UTC (Tue) by tajyrink (subscriber, #2750) [Link]
The comment was answering a quite confused post about taking leadership and saying apparently something that open source means closed development (and that open source "is not GPL"), so the comment was merely pointing out that maybe "taking leadership" was not really to the point.
The delay is the delay where Android is not an open project but a code dump, but Google also admits this. Some people would like Android to be an open project so that they could participate into it and help shape its future. Meanwhile, it's more likely that GNU userspace + Linux + freedesktop.org continues to evolve as a competitor to Android than that Android itself would become an open project.
Android 4.0 source released Posted Nov 15, 2011 17:25 UTC (Tue) by jcm (subscriber, #18262) [Link]
If you're referring to what I said, I stand by it. Google is taking leadership because they realize that worse than not releasing the code sooner is platform fragmentation caused by people taking their release and inflicting incompatible changes on it. I also did not say Open Source is not GPL, I said that Android is not released under the GPL. They are free to decide when they publish their own code, and under what terms.
I actually think Google is being very pragmatic. Their heart is in the right place when it comes to releasing the code, but they are trying to avoid the zoo that will result if there is too much flexibility for others to create a giant moving target. When users install software from the Market, it needs to "just work". This is where Google have an actual *platform*.
So far we have two failures... Posted Nov 15, 2011 18:27 UTC (Tue) by khim (subscriber, #9252) [Link] Meanwhile, it's more likely that GNU userspace + Linux + freedesktop.org continues to evolve as a competitor to Android than that Android itself would become an open project. We'll see. So far the tack record is not great: failure after failure. I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader. Well, may be KDE - end even then it's leadership is questionable. Significantly more often open project is born as fork of cathedral project (like GCC, X.org, or OpenOffice.org) when said cathedral is slowed down for one reason or another. So my bet will be with CyanogenMod or some other alternative version of Android rather then "GNU userspace + Linux + freedesktop.org".
So far we have two failures... Posted Nov 15, 2011 20:21 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Python and Perl? They had a rather open model, though they have their BDFLs.
Perl is great example... Posted Nov 15, 2011 21:32 UTC (Tue) by khim (subscriber, #9252) [Link] Well, Perl and Python actually show my point quite nicely. Even major changes (like Perl4 to Perl5) were done quickly and efficiently when development was driven by a single person (or small tightly-knit team). When Larry decided to do next step using "bazaar approach"... the result was unmitigated disaster. Note that while python2 to python3 transition is not as smooth as many hoped it's still goes much better. When project is mature enough bazaar development can work just fine (there are numerous examples) but still major refactorings must be done in cathedral manner. Bazaar can fix things, but to create something new you need master. Someone who may say: "no, we will not do X or Y - this is outside of scope of this work". Otherwise feuterism makes advances in development so slow that project either never reaches the "release" state or if it ever does it produces useless chimera (because there are thousand features out of which may be 10% works as advertised, 50% works poorly and the rest are just confusing everyone because noone is sure what they were supposed to do). Of course if you do have a release and the base is robust you can start adding features (this is where bazaar shines), but BDFL is still good to have around because otherwise features will be added in half-backed state which can eventually kill the project anyway (because at some point features are so intermixed that you can not add anything to this mess). Some projects break apart at this stage, some decide to "reboot the franchise" (like GNOME, KDE, or Netscape/Mozilla/Phoenix^WFirebirn^WFirefox), some do the hard thing and actually clean the code instead (Linux kernel is good example, GCC developers are trying to do that for last few years, LibreOffice is now enthusiastically does that too). It's be interesting to compare fate of "rebooters" to fate of "cleaners" but we don't have enough projects to actually make a good comparison: this is fate of large projects and they all are too unique for the stats to say anything definitive.
Perl is great example... Posted Nov 16, 2011 9:48 UTC (Wed) by dgm (subscriber, #49227) [Link]
The two styles (Cathedral and Bazaar) serve different goals.
Cathedral, that is, one or a few directors and many workers, is the best to start because is the fastest way to get somewhere, when that "somewhere" is well defined. It also requires less resources. The requisite is, obviously, that the leader knows where he wants to go. It also
Bazaar is great for exploration when there's no defined destination. In this style projects usually take a long time to reach anything in particular, but in the mean time many options are tested. It's main benefit is that it's safer in terms of preventing choosing the wrong destination, but also that sometimes unexpected gold is found in an apparent minor branch.
So far we have two failures... Posted Nov 16, 2011 6:41 UTC (Wed) by tajyrink (subscriber, #2750) [Link]
To jcm: ok, now your wording is much clearer. The biggest confusing part was the place where the words seemed to put open source somehow against GPL, and even though GPL says nothing about requiring open project/governance either.
To khim: The free/open stack itself is not a failure, the smoothest and most innovative mobile phone of 2011 (Nokia N9) was made with the stack. But more importantly: I don't mean the platform couldn't or shouldn't be strictly controlled if companies don't get (and/or want) open governance done right, but that it would be made up of pieces mostly done in open projects instead of one gigantic non-open project like Android put on top of Linux kernel. The platform and its app story needs to be something clear, but it doesn't automatically mean that the components, especially lower level, of the platform should be developed behind closed doors.
So again, Linux + GNU basic tools + freedesktop.org + Qt/EFL/GTK as building blocks of the platform is much better for FLOSS in general than Android (even though Android is a very good thing as well - I'm just discussing, not bad-mouthing Android), even if the platform itself would be very strictly controlled. MeeGo.com was actually very non-open in parts, managed by Intel internally, despite the promises. WebOS was very closed development but freedesktop.org stack, it didn't fly either but not because of these technical reasons. I don't doubt Tizen will be different, and it does not need be. Tizen at least seems to have promises that vendors can do their own variations of the stack, contributing to various pieces of open projects, as long as they fulfill the app story as is. So Samsung can push Enlightenment, others can push Qt, etc. Diversity and non-fragmentation at the same time, while keeping truly open middleware projects competing against each other.
Of course it might go in any direction in the end, but I'm not here to make predictions.
So far we have two failures... Posted Nov 16, 2011 6:53 UTC (Wed) by jcm (subscriber, #18262) [Link]
Actually, I think Android will wind up doing the most for FLOSS. It will put the software in the hands of millions of actual users and ensure a standards based, stable platform. At the same time more purist FLOSS projects will look at Android and say "hey, wait, why is that working so well?", and after accounting for the size of Google, etc. they might realize that the platform standardization angle is why Android is so successful after all. I think both will ultimately learn from each other. Google is not evil, Google is a big corporation in the business of making money and they know how to do that while offering products based on Open Source that consumers will use.
So far we have two failures... Posted Nov 16, 2011 9:04 UTC (Wed) by tajyrink (subscriber, #2750) [Link]
Yes, it might be so, and at least it does a huge promotion of Linux the kernel. Over time Android as a project probably also continues to improve, and can be eventually be truly forked if it gets mature, the modding communities continue to get larger, but Google won't open its governance.
There's also risk that Android has problems lurking in its approach (throwing everything away from top of Linux kernel and not co-operating with other similar projects) and Android goes away, but let's hope it's not so.
Also possible would be that parts of Android would be separated into components of their own, usable by other projects. For example if their mobile phone / modem stuff would triumph over oFono/FSO.
Ah, N9... Posted Nov 16, 2011 7:22 UTC (Wed) by khim (subscriber, #9252) [Link] To khim: The free/open stack itself is not a failure, the smoothest and most innovative mobile phone of 2011 (Nokia N9) was made with the stack. Bwa-ha-ha. Sorry, but no. Nokia wanted to sugar-coat it's failure so they took Maemo, replaced open-source UI with proprietary swipe interface and marketed it under Meego name. N9 is cool phone but it's most definitely not the success of "GNU userspace + Linux + freedesktop.org" or even remotely similar. And it's "last one of the kind" anyway. You can as well say that MacOS X is real triumph of GNU... Tizen at least seems to have promises that vendors can do their own variations of the stack, contributing to various pieces of open projects, as long as they fulfill the app story as is. MeeGo pushed the same story - and look how well it flew. So Samsung can push Enlightenment, others can push Qt, etc. In other words: you'll not have a compatible UI and you'll have repeat of "Linux Desktop" story all over again. Diversity and non-fragmentation at the same time, while keeping truly open middleware projects competing against each other. This is pipe-dream: noone was able to produce anything like that so far. Either you have diversity and fragmentation which attracts tiny slice of market or you have large market share - and diversity then happens too, but it's in individual applications, not in OS variations. Of course it might go in any direction in the end, but I'm not here to make predictions. Well, I am. My crystal ball is cloudy today, but I can see only two possibilities:
Ah, N9... Posted Nov 16, 2011 8:56 UTC (Wed) by tajyrink (subscriber, #2750) [Link]
Again I find it quite "forum chit chat" level of discussion to argue with you, but to each one of your replies my answer is more or less "you're wrong": N9 is GNU userspace + Linux + freedesktop.org (X, bluez, pulse, gstreamer, etc) + Qt + MeeGo Touch framework, all open source, with proprietary compositor and applications. Can be made by someone else on the same basis, and Nemo Mobile basic UI by the community is already quite nice and smooth - hopefully some vendor would do it as well. Comparison to MacOS X is pure trolling.
MeeGo did not push the same story. Compatible UI comes from the app story API and its selected (single) toolkit, not the system toolkit or eg. compositor technology. And yes I've noticed you're always ready for predictions.
So far we have two failures... Posted Nov 16, 2011 10:02 UTC (Wed) by spaetz (subscriber, #32870) [Link]
> We'll see. So far the tack record is not great: failure after failure.
Others have already commented on the fact that Meego has not been an "open project" at all. As for OpenMoko, are you surprised that a technologically inferior geek phone did not conquer the masses?
> I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader. Well, may be KDE - end even then it's leadership is questionable.
Apache? Samba? GTK, Gnome (well for some :-))? There are plenty of examples of both failures and succeses, so I am not sure how useful it is to just mention a few as proof.
Hmm... Posted Nov 16, 2011 13:04 UTC (Wed) by khim (subscriber, #9252) [Link] Apache? Fork of the most popular server. Samba? This is borderline case: at the time of The Cathedral and the Bazaar it was already developed by large group of people - but then later rewrites (Samba3, Samba4) were done in quite Cathedral fashion. GTK? Similar: initial version was developed buy a couple of guys for their own need and when bazaar style was adopted it was quite established. There are plenty of examples of both failures and succeses, so I am not sure how useful it is to just mention a few as proof. Actually I'll be interested in seeing at least one "success story". Most successful projects which are currently developed in bazaar model were initially developed in cathedral manner and only switched to bazaar model when they were well-established and popular.
Hmm... Posted Nov 16, 2011 13:20 UTC (Wed) by spaetz (subscriber, #32870) [Link]
Seems we just have different definitions of what cathedral and what bazaar is:
You mean by "cathedral" that most code comes from few people. If that is your definition of cathedral I concur, as most if not all projects have 90% of their code written by 10% of the contributors.
I would characterize a Project as a bazaar model that is dominated by a few core coders (who by contributing most of the code, determine most of the architecture), but which is willing to listen and to react to its community, and which is willing to take patches from the outside. Bazaar relates to 2 aspects, transparency (can look) and accessibility (can touch) in my book. If a project exposes all its dirty laundry via public email lists (see Apache's "if it's not in an email it doesn't exist" mantra), that is a bazaar aspect.
So in the end, this boils down to a discussion of how you exactly define cathedral-style :-).
the Elephant in the room Posted Nov 16, 2011 18:51 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
what about the linux kernel?
Also Cathedral vs Bazaar has less to do with the number of people who are writing the code than it has to do with the barrier to entry for new people writing code (who is allowed to submit code), visibility (how hard is it for someone new to find out what's happening), and to some extent how open the project is to suggestions from outsiders (but this is the hardest part to objectively evaluate)
Hmm... Posted Nov 16, 2011 23:39 UTC (Wed) by jra (subscriber, #55261) [Link]
"but then later rewrites (Samba3, Samba4) were done in quite Cathedral fashion."
This is not true. Whilst we have architects who know particular subsystems best, the code is still open and hacked on at will by pretty much everyone.
Jeremy.
So far we have two failures... Posted Nov 16, 2011 20:39 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] I'm not sure I can name open-source project of sizable size which started as open project and evolved to become leader. Linus Torvalds might be able to point out a couple. The Linux kernel is a very good example of a project that started out in bazaar mode and developed to become a real leader. GIT is another great example. Significantly more often open project is born as fork of cathedral project (like GCC, X.org, or OpenOffice.org) when said cathedral is slowed down for one reason or another. The obvious reason for a cathedral style project to slow down is because something happens to the architect. Top-down management helps to provide focus for the project, but the focus is only as good as the person at the top. If the project leader has a clear, good idea of where the project should go, having strong direction will help to get the project there. But if the leader gets bored or distracted, the project will lose direction. If the leader gets off track with a crazy idea, the project will go off track and focus on that crazy idea. A bazaar project has the opposite situation. There isn't a single voice telling people what to do, so people are more or less free to pick their own interest. That means you don't have a single clear direction, but it also means the project can't get sidetracked by a single person's mistake. It's good if you have a lot of obvious work to do, like fixing bugs or writing a bunch of drivers for diverse hardware, where individual coders can pursue their personal interests and still add obvious value to the project. My impression is that the very best projects have a mix of the two modes going on. They have a strong, but often fairly small, core that can push forward new ideas. The core often replaces a single architect with a formal or informal steering committee to avoid the risk of a single leader getting distracted, burned-out, or lost on a tangent. Outside that group, they have a larger set of people who are working on cleaning up and polishing the work done by the core. They take care of things like fixing bugs, writing drivers, translating documentation, creating artwork, etc.
Android 4.0 source released Posted Nov 17, 2011 13:58 UTC (Thu) by jjs (guest, #10315) [Link]
> ome people would like Android to be an open project so that they could participate into it and help shape its future.
Many would, and I would. Cyanogenmod is actually trying to do that. However, in terms of what Google is doing, they made public statements and promises. They carried out those statements. So "delay" is NOT what happened. Delay would be them not delivering ICS.
Whether it's leadership is slightly different, but I point out they ARE doing more than most companies - we might want to be more involved, but at least they ARE dumping the code.
Android 4.0 source released Posted Nov 15, 2011 14:33 UTC (Tue) by clump (subscriber, #27801) [Link]
You might wish to re-read my comment and the thread it pertains to.
Android 4.0 source released Posted Nov 15, 2011 17:20 UTC (Tue) by marcH (subscriber, #57642) [Link]
> Honestly, some are never going to be satisfied until every git pull comes with a $100 Android Market gift certificate personally delivered by Page and Brin
+1
I guess the same people would complain about dirty carpets if they were offered a car for christmas.
Only 5 years ago, anyone pretending such a successful system would be available as open source some day would have been laughed at. Well done Google.
Android 4.0 source released Posted Nov 15, 2011 0:22 UTC (Tue) by tdwebste (guest, #18154) [Link]
"with individual vendors fixing honeycomb issues differently"
There is a widely used class of licenses, gpl, that requires all contributors to share their changes. With this license individual vendors cannot fragment the code keeping their improvements private.
Android 4.0 source released Posted Nov 15, 2011 0:46 UTC (Tue) by tbird20d (subscriber, #1901) [Link]
The fragmentation issue wasn't whether the changes would be kept private. It was whether disparate tablet manufacturers (particular non-partners) would create a fragmented ABI landscape for Android applications, due to the immaturity of the code base. This was a real possibility that was precluded by holding off on releasing the source.
Android 4.0 source released Posted Nov 15, 2011 17:01 UTC (Tue) by cwillu (subscriber, #67268) [Link]
The GPl doesn't do much to prevent fragmentation, it just makes it possible to fix it eventually. As the ongoing ARM cleanup in the kernel demonstrates, that's still a labour intensive process.
Android 4.0 source released Posted Nov 15, 2011 17:50 UTC (Tue) by ajross (subscriber, #4563) [Link]
I don't buy that at all. There are devices in the wild running that code, and we need to use forensics to figure out what it is? Thinking back a few years: consider if Red Hat had never made the source of its forked "2.96" gcc available and just told you to figure it out from the FSF source history. Would *that* be acceptable?
Mmm... Why not? Posted Nov 15, 2011 18:34 UTC (Tue) by khim (subscriber, #9252) [Link] Thinking back a few years: consider if Red Hat had never made the source of its forked "2.96" gcc available and just told you to figure it out from the FSF source history. Would *that* be acceptable? Great example, thanks! How many users do you know who successfully used "gcc 2.96" sources for anything after gcc 3.x release? In time between 2.96 binary release and gcc 3.x release? Well, it was useful on rare occasions. Later? It was just a dead code which hurt people who knew nothing about this fiasco and tried to use it in production instead of gcc 3.x (or gcc 2.95 for the ones who needed stability).
Android 4.0 source released Posted Nov 15, 2011 22:09 UTC (Tue) by anselm (subscriber, #2796) [Link] GCC is under the GPL, which means that people who distribute binaries of GCC forks must also supply the corresponding source code. Android, on the other hand, is almost exclusively not under the GPL, so no such obligation exists on the part of Google and its partners (the handset manufacturers). Google is fairly diligent about publishing source for those parts of Android that they adopted from third parties under the GPL (like the Linux kernel).
Android 4.0 source released Posted Nov 15, 2011 23:44 UTC (Tue) by ajross (subscriber, #4563) [Link]
Agreed, but that's not really the point. My point was that Red Hat shipped a compiler based off of FSF source, but it was a snapshot that didn't correspond to an actual release. So while you could see the source code in the FSF tree, you'd be SOL if you wanted to track a bug (or whatever) in the compiler based on that alone. Obviously Red Hat did ship source to their compiler (and the GPL required it), but if they didn't, it would have been ... rude, no?
Google has products in the field running software they don't want to support. That's just a mess, and hiding the release tags doesn't make it less so.
Android 4.0 source released Posted Nov 16, 2011 0:01 UTC (Wed) by anselm (subscriber, #2796) [Link] It's arguably not Google's job to support these devices, but the device makers'. It is they who did put the devices in the field, not Google. Whether the manufacturers are keen on doing more than they would do with most other, and especially non-Android, devices they sell (i.e., nothing) is of course anybody's guess. One gets the impression that Google, retrospectively, would rather Honeycomb had never happened; not making it straightforward to find out exactly what it consists of is perhaps Google's way of encouraging everybody and especially the device manufacturers to upgrade to Ice Cream Sandwich. I've heard that, resource-wise, ICS is supposed to run on any device that can run Gingerbread, which includes a large number of not-quite-new phones, so this shouldn't be a physical impossibility.
It's actually similar to gcc 2.96 situation... Posted Nov 16, 2011 6:58 UTC (Wed) by khim (subscriber, #9252) [Link] One gets the impression that Google, retrospectively, would rather Honeycomb had never happened Well, it's like RedHat and gcc 2.96: they don't want to support it (even Cygnus people often refused to answer questions about gcc 2.96... and Cygnus was RedHat subsidiary at this point), but they needed it because gcc 2.95 had such a poor C++ support. Honeycomb is the same way: Google needed it (because otherwise the whole year would be lost), but now they want to switch to ICS as fast as possible. Both "fiascos" come from the good understanding of the facts of life. Namely the fact that "it'll be ready when it'll be ready" is not the best long-term strategy: sure, the initial release will be better but mindshare will be lost and eventually it'll lead to stagnation of the project.
Android 4.0 source released Posted Nov 15, 2011 1:07 UTC (Tue) by leif81 (guest, #75132) [Link]
Rude indeed. From an academic/historical it would be very interesting to be able to diff parts of the source between honeycomb and ics. I'm sure someone will figure out the sha1 for honeycomb though.
Android 4.0 source released Posted Nov 15, 2011 18:55 UTC (Tue) by ajross (subscriber, #4563) [Link]
Or just from the perspective of someone wanting to hack their Xoom. Again, there are real devices running this code. It's not an academic problem.
Android 4.0 source released Posted Nov 15, 2011 22:01 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
just upgrade them to ICS
Android 4.0 source released Posted Nov 15, 2011 6:15 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
Are you _really_ sure that the honeycomb code is in this tree and just not tagged?
it's very possible that some of the honeycomb code was dead-end and instead of developing from that code to ICS they went back to a prior point in the tree and branched from there (in fact, from the explanations of how honeycomb was a quick-n-dirty hack that they didn't want to have people developing from, I could easily see google going back to a point prior to honeycomb and developing cleanly from there rather than working to fix up the hacks)
Android 4.0 source released Posted Nov 16, 2011 4:47 UTC (Wed) by swetland (subscriber, #63414) [Link]
The ICS tree is a direct descendant from the HC tree.
Android 4.0 source released Posted Nov 15, 2011 0:07 UTC (Tue) by drag (subscriber, #31333) [Link]
Nice. Looking forward to running on my phone.
Android 4.0 source released Posted Nov 16, 2011 10:14 UTC (Wed) by oever (subscriber, #987) [Link]
I would love to use it on my desktop. It is really a shame that Android applications cannot simply run on the desktop. The whole stack would be much more attractive if it was as easy to do this as it is with QtCreator for the Linux, Mac, Windows and MeeGo.
At the moment, the best strategy to write code that runs on desktops and mobile phones is to use a combination of C/C++ for the core logic on top of whatever the phone/desktop requires. If the C/C++ is written nicely enough it can even be converted to JavaScript and run in a webpage.
Android 4.0 source released Posted Nov 15, 2011 0:36 UTC (Tue) by yokem_55 (subscriber, #10498) [Link] OMG. Skyrim, Ice Cream Sandwich source, Linux
Android 4.0 source released Posted Nov 15, 2011 6:33 UTC (Tue) by karim (subscriber, #114) [Link]
... since the story was posted, JBQ did post a message saying that people can now sync at will: https://groups.google.com/group/android-building/browse_t...
I've finally got my copy and have started toying around. The first and most glaring observation for now is that it took about 55 min to build. Gingerbread takes 20min on the same system ...
Let the fun begin
Android 4.0 source released Posted Nov 15, 2011 13:54 UTC (Tue) by aorth (subscriber, #55260) [Link]
Curious about the specs on your build system. For posterity's sake :)
Android 4.0 source released Posted Nov 15, 2011 18:21 UTC (Tue) by karim (subscriber, #114) [Link]
Lenovo W520 (workstation replacement): Quad-core i7 w/ Hyper-Threading, 8GB or RAM and RAID-1 disks (real disks, not solid-state.) It's the best-performing Lenovo I could find.
Android 4.0 source released Posted Nov 16, 2011 18:43 UTC (Wed) by xxiao (subscriber, #9631) [Link]
it's 32 minutes here on i7 4-core(2670) with 8GB memory, i used make -j8 to do it.
it boots up on pandaboard well
|
|||||||||||||