This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Google, a collaborative effort to improve the coverage of Google and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.GoogleWikipedia:WikiProject GoogleTemplate:WikiProject GoogleGoogle articles
"Enhancements wished for by the Android community" section
Hi User931, please consider the guidelines in WP:TOPIC. The topic for this page is the actual version history of Android, not enhancements that may or may not be included in future versions. The Android version history is obviously going to get a lot longer so we need to try to keep this article short and to the point. If you would like to document these enhancement requests please consider starting a separate article. Thanks. Dcxf (talk) 21:18, 1 June 2011 (UTC)[reply]
I have given you a reason as to why I removed it and yet you have seem to ignored it and persisted. Create a new subsection under Android 4.0 and elaborate the security issue, it does not below in the feature list as it is NOT a feature that was intended by Google - obviously. All we are doing is keeping Wikipedia in an encyclopedic state. YuMaNuMa (talk) 22:45, 13 November 2011 (UTC)[reply]
The flaw does not render the feature worthless, what are the odds that someone who has stolen the phone will have an ID image of your face lying around. Regardless, this does NOT below in the feature section, asserting it as useless is your own opinion and was not reflect in the cited source. If the thief was keen, he would have wiped the ROM or factory reset from recovery. YuMaNuMa (talk) 23:48, 13 November 2011 (UTC)[reply]
If the thief was smart, he wouldn't steal a device which is remotely trackable (and in addition, can be remotely wiped and completely disabled) by the manufacturer once a police action has been filed, which essentially is a guaranteed one-way-ticket to prison rape. Not only is theft via the face recognition software impractical, it's also stupid in the first place. -- 李博杰 | —Talkcontribsemail01:44, 14 November 2011 (UTC)[reply]
I won't even bother arguing this because it has just crossed beyond stupidity. Stop trying to argue an invalid point and accept defeat, not only is your first point extremely, extremely, extremely impractical but your 2nd point is completely incorrect as manufacturer can disable and track phones regardless of whether a SIM is in place (of course local law and regulations apply but in most countries this can be done as long as the phone is connected to a network, I'm unsure of the specifies but I'm certain it can be done) YuMaNuMa (talk) 07:25, 14 November 2011 (UTC)[reply]
It's also one of the most stupid ideas I've ever heard, in that you're stealing a phone, but you can't use it as a phone. You can't sell it either. Anyway, this discussion is essentially going nowhere, Wikipedia is not a WP:FORUM, and we are essentially done here. Any further talk is just beating a dead horse. -- 李博杰 | —Talkcontribsemail12:26, 14 November 2011 (UTC)[reply]
We are talking about information stealing, not phone stealing. That you guys do not understand that it is insecure does not mean that it is secure. — Preceding unsigned comment added by 2.137.175.250 (talk) 07:13, 15 November 2011 (UTC)[reply]
The idea that someone with something to hide using face recognition as authentication is unlikely. Consider the two individuals:
A CIA executive officer with a laptop full of state secrets
A 16 year old bimbo girl who hangs with all the hot boys at school everyday
which of the two is likely to have:
A 6-character lowercase alphabetic password?
A 32-character passphrase with upper and lower case alphanumeric and symbol characters, changed every three days, a hard drive encrypted using TrueCrypt and 50g of thermite attached to the interior of the hard drive, ignitable by an magnesium fuse hooked up to a remote switch via a specific radio frequency?
Simply put, if you have something to hide, be it company secrets or state secrets, you're a complete idiot for using face-rec. If you're a 16 year old bimbo who texts all the hot boys at school, it's a different situation. Different authentication methods cater for different people, and not everyone requires the same level of security. For those who need more security, they use the more secure methods, and for those who don't, they can use the less secure methods (face-rec isn't the only option, you know). You're essentially making mountains out of nothing. This is a non-issue, and this discussion is completely outrageous. Plus, I'm getting the feeling that you are moving the goal posts; now you've changed the topic to data theft, even though you've never mentioned anything even remotely similar before. -- 李博杰 | —Talkcontribsemail07:29, 15 November 2011 (UTC)[reply]
>Why do you guys want to hide this information? Because your additions have either been failing in WP:RS, WP:V, WP:UNDUE (the section was a feature list, not a dumping ground of information), or any other standard Wikipedia policy. >Do you guys work for Google or have any Google special interests? As dictated by Wikipedia's policies, personal attacks are prohibited, and repeat offenses can lead to a block. For the record, I am a Bachelor of Physiotherapy student. I make no money from Google - I don't even own Google shares. >Wikipedia should be objective and not just a company marketing tool. Again, quite an ad hominem on your part against us, and an argument from ignorance. -- 李博杰 | —Talkcontribsemail01:38, 14 November 2011 (UTC)[reply]
Android version history was the original title. Earlier this week a newish editor moved the page without discussion. I don't really like either title, and there doesn't seem to be a standard format for this kind of thing either. – Steel15:46, 19 November 2011 (UTC)[reply]
Has the 4.0.1 changelog been released yet? It seems that the first publicly available ice is version 4.0.1 and any small fixes should obviously be included in the article. YuMaNuMa (talk) 13:44, 21 November 2011 (UTC)[reply]
Version History layout
Is it possible to go back to the table layout that the version history used? It was much easier to read. Also, moving the version history back to the main Android OS page would be nice too.--Jimv1983 (talk) 21:07, 26 November 2011 (UTC)[reply]
Hi, I'm just passing by and I hope this way of leaving comments is ok. I think that we miss a timeline here. It would show the version history in one shot! Consider implementing that, thanks! — Preceding unsigned comment added by 212.198.117.35 (talk) 20:33, 30 June 2012 (UTC)[reply]
Expected future updates
This section is complete speculation, there are no references, just links to blogs and news pages. It is even written "may carry the version number ..." and "Google has not yet officially confirmed this".
Wikipedia is not made for speculation and rumors and this section has no place on Wikipedia. Removing it as the crystal infobox informs you to do: "This article may contain unsourced predictions, speculative material or accounts of events that might not occur. Please help improve it by removing unsourced speculative content." results in constant reverting. Even adding "citation needed" or making it clear to the public that this section is speculation is reverted.
Why especially Jenova20 has this agenda and wants Wikipedia to be his/her rumor blog is very hard to understand. User931 22:19, 30 May 2012
Pushing aside the personal attack there, i did not create the section in question but did restore it after someone else or possibly you (i don't remember) deleted it. Citing WP:Crystal as an excuse to have it deleted is no good when i can use the same policy to justify its inclusion.
So what i've tried to do here and for the last 2 (?) weeks is get you to contribute to a discussion (and now i need you to do it in an adult way) and quit the edit warring. Jenova2020:54, 30 May 2012 (UTC)[reply]
I have a suggestion, why don't you create a new page on wikipedia instead, "wikipedia.com/speculated_android_updates" where you can blog about this without getting disturbed? User931 12:19, 1 June 2012
This section is very speculative and all the product features are simply rumours. The reference used for the features is not a decent (primary) source. I propose the entire "Features" section be removed until there are clearer details surrounding this release of Android. 163.1.120.27 (talk) 18:41, 4 May 2012 (UTC)[reply]
Possible future upgrades is verifiable in reliablish terms and is line with policy predicting events as notable and almost a certainty.
If you want to keep removing the same section then bring it up here as edit warring is unacceptable and it can be avoided. Thanks Jenova2008:28, 8 May 2012 (UTC)[reply]
There are sources. Not at all meaning this to seem rude but can commentors please read the section before you ask questions that could be solved yourselves simply by reading?
I believe that it would be beneficial to the article to have a table of each major Android update (beta, 1, 1.1, 1.5, 1.6, 2.0/2.1, 2.2, 2.3, 3.0, 4.0, 5.0) along with release date such as can be seen on the List of Linux Mint releases page. I believe that this would help clear up some confusion as to the Android release cycle, as many people (including the person who wrote the article used as a reference for Android 5.0's release date) currently believe that there is a 1 year gap between every named version of Android, when history shows that it is closer to 6 months in between each major version. — Preceding unsigned comment added by 173.34.28.208 (talk) 10:36, 8 March 2012 (UTC)[reply]
Edit
Note to article maintainer(s): My last edit has been brewing a bit, so chances are that some of the bits between when I started editing and when I saved (there were several days in-between) might have gotten lost. -Mardus (talk) 20:53, 29 April 2012 (UTC)[reply]
Speculation
Since Jelly Bean is confirmed and cited i've changed the headings:
Jelly Bean is under an "Unreleased updates" heading now.
While Key Lime Pie is under "Expected future updates" since it is sourced somewhat reliably but not due til 2013.
Can i get comment on the refusal of User:User931 to cooperate in an adult and mature manner here discussing changes to the "speculation" he keeps tagging and deleting without discussion? Also a comment on the section in question would be useful. The same user has cited WP:CRYSTAL as a reason to delete even though i can use the same policy to keep the section and most of the content, which is reliably sourced. And discussion as you can see above is just personal attacks. Thanks Jenova2011:18, 1 June 2012 (UTC)[reply]
From what I can see, the next installment of Android has definitely been confirmed, numerous devices that will be released with this installment have also been unofficially announced or possibly leaked however the name Jelly Bean has not been confirmed according to CNET which is considered a reliable source, in addition to that, contrary rumours state that the next installment could be a minor upgrade to 4.1 instead of the expected Android 5.0 upgrade hence to some extent the WP:CRYSTAL can be used as a reason for deletion. YuMaNuMaContrib11:36, 1 June 2012 (UTC)[reply]
There are 2 reliable sources stating the name. ASUS has confirmed the name also and the most recent source added states the version number would likely be 4.1.
The controvertial issues that are unsourced are the name "Key Lime Pie" and all the features both versions would carry, minus a couple from Jelly Bean. Jelly Bean is confirmed from the available sources. Thanks Jenova2012:55, 1 June 2012 (UTC)[reply]
I've looked at the cites you added for Jelly Bean - they seem fairly reliable. As long as those cites remain, there's no reason to delete the info. Michaelmas195712:57, 1 June 2012 (UTC)[reply]
Brilliant. I've left Key Lime Pie tagged then and so that only leaves one other issue of the person who is refusing to cooperate or discuss this...Jenova2014:16, 1 June 2012 (UTC)[reply]
I think I misread your request but anyways, do you have any sources to reference the individuals changes in the expected features column? The sources you have provided confirm the next installment (however, I'm still skeptical) but the expected features list is mostly unsourced and in my opinion, speculative. YuMaNuMaContrib14:55, 1 June 2012 (UTC)[reply]
A lot of it is only assumed from the other 2 links and so speculation. The only thing i think is actually confirmed there is the name and that "majel" is being developed.
So why are you listing asumptions and speculations? Removed it from the article. User931 14:00, 4 June 2012
I'm not listing anything, i just wasn't the one to remove them and you wouldn't either, you removed everything each time instead. It looks good now and lists only the bare minimum, which is all completely sourced. Jenova2018:13, 4 June 2012 (UTC)[reply]
The current information is ridiculous, it doesn't contain any official information nor any information of importance. I'm sure next version will be called jelly bean but thats not the point. The point is that information written on Wikipedia should be backed up by proper and/or official references. I could start a blog, list names of "expected" future Android versions by looking up popular deserts for every letter and then use it as a reference. Thats about the value the current references have. I'm removing the blog post by digitaltrends which contains some form of wish list of features and no references as well as the other from cnet which also lacks any references in it, just one guys opinion. This will result in deletion of Key Lime since it will lack references. Also the reference for Majel is based on anonymous tips sent to, drum roll, another android blog, androidandme.com and will be deleted aswell. User931 22:50, 4 June 2012
It is clear that the next Android will be called Jelly Bean, and it has been confirmed by many apple employees that Jelly Bean will have Assistant, so I believe that the Jelly Bean section as it currently stands is fine. As for the Key Lime Pie update, there is no way to confirm it at ALL, other than by one Verge tipster. The Key Lime information is clear speculation, and should not be included. ҭᴙᴇᴡӌӌ20:56, 4 June 2012 (UTC)[reply]
I agree Trewyy, i'm fine with the deletion of that section. User931, Wikipedia tends to avoid primary sources and so you should familiarise yourself with the appropriate policies. There is No policy that requires us to use only primary and official sources as the opposite is actually true. If it's reliable we can use it. Thanks Jenova2021:01, 4 June 2012 (UTC)[reply]
First I don't see and haven't seen sources in this article from Apple emplyees confirming an assistant, second, it sure would be inappropriate to use a source from Apple for something that relates to Google. User931 23:10, 4 June 2012
User931 if you continue to delete sections without discussing them here i will consider it vandalism since Everyone is agreeing they are sourced and productive and you are going out of your way to fight this without discussing it in a productive way. Jenova2021:12, 4 June 2012 (UTC)[reply]
No, you just don't get it, this is a discussion talk page. SHOW the reference and I will gladly let it stay! User931 23:16, 4 June 2012
I am a volunteer clerk/mediator at Wikipedia:Dispute resolution noticeboard. This RfC was randomly selected[2] for me to look at. I have no connection with this topic (I use Slackware Linux when I have a choice, Windows when I have to, and my phone is a G'zOne Ravine.) Here is my opinion:
There are two issues here, what is allowable in the article and what is best for the article. Just because something is allowed does not make it a good idea.
What is allowed: information about future versions if and only if it is from a reliable source and the source is reported ("X says it will be", not "it will be") and if and only if it is allowable under a strict interpretation of WP:CRYSTAL.
What is best for the article: No information about future versions or features. None. There are plenty of technology blogs out there. Wikipedia should not try to be one of them. Instead, Wikipedia should be an encyclopedia, reporting things that are in the past, not in the future. Not even late-breaking news.
I realize that this in a view that some will disagree with, so I am going to ask for a quick consensus check. Place your name without comments under one of the following, and (optionally) make your comments below.
Report things that are in the past, not in the future
To prevent future incidents as such, I support the inclusion of future versions and expected changes only if it has been directly confirmed by Google - tip-offs or anonymous sources should not be used when verifying expected changes and/or future releases. If an extremely compelling piece of evidence such as a screenshot is released, the blog, author/publisher of a video or article should be included in the prose as well as the citation. YuMaNuMaContrib08:18, 6 June 2012 (UTC)[reply]
I don't particularly agree with having just Google as the verifier here, especially when in this case a lot of the reliable sources lead back to ASUS revealling the name first in front of the entire world media. If Google was producing Android And the sole handsets fine, but the case here is Every handset maker in the world can get access to Android and put it on a phone and so Google is not the only reliable source. The handset maker would be less reliable than Google but they're still reliable when combined with multiple sources and placed in context. Take this whole thing as what it is; 2 people interpreting a policy differently and an edit war because one won't discuss it and continues to edit war. Thanks Jenova2011:49, 6 June 2012 (UTC)[reply]
If handset makers do release information about future releases, I would definitely question their intent, perhaps the purpose of leaking out such information is to garner attention to their future products. If a handset manufacturer is the main source, at least one primary source directly from the manufacturer's website or a quote from a representative should be cited, I would also limit this to some manufacturers that have a special "bond" with Google, since Android is open-source almost anyone can manufacture a phone given that they have the components. YuMaNuMaContrib12:57, 6 June 2012 (UTC)[reply]
Exactly why we shouldn't be using just Google. Example:
Google refuses to name the next version when asked. - As they may well do and have done before.
Motorola announces at the Mobile World Congress the next version of android will be launched on their new feature phone first and be named "Example". - Reliably sourced, there's your motive sorted and it would be well publicised and follows the convention Google already uses for releasing new versions on their "special" phones like the Nexus series. Thanks Jenova2014:17, 6 June 2012 (UTC)[reply]
And just as i pointed out the spotted device running V4.1 has been revealed as a Google sponsored Tablet - A Nexus tablet.
So as usual for a Nexus branded device it will be launched with the next version before anyone else gets it. ASUS was right and i'll add sources in the article. Thanks Jenova2014:56, 11 June 2012 (UTC)[reply]
I'm glad to see that I finally get some support in this issue. I believe a big part of the problem lies in that (probably) young people seems to fail to see the big picture; they seem to take news on blogs as something official when in fact it all comes down to that the person or persons behind blogs generate money from ads on their websites and more so from a high number of visitors. Publishing spectacular news draws people to their websites and therefore generates money. This kind of information as references just doesn't belong belong on Wikipedia. While I do think future features, if properly sourced, can have its place, but only if properly sourced means directly from the company in question - for example today, when Google said that they will bring offline maps to Google maps. Just saying properly sourced is too wide and opens up for different interpretations. Take the Asus "source" discussed above for example, Asus sounds very proper but when you look at it you see that this is not official information from Asus, it is a few words taken out of context from an Asus person during a mobile show/congress. Why is he saying what he is saying? Maybe he doesn't know anything about the next android version and just wants the public to know that Asus will bring products to the market with the next version faster than any other company, to drive sales of Asus products? If he know something about the next Android version, how can he know that Google doesn't change its mind 6 months later and go for Android 4.5 instead? So in the end, it is still speculation because it isn't confirmed by the only proper source in this matter, Google. Therefore I have put my name under "report things that are in the past". If there would be an alternative reading "Report things that are in the future, if sourced from the company of the product" I would choose that one. Also I would like to add that when consensus is reached in this matter, I think this page needs some form of protection to avoid similar issues in the future. User93121:27, 6 June 2012 (UTC)[reply]
Dealing with future releases is an inevitable part of technology articles like this. If more reliable sources are needed, then of course we should find and cite them; but there is little question that Google does intend to release further Android updates. Michaelmas195703:09, 7 June 2012 (UTC)[reply]
I am not too much of an expert on technological matters such as these, nor have I followed the history of Android. However, I checked Cite Number 67 through 71, and did not find the sites, expressly reliable. I also did a quick Google search with the keyword(s) Android 4.1, which yielded no results from any Newspaper, or official Google Blog/site. It is for these reasons that I support reporting things as they are. HarshMujhse baat kijiye(Talk)(Contribs) 15:37, 11 June 2012 (UTC)[reply]
68 + 70 are from The Register, both are reliable sources with knowledge of the topic and editorial oversight from the authors. I cannot vouch for the others as i'm not a regular to their sites but they are reporting on things that either the Asus vice president said or happened at the Mobile World Congress. Before my last edit the article said Jelly bean would be version 5, even though there have been at least 6 sources provided and they all say 4.1 is Jelly bean.
The strange thing is Asus say at the MWC that Jelly bean is version 5 but they're now about to release the Nexus Tablet as Jelly bean in 2-3 weeks (from reference) and they now state it's 4.1...Either they deliberately tried to fool people or they have no idea what they're even doing... Thanks Jenova2015:55, 11 June 2012 (UTC)[reply]
First off, pleasedon't edit the relevant section during this discussion as it undermines what we are doing here. If consensus is reached you may very well go ahead the section. This includes adding references, which I have reverted.
Second, I checked again and Cite Number 70 has no mention of 'Jelly Bean' as the possible version name for Android 4.1, although it does mention that the Asus-made Nexus could be launched in late June.
Third, the site you used as reference that is [www.reghardware.com] has been cited only for Nos. 68 and 70 and have not been used as reliable source anywhere else in the article hence casting into doubt the site's veracity. Now I'm sure that your experience using said site has been utmost reliable but for the purposes of this discussion it merely looks like a claim. Also WP:BALL is fairly clear on this matter "Individual scheduled or expected future events should only be included if the event is notable and almost certain to take place. Dates are not definite until the event actually takes place. If preparation for the event is not already in progress, speculation about it must be well documented." This point in my opinion is not met satisfactorily. --HarshMujhse baat kijiye(Talk)(Contribs) 16:32, 11 June 2012 (UTC)[reply]
And the quote from policy you cite does not support removing a section that is an almost certainly going to take place, just as WP:CRYSTAL says.
Android WILL be updated and so the thing we need to decide on here is what information to include.
I split off the information about "Majel" since that is again an almost certainty since it would be natural progression from the current voice controls of Android and wouldn't take a massive amount of work as there is already a similar dumber function available. This section has no suggested link to 4.1 and should not be linked for the risk of original research without a reliable citation.
So again we're back to text. And If you rule out The Register as reliable then i challenge that as that leaves nothing but a direct reference from Google, which cannot possibly exist since Google could never air this view themselves except on the Google search page, which is of course an impossibility. Thanks Jenova2019:05, 11 June 2012 (UTC)[reply]
I give up and I'm sorry to say, but there is just something fundamentally wrong in the understanding of how Wikipedia works when someone is writing something like this "since that is again an almost certainty since it would be natural progression from the current voice controls of Android and wouldn't take a massive amount of work as there is already a similar dumber function available." in other words, suggesting that information on Wikipedia should be based on reasoning and assumptions by the very people that writes on Wikipedia. Hopefully some moderator will find this and see that everything on this page was perfectly fine and in order a month or so ago. User93123:59, 11 June 2012 (UTC)[reply]
I absolutely agree that the progression from the current version of Android will could go to 4.1 BUT till there is a tangible and reliable reference available, it is still in view of WP policy, speculation. And therefore as the section I cited explicitly mentions, Speculation should be well documented, which it is not; owing to two things:
Only one article The Register mentions that 4.1 will be Jelly Bean and there is another 'related' article there, which says that both the version numbers are a possibility {5.0 and 4.1} and that the next version IS 4.1 could just be rumour.
Now, contrary to what you are convinced of, that 4.1 WILL be Jelly Bean two articles here and here mention that Android 5.0 will be Jelly Bean and NOT 4.1. Therefore, it is premature to label Android 4.1 as Jelly Bean until either (A) You find a direct mention on Google's Blog/Android Blog or site or B A newspaper report suggesting the same. -- HarshMujhse baat kijiye(Talk)(Contribs) 05:58, 12 June 2012 (UTC)[reply]
That's why i added 4.1 yesterday, we have sources mentioning both but only list one, even though the most likely is 4.1 with the spy shots revealled. I support removing both dates or leaving both in as claims by different sources, as they are now i believe. The rest comments on claims made by the sources to include no speculation from us and no original research and is why i moved Majel away from the Jelly Bean section, since it has no link to it but is a separate rumour expected in future (and so possibly doesn't even belong in this article).
OK, so what about making clear they are both rumours? Or do you just support a simple removal of both irrespective of the wording? Thanks Jenova2010:32, 12 June 2012 (UTC)[reply]
No truck, sir! Actually the thing is that IF we include the two versions then the indications which I found in my recent familiarity with Android such as the version released after Jelly Bean is to be Key Lime Pie and then site must have their versions of all 26 alphabets. So no, keep only those versions that have confirmed names and numbers. --HarshMujhse baat kijiye(Talk)(Contribs) 11:43, 12 June 2012 (UTC)[reply]
Or we could make sure there's something for him to see when he gets here?
If you wan't to mock up a reworded paragraph here than Guy Macon can see it when he's online and give his opinion. Thanks Jenova2014:12, 12 June 2012 (UTC)[reply]
Mediator, not Moderator. A Moderator looks at the evidence and makes a decision. A Mediator tries to help you to reach an agreement. (We also enforce Wikipedia policies like WP:V, but that is something every Wikipedia editor should be doing). If asked, I will give an opinion as to what I prefer, but my opinion should not carry any extra weight. --Guy Macon (talk) 16:16, 13 June 2012 (UTC)[reply]
Report things that are in the past, not in the future?
The vote came out like this:
Report things that are in the past, not in the future: 4 votes
Report things that are in the future, if properly sourced: 3 votes
I personally don't like to use the phrase "the consensus is" unless there is at least a 2:1 (66.66..%) ratio in the votes, and I really want to see 3:1 (75%). I am calling this "No Consensus either way". This has been discussed enough that I don't think talking about it further is going to change any minds. And there is no Wikipedia policy violation either way.
I like the removal of Key Lime pie. It wasn't sourced adequately at all and with the removal of the version numbers from Jelly Bean i think that could be an informative, accurate and useful section.
I'm willing to choose the first option however if a future version of Android is to be officially announced by Google, that version should definitely be included in this article after it has been unveiled or even announced. It would be foolish of us to do otherwise. I hesitated to choose the first option as it's a bit ambiguous, I don't see any reason why we shouldn't include something that has been officially announced or unveiled by Google. YuMaNuMaContrib16:28, 13 June 2012 (UTC)[reply]
To me sourcing is a primary concern and therefore I'd rather have no mention of things that are not well-sourced. That being said, I have no objection to reporting things that are sure to occur, if properly and reliably sourced. --HarshMujhse baat kijiye(Talk)(Contribs) 17:33, 13 June 2012 (UTC)[reply]
I agree. The key is whether it is a "sure thing". Some companies announce things that never happen. A lot of them announce that something will ship on a particular day and it ends up being late, but it does happen eventually. To my way of thinking, Wikipedia should ignore the first kind and list the second kind as "future" rather than bothering to give a projected date. Likewise, if a company has a habit of changing the details of a product between announcing and delivering, we probably should avoid listing the (possibly bogus) details. Duke Nukem Forever and GNU Hurd are good examples of what I am taking about. The key point is to only put things in the article if pretty much everybody agrees that they are sure to happen as described. --Guy Macon (talk) 17:46, 13 June 2012 (UTC)[reply]
Here as far as I can tell the next version has been confirmed to be Jelly-Bean but the version number itself is undecided. So, what I suggest is we'll keep that and remove any mention of version numbers. --HarshMujhse baat kijiye(Talk)(Contribs) 20:33, 13 June 2012 (UTC)[reply]
I agree Harsh, while there's no confirmation of version numbers, only "leaks" and rumours - the name has been confirmed. Thanks Jenova2008:55, 14 June 2012 (UTC)[reply]
The title and subject of the article is "Android version history", not "Android version history and future versions". Anything that hasn't been released yet isn't part of the history, so is offtopic. Sticking to this would avoid this same controversy every time a new version is in the offing. If there is well-sourced info about an upcoming new version it could go in the main Android article, where it will probably be more critically assessed as there are more editors watching it. Dcxf (talk) 09:50, 14 June 2012 (UTC)[reply]
Anything that has been announced and substantiated by several reliable sources including one from Google(IMO) is considered history - history of the version includes the announcement details and release, regardless of whether the release has occurred or not the preliminary details of this release should be included. Once the version has been officially release we can include the full detail of the version and remove anything that is considered redundant or unnecessary such as the announcement date and irrelevant pre-release details. Of course the essential information of the announced version would also be added to the main Android article. YuMaNuMaContrib10:13, 14 June 2012 (UTC)[reply]
Note on the vote count, a simple counting of the votes is meaningless on wikipedia, we aren't a democracy WP:NOTDEMOCRACY, one must weigh up the quality of the votes themselves to determine consensus as is stated in WP:RFC. Also, the RfC does not specify exactly what the issue is clearly, I'm not sure where the previous discussion of the issue is, nor the discussion about setting up an RfC, so it is difficult for uninvolved editors to comment. IRWolfie- (talk) 16:42, 14 June 2012 (UTC)[reply]
The top of this section has Guy Macon declaring a "no consensus". Still, what's your opinion as an uninvolved editor? Thanks Jenova2019:14, 14 June 2012 (UTC)[reply]
YuMaNuMaContrib 07:12, 15 June 2012 (UTC) - When handset manufacturers "officially" announce a controversial and speculated Android version for their devices, Google will sure follow suit in either denying or upholding. YuMaNuMaContrib07:12, 15 June 2012 (UTC)[reply]
We just went through this with no consensus just to try again? Stick to reporting facts and not rumours and there won't be any problem. Jelly Bean is already confirmed reliably, just not by Google and so this policy stinks. Frankly it would remove information and rely on messages directly from Google, even if devices go on sale with a new version and Google says nothing for a long while. I support the removal of the update with Majel since it has no link to a version yet. Thanks Jenova2008:53, 15 June 2012 (UTC)[reply]
How about mentioning it in the lede and mentioning the sourced paragraph of how/when/where it was announced (without version numbers) either there or at the bottom where it is now? I think the only thing we really disagree over is the use of only Google as a reliable source. Thanks Jenova2009:52, 15 June 2012 (UTC)[reply]
I only disagree because i don't want us reliant on Google for the entire article, which is what this means from this point. There's also their timing, which could be announcing something well after everyone else. Reliable is reliable, everything else is questionable. Thanks Jenova2011:31, 15 June 2012 (UTC)[reply]
That is no excuse, primary sources are generally to be avoided becuase of issues with bias and this very thing. I don't agree at all with using Google only if there are other highly reliable sources available. Thanks Jenova2013:54, 15 June 2012 (UTC)[reply]
That I agree with, but since the sources weren't as reliable as they should have been we have to do so. Now since User:Jenova20 is the only one here in opposition is it okay if I conclude that consensus is reached and make appropriate changes to the article or should I wait for users who have voted for in the previous vote? --HarshMujhse baat kijiye(Talk)(Contribs) 04:22, 16 June 2012 (UTC)[reply]
Jenova20 "everybody who voted but you" is about as clear as consensus gets. You are going to have to step aside on this one. The good news is that consensus can change, so it might be worthwhile asking again after 3-6 months.
HarshAJ, as a rule you don't need to be concerned about previous votes. Notable exceptions are when the previous vote had many more voters or when you suspect fraud or ballot stuffing of the new vote -- none of which applies here. Go ahead and make appropriate changes to the article, paying attention to the talk page in case someone else objects. --Guy Macon (talk) 11:25, 16 June 2012 (UTC)[reply]
I wouldn't ask again in future because i respect the consensus, i just didn't want agreement on using just Google. As it standds i like the changes to the article now. It has no rumoured version numbers now and says clearly who announced the name - the reader can decide on reliability of the source from that rather than us. Thanks for the work you all put in and feel free to end the RFC Jenova2008:59, 18 June 2012 (UTC)[reply]
So, here we go again. Someone adding:
"In May 2012, both the Galaxy Nexus and the rumored "Nexus 7" tablet were spotted on a benchmarking site running Android builds with the version number 4.1 — which is speculated to be Jelly Bean."
Seriously, the only information left after this whole discussion (due to my deletion because of faulty references) is a line by Asus stating the next version will be named Jelly Bean.. This information is utterly pointless on a page named "Android version history" and Only gives the opportunity for new people to come in and starting this all over again by adding speculation like above once more. IMHO Jelly bean has no place on this page with the incredibly dull information that is currently provided. User93123:48, 18 June 2012 (UTC)[reply]
Then we revert it and point out the cosensus that was built here. Consensus did not agree to remove Jelly Bean though so you're best reverting it to how it was before the last edit. Jenova2021:56, 18 June 2012 (UTC)[reply]
Separate articles
Last week User:Marc Lacoste split off some content from this article into Android Ice Cream Sandwich with a view to having separate articles for each Android release. I reverted this on the basis that Android releases are just incremental updates every 6-9 months, similar to Ubuntu or something, rather than significant discrete updates like Windows releases, and aren't worth talking about. It didn't help that his article was really really bad [3], and I asked him to bring it here for discussion. He decided not to.
Now I'm thinking maybe Android releases do deserve their own articles. They do receive significant media coverage and there's quite a lot that could be written about them beyond the crap tables of changelogs that we have now. I spent 20 minutes hastily drawing up an artist's impression of such an article at User:Steel/ICS. It would probably not be possible to include this much content about each release in one big version history article like this. On the other hand, if people aren't willing to write interesting content about each release we needn't bother, we can't just have 8-9 articles of just changelog tables. I'm on the fence right now as to which way to go, so I'm throwing it up for discussion and maybe someone has ideas here. – Steel13:50, 16 June 2012 (UTC)[reply]
I think there is enough problem as it is keeping this page in good condition with correct references and information. Information about Android seems to bring out the worst when it comes to edits, introducing rumours and speculation as facts and having several separate pages will only contribute to this problem -we would probably see a jelly bean page, key lime page, L-desert page etc. I think it's a better idea then to bring that extra information into this page for each version under a strict frame of sub-categories features, changelog etc. By no means does version history imply that it can only contain changelogs as it is today. But I really think its a bad idea to expand compact good information in the changelog with empty words, just to create a features-section for the sake of it. User93116:01, 16 June 2012 (UTC)[reply]
What does the Windows Phone article(s) do here? Same for iOS. Just follow their convention because eventually it will be a convention and we could end up with them just being remerged into the same article. Besides, each article would be stub-like if we split them. Thanks Jenova2008:55, 18 June 2012 (UTC)[reply]
I do think major revisions deserve their own articles, not only for the software but for the ecosystem around : the V2 era is nexus one likes devices, V3 are tablets and V4 are nexus galaxy and nexus 7 era (V1 are prototypes ;) - like the iPhone 4 and iPhone 4S have each their articles. That's why I included a handsets table in my draft. The User:Steel/ICS is excellent, why not using it? Perhaps it could be grouped with Jelly Bean in a V4 article. --Marc Lacoste (talk) 17:47, 13 July 2012 (UTC)[reply]
link to this placed in See Also at Android OS
I couldn't see just having the link at the excerpt in that article.
I'm not firmly decided ... but the currently disputed wording needs to be improved. If it's mentioned, it should be made clear that the decision to eliminate support is a business one by Adobe to withdraw completely from the mobile space, and has nothing to do with v4.1 itself. --- Barek (talk • contribs) - 00:16, 30 June 2012 (UTC)[reply]
Still, it seems a very important piece of information linked directly to the 4.1 version features or lack thereof (regardless of the origin of the support withdrawal). Browsing Wikipedia and knowing that 4.1 does not support Flash and not finding this information made me feel that this information was withheld on purpose (what purpose)? It can be stressed that it's Adobe's decision, but witholding this information seems very confusing. — Preceding unsigned comment added by 95.143.243.150 (talk) 11:38, 11 September 2012 (UTC)[reply]
From what I can tell based on the article, Google normally sends a completed update to the big companies (Samsung, AT&T, etc.), waits a couple of weeks, then releases the source code for anyone to work with that wants to. In any program or OS, sometimes bugs or other urgent issues appear around the time an update is released, so the team decides to rush to fix it and ship another update ASAP; if they act fast enough, the new update could come out for companies around the same time the community gets the source code for the old one. Xyzzy☥Avatar (talk) 07:16, 30 July 2012 (UTC)[reply]
Android 2.3.4 Features
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please can someone add "* Android Open Accessory support" or similar to the feature list for Gingerbread 2.3.4 . To me it was one of the major new features and is a very important milestone. [4]Techno74 (talk) 11:12, 3 August 2012 (UTC)[reply]
Done Yes? To your liking? The page protection was granted because there was an increase in vandalism on the page. It is temporary but if vandalism starts again at unacceptable levels i'll reapply for page protection. Thanks ツ Jenova20(email)11:27, 3 August 2012 (UTC)[reply]
If you see anything else amiss then add it yourself when page protection ends or ask here. I'll notice and i'll get to work on it. Thanks ツ Jenova20(email)13:13, 10 August 2012 (UTC)[reply]
Links in first paragraph (Cupcake, Donut, etc.)
Hi folks,
I'm too junior to edit this semi-protected page, but it seems to me that the list of versions in the first paragraph have the wrong hyperlinks. It's kind of fun that clicking on "Jelly Bean" takes you to a page on actual jelly beans, but it's not so useful in this context--I'd expect instead an internal link to the section of this page that talks about Android 4.1, i.e. http://en.wikipedia.org/wiki/Android_version_history#Android_4.1.x_Jelly_Bean. Same with the others of course.
Not done - the versions don't have their own articles. they are all in this article as your link shows. The hyperlinks are to the appropriate foods of the same name and it would be pointless to point them all at the same article the reader is already at. Short of finding enough information for individual articles of each name there is nothing else i can do here. :Thanks ツ Jenova20(email)08:19, 13 August 2012 (UTC)[reply]
Change request to 'Android 4.1.x Jelly Bean'
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
At "Android 4.1.x Jelly Bean" there is stated: "Android 4.1 Jelly Bean was released [...] and an OTA update for the Samsung Galaxy Nexus to Android 4.1.1 was released on July 11, 2012, making it the first device to run Jelly Bean.[70]"
But this is not true (Android 4.1.1 is not yet release in an OTA update for the Samsung Galaxy Nexus) and the reference talks only about Nexus 7.
So my request is to please change "Galaxy Nexus" to "Nexus 7".
"Astro" and "Bender" codenames are completely unsourced and should be removed
I've never heard of the "Astro" and "Bender" codenames, and Wikipedia has no citation for them. Googling only finds random forum posts, probably citing wikipedia. Unverifiable "facts" should be removed, right? I'll take the initiative and delete the references. If that's wrong or something, let me know. — Preceding unsigned comment added by 68.39.112.43 (talk) 05:10, 15 September 2012 (UTC)[reply]
Turns out there was a citation earlier, but it linked to a video that didn't say anything about code names, I guess they were hoping no one would check. 68.39.112.43 (talk) 05:21, 15 September 2012 (UTC)[reply]
I have never been happy with listing these codenames alongside 1.0 and 1.1 but also didn't feel like fighting the legions of users who really liked having them there. But yeah removing them completely would be super-duper unless an actual WP:RS is provided. – Steel20:58, 15 September 2012 (UTC)[reply]
I actually reworded the preceding paragraph of Android (operating system) to mention they are internal names only as someone else told me (i don't remember who). I think that's enough really as it's minimal use and the names shouldn't actually be too difficult to cite. They are important and were the precursor to the current publicised names. They may even have been the inspiration for everyone to publically name each of their releases...That's a thinker right?
It seems clear that at some point there was a plan to use robot codenames, and at some point a couple of internal builds were named Astro (Boy?) and Bender. So I don't really have a problem mentioning that. Just as long as there's no claim that 1.0 = Astro or 1.1 = Bender, as that point appears to be made up. Made up, and then repeated over and over until everyone accepted it as established fact. – Steel22:19, 15 September 2012 (UTC)[reply]
I created a chart with historical distribution of Android version (access from Android Market/Play Store)
I added it to the page, since it seems like a relevant chart, instead of the Android logo, but it was removed for whatever reason. I will keep updating the chart as new data becomes available, and can share the underlying data (not sure how). --Fjmustak (talk) 17:15, 16 October 2012 (UTC)[reply]
Slight criticism - you could have at least used varyingly different colours so we can tell which version is which easier. Just because it's Android, it doesn't need to be green. Other than that it's a lovely chart and would be great to include. Thanks ツ Jenova20(email)17:41, 16 October 2012 (UTC)[reply]
I think the chart might be more relevant in Android_(operating_system)#Reception than this article. It was certainly removed because it shouldn't be used in place of the android logo at the header of this article at the very least. But I think it would go well accompanying the pie chart at Android_(operating_system)#Reception, but I do agree with the above criticism - this chart would definitely benefit from more contrasting colours> I found it really hard to read of the correct versions. --kikumbob (talk) 10:55, 19 October 2012 (UTC)[reply]
Thank you both for your input. Next week, I will change the colors. I would also like to share the data file, but am unsure how to do that within Wikipedia. --Fjmustak (talk) 22:26, 19 October 2012 (UTC)[reply]
There's a bigger worry here that it will be out of date really quick and we may need a completely new article for it or constant updates to it... Or we could have a new article to free up some space in the main Android article; maybe something along the lines of Android version distribution? Thanks ツ Jenova20(email)23:40, 20 October 2012 (UTC)[reply]
Thanks, this is much clearer. Is the data from those official pie-charts on developer.android.com or somewhere else? – Steel14:43, 31 October 2012 (UTC)[reply]
The data is from all over the place (all screenshots of the tables initially posted on the developer site). I will try to recompile the list of sources I found, and add them to the Excel file Done. Some of the older data was particularly difficult to find. --Fjmustak (talk) 09:21, 1 November 2012 (UTC)[reply]
Can we also colour code the tables for versions to match the historical distribution chart in the same way that both the Windows Phone and iOS version history articles do? This would add a much needed splash of colour and defeat some of the repetitiveness from the article. Thanks ツ Jenova20(email)23:55, 3 November 2012 (UTC)[reply]
I was bold and made a change to the layout (or 15). I'm sure you'll all find the new look satisfactory? And you don't have to be gay to look good Steel. Thanks ツ Jenova20(email)20:55, 5 November 2012 (UTC)[reply]
Discussing Android with my dad and we came across this chart, he noticed it was a little hard to read the bottom dates. Decided to play with it and change around how the dates are displayed. Just uploading both versions I made, if you wanted to do anything with them. - Brendan10211
This is definitely easier to read, but were the last few months cut off? The current one finishes at Feb 2013, these ones at Nov 2012. – Steel23:46, 18 May 2013 (UTC)[reply]
I have no idea why the months are cut off.. it should just be a matter of adding more data to the chart. I don't have the means of doing that currently, sorry about that. Brendan10211 (talk) 20:57, 20 May 2013 (UTC)[reply]
@Fjmustak I added a new section to the bottom of this Talk page. Please link to the source of that data. Right now this is OR, and that is not acceptable by Wikipedia terms. Also, on a side note, could you create a chart by API version. That would be VERY useful, too! I want to be able to grab API specific data, map it over time, and project where it will be in several months. I created this StackOverflow page for this request.
Why are 2.3.1, 2.3.2, 3.2.3, 3.2.5, 4.0 and 4.1 not listed on the article? They were real.
Those versions were real and should be on the list.. I don't see any reason why they aren't there.
Android 2.3.1 and 2.3.2 were short updates that preceded the big 2.3.3 update for the Nexus S.
Android 3.2.3 and 3.2.5 were incremental upates starting on Motorola Xoom.
Android 4.0 was the starting version of the Galaxy Nexus, even if the 4.0.1 came as a OTA few days later.
Android 4.1 was the starting version of the Nexus 7, even if the 4.1.1 update came as OTA 2 weeks later.
Please fix it, it doesn't have any sense to have "3.0, 3.1, 3.2, 3.2.1, 3.2.2, 3.2.4, 3.2.6" and such...
Why do you start off asking why some versions are in but then say there's no point having the tablet versions? And please sign your posts with (~~~~)
What do you all think of including the images in the table something like this, rather than floating outside in a distracting and less neat fashion?
Thanks ツ Jenova20(email)17:02, 5 November 2012 (UTC)[reply]
Done - I find it neater and less forceful. No longer do you have to scroll through loads of tables to find the version you want. Plus we've made the most use of the earlier graph that was added. Opinions? Thanks ツ Jenova20(email)20:52, 5 November 2012 (UTC)[reply]
Your layout had deleted most of the useful information. Therefore, I reverted to the original layout. Please do not change the layout again before a several-month-long discussion with several editors. Esirgen (talk) 18:37, 7 November 2012 (UTC)[reply]
(edit conflict)That's a joke right? First off you don't get to set a time limit, that's not how consensus works on Wikipedia. Secondly, nothing was deleted so i have reverted your revert. If you want to discuss this reasonably then go ahead. If you want to revert then we will take this to the edit warring noticeboard where i will push for a temporary block. Thanks ツ Jenova20(email)18:45, 7 November 2012 (UTC)[reply]
Please revert the compact table format layout to the old expanded layout I'm sorry but the new layout is not good at all from a user perspective. By default there is not enough on the page to compare the versions or see the features of each version. I have concrete data that shows web visitors don't usually like to dig through the page and do bunch of clicks to unlock more info. If what they are looking for is not right there in front of them, they will go somewhere else. The Show button isn't obvious enough. I had to go all the way through the version history looking for vandalism, and then come here to and go through this layout talk stuff to find out what is going on and that I have to use the "show button". As a product manager that works for one of the largest e-commerce sites and digs through tons of clickstream and user behavior data on regular bases I highly recommend to revert the layout to one that does not hide the info by default. If the problem is the amount of the data on the page and the fact that everyone has to scroll a whole lot of info, I suggest either redoing the page in a reverse chronological order or splitting it in two where the second page is for historical versions of android which are obsolete or have less than 5% user base. Jenova20 you made the layout change on November 11th, 2012. Right? I do understand that you have spend a lot of time on this page and a few people said it is "neat" and you like it, I'm sorry this layout is just not a good experience and needs to go. YasharF (talk) 23:20, 18 January 2013 (UTC)[reply]
I guess it now looks vaguely more like {{yes}}, although the color is actually different. On the other hand, the current/obsolete distinction seems a bit wonky - the latest version is obviously current, but earlier versions are still used and as far as I know there isn't an official document declaring everything before the current version "obsolete." The colors corresponding to the chart were more useful, although perhaps not obvious at first glance. — daranz [ t ] 22:39, 22 November 2012 (UTC)[reply]
I never really liked the way each version was split up into multiple tables, but the colour coding with the chart was quite nice and it was necessary for that. I'm not sure which one I prefer, but judging by this edit summary, User931 probably wasn't aware of the colour coding when s/he was making those changes. I don't think there's much benefit to the current/obsolete distinction though, per the reasons above and also because it's fairly obvious that the latest version is the current one and the older ones are older. – Steel13:41, 23 November 2012 (UTC)[reply]
I restored the last non-vandalism version and changed the title from Version History', to Version history by API level.
User931's change didn't make anything clearer, it just made the article dull again and highlighted the "current" version, despite multiple devices and carriers still supporting and working on previous versions. Thanks ツ Jenova20(email)14:17, 23 November 2012 (UTC)[reply]
Jenova completely changed layout of the article without any meaningful discussion here, (1 person saying it looked "neat"). Several things are awkward in this layout; the colors make it look childish and deviates completely from iOS, Windows Phone and BlackBerry version history. There is no point to color code the versions according to a graph that is hardly visible in its thumbnail form. And the tables are now split into separate tables within the same versions which is very confusing.
They're split by API level as Fjmustak (sorry if that's spelt wrong) did when he created the graph and matched the colour schemes. The tables were collapsed by me because the article was a mess and took ages to find the right thing. Now it's at least on par with the other version history articles, maybe better.
Also if you put your childish you against me feud down and look at the reviews to the article you'll see it has an extremely high approval from 500+(somewhere in that region) people to come across that page.
So while it looks childish to you, it also has a massive approval rating and can be easily updated.
The issue i take with your version is not just that it is dull, but also that listing any version as "current" and any as "obsolete" is POV as what you list as obsolete is still being updated by carriers and manufacturers well after Google has released the next version (meaning it's not obsolete). The open handset alliance and open license of Android in fact makes all versions "current" to everyone except Google who won't develop them further, while anyone can release updated versions of any, including donut (Just like Linux forking).
Please revert the compact table format layout to the old expanded layout I'm sorry but the new layout is not good at all from a user perspective. By default there is not enough on the page to compare the versions or see the features of each version. I have concrete data that shows web visitors don't usually like to dig through the page and do bunch of clicks to unlock more info. If what they are looking for is not right there in front of them, they will go somewhere else. The Show button isn't obvious enough. I had to go all the way through the version history looking for vandalism, and then come here to and go through this layout talk stuff to find out what is going on and that I have to use the "show button". As a product manager that works for one of the largest e-commerce sites and digs through tons of clickstream and user behavior data on regular bases I highly recommend to revert the layout to one that does not hide the info by default. If the problem is the amount of the data on the page and the fact that everyone has to scroll a whole lot of info, I suggest either redoing the page in a reverse chronological order or splitting it in two where the second page is for historical versions of android which are obsolete or have less than 5% user base. Jenova20 you made the layout change on November 11th, 2012. Right? I do understand that you have spend a lot of time on this page and a few people said it is "neat" and you like it, I'm sorry this layout is just not a good experience and needs to go. YasharF (talk) 23:19, 18 January 2013 (UTC)[reply]
Splitting the article in two is not something i could support as there is not enough information there to justify it at all. Secondly, i don't see what you mean when you say that it's harder to compare this way as you can expand just the tables you wish to compare and have no distractions, whereas with the old layout that was impossible and would involve a decent amount of scrolling, with pictures scattered in a seemingly random fashion too. Thanks ツ Jenova20(email)00:05, 19 January 2013 (UTC)[reply]
Just expanding the table doesn't quite work, most users miss the show button on the far right side. How about we change the "wikitable collapsible collapsed" to "wikitable collapsible". That way anyone who wants to do the collapsing can just collapse them and compare versions that are far from each other. It won't be impossible to compare versions that are far apart either. Although, the use case of comparing things that are far apart is somewhat moot because readers want to read what has changed between two versions and will be going through all of the incremental changes between them. Also another improvement would be reversing the order of the versions with version 1, the oldest, appearing last, while the latest version comes first. Most technology readers want to know about the latest and the greatest item. They most likely have one of the latest versions too and as the data in the chart shows versions <2 barely have any users. With this second improvement, most readers will see what they are looking for first without a whole lot of scrolling and if they really want the old stuff, then they can scroll down. YasharF (talk) 05:30, 25 January 2013 (UTC)[reply]
Hmmm...i'm not for that argument personally. And the history is chronological in most articles with oldest first, so there may be a policy or Manual of Style guideline on it, and again i would not personally support that change. It would also run opposite to the table at the top and the API order and would be counter-productive, with a table redesign necessary...Thanks ツ Jenova20(email)12:46, 25 January 2013 (UTC)[reply]
Well in the style guide http://en.wikipedia.org/wiki/Wikipedia:MOS#Scrolling_lists_and_collapsible_content it says "Scrolling lists, and boxes that toggle text display between hide and show, should not conceal article content" The current show/hide by default hides the main content of the page. The information that is being hidden at first glance is not already in the main text of the article that is visible at first glance, in fact the entire page is almost empty with the collapsible table that is now hiding everything. That means we need to change at least the default for the collapsible tables to show the content with the option of hiding them if we are not opting to eliminate the collapsible table all together. YasharF (talk) 20:30, 30 January 2013 (UTC)[reply]
Well strictly speaking, it's only concealing the features. The actual directly relevant article content is the unhidden text and the version name since this is Android version history and not Android version features. Also from the Manual of Style on this topic, you left out "Collapsible sections or cells may be used in tables that consolidate information covered in the main text". Since this information is not directly relevant it could be argued that it doesn't belong in the article at all, but i would not support that and nor would many others i expect. Either way i think we disagree and could consider a third opinion if you want an outside opinion? Take a look in the history of the article at what the page looked like before the changes if you haven't already as it would be terrible to end up with a mess like that, which floods the article with about 20 tables and increases the article size so drastically. I would also argue it harms readability. Thanks ツ Jenova20(email)21:16, 30 January 2013 (UTC)[reply]
I think it makes sense to list the most recent release first as that is what most people are interested in. I remember a guideline that most interesting content goes first. Daniel.Cardenas (talk) 20:44, 31 January 2013 (UTC)[reply]
That's an opinion unless proven, not a fact. And i would contest it to keep the article in chronological order, like every comparable operating system article. Thanks ツ Jenova20(email)10:28, 1 February 2013 (UTC)[reply]
A list of the Android logos (yes, the green/brown/white... damn robots) according to versions would be HIGHLY appreciated; it's strange those logos are used everywhere in the world, especially in phone marketing, but I could not find 1 description, period, of their meaning on the Internet. If the logos can't be directly displayed for copyright reasons, at least please give a worded description maybe with a link to an example of each on the net. Thanks and... good luck (that information is sparse), AlainR345Techno-Wiki-Geek21:53, 11 December 2012 (UTC)[reply]
More about the early days
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Adrian, thanks for your guidance. The source does mention all the version numbers. Just use the years and months to work your way up through the posts. Their titles already show most of it. When you've moved through a few dozen posts from 2007 up to 2009 you should have found all these version numbers. Of course, I can add links to each single post, but I'm not sure if that would add much, or make it more legible. Let me know what you think.--Pjv (talk) 07:10, 30 December 2012 (UTC)[reply]
What is the point of version history by API level?
Version history by API level is great for developers and the information is readily available at http://developer.android.com/about/index.html Wikipedia on the other hand is made for the general public and most people don't know what API is. I really can't see the relevance in showing version history by API level when 99% of people don't know if their phone is on API level 15 or 16. If people really think it is a good idea to list API level then the actual levels 1, 2, 3 etc should also be written out for every version in the article. User93117:01, 5 January 2013 (UTC)[reply]
Maybe the API levels should be spelled out...It would be a bit more informative. It does reflect what is in the main Android article though. Thanks ツ Jenova20(email)16:47, 5 January 2013 (UTC)[reply]
I spelled them out but after a while i felt it was just too much information cramped in, hard to oversight. I made a separate table for API versions instead, could we compromise on this? Cheers User93123:13, 5 January 2013 (UTC)[reply]
The table you added is very good but it looks out of place on its own. I just toyed with placing the main article image in line with it but that also looked too much...Maybe Someone else can give their opinion if available here? Steel perhaps? Thanks ツ Jenova20(email)22:24, 5 January 2013 (UTC)[reply]
I restored an older version because i just noticed you hid a lot of the versions. They're grouped by API level, NOT name, and that is the reasoning for the split. Please use edit summaries too as some of your edits are controversial. Thanks ツ Jenova20(email)22:44, 5 January 2013 (UTC)[reply]
I didn't hide any versions, they are all there, but this split of versions to API level is something you created which never was here for several years before. And your complete unwillingness to compromise is frustrating to say the least.User93123:48, 5 January 2013 (UTC)[reply]
I never created it and i've told you that before. All i did was collapse the sections because the article was too big. And i coloured it to match the table made by Fjmustak (apologies if i spelt that wrong). I don't have to cooperate with something i don't agree with. I liked the table you added before and still do, but it looked a bit out of place. I never said remove it, i just said it looked out of place a bit. Thanks ツ Jenova20(email)23:01, 5 January 2013 (UTC)[reply]
Also edit summaries like your last seem designed to damage the article just to spite me.
There is no need to list an API level in the heading of each version like that and make it less readable as it can be included either in the table or left out completely since it's already in the image at the start of the article. We have to stop this feud. We don't agree but this is childish. ツ Jenova20(email)23:06, 5 January 2013 (UTC)[reply]
...Because it's completely green and Fjmustak made his first table green (which he/she showed off here) and agreed to change the colours because it was difficult to interpret.
Google's graph is a pie chart and less informative than what we currently have in many ways. And i defend the layout solely because it looks better, is easier to find the vesion you want, and because no one else has complained about it, argued, or attempted to edit war over the layout. Thanks ツ Jenova20(email)23:18, 5 January 2013 (UTC)[reply]
The thing is, as i mentioned above, no one, not even on technically oriented web pages, talk about Android versions as versions by API levels. That only has purpose for developers. But now this whole article is changed just because of adaption to a home made graph. I disagree that Googles chart is less informative, i find it more current, up to date and easier to read. User93100:35, 6 January 2013 (UTC)[reply]
(edit conflict) FYI, the dashboard thing on the Android website lists actual distribution percentages per API level. The codename - API level hierarchy that was here before made sense: codenames group a larger set of releases, whereas API levels distinguish between major releases (ie, releases with changes significant enough to warrant a new API level). — daranz [ t ] 23:38, 5 January 2013 (UTC)[reply]
And so there we have it. Like i said before, grouping by names hides a lot of important content and the API level graph in the article not only shows more than Google's pie charts, but also shows the history and how fast the uptake of the new versions is. Thanks ツ Jenova20(email)00:14, 6 January 2013 (UTC)[reply]
I'm not particular about the chart. I could combine all dessert versions with different API levels together. However using a pie chart does not show the historical distribution! Chart using only dessert name versions without API level or version number --Fjmustak (talk) 01:12, 17 February 2013 (UTC)[reply]
The historical distribution must be preserved as it is massively informative to the article. It sums up the Android version history simply and informatively! Google shows the newest uptake figures, we show all the figures. Thanks ツ Jenova20(email)09:40, 18 February 2013 (UTC)[reply]
Where's Android 4.2.2 Jelly Bean?
Android 4.2.2 Jelly Bean has been released, where's information and all the features? 𝕁𝕠𝕣𝕕𝕒𝕟 𝕁𝕒𝕞𝕚𝕖𝕤𝕠𝕟 𝕂𝕪𝕤𝕖𝕣 21:36, 14 January 2013 (UTC) — Preceding unsigned comment added by JordanKyser22 (talk • contribs)
This and the main Android article seem to lack information about the support status of various Android versions. So, if I were a prospective buyer, I'd like to know if Android Gingerbread is still supported. So far the only indication, for example, is that 2.3.7 was released on late September 2012 and that's that. -Mardus (talk) 10:08, 22 January 2013 (UTC)[reply]
I think you mean September 2011...I thought that was odd. Anyway, the support status is complex. Google only supports the newest version i believe, but the Carriers support the older ones and manufacturers chop and change parts to fork them like classic Linux.
Technically they're all supported, just not by Google. We had a similar issue with someone once listing each version as supported or obsolete. Technically they're all supported.
The best advice i can give you is to buy a phone that's fairly new and with a newish version of Android, and that way you'll have official support for around 18 months. Thanks ツ Jenova20(email)10:54, 22 January 2013 (UTC)[reply]
HDMI out on Android 2.3.6
I put in the following edit which was rejected:
HDMI output is disabled on Samsung Droid Charge upon update to 2.3.6.
The basis for this was that I own a Samsung Droid Charge which had a version of Android from July 2011. I sent it to Samsung with a cracked USB port. Before I sent it it worked fine on my old HDTV plugged into the HDMI port. Samsung flashed 2.3.6 onto the phone. When I got it back the HDMI port didn't work anymore. I called them and they said Yes, it won't work anymore except maybe with a Samsung TV. Unfortunately, while I can find numerous other instances on web forums of people complaining about 2.3.6 not working on HDMI, I can't find a definitive manufacturer's source. So people, please: Can someone help me find a definitive open source (say Android code for 2.3.6) which clearly gives evidence of HDMI functionality changing in a bad way on 2.3.6 versus earlier releases?
I've looked around but the only references I can find are on web forums, which don't qualify as reliable sources. I imagine that Google aren't very likely to announce a glitch like this in an official report, but maybe a third-party Android website will cover it? — Michaelmas1957 (talk) 04:46, 6 February 2013 (UTC)[reply]
I don't know offhand where to find Android sources, but the version that worked was release EP4 and the version that doesn't is FP1. Since then there have been many major releases but FP1 is what Samsung as of 31JAN13 is installing 2.3.6 FP1 on Droid Charge. They also claim that they have no way of re-flashing to an older release once they put a higher release on the phone. I strongly doubt that but maybe someone can explain how this might be possible. Erxnmedia (talk) 14:29, 6 February 2013 (UTC)[reply]
The way it is worded it appears this article, iOS version history and Windows Phone version history all violate that policy...I suppose the easiest way to solve it is to trim it or make it look more like Symbian. I would also like to point out that i do not have the time to do this work myself, but can help out with it. Suggestions anyone? Thanks for bringing it up here ツ Jenova20(email)17:09, 23 February 2013 (UTC)[reply]
I think this article would work better as something similar to List of Ubuntu releases - mostly prose overview of the releases, rather than a feature list for each one. We tend to have articles for every major release of notable operating systems (like Windows 7), but with something versioned like Android, a prose history of releases makes more sense. — daranz [ t ] 23:16, 23 February 2013 (UTC)[reply]
Maybe it's time to revisit the separate articles suggestion from #Separate articles. Perfectly respectable small- to medium-length articles could easily be written about each version, and it would allow us to keep the changelog information in a way that doesn't violate WP:NOTCHANGELOG because there would be lots of interesting accompanying prose about the update's release and reception. See the mockup from the section above. In turn, Android version history, which is becoming problematic, could be scaled down to something sensible. Rapture's Sander Cohen (talk) 16:37, 24 February 2013 (UTC)[reply]
After further reading of the currently being debated wording of the policy and looking also at the overwhelming keep consensus offered by Dcxf - i will drop my earlier support for trimming the article. This is a short summary and prose layout, not a changelog. Thanks ツ Jenova20(email)09:42, 27 February 2013 (UTC)[reply]
Cupcake was changed to cookie
Somebody replaced all mentions of 'Cupcake' with 'Cookie'. Could this page be reverted to the previous state and protected for some short period of time or smth like that? 89.176.223.126 (talk) —Preceding undated comment added 16:26, 24 February 2013 (UTC)[reply]
They were deleted under Wikipedia:NFCC#8. I was told by a Wikiproject a while back that Android screenshots were under compatible licenses to free since they're a Linux fork (or something like that). Seems they were wrong...Thanks ツ Jenova20(email)14:20, 3 April 2013 (UTC)[reply]
No, they were right about Android's licence. It looks like these images were incorrectly tagged as fair use for some reason. And I'm not even convinced NFCC#8 would have applied anyway, since the images were inside collapsed sections due to article length concerns (which we really need a proper solution to, by the way), not because they were unimportant. I am tempted to restore the lot of them, but someone would need to go through and correct the image description pages, and possibly blur out some copyrighted Google logos. Rapture's Sander Cohen (talk) 16:12, 3 April 2013 (UTC)[reply]
With those sections uncollapsed the article is too big to navigate. What about splitting each version into separate articles? Thanks ツ Jenova20(email)16:14, 3 April 2013 (UTC)[reply]
The idea seemed radical to me and that's why i've taken so long to come around to the idea. As i see it the names would have to be similar to one of these:
I was the one who nominated the images for deletion. As I can see, they failed at least three of the non-free content criteria:
WP:NFCC#1: Android is partially open source. Google takes the freely licensed source code and changes some things, for example by adding Android Market, and possibly changes some artwork such as icons and backgrounds. In this case, you would probably get the same understanding by using a screenshot showing only the open source parts of Android.
WP:NFCC#3a: You shouldn't use lots of non-free images when just one or two would give you the same understanding. There are often not that big changes between each version, so not all versions are needed.
WP:NFCC#8: You should only use non-free images if the images increase the understanding of the topic and if the removal of the images would be detrimental to that understanding. The images were in collapsed sections. A collapsed section screams that the contents of the section is something so unimportant that you can safely ignore it. That is more or less the opposite of what WP:NFCC#8. Additionally, the collapsed sections largely ignore what the versions look like, so the images would have violated WP:NFCC#8 even if the sections wouldn't have been collapsed.
I don't think that each of those versions would meet WP:N to qualify for an individual article. New versions pop up all of the time and they don't contain that many differences. Compare with List of Ubuntu releases where there isn't an article for each individual version. --Stefan2 (talk) 17:32, 3 April 2013 (UTC)[reply]
Thanks, but this is irrelevant. It doesn't matter how many images are used, or where, if they weren't non-free in the first place. At least two images, File:Android 1.0 Home Screen.jpg and File:Android 1.1 Home Screen.jpg, contain no non-free elements whatsoever. Most of the others contain small Google logos which are incidental to the image, and might not be enough to make the image as a whole fair use - but if they do, blurring them out would have been trivial. Rapture's Sander Cohen (talk) 17:47, 3 April 2013 (UTC)[reply]
Some wp:commonsense applies here. Do you think Google would object to the use of those images? No they wouldn't. In my opion WP:NFCC#8 does not apply. You don't judge it because it is collapsed. You judge it when it is uncollapsed and ask if it helps the uncollapsed content. Otherwise one could say delete all the content that is collapsed because it screams of not being needed. Daniel.Cardenas (talk) 22:47, 3 April 2013 (UTC)[reply]
Microsoft does not object to the use of Microsoft screenshots on Wikipedia (see {{Microsoft screenshot}}). However, all images which do not meet the definition are treated as unfree (see wmf:Resolution:Licensing policy) and need to comply with WP:NFCC#8. If some of the images were in fact free (although mistagged as unfree), then those images can be undeleted. However, they were, if I remember correctly, from a variety of different phone manufacturers. For example, I have a Samsung phone, and I would suspect that the default background image was produced by Samsung and that this image is unfree. You would have to verify that the background images and icons indeed are freely licensed. I would assume that many of the default background icons are freely licensed, but this is probably not the case with for example the Gmail icon, the Android Market icon or the Google Play icon. --Stefan2 (talk) 13:49, 4 April 2013 (UTC)[reply]
We deliberately chose screenshots that were as close to the free, default Android as possible. Everything is fine except for some copyrighted Gmail or Twitter icons on a few of the homescreens. As I said, I'm not convinced that one or two small, incidental icons can force the entire image to be fair use, but regardless it would be easy to blur/blank these out and the end result would be a free image. That's what I would like to do. Rapture's Sander Cohen (talk) 11:07, 5 April 2013 (UTC)[reply]
Although it doesn't say in the image it appears that X is "distribution as of this date" and Y is "percentage of all Android devices currently in use". This assumption made on the basis that the image is updated every time new figures on activations are released.
I also wondered about the axes Readers shouldn't have to come to a Talk page to understand the chart. The description of the axes should at minimum be in a footnote on the chart(if the axes can't be made more clear). Also, all the references for the chart really need to be on the chart. From reading above, it looks like the creator has compiled the references in an external spreadsheet, so maybe that wouldn't be hard to do. BTW, I love the chart, and it adds a lot to the article. 108.17.33.35 (talk) 04:23, 30 June 2013 (UTC)[reply]
I can see about the caption but i think the rest of that would require someone like fjmustak (the creator). You're right of course though. It needs to be simpler. Thanks ツ Jenova20(email)08:36, 1 July 2013 (UTC)[reply]
I've updated the versions up to the June numbers. The updated spreadsheet can be found here. I created two versions of the chart, one with every API version available (the second sheet), and the other with only dessert names (the first sheet). The third sheet contains the references to the historical data. Note, the months that are missing are the ones that I took the numbers directly from the Android developer site. As for the axes, the horizontal axis is the date data is released by Google, while the vertical axis is the percentage of usage recorded by Google for each API level. It is worth noting that the way Google now collects data is slightly different as of the April numbers, which is somewhat obvious from the jumps in the chart. More details can be found here. --Fjmustak (talk) 12:07, 3 July 2013 (UTC)[reply]
Also note that the x axis is not exactly linear, as Google is now releasing the numbers monthly, while in the beginning it sometimes released the numbers twice a week, other times every couple of months. --Fjmustak (talk) 12:15, 3 July 2013 (UTC)[reply]
The Image description says it is Android 2.3, and the caption adds "on the Samsung Nexus S". Since every manufacturer can reskin Android to take a different appearance we really can't take your word for that. If you can prove it then we can do something about it. Thanks ツ Jenova20(email)08:25, 11 July 2013 (UTC)[reply]
Actually the prior screenshot was Android 2.3 but not with the stock/vanilla skin. The screenshot was from a Sony Ericsson Xperia phone running Android 2.3 with their OEM skinning. Just FYI, I personally believe a stock screenshot is preferred over a OEM skinned screenshot. 「gu1dry」⊤ • ¢08:53, 12 July 2013 (UTC)[reply]
The Geofencing and Wi-Fi scanning APIs in the new Google Play services (revealed at Google I/O) now have system-level support on certain hardware, the new Nexus 7 and Nexus 4 being the only Google devices that are currently compatible. For example, the gyroscope and magnetometer can now report raw and ostensibly more accurate data to games and apps, and the WiFi scanning mode can be enabled without connecting to a network for better location tracking without using GPS.
I am thinking the 2 examples provided above could be used to provide some context as to give a general idea of what it does and also add a note that only the 2nd Gen Nexus 7 and Nexus 4 support it at the moment, the same also for the improvements to Photosphere (Only Nexus devices officially):
System level support for Geofencing and Wi-Fi scanning APIs (For example, The gyroscope and magnetometer can now report raw and ostensibly more accurate data to games and apps, and the WiFi scanning mode can be enabled without connecting to a network for better location tracking without using GPS.)
While on the topic of changes to 4.3., Would the "Google Play Music" update really be considered part of the 4.3 Android update? Lorondos (talk) 16:14, 28 July 2013 (UTC)[reply]
Android Version History Chart is Original Research (OR)...Link to reference
I wrote the following on Stackoverflow to try to find a better graph (or data) on rates of change of Android versions (or by API level). I have not been able to find actual data, or any archived data that would allow me to build this chart over again...or even a derivative of it.
There is no source to this chart and the data cannot be found...therefore this is OR. I would suggest that information be published on the web and linked to it. Google's own Android Dashboards does not satisfy the requirement for actual data of that chart, because it is not achieved. Google Cache and Wayback Machine either don't go back far enough, or don't save the pictures to see what it was.
Please make this changes as soon as possible. There is important information that people will want to use that information for because that chart does not provide the level of granularity needed. Ciscorucinski (talk) 18:22, 27 August 2013 (UTC)[reply]