Talk:Android (operating system)/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

Optional hardware section and possibly keeping/readd it later it in the versions article

Thanks for moving here. I put it in the versions article and intended to expand it (or hoped someone would) to include in what versions certain features got added or dropped as requirements. Since nothing such is mentioned I can see that it fits here.

What I mean with "Android supports OpenGL ES 1.0, 1.1, 2.0 and 3.0." is that all these versions have at one point been supported as the most recent version (and I wanted to know at which Android version). For this article as it refers to the most recent version of Android, saying only OpenGL ES 3.0 might seem enough but that is wrong. Note 1.1 and 2.0 APIs are not compatible. I think 3.0 is with 2.0. Hardware that supports newer versions probably always supports all older onces. 1.1 might theoretically be an exception, not sure any hardware only support 2.0 and newer in practice.

I'll change to "OpenGL ES 1.1, 2.0 and 3.0". I assume 1.1 is compatible with 1.0 and 1.0 needs not be mentioned. Note 1.1 and 2.0 are not compatible, I think 3.0 might be with 2.0.

Regarding: "Android devices can include still or video cameras, touchscreens, GPS, accelerometers, gyroscopes, barometers, magnetometers, dedicated gaming controls, proximity and pressure sensors, thermometers, accelerated 2D bit-blits (with hardware orientation, scaling and pixel format conversion), and accelerated 3D graphics." I copied this and all seem optional. I guess screens are not optional but touchscreens are in principle. Does anyone know of a mobile device though that doesn't have a touchscreen? comp.arch (talk) 01:23, 16 November 2013 (UTC)

Hello there! I had exactly the same thoughts as you've just described above — it would be great to have such a list within the Android revisions history article, so we know which version required what, hardware-wise. Though, if you agree, starting that within the revisions history article would be much better with some kind of a requirements matrix instead of a list, so people can more easily chip in later, filling in what's missing. Also, that way it should be much more readable, and thus much more usable — if you agree?

Regarding Android devices having a screen not supporting touch input, I really can't recall one. -- Dsimic (talk) 01:34, 16 November 2013 (UTC)

Btw, (touch)screens are optional. Just think of all those "HDMI sticks" running Android. -- Dsimic (talk) 02:06, 16 November 2013 (UTC)

Well, yes and no.. Not sure screens are the best example of optional hardware. Yes in the device they are optional, but HDMI implies connecting to a monitor. For Android as an operating system and as a user interface a screen is pretty much required. A GPS is completely optional, could theoretically be added through USB (not sure if supported by Android). A physical keyboard is optional but a virtual one is provided instead (some form is "required"). A mouse, I'm told, is optional (you get I pointer if connected, true?). Screens (for that reason), do not have to be touchscreens. Android doesn't work at all for blind people right? comp.arch (talk) 12:24, 22 November 2013 (UTC)

Yeah, having a (touch)screen is pretty much making current Android devices usable, at least in a way Android is supposed to be used. Regarding having a mouse connected, I've seen those air mice (or however they're called) connected, and there was an on-screen mouse pointer, though I'm not sure whether additional applications were installed for that purpose. Blind people and Android, hm? There seem to be some applications claiming to provide accessibility. -- Dsimic (talk) 13:58, 22 November 2013 (UTC)

Can we make sourcing this section a priority please? – Steel 14:56, 16 November 2013 (UTC)

Are you referring to the subsection in this article, or to the planned subsection in Android version history (section Hardware requirements)? -- Dsimic (talk) 15:15, 16 November 2013 (UTC)

For now, the whole hardware requirements section in this article (assuming it does stay here at all), some of which has been sitting with citation needed for weeks now. – Steel 16:00, 16 November 2013 (UTC)

There you go, please check it out. -- Dsimic (talk) 16:23, 16 November 2013 (UTC)

GEL closed source?

It's not. Proof of this are the numerous third-party aplications available that install the launcher, which are compiled from the AOSP source. That said, I still don't think it's representative of KitKat since it's not included in all distributions of the OS. --uKER (talk) 14:32, 6 December 2013 (UTC)

Hm, I'd say that GEL actually is a closed-source application, please allow me to explain. This article describes GEL's actual functionality as tied into the Google Search application, and all new features for that application went into its closed-source version, as described in this article. In other words, AOSP distributions can have the GEL, but by using some kind of a shim application, in order to utilize the functionality provided through an installation of the Google Apps suite. Of course, I might be plain wrong there, as I'm not an Android hacker patching and compiling AOSP all day long. :) — Dsimic (talk) 14:50, 6 December 2013 (UTC)

First Android television set top box?

I've been noticing on Ebay that there's a ton of Android set top television boxes that play all kinds of Internet streams/feeds. Anyone have an idea who might have been first to this area? Kudos to Android for going into autos and television set top boxes. CaribDigita (talk) 18:38, 7 December 2013 (UTC)

Android 4.4.1

Android 4.4.1 was released on December 5. Should we update the infobox to state that 4.4.1 is the latest stable release? --WikiWinters (talk) 15:08, 8 December 2013 (UTC)

Thank you for pointing that out! Went ahead and updated the infobox. — Dsimic (talk) 15:23, 8 December 2013 (UTC)

Forks of Android - Fire OS, when?

See: Talk:Fire OS#When was Android forked into Fire OS? And where do you draw the line between Android (AOSP) and the rest of the software? Try not to duplicate the discussion (too much) here. Should we do more in this page about forks? comp.arch (talk) 14:20, 13 December 2013 (UTC)

Hm, Fire OS should probably be mentioned in this article, in the same place where Amazon and Kindle Fire are already mentioned. Thoughts? — Dsimic (talk) 15:21, 13 December 2013 (UTC)

 Done (Diff) Wasn't too hard to decide where to put it. --uKER (talk) 15:39, 13 December 2013 (UTC)

Looking good, thanks. — Dsimic (talk) 16:38, 13 December 2013 (UTC)

"Amazon's Kindle Fire line uses Fire OS, a heavily modified fork of Android which does not include or support any of Google's proprietary components". In what ways is it heavily modified? This should be answered it the Fire OS page.. I really want to know for this fork or others. comp.arch (talk) 16:08, 13 December 2013 (UTC)

At the same time, there might be another Android fork around the corner... To me, it seems logical that Fire OS is basically "leeching" on the Android's (and Linux kernel's) wast hardware/drivers support, building a customized UI on top of it, which acts as a consumer of Amazon's proprietary services and their own application store — while keeping everything tight, so any further customization is hard. That's what makes it an actual Android fork. — Dsimic (talk) 16:38, 13 December 2013 (UTC)

Ah, there's Aliyun OS, too. We might want to mention it within this article. — Dsimic (talk) 16:44, 13 December 2013 (UTC)

AOSP

Although AOSP redirects to this article, it should now have its own article. -Mardus (talk) 11:31, 16 December 2013 (UTC)

IMO, that would introduce too much fragmentation. Just my $0.02. :) — Dsimic (talk) 18:33, 16 December 2013 (UTC)

Semi-protected edit request on 23 December 2013

41.178.223.108 (talk) 08:10, 23 December 2013 (UTC)

Not done: no actual request made. Please resubmit your request in the form of "change X to Y", providing all reliable source. Thanks, NiciVampireHeart 09:32, 23 December 2013 (UTC)

User Interface

The elements of the Android UI were incomplete, I thought. I have added a few more things it may contain, to fully contrast it with iOS. Perhaps the hard and soft buttons need mention too? 51kwad (talk) 22:38, 23 December 2013 (UTC)

iDroid

Why are iDroid redirected to the Android article. --David Hedlund (talk) 18:30, 30 December 2013 (UTC)

Hello there! Well, it seems iDroid isn't described anywhere on Wikipedia, so this redirection is currently the best possible thing to be provided. Sure thing, you (or anybody else) are more than welcome to write a separate article on iDroid. :) — Dsimic (talk) 00:17, 31 December 2013 (UTC)

Semi-protected edit request on 12 January 2014

Change this line, | kernel type = Monolithic (modified Linux kernel) with this line: | kernel type = Monolithic (modified Linux kernel) because it isn't working otherwise. Thanks. Cihanozvez (talk) 01:02, 12 January 2014 (UTC)

Done Jackmcbarn (talk) 01:27, 12 January 2014 (UTC)

• Improved further, no need for article name in the link. — Dsimic (talk) 01:36, 12 January 2014 (UTC)

Google Home

We already had consensus earlier not to acknowledge Google Home (a.k.a. Google Experience launcher) in any form on this page (aside from, possibly, a mention of it as an example of a component Google has made non-open), as it is officially exclusive to the Nexus 5 and not technically part of Android.

Additionally, the source an editor used to bring up Google Home on this page is also deemed unreliable because it is merely a forum (how major a forum is doesn't matter), and the Ars Technica "Iron Grip" article only discusses Google's practices itself and makes little mention to Google Home. This is why I keep removing it. ViperSnake151  Talk  21:28, 8 December 2013 (UTC)

Hello there! Regarding recent edits (edit #2, edit #2) on the Android (operating system) and Android version history articles, please allow me to explain the background of adding those notes. As we know, there have been numerous edits replacing the stock screenshot with the GEL one, and the note is there for providing additional explanation so confusion is avoided. People expect to see translucent bars for 4.4, and it should be explained why they aren't there — if you agree.

Also, could you please explain why do you keep reverting that, only because it's using a forum post as a reference – while it's a pure fact? Shouldn't you try to provide a better reference instead of performing plain deletion? — Dsimic (talk) 21:32, 8 December 2013 (UTC)

We don't put notes in articles to tell users why the Android screenshot isn't showing TouchWiz. This is a similar case. Google Home might get its own article once its actually released officially. Also read WP:V, "internet forum postings [..] are largely not acceptable as sources." ViperSnake151  Talk  21:39, 8 December 2013 (UTC)

That totally makes sense, but on the other side I haven't seen people switching those images for the TouchWiz ones, :) while they've been switched to GEL variants at least 5-6 times so far. The trouble comes from the fact Nexus phones are taken as some kind of a reference point, regarding deciding what is and what isn't "bare" Android, while Google's recent shift to segmenting Android's features into closed-source applications is breaking that assumption. — Dsimic (talk) 22:27, 8 December 2013 (UTC)

Also, would this be a better reference for the GEL / Google Home and its relationship with the "bare" Android, instead of a forum post? If we care to explain that at all, of course. — Dsimic (talk) 22:38, 8 December 2013 (UTC)

@ViperSnake151: Any comments, please? It would be polite to say something, at least. — Dsimic (talk) 15:07, 10 December 2013 (UTC)

The sources we have right now are fine. GEL is a Google app, not stock Android. This article is only about Android, not what companies (even Google) add to Android. ViperSnake151  Talk  15:42, 10 December 2013 (UTC)

Thank you. With your latest edit, it is much more clear what's the relationship between Google Home / GEL and Android, especially regarding what's available on Nexus 5. — Dsimic (talk) 16:00, 10 December 2013 (UTC)

The open-source portion version of the "Google Experience Launcher" is named Launcher3 in AOSP (https://android.googlesource.com/platform/packages/apps/Launcher3/) which is indeed a part of the OS. I've replaced the screenshot boldly, if anyone has a different opinion, feel free to revert. Zhaofeng Li [talk... contribs...] 05:57, 15 January 2014 (UTC)

I'll replace the screenshot with the open-source Launcher3. Zhaofeng Li [talk... contribs...] 06:01, 15 January 2014 (UTC)

Uploaded new version of the screenshot with Launcher3 included in AOSP, and without Google Apps which are "not stock Android". I think it's a accurate representation of Android 4.4. Zhaofeng Li [talk... contribs...] 06:12, 15 January 2014 (UTC)

Hello there! Hm, where are the soft buttons on the Android 4.4.2 screenshot you've provided? From which device is it? — Dsimic (talk) 00:33, 16 January 2014 (UTC)

@Dsimic Hello. It's a Galaxy S3 with OmniROM (AOSP-based). I can upload a new one with soft-key enabled if you like. Zhaofeng Li [talk... contribs...] 05:09, 16 January 2014 (UTC)

Ah yes, Galaxy S3 has physical buttons. :) It might be better to have a picture with soft buttons, as that's somehow expected to be displayed in screenshots of "AOSP" builds, as they (in turn) tend to be associated with recent Nexus devices which have no physical buttons. — Dsimic (talk) 05:17, 16 January 2014 (UTC)

@Dsimic New uploaded with soft-key enabled. Any suggestions? Zhaofeng Li [talk... contribs...] 15:31, 16 January 2014 (UTC)

Looking good to me, thank you! We'll see what the other editors are going to say, and if it goes well, this screenshot could be also propagated into the Android version history article. — Dsimic (talk) 19:04, 16 January 2014 (UTC)

64-bit Android?

Tegra#Tegra_K1: "the world's first 64-bit mobile chip running Android" is probably untrue. Not because Intel was first but Google isn't ready: "Intel has ensured that the bottom layer, the kernel, will boot and work in 64-bit mode on Silvermont processors. However the rest of the layers seem at the moment to remain 32-bit and it is likely that a full conversion to 64-bits will take some time." [1]. Linux-kernel has been know to run on (Intel) 64-bit x86 for a long time, the addition must be a something (non-essential?) GPU (or something (what?) Android-Linux-kernel fork) specific. Mainline Linux-kernel has been running for a (shorter) while on 64-bit ARMv8. I would not say "Android" is running on 64-bit until 64-bit Dalvik (or ART?) is supported. Android running *on* 64-bit chip could arrive sooner. Please don't add that to the page saying "64-bit Android" has arrived or is coming. Would there be any benefit, could 64-bit C code (or 64 ARM code) be called from 32-bit Dalvik code through JNI? I guess not.. comp.arch (talk) 09:22, 21 January 2014 (UTC)

Disambiguation

There is a disambiguation page for the word "android". Why doesn't this page link to it? — Preceding unsigned comment added by BlackmailedIntoRegistering (talk • contribs) 05:02, 27 January 2014 (UTC)

Good point! It's now added. — Dsimic (talk | contribs) 05:10, 27 January 2014 (UTC)

NSA's kit for Android

[2] Article: [3]. Someone not using his real name (talk) 20:07, 27 January 2014 (UTC)

Looks like something to be included into this article. — Dsimic (talk | contribs) 22:57, 27 January 2014 (UTC)

I will update the article with info from these recent reports at the weekend unless someone beats me to it. – Steel 18:29, 28 January 2014 (UTC)

Market share vs. installed base (for eg. tablets)

I wanted to know installed base (not just sales numbers in a quarter of some specific brand) and assumed "market share" meant "installed base". It doesn't meant that. I think we should throw out these numbers.

However, "Installed base" (US, tablets):

2012: Apple 52% Android 48% (including Kindle Fire 21%), Android way up from 2011 (no Windows etc..?): http://www.forbes.com/sites/benedictevans/2012/10/02/how-many-tablets-are-in-the-usa-and-does-it-matter/

2013: "We believe about 51% of the tablet installed base is coming from iOS and 40% Android when all is said and done in 2013." Big Brand Tablet Installed Base to Surpass 285 Million by Year’s End. Note iOS/Apple/iPad down from 52%, could mean Android up to almost 49%, 40% excludes non-"Big Brand Tablets".

Smartphnoe numbers [4], seem two liked Guardian articles. comp.arch (talk) 17:01, 29 January 2014 (UTC)

RfC: Which screenshot should be assigned?

This and This reports from International Business Network reveals that currently Google hasn't released any update of Android 4.4 for Galaxy S3, it also states clearly that now-a-days the updates has been available in the form of CustomROMS by third-party sources other than Google.

But an user Zhaofeng Li has uploaded two screenshots of Galaxy S3 running Android 4.4.2, i.e, File:Android 4.4.2.png and File:Android notification area.png, and also assigned in the infobox of the article, comparing the screenshots with the references provided above, I found that those screenshots quietly matched to the images that are in the references.

So, I reverted those images and assigned the image of KitKat running in Nexus 4. Have I done something wrong ? Himanis Das Talk 13:05, 21 January 2014 (UTC)

... As currently the Rfc has been added, the image of Android KitKat running in Nexus 4 is File:Android 4.4 with stock launcher.png and the question is which screenshot should be assigned in the article ? Himanis Das Talk 14:50, 24 January 2014 (UTC)

Hello, @Himanis Das. The whole point of the screenshots is to demonstrate the UI, which is not related to the device model. The ROM running on my phone is based on AOSP which does not include any UI modifications from the device vendor (Samsung) and therefore considered "stock Android". My screenshot also features the new home screen design which is one major UI change in Android 4.4. What's more, Google-made ROMs are also based on AOSP and includes many proprietary elements that are not a part of stock Android (such as the Google Experience Launcher). Please read the discussions in the "Google Home" section above. Thanks. Zhaofeng Li [talk... contribs...] 15:33, 23 January 2014 (UTC)

... And please don't treat ROMs produced by Google as "original Android". Zhaofeng Li [talk... contribs...] 15:42, 23 January 2014 (UTC)

This is something having a long history of changed and then reverted screenshots. From one side, any clean AOSP build can be considered to be stock Android, while on the other hand only Google's releases could be treated as such. Then again, we have Google Home as an exception, bringing in additional confusion (especially among readers, who probably expect to see Google Home screenshots).

How about opening an RfC, so we end up having this defined through comments from a broader editing audience? — Dsimic (talk) 17:33, 23 January 2014 (UTC)

So much time has been spent agonising about 4.4 images when really they all look substantially the same as each other. My personal preference at this point would be to use File:Android 4.4.2.png since it shows the UI changes in 4.4 (eg, the transparent status bar) and is as close to Google Home as possible while using only icons and backgrounds which we know for sure are freely licensed. This makes it the image with the lowest number of possible objections which I think is sadly the way we'll have to make the decision. The fact that it's speculated to be from a custom ROM is neither here nor there since you could replicate the exact same screenshot on an official AOSP build. – Steel 20:00, 23 January 2014 (UTC)

Well, life isn't perfect; my vote also goes to File:Android 4.4.2.png. Also, that's what the majority expects to see when a KitKat version is depicted. — Dsimic (talk) 21:23, 23 January 2014 (UTC)

So I've restored the screenshot boldly. Any comments on the notification area screenshot? It looks exactly the same on Nexus 5, I think. Zhaofeng Li [talk... contribs...] 00:29, 24 January 2014 (UTC)

The Home launcher is only on the Nexus 5 (not stock). The screenshot depicts non-stock software regardless, the lead screenshot on an OS article should reflect defaults. We had this discussion before. ViperSnake151  Talk  00:32, 24 January 2014 (UTC)

@ViperSnake151 Please read the description page of the screenshot and the discussion on the "Google Home" section. The home screen is not Google Home, but the open-source Launcher3 (included in AOSP so it's "stock") which uses the same design (Launcher and Launcher2 uses designs found on older versions of Android, respectively). Zhaofeng Li [talk... contribs...] 00:39, 24 January 2014 (UTC)

Oh wait, I actually did notice. I was under the impression that Google Home wasn't in AOSP at all; but then why didn't they put Launcher3 on the Nexus 4/Moto X updates then? I'll accept it if the page layout is changed to mimic the old screenshot (Chrome's icon is pd-ineligible, so its okay) ViperSnake151  Talk  00:42, 24 January 2014 (UTC)

@ViperSnake151 Who knows? Maybe Google just wanted Nexus 5 to "stand out" from the crowd. By the way, Chrome logo is copyrightable, so I think that might be better left out (the Google logo on the search bar is copyrighted, but removing it hurts the "stock" appearance). Zhaofeng Li [talk... contribs...] 00:54, 24 January 2014 (UTC)

...And Chrome is not "stock", anyway (Chromium core is available on Android, but a full Chromium is not). Zhaofeng Li [talk... contribs...] 01:09, 24 January 2014 (UTC—)

As previously stated, I support using File:Android 4.4.2.png as the screenshot instead of File:Android 4.4 with stock launcher.png. Since an RfC has been started for this debate, I'll explain my reason:

1. The previous screenshot (File:Android 4.4 with stock launcher.png) uses the old Jelly Bean launcher instead of the new one,^{firstpost.com article} which is an inaccurate representation of Android Kitkat, and it also lacks the translucent status bar which is a major UI improvement made in KitKat.
2. The launcher on File:Android 4.4.2.png is the open-source launcher called Launcher3 in AOSP^repo which features the new KitKat home screen design, not the proprietary launcher found on Nexus 5 called Google Experience Launcher by the public. Launcher3 is a part of AOSP, and therefore it should be considered "stock".
3. File:Android 4.4.2.png does not include copyrighted wallpapers or icons of proprietary Google Apps which are copyrighted visuals and replaces them with their AOSP counterparts. However, File:Android 4.4 with stock launcher.png contains copyrighted icons of non-stock Google Apps and that might add restrictions to the distribution of the screenshot. I am aware that there is a Google logo on the search bar of both screenshots, but removing it hurts the "stock" appearance, since it's a part of the AOSP source.
4. Device model does not matter. Himanis Das argues that File:Android 4.4.2.png is taken on a device (Samsung Galaxy S3) running a custom ROM which is not released by Google. Based on Dsimic's statements, "any clean AOSP build can be considered to be stock Android". The custom ROM in File:Android 4.4.2.png is AOSP-based OmniROM and few UI modification is visible on the screenshot(The custom ring battery indicator is enabled by default on OmniROM, but it's disabled on the screenshot). Therefore, it can be considered "stock Android".

Zhaofeng Li [talk... contribs...] 07:44, 25 January 2014 (UTC)

Some notes. One, we have the Chrome logo tagged as free because of the threshold of originality. Additionally, I mean "stock" as in, stock, unmodified. Not an unofficial branch like CM. But as long as it still appears exactly like how it is on a Nexus device or similar. ViperSnake151  Talk  22:29, 31 January 2014 (UTC)

Agreed, "any clean AOSP build can be considered to be stock Android" from above was intended to mean "any unmodified AOSP build can be considered to be stock Android". — Dsimic (talk | contribs) 00:02, 1 February 2014 (UTC)

I agree. I think it's okay as long as the UI is exactly like stock AOSP. About Chrome, I don't think it represents "stock" as it's closed-source. A question though, can we consider all AOSP components as "stock" and "default"? And can we consider all non-AOSP software (including the open-source ones) as "non-stock" and "non-default"? Take Chromium as an example, if Chromium is available on Android (as a full browser, not just WebView), can we treat it as "stock" software (And no, I don't think it's going into AOSP, but it's it will be open-source)? Zhaofeng Li [talk... contribs...] 07:56, 2 February 2014 (UTC)

Hm, that's a good question, and quite debatable. On one side, Android needs a browser, but it's not part of the AOSP; on the other side, including it makes an AOSP build no longer unmodified. Anyway, I'd vote for including Chromium, rather than bundling Chrome application. — Dsimic (talk | contribs) 22:22, 2 February 2014 (UTC)

Multitasking

In the section "Memory management", it says that When an Android app is no longer in use, the system will automatically suspend it in memory. To me this sounds like normal desktop multitasking, e.g. when an app calls sleep(). --Frederico1234 (talk) 23:19, 9 February 2014 (UTC)

Hello there! The main difference between Android and Linux (for example) is that Android applications don't have full control over their execution. Android activities are going through various states during application execution, so an activity can become really stopped by the Java virtual machine (Dalvik or ART), and not just sleeping on its own; that's why you need to implement Android services in order to have continously running operations as part of an Android application, for example. This paper provides a good further overview. — Dsimic (talk | contribs) 23:53, 9 February 2014 (UTC)

Thanks for your response and the interesting links! I had clearly misunderstood how multitasking works on Android. You were right to revert me. --Frederico1234 (talk) 19:59, 10 February 2014 (UTC)

I'm glad it helped. :) — Dsimic (talk | contribs) 20:14, 10 February 2014 (UTC)

Hatnote

Please change {{Other uses|Android (disambiguation){{!}}Android}} to {{Other uses|Android (disambiguation)}} per WP:HOWTODAB. Thanks. 82.132.213.152 (talk) 04:52, 17 February 2014 (UTC)

 Done Kap 7 (talk) 08:28, 17 February 2014 (UTC)

Can someone fix the lead section's grammar?

The Android article's lead section's grammar is wrong, can someone fix it? It says who where it should say which: Android is popular with technology companies who require a ready-made should become Android is popular with technology companies which require a ready-made. Sofia Lucifairy (talk) 19:50, 17 February 2014 (UTC)

Lead section cleaned up. — Dsimic (talk | contribs) 19:59, 17 February 2014 (UTC)

App Ops

I removed the section on App ops because it is just about 100% inaccurate, this has since been reverted by @Dsimic so here is my expanded reasoning: The section states that this was an application introduced in 4.3, it was not, it was a hidden preferences pane that Google used as "an internal testing and debugging tool";[5] it is not clear when this was added to the operating system. Some end users discovered it in 4.3 and published a trick to un-hide it. The section goes on to state that it was removed in 4.4.2, which is again wrong, it is still there, Google just made it more difficult to access. However, it can be accessed if you have root access on your device. Mentioning alternative apps is misleading as they also require root access—so they offer no benefit to a non-rooted user, and the benefit of these tools for a rooted user over re-enabling app ops is not explained. As it was never an official part of the operating system, I can find little discussion of it beyond Android blogs, which would not be considered reliable sources. —Jeremy (talk) 21:14, 10 February 2014 (UTC)

Hello there! Please allow me to spend some time re-researching the App Ops in detail (and I mean in detail :), and I'll come back with an update. — Dsimic (talk | contribs) 21:25, 10 February 2014 (UTC)

When you think there is an error somewhere, do not just delete the whole thing. Try to fix it or bring a conversation on the talk page. Just deleting does not show good intention on your part. —Sfierce (talk) 13:12, 11 February 2014 (UTC)

On the contrary, I think that removing incorrect information from articles is entirely appropriate. If someone writes in the Ford Focus article that this car can fly, I will remove it because it is clearly incorrect. The information that you added to the article was wrong, plain and simple, it also did not cite reliable sources, and the app recommendations appear to be a case of WP:NOTHOWTO. —Jeremy (talk) 16:30, 11 February 2014 (UTC)

I have changed it to say disabled (instead of removed) requiring root access to enable it. —Sfierce (talk) 13:24, 11 February 2014 (UTC)

I agree with JeremyA and don't mind if this content ends up being removed, but in the meantime I've rephrased it to be more accurate and avoid the trainwreck of a sentence that was "[App Ops], whose code was made available in Android 4.3, although in disabled state, was totally disabled in version 4.4.2, although root users can enable it." – Steel 12:00, 14 February 2014 (UTC)

Could you explain why you removed the information about third party privacy managers? Otherwise I will restore it. —Sfierce (talk) 10:06, 16 February 2014 (UTC)

Please refer to Jeremy's explanation above. – Steel 13:16, 16 February 2014 (UTC)

The new wording is different but not better. Why are third party privacy apps being presented as the solution when they have exactly the same requirements and limitations as App Ops? – Steel 19:40, 17 February 2014 (UTC) (Tag User:Sfierce)

In addition to what Steel says there are further issues: 1) I'm not sure what "To supply the lack of fine grained permission management" is supposed to mean. 2) Why highlight XPrivacy specifically? Why not a different tool? As an encyclopaedia we should not be in the business of giving app recommendations to our readers (WP:NOTHOWTO). 3) From Wikipedia's point of view I'm not sure if Android Police would be considered a reliable source. 4) Even if AP is a reliable source, an app review for a specific app is not a sufficient reference for this sentence. Although only one citation is used, I think this is an example of WP:SYNTHESIS—i.e reaching or implying a conclusion not explicitly stated by the source. As per Steel's edits, I think that saying that EFF have criticised Google for not allowing fine grained permission control in Android is (more than) sufficient.—Jeremy (talk) 20:14, 17 February 2014 (UTC)

Having modifiable permissions is a common request of Android users. XPrivacy is currently the only privacy manager that is easily installable. XPrivacy is an example of a privacy manager, just like there are other third party products cited as example in this article. It seems the article of androidpolice is valid as a source, but anyway there are more sources. If you want I can include more sources. I do not see any problem improving this article to let people know there are other easily installable privacy managers. Citing third party products is common on this article and changing that, we would need to remove lots of citations. --Sfierce (talk) 11:53, 18 February 2014 (UTC)

It's still not clear what relevance third party apps have to anything when they're no more widely available or easier to install than App Ops, which we have just criticised for not being widely available or easy to install. – Steel 14:51, 19 February 2014 (UTC)

Well, I've finally managed to re-research the whole thing about the "App Ops"... After all, I'd say that it should stay within the article, so I've rephrased the paragraph making the "App Ops" (hopefully) as neutrally described as possible. It was accidentally included in a few Android releases, but it was released and accessible to the end-users, thus I'd say it deserves to be written about. — Dsimic (talk | contribs) 21:44, 19 February 2014 (UTC)

I'm not sure the issue was one of neutrality, rather that the information being added was misleading, irrelevant, phrased clumsily, or just wrong. Unfortunately most of this is still the case. One example: where you state that, for 4.4.2 onwards, App Ops is still there but requires installation of third party apps to be used, implying that it didn't before. In fact it always required installation of a third party app to access and this therefore leaves a misleading impression of what exactly App Ops was before it was removed. Rephrased again. – Steel 11:24, 20 February 2014 (UTC)

Thank you for cleaning it up; I've intentionally added too many references so other editors can also decide on their notability. Went ahead and edited it further, for (hopefully) even more clarity. I'd say it's pretty much fine now, reflecting the facts related to the App Ops feature. — Dsimic (talk | contribs) 22:55, 20 February 2014 (UTC)

Structure

There is a fair bit of overlap between the intro section and the later sections. Really this needs to be rationalised. ---CPES (talk) 21:47, 20 February 2014 (UTC)

Are you referring to the lead section? — Dsimic (talk | contribs) 21:58, 20 February 2014 (UTC)

Yes, that's it. Appologies for using the wrong term. By the way, although I have done a load of copy editing, I still found the original article to be full of information (the hard part) and relatively easy to read and digest. The lead section was a bit daunting though; thats why I divided it into sub sections. --- CPES (talk) 22:12, 20 February 2014 (UTC)

No worries about using the wrong term – the real trouble is you've pretty much destroyed the lead section in this article. :) Please read the above linked section of the Wikipedia's Manual of Style describing the lead section's intended layout; in a few words, lead sections are there to summarize articles, so repeating the content is actually what's intended. I'll be returning back the old lead section layout in a few minutes. — Dsimic (talk | contribs) 22:31, 20 February 2014 (UTC)

Ok, normality restored. :) CPES, in case you're feeling bad, don't – your intentions were good, and the only missing piece was that you haven't made yourself accustomed to the Wikipedia's Manual of Style. It's a long text to read, I know (been there, done that), but it's a good text, applicable outside Wikipedia as well.

Also, I went through all of your edits regarding language cleanups and simplifications, and unfortunately they were pretty much oversimplifying the content, causing a number of fine details to disappear. I know that way it would sound more approachable to Joe Averages, but losing the details—unfortunately—isn't an option, at least not in my opinion. — Dsimic (talk | contribs) 23:33, 20 February 2014 (UTC)

Hello Dsimic, I appreciate your concern about the Android article and have no hang-ups about anyone changing my edits to improve any article- in fact I welcome it. I also appreciate your polite approach. But I don't agree with your rather sweeping statement about 'pretty much destroying the lead section'. Ironically, I consider the reverse to be true.

I do know that Wikipedia's Manual of Style describing the lead section's intended layout is: in a few words, lead sections are there to summarize articles. That was my concern about the lead section as was; it didn't just summarise, it gave too much detail which was repeated later. It didn't give the average reader a simple, consistent, and complete overview either.

I do accept that giving the lead section paragraphs headings was against Wiki style rules though- I was going to sort that out. In the meantime the paragraph headings made the lead section more digestible.

I can't agree that my language cleanups and simplifications [and subject grouping], 'oversimplified the content, causing a number of fine details to disappear'. I don't think any details that were originally there were lost- it may have seemed like it because the language was rationalised and shortened but that only made it more readable. My objective with edits is always to make the article more understandable to the average reader, especially where technical terms are concerned.

I suggest that the article would be much improved if it were reverted to my last edit and then the lead section sub titles deleted to comply with Wiki style. Once that is done, we could discuss any specific detailed issues you may have. That way the article would be more readable and more easily understood by Mr Joe Average.---CPES (talk) 08:49, 23 February 2014 (UTC)

Hello there! I'm sorry if "pretty much destroyed the lead section" sounded harsh, as that wasn't my intention; however, introducing subsections into the lead section is actually removing content from the lead section, as everything ending below the table of contents no longer belongs to the lead section.

Went again through your edits to the lead section, and—while mentally deleting the sub-sectioning—I'm still under impression that a few important details were lost, and the language style was made worse. For example, let's compare these two versions of the opening paragraph:

Original version:

Android is an operating system based on the Linux kernel, and designed primarily for touchscreen mobile devices such as smartphones and tablet computers. Initially developed by Android, Inc., which Google backed financially and later bought in 2005, Android was unveiled in 2007 along with the founding of the Open Handset Alliance—a consortium of hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices. The first publicly available smartphone running Android, the HTC Dream, was released on October 22, 2008.

Version including your edits:

Android is an operating system primarily for touchscreen mobile devices, especially smartphones and tablet computers. It is based on the Linux kernel, and was developed by Android, Inc. with Google's financial backing. But in 2005 Google aquired Android Inc. 2007 brought the unveiling of Android and the founding of the Open Handset Alliance, a consortium of hardware, software, and telecommunication companies devoted to advancing open standards for mobile devices. HTC released the first Android smartphone, the HTC Dream, on October 22, 2008.

In your version, parts "... operating system primarily for ..." and "... financial backing. But in 2005 Google ..." don't sound very well, as they look like something is missing, or introduce too short sentences. Sorry, but to me that isn't better than the original version. Also, HTC Dream was the first publicly available smartphone running Android, while there were other prototype devices as described here.

Anyway, please don't get me wrong, I'm by no means married to this article or to its current layout, so let's also hear comments from the other editors. — Dsimic (talk | contribs) 21:35, 23 February 2014 (UTC)

Per WP:LEAD, the lead has to summarize the entire article. ViperSnake151  Talk  21:25, 23 February 2014 (UTC)

The Iron Grip article

The Iron Grip article has been used to source 6 items in this article. Most of the boiling down to "Android is Open source with proprietary components" and all with other sources. I think we should be careful about sourcing an opinion piece as if it is fact, it may contain facts but overall it is an opinion piece and the facts can and, for the most part already have been, sourced better.Ryftstarr (talk) 15:55, 24 February 2014 (UTC)

Tl;dr. :) — Dsimic (talk | contribs) 21:29, 24 February 2014 (UTC)

Stock launcher?

Android is extensible. It has hooks so that manufacturers or users can change its launcher or many other features. For instance, the dock can be removed or changed to be multi-page.

Some of this article appears to be fixated on default features in some particular version of Android. Which manufacturer is featured is unclear, but presumably the Google Nexus is the only really stock vanilla version of Android.

Changing the launcher on Android is as simple as running an App. In fact, Android will then ask which default launcher to use the next time the Home key is pressed. It is a built-in feature of the stock Android OS, unlike its main rivals.

Some edits I have made here have been reverted twice. I don't see any evidence for the reasons. The stock Android allows the launcher to be changed. 51kwad (talk) 08:26, 3 March 2014 (UTC)

To me, that's perfectly fine to be included into the article; even more, we need to provide that in order to maintain a WP:NPOV. I've just touched it up a bit so the addition is slightly more neutral and with improved clarity, please check it out. — Dsimic (talk | contribs) 19:58, 3 March 2014 (UTC)

unaccurate information in para Security and privacy:

Before installing an application, the Play Store displays all required permissions: this paragraph is very confusing as you can still install an APK with the inbuilt android apk installer (which i beleive happens eitehrway) and it would still ask you weather you want to grand the spesified permissions or not. — Preceding unsigned comment added by 109.66.54.213 (talk) 13:38, 11 March 2014 (UTC)

Yeah, but that section is describing privacy/access control mechanisms which allow an user to deny specific privileges to particular applications after the installation. What you're describing is the "bulk approve" installation-time procedure. — Dsimic (talk | contribs) 04:28, 12 March 2014 (UTC)

true, however it does not have to do anything with google play store, you dont have to link them.

what i mean here is that a reader might think that they must use the store in order to be able to deny spesific privileges which is missleading and not true. 109.66.54.213 (talk) — Preceding undated comment added 04:34, 12 March 2014 (UTC)

Could you, please, quote the exact part which you find confusing? — Dsimic (talk | contribs) 04:43, 12 March 2014 (UTC)

unless access permissions are explicitly granted by the user when the application is installed. Before installing an application, the Play Store displays all required permissions: "

if im not using play store to install my game/app i might think that i wont be able to spesify app priviledges. i would put it something like "upon installing an application ...(as in regardless of what methood i choose to install it with)" 109.66.54.213 (talk) — Preceding undated comment added 07:06, 12 March 2014 (UTC)

Hm, but what about sideloading via ADB – no questions regarding application permissions are asked in that case? Having that in mind, not all application installation methods are checking for granting the privileges. — Dsimic (talk | contribs) 07:12, 14 March 2014 (UTC)

thanks for your replay , well you could make an exception for ADB you do not cover all instaltion methoods anyway. why did you choose to use play store as the example? is it becauase it is the most used one? 37.142.221.225 (talk) 11:55, 20 March 2014 (UTC)

This article is dealing primarily with the stock variant of Android as created by Google, what makes Play Store the official way for getting/installing Android applications. — Dsimic (talk | contribs) 00:32, 22 March 2014 (UTC)

Semi-protected edit request on 28 March 2014

Version	Code name	Release date	API level	Distribution	Crash Rate/Reliability, [lower is better]
4.4	KitKat	October 31, 2013	19	2.5%	N/A
4.3.x	Jelly Bean	July 24, 2013	18	9.6%	0.7%
4.2.x		November 13, 2012	17	17.1%	0.7%
4.1.x		July 9, 2012	16	35.3%	0.7%
4.0.3–4.0.4	Ice Cream Sandwich	December 16, 2011	15	15.2%	0.7%
3.2	Honeycomb	July 15, 2011	13	0.1%	N/A
2.3.3–2.3.7	Gingerbread	February 9, 2011	10	19.0%	1.7%
2.2	Froyo	May 20, 2010	8	1.2%	N/A

Jay m canada (talk) 19:50, 28 March 2014 (UTC)

• Not done: it's not clear what changes you want made. Please mention the specific changes in a "change X to Y" format. — {{U|Technical 13}} ^{(t • e • c)} 21:51, 28 March 2014 (UTC)

Crash rate/reliability column, although its value to the market share table is not explained. – Steel 22:29, 28 March 2014 (UTC)

Powered by Android

So this a good example of Google trying to strengthen the Android brand and mentioning it in reception is entirely appropriate given it follows the discussion of forks and things. However it's currently mentioned twice in the article, under both licensing and reception, just a few paragraphs apart. From a readability point of view this is not optimal, and the article is already very long without us repeating ourselves. And among other things it's not a particularly good example of 'leverage' over manufacturers - a small note on the boot screen is probably the most trivial and least onerous of all the demands Google makes of OEMS, some of which are quite significant.

Hence my preference to just mention this once, under reception, where it fits quite well, and remove it from licensing, where it doesn't. Opinions? – Steel 22:46, 31 March 2014 (UTC)

Hm, to me it fits better into the licensing section, rather than into the reception section. — Dsimic (talk | contribs) 22:59, 31 March 2014 (UTC)

Privacy

Currently Security and privacy section only says about malware and NSA. While both of these concerns are popular and huge, is there any reason why other privacy concerns are not mentioned: Google's own surveillance, traffic analyzis, etc? May be the section should be divided in three subsections: malware, government and private surveillance respectively? Or am I missing something? — Dmitrij D. Czarkoff (talk•track) 23:00, 24 April 2014 (UTC)

FYI: "Rooted Android" is not Android, it seems

From Android 4.4 Compatibility Definition:
Chapter 1. "the Android Open Source Project is both the reference and preferred implementation of Android."
9. "Device implementations MUST implement a security model consistent with the Android platform security model"
9.4. "Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However such alternative execution environments MUST NOT compromise the Android security model"..

A "rooted Android" (not possible from "within" Android, or from any APK) would violate, I assume, and then not be Android anymore:
"Alternative runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications."
"Alternative runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID."

3.1: "The managed (Dalvik-based) execution environment is the primary vehicle for Android applications."

"because it breaks Google’s CTS. Root access is planned to be COMPLETELY removed by default, and to be downloaded in a separate package. Users don’t use root anyway, they say. All of this because of a future CyanogenMod Phone, which has to pass CTS to get Google Apps officially." Forking Android is ok, but as Android is a trademark and Google requires the above to get it, rooted Android doesn't belong in the Wikipedia article or discussion (unqualified). comp.arch (talk) 22:32, 19 April 2014 (UTC)

Google doesn't get to say what belongs in an Android article. Bhny (talk) 23:07, 19 April 2014 (UTC)

The article is about Android. Android is stock Android ("AOSP"), or Android, with bundled applications, bearing the trademark Android, eg. what is in Samsungs mobile phones. The homescreen is just another app (eg. TouchWiz), just modifying the UI slightly, not changing, the inherant nature of the operations system, what apps are compatible. comp.arch (talk) 23:39, 19 April 2014 (UTC)

You prove (I'll suppose you are right for a moment – I just don't want to get into legalize) that rooted Android would not be eligible to Android trademark. Now, please, prove that it won't be Android operating system. Hint: you can't. Rooting is simply privelage elevation. It changes relationships between users of operating system, but it doesn't change the system itself. "Hacked" Linux server is still Linux server. Rooted Android is still Android. Trademarks are from marketing department, they have nothing to do with essencial properties of software. — Dmitrij D. Czarkoff (talk•track) 23:16, 19 April 2014 (UTC)

I (and Google, the WP:PRIMARY source, see first quote above) am saying the authorative source code ("AOSP") defines what Android is. A fork, such as rooted Android is something else (might be similar). CyanogenMod eg. or other rooted versions are not Android. They are based on Android, just like Ubuntu is based on Debian. I'm not sure what OS/phone you are using, is it CyanogenMod? That one may be more Unix-like (or equally), I don't know. I would count it in the "Android OS Family" - an "Android", not the Android. Fire OS, probably follows the security model to the letter (I wouldn't/couldn't know for sure) and is probably closer to Android, in some ways at least. Both have their separate articles. comp.arch (talk) 23:39, 19 April 2014 (UTC)

"Hacked" Linux in what way? The details matter. You can go in with a hex editor and change Linux to Windows :) You can change only userspace, or you can change the kernel, then it is no longer Linus's mainline kernel (if that's what you started with). comp.arch (talk) 23:45, 19 April 2014 (UTC)

"Trademarks are from marketing department, they have nothing to do with essencial properties of software." The spec for the operating system defines the essential properties - "compatibility" of the operating system. That what this technical document is. The trademark policy just depends on it, and the official name Android is part of that policy. And trademarks are the legal way prevent confusion. The license, Apache 2.0 allows you to change and even distribute, but not make confuse Android with something else and Google makes the rules where you draw the line, trying not to repeat some of the Unix's mistakes. comp.arch (talk) 23:53, 19 April 2014 (UTC)

Ubuntu and Debian are the same operating system – GNU/Linux. Equally, CyanogenMod and AOSP are the same operating system – Android. Even the CTS document you've linked says that AOSP is merely an implementation of Android.

Speaking of CTS document... Do you seriously believe that clock widget (3.2.3.1) may be a defining factor of operating system? AOSP without desk clock is not Android any more?

You should also note several facts about rooting:

1. Rooting doesn't change software. At all. It basicly sets permission bits, modifies configuration files and adds a simplistic executable that calls a system call from vanilla Android Linux kernel.
2. Rooting does not violate Android security model. As the name implies, rooting is a reconfiguration allowing user to escalate privelage arbitrary – to make use of security model of the Unix system that comprises the lower level of Android.

Now, I am really tired of this. Please, next time before posting anything make sure that you have references directly supporting your statements – you argue against the widespread opinion, which doesn't appear to be ever challenged before. — Dmitrij D. Czarkoff (talk•track) 02:22, 20 April 2014 (UTC)

Can we agree on one thing. Let's base the article (and Infobox, that should summarize it non-controversially) and discussion on the reference implementation (AOSP) or at least some compatible version (when it applies), that is bearing the Android name. Some of the things you've said seem based on some other version, that might be compatible or strictly not. I want to find out if Android ("AOSP") is clearly Unix-like, and will not object to "Unix-like" until I'm sure. The CDD (it's not the CTS) seems awfully comprehensive about including apps; note that part is not in the 3.1 Managed API section (Dalvik, that is required), but under "soft" API (3.2), and seems to have nothing to do with app compatibility (or security model/rooting):

3.2.3.1. Core Application Intents

The Android upstream project defines a number of core applications, such as contacts, calendar, photo gallery, music player, and so on. Device implementations MAY replace these applications with alternative versions.

I would include 3.1 "Dalvik", as Google does, as a part of the OS (for app compatibility). Not just the Linux kernel, just as you seem to do, implying by GNU/Linux that (some of) the GNU userland defines "Linux" as an OS (for compatibility sake), that is also true. Your nr.2 seems wrong violating "MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications" You may have missed "[CyanogenMod] breaks Google’s CTS [Compatibility Test Suite]. Root access is planned to be COMPLETELY removed [because it has to] pass CTS"], that suite tells if the implementation is incompatible with Android incompatible. comp.arch (talk) 22:58, 20 April 2014 (UTC)

Your nr.2 seems wrong violating "MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications"
— User:Comp.arch

No, it doesn't. From the context of 9.4. (and the whole "9. Security Model Compatibility" chapter) you may see that "Android permissions" are the permissions withing Dalvik infrastructure (web access, personal data access, sms sending/reading, etc). Thus the text you quote basicly means that alternative implementation should not provide these permissions when it is expected not to do so.

Unix permissions are rather different thing, and they are managed completely separately from Android permissions. Access to "root" privelage on Android doesn't change the way Android permissions are assigned and enforced, so rooting doesn't violate this rule.

I would include 3.1 "Dalvik", as Google does, as a part of the OS (for app compatibility), not just the Linux kernel
— User:Comp.arch

Dalvik is obviosly a cruicial part of Android operating system and the only part allowing to separate Android from any other Linux-based Unix-like. This fact has nothing to do with OS family though. One may even argue that this fact does not stop Android from being Linux distribution, as you may find in the reference of this article.

Can we agree on one thing. Let's base the article on AOSP, the reference implementation or at least some version bearing the Android name.
— User:Comp.arch

No amount of lawyering will discard the following facts:

1. Trademark doesn't define operating system. Whether any "version" is "bearing the Android name" (trademark, actually) or not is completely irrelevant to the charactiristics of Android operating system.
2. Exploitation doesn't change essense of expoited OS. Exploited Linux server is still Linux server, pirated Windows is still Windows, rooted Android is still Android. Google's trademark policies and related legalize has no power over it.
3. Independent reliable sources unanimously discuss rooted Android installations as "Android" installations, so this is WP:NPOV that should be covered in the article, even if they are all wrong and you are right. See WP:FLAT for explanation.

I may assure you that you won't be able to drag your pet idea through this article without providing really exhaustive proof – in form of citations, directly and unambiguously supporting your position, – of general acceptance of your theory. — Dmitrij D. Czarkoff (talk•track) 00:42, 21 April 2014 (UTC)

You may have missed "[CyanogenMod] breaks Google’s CTS [Compatibility Test Suite]. Root access is planned to be COMPLETELY removed [because it has to] pass CTS"], that suite tells if the implementation is incompatible with Android incompatible.
— User:Comp.arch

CTS is Google's instrument allowing to determine whether particular implementation may be allowed to use Android trademark. This is something Google has authority over. But saying whether particular operating system is the same operating system as the one known under name "Android" is something Google doesn't have authority over, and something CTS can't help with.

That said, this citation says much less about rooting and being Android then you believe it to say. First, it doesn't give any details about the technical side of affairs: is the problem with CyanogenMod's handling of root, or the root access in general? Is removal required, or is it just the most practical thing to do in a short term? In the end, the post is half a year old (quite a lot of time in the world of mobile appliances), and there were several releases since, including preview releases of the new major version; root access was never dropped. — Dmitrij D. Czarkoff (talk•track) 01:00, 21 April 2014 (UTC)

Now, about where you first quote me, if I'm wrong in my reading of the Google's Compatibilitity Definition Document (CDD) (then I'm not alone in this misunderstanding, see last quote) I apologize to you and stand corrected. "Uncontrolled customization can, of course, lead to incompatible implementations.[6] comp.arch (talk) 02:41, 21 April 2014 (UTC)

I wouldn't say that rooting should be considered as "uncontrolled customization". Sure thing, with root access you can change whatever you want and even break things; however, using a hammer could also lead to an "uncontrolled customization", and even in a much quicker way. :)

As I've already provided as an example, many Linux installation CDs/DVDs lack many of the common utilities due to being excluded from their busyboxes etc. Anyway, that doesn't change their Unix-like status. A very similar set of "issues" applies to various Linux kernel–based embedded systems. To me, if something uses Linux kernel and has a standard "root and below" filesystem layout, that's Unix-like. It could be argued whether Android is a Linux distribution or it isn't, but it is Unix-like no matter what lawyers wanted it to be. — Dsimic (talk | contribs) 12:59, 22 April 2014 (UTC)

I didn't want to drag this discussion on but since you bring it up. Regarding "standard "root and below" filesystem layout", I've been looking into what I can do with the add-on terminal emulator I found, and the filesystem layout seems non-standard to me, not following: the Filesystem Hierarchy Standard "defines the directory structure and directory contents in Unix and Unix-like operating systems, maintained by the Linux Foundation." I can't find /usr/bin, or grep (at least not in path), or vi, or the standard Unix tools I use every day; Nor Linux Standard Base either ("lsb_release -a" doesn't work). That is, my stock out-of-the-box, admittedly only Android 4.1.1, doesn't feel much Unix-like (or "Linux-like") to me as a user and I can't even make it so using standard installation procedures (without hacking/rooting). What you can do as a programmer is add Unix binaries to your Android apps for their use. I'm not even sure where they land so I haven't checked if they are only usable from within that app, that is locked in the app's sandbox or readable from other apps such as the terminal to make Andoid also feel like Unix-like for the user, providing tools to use together. It seems maybe it could be done but if I understand right only as a system within the system, then it might as well have been a virtual machine. comp.arch (talk) 14:06, 22 April 2014 (UTC)

You're right, it isn't a standard filesystem layout, but it is a "root and below" layout. Anyway, that doesn't prevent you from creating /usr/bin and adding a set of standard utilities. By the way, have you ever worked with Solaris boxes? If not, you'd be surprised how different they are from something that's "Linux-like", and the only solution for making Solaris less weird (even ls and ps act weirdly) and more "Linux-like" is to install numerous Sunfreeware packages; that would also qualify Solaris as not being Unix-like in its out-of-the-box state. — Dsimic (talk | contribs) 14:27, 22 April 2014 (UTC)

Yes, we still use Solaris (and have used HP-UX) on older machines. They had /usr/bin. Permision denied for "mkdir /usr" etc. so I can't on my "standard Android" (I'll see if I can make it "usable" from non-standard place). I guess you meant all filesystem under one root (unlike DOS/Windows, RISC OS, Amiga and CP/M?). comp.arch (talk) 09:35, 25 April 2014 (UTC)

Exactly, the typical Unix-like layout. — Dsimic (talk | contribs) 02:05, 26 April 2014 (UTC)

There are many Unix-like systems out there where you have read-only root. LiveCDs, embedded systems, media players, etc. Many of them are even as POSIX-compliant as you name it Linux distro. Also:

u0_a58@saga:/ $ which vi
/system/xbin/vi
u0_a58@saga:/ $ which sed
/system/xbin/sed
u0_a58@saga:/ $ echo $PATH
/system/bin:/system/xbin

Compare this to, say, GoboLinux.

The actual problem is that definition of Unix-like is vague enough to fuel lengthy flame wars. Nearly every system out there include more or less complete Unix compatibility layer. My personal checklist is:

1. Does the OS include reasonable amount of common Unix interfaces?
2. Do those interfaces represent lowest layers of OS?

BSDs, Linux, OS X, Solaris, etc pass these tests. Android passes these tests. Windows (until Windows 8) and Haiku pass the first test, but fail last one. Hense the respective conclusions. Before NDK was release one would argue that Android could dump Linux kernel and get rebased on minimalistic microkernel with Dalvik right on top of it, and still essencially remain the same, but now that every single POSIX-compliant C program is proper Android software, I just see no room for such speculation. — Dmitrij D. Czarkoff (talk•track) 10:29, 25 April 2014 (UTC)

Thanks, wasn't aware of GoboLinux. When I judge if a system is Unix-like I go by Unix-like#Functional UNIX: "Broadly, any Unix-like system that behaves in a manner roughly consistent with the UNIX specification, including having a "program which manages your login and command line sessions" ". That is if you mean "lowest layers of OS" as in the kernel API (of eg. Linux kernel), then I disagree that it defines an OS or Unix-like in general. I'm not weded to where the programs reside, you can change with PATH, but you have to be able to use programs together that have been installed independently. That is the Unix way for me at least, see Unix philosophy. I wasn't born when Unix was born, and might not know enough about "first-Unix-like". I would say Unix without root is ok (non-multi-user, still multi-user was part of Unix in the beginning, and Android isn't (always) multi-user) if you can still install Unix programs separately, not just in a sandbox, to be used together. I assume this is your "Android" (rooted?) phone above; mine doesn't have vi or sed there either, but /system/xbin is writeable and in PATH, so I was wrong, it seems, about not-user-installable. Then your "Android distro" is more Unix-like then my out-of-the-box Android, but mine can be made (more) Unix-like. Thanks. comp.arch (talk) 11:57, 25 April 2014 (UTC)

Neither many bootable parts of Linux installation CDs come with a full set of userspace utilities, and at the same time they have no login or session management. Also, you can't run X Window applications on an embedded Linux system which even doesn't have a GPU or a framebuffer device, and most of them even have no logins enabled; moreover, they ususally come with almost none of the standard userspace utilities. Just two more examples of what could also easily fail the Unix-like verification. — Dsimic (talk | contribs) 02:05, 26 April 2014 (UTC)

Semi-protected edit request on 13 April 2014

In section 'History', paragraph 3 I would like to suggest adding the following information: According to Dianne Hackborn, who worked in the engineering team of Android, when the iPhone was unveiled, this announcement did not cause a complete turnaround in Google plans, since there was a second prototype called 'Dream' which already had a touchscreen and several new sensors, etc. The arrival of the iPhone only caused them to concentrate more on the second, touchscreen-based prototype and to give up the 'Sooner' model.

Source: http://bgr.com/2013/12/20/iphone-sooner-dream-story/

Hiwasgehtabwasmachstduso :) (talk) 20:00, 13 April 2014 (UTC)

Question: Why? — {{U|Technical 13}} ^{(t • e • c)} 13:41, 27 April 2014 (UTC)

USB & MTP

No mention is made of the move to MTP as the main method of connection between the Android OS and PC's. Should this be added? There are differences between the methods of connection. ICS-feature-mtp — Preceding unsigned comment added by 60.242.152.37 (talk) 01:15, 28 April 2013 (UTC)

Clumsy and long introduction

Won't someone take the time to thoughtfully can clearly rethink, and then rewrite the whole intro? — Preceding unsigned comment added by 105.236.209.166 (talk) 15:29, 15 May 2014 (UTC)

Ugh, not again. :) In a few words, the lead section has been already edited and reworded a few times, additionally followed by brief discussions, and its current version isn't that bad. — Dsimic (talk | contribs) 06:36, 17 May 2014 (UTC)

Software architecture

I introduced a section named software architecture. Subsections are

• "Linux kernel" with link to Linux kernel and an explanation of the Android-specific chnages with references
• "C standard library" with link to Bionic (software) and a sentence about it
• "Graphical user interface" at least this part should mention SurfaceFlinger, references welcome
• "Applications" with the first "main" link to Dalvik (software)
  • IMHO this section is major crap with links to "Google Play" or the "Amazon Appstore" without mentioning the technical necessities, features and advantages of applications

At the moment the article contains in the section "Development" the subsections:

• Linux kernel
• Software stack

IMHO these belong into "software architecture". Any takers? User:ScotXW^t@lk 20:58, 23 May 2014 (UTC)

I have reverted these edits pending further discussion. Structurally this has introduced three new subsections each with only one line of content, which looks bad and is the hallmark of low quality Wikipedia articles. And most of the new content introduced just duplicated the exact same content already present further down the article. Further the changes to the section titles (namely 'Features' to 'Software architecture') subtly alter the focus of the article away from a general explanation of what Android is and does for the user, and its impact on the world, towards a simple list of its technical specifications. I think we as editors need to bear in mind that this article is intended for the general audience, and it's not a replacement for http://developer.android.com or some development manual. Obviously the technical details of Android are relevant but this should be confined to its own section (currently titled 'Development', should this need to be changed) and not allowed to take over the rest of article. – Steel 10:08, 24 May 2014 (UTC)

I agree with Steel, this is an article intended for a broad audience and it does that job pretty well. Also, ScotXW's edits introduced not that much of a new content, while the previous layout of the article was better to me. Anyway, went ahead and restored those additions where suitable so all new content is preserved – please check it out. — Dsimic (talk | contribs) 10:45, 24 May 2014 (UTC)

biased

This article, especially the parts discussing sales and market share, seems rather biased and almost as if the language was carefully selected to mislead. I would really encourage this community the thoroughly review this article and to actually vet the sources cited in it. 69.122.4.110 (talk) 05:58, 4 June 2014 (UTC)

Could you please be more precise? What figures do you believe to be wrong, and what figures do you suggest to use as replacement? Same about sources. — Dmitrij D. Czarkoff (talk•track) 06:30, 4 June 2014 (UTC)

Hugo Barra

I added a portion to the introduction regarding Hugo Barra, who - in addition to serving as the 'face' of Android, product spokesman at Google I/O etc. - directed product for Android software and hardware. I'm not sure, however, if the selection offers too much weight to Barra's role - i.e.; am I going into too much detail? He is certainly a key individual in the evolution of Android and deserves inclusion. Thoughts? Wintertanager (talk) 04:07, 12 June 2014 (UTC)

This article is about the OS so I think we should probably avoid lots of text about individual people. This article is long enough already and most (all?) of the significant Android people have bios anyway. – Steel 18:37, 15 June 2014 (UTC)

New logo

I saw a new Android OS logo with a new font that will replace the current logo on the wiki page about Android. The new logo looks like this: http://cdn0.vox-cdn.com/uploads/chorus_image/image/33867049/android-logo-g-watch.0_standard_640.0.png and it was featured at the end of the YouTube video here and on the official Android website. Will this new Android logo appear on the Wikipedia page about the Android operating system? Npx122sy (talk) 21:09, 25 June 2014 (UTC)

I could upload the new logo, but you need a better source of the image. It has officially changed.Frmorrison (talk) 22:08, 25 June 2014 (UTC)

(Kernel only?) updates to older Android versions

Hi, I recently got two updates for my Samsung Galaxy S III Mini:

Kernel version
3.0.31-1549853
dpi@DELL148 #2
SMP PREEMPT Thu Jun 12 11:22:11
KST 2014

The date coincides with 4.4.3 (to soon for 4.4.4 CVE-2014-0224 security update?). The other update was days before (4.4.2?) and was also with 3.0.31-sometingelse with a date in December and I assume "KST 2013" (remember for sure the 2013 part). I assume the security update for 4.4.4/CVE-2014-0224 could be in the pipeline (or 4.1.2 not affected, can't see for sure) or maybe not.. Anyone know what these updates are? Only kernel? Backported Android 4.4.x-Linux kernel (3.4+.x?) down to 3.0.31? Should I assume nothing above the kernel has not changed as Android version/API is not changed? Would all this mean that Google supports older Android versions or maybe not and that Samsung/vendors do it? comp.arch (talk) 11:20, 25 June 2014 (UTC)

The update to your S III Mini is not Android 4.4.3, but could be 4.4.2. Samsung decided to update the S III to Kitkat. A Kernel update does not change your Android version. Frmorrison (talk) 22:08, 25 June 2014 (UTC)

It's not 4.4.2, it's still 4.1.2 as it's always been. I assume nothing from (non-kernel space) 4.2.x (or never) is backported, just wanted to be sure. Does Google still patch the Linux kernels or has everything been mainlined? Still those patches are probably the same now for several Linux kernels that have been used with Android. comp.arch (talk) 16:55, 26 June 2014 (UTC)