Talk:Android (operating system)

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

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)

Is Android Unix-like (without rooting)?

I took Unix-like out as, I define Unix-like as "Unix user program"-compatible, and Uniwersalista, reverted. I hesitate to revert him, as he could be right. In some sense it seems more Unix-like than I thought, but it might still be less wrong than right. See: Talk:Unix-like#What_constitutes Unix-like. Please discuss the general issue there (eg. we would agree Firefox OS is not Unix-like) but Android specific here. I installed some terminal (Dalvik, not "Unix"-program, some seem less capable without root) and could do:

ls

but not:

ls |wc -l

as wc was not available. I can not(?) install wc with Google play? apt-get? compile? How would I get my Unix programs in (without root)? Clearly the Unix way is at least not emphasized and while it seems in has pipes what can you pipe into? comp.arch (talk) 12:26, 31 March 2014 (UTC)

To me, Android is Unix-like, despite the fact it doesn't run standard shell commands out-of-the-box. If Android, as such, isn't Unix-like, then many bootable Linux installation CDs/DVDs aren't too, as many of them are missing some of the standard shell commands as not compiled into their busyboxes etc. Of course, all that can be added. Hope it makes sense. — Dsimic (talk | contribs) 22:20, 31 March 2014 (UTC)

But you can easily add the programs (if not might be based on Linux kernel but not an OS, see below). Maybe nobody just wants to with Android as it is not targeted as a command line OS. I'm just not sure you can without porting. If you need porting you may as well say its a different "OS family" (you can port Unix programs to Windows too). comp.arch (talk) 11:46, 1 April 2014 (UTC)

What do reliable sources say. If reliable sources say it is Unix-like we can report that in the article. If other reliable source say it is not, we can report that to. If they are silent on the subject then we should say nothing. —Jeremy (talk) 23:03, 31 March 2014 (UTC)

One reliable source even says that Android is a Linux distribution. It can't be that without being Unix-like, right? — Dsimic (talk | contribs) 23:09, 31 March 2014 (UTC)

I say it can. The Linux kernel only is not an "Operating system", you can't boot into one and run user supplied programs. Since the beginning Linus used bash with his kernel to make it Unix-like. All traditional Linux distributions have used bash or a some shell replacement to maintain it's Unix-likeness. If you take that out or something fundamental it can still be "Linux" but no longer Unix-like. Does Android allow installing "Unix programs" (runnable from a shell, leave X-Window programs out of this)? As programs have to use Dalvik, isn't there porting involved? comp.arch (talk) 11:37, 1 April 2014 (UTC)

Android programs don't have to strictly use Dalvik, that's why Android NDK exists, for example. You can run any Linux program on Android if you also install all of the dependencies, for example by chrooting into a whole Linux distribution; you can even get something like that from the Play Store. — Dsimic (talk | contribs) 20:04, 1 April 2014 (UTC)

I know about the NDK, but apps have to start in Dalvik first. I'm not sure if the porting is easy. Will only a generic "wrapper" do, that would work for (all) C standard Unix programs? Still would be a hassle and I wouldn't call it supporting Unix. Clearly it is not meant to (some C code yes, however). The Debian link you gave requires root so it's Android is not "supporting" Unix there. The other link is less clear but I clicked on a similar project from it that says: "THIS APP REQUIRES ROOT : ADVANCED USERS ONLY". In any case at least Android is not Unix like without hacking and/or modification. comp.arch (talk) 09:14, 2 April 2014 (UTC)

I wouldn't make decisions based on whether hacking or modifications are required or not; if we had no hacking around, we'd have no things such as Linux or various BSDs. If we'd take that route, many bootable Linux installation CDs/DVDs also couldn't be classified as Unix-like (what wouldn't make much sense, in my humble opinion), as they lack pretty much everything Android also lacks out-of-the-box; Ok, they don't run Java applications. :) By the way, this thread is quite interesting, and it pretty much concludes that Android isn't Unix-like. — Dsimic (talk | contribs) 14:41, 2 April 2014 (UTC)

I would say if sources do not agree with me they are not reliable :) The reliable sources would confirm this.. comp.arch (talk) 12:00, 1 April 2014 (UTC)

Czarkoff obviously disagrees. Perhaps we can discuss it further? — Dsimic (talk | contribs) 02:33, 16 April 2014 (UTC)

Yes, I obviously disagree:

1. One may use Android market app to install missing parts of Arch, Debian or Ubuntu userland on Android and use it as any other Unix-like system – even as a mobile failover node for production server.

2. There is "prior art" to Android+Dalvik combination: NeXTSTEP also had huge custom runtime on top of Berkley-style Unix, but even Jobs admitted it was still Unix.

— Dmitrij D. Czarkoff (talk•track) 06:59, 16 April 2014 (UTC)

1. I might be wrong, but a lot of the apps I see require root (that isn't available by design). Can you point me to one non-root app that adds any of these? Still is it Unix-like until then? Is Windows NT (already POSIX compatible) Unix-like before adding Windows Services for UNIX?

2. I have to look into NeXSTEP, did it only have a framework that most programs used or had available but was optional? Starting inside Dalvik in non-optional in Android for user-supplied programs. It seems JavaOS-like to me :) More than Unix-like.

3. Android doesn't have a CLI, where can I go in and compile my own Unix programs from source that is very much Unix-like to me..

I do not have much time now, but would really like to know more. What I found so far: [1] [2] [3]. comp.arch (talk) 09:18, 16 April 2014 (UTC)

1. Of course they require root for installation, as does every Unix-like system. FWIW installing software from Play Store also requires root, and corresponding permissions are granted by infrastructure.

2. NeXTSTEP is now MacOS X, so yes, it had framework that nearly every program used. Of course there were cat, sed, cp, rm and other utilities that are present on most Unix-like systems (including Android). MacOS X and Android are absolutely identical in this regard.

3. Android doesn't have pty support because it wasn't compiled in. You may compile custom Linux kernel without pty support as well. Nothing of difference. (FWIW my phone has terminal emulator as stock package.)

4. If you replace bionic with OpenBSD libc in year 2000 in that article, it will mostly hold true; if you replace bionic with System V libc, it will become a huge overstatement. Also note: one could replace bionic with modified musl, install toybox and enjoy reasonably POSIX-compliant Android.

— Dmitrij D. Czarkoff (talk•track) 11:38, 16 April 2014 (UTC)

1. Sorry, I meant to say without rooting (from section title) the device first. Android is NOT meant to be Unix-like, while it still uses the Linux kernel. While Android does have root-account (superuser) internally, it doesn't have the concept of root/superuser as a privileged status that the user can attain. Devices are locked down in that sense. You can (in some devices) install APK-files not from Google Play, but it is the only format of programs allowed. That, as far as I know, does not allow you root-access or allowing user supplied program to not start without using Dalvik (in a JVM-like environment). That is user programs (at least user supplied, not all internal) run in a JVM-like environment making the os more "JavaOS-like" than Unix-like, as the point of operating systems is to run programs. At least the OS would be a hybrid of both; more JavaOS-like than Unix-like. I believe NeXSTEP didn't try to exclude Unix-programs. Then we can also disagree on the Family-part of "OS Family", as a concept, elsewhere. I say we should stop using the field in Infoboxes.

2. NeXSTEP probably had theses and more utilities, but while Android has some, eg. cp, my phone does not find sed (or locate, for locate sed). I could add programs like this on OS X; and on Debian with apt-get but I believe I can't in Android with APK-files, weather from Google Play or not. And the OS allows no other way unless changed/broken by rooting (that is not "allowed") first.

3. What is compiled in stock Android, or more correctly, what is in AOSP, defines Android as an operatings system. Not what can be added, a custom-kernel, or other things requiring rooting first. BTW, what is your phone?

4. You seems to be saying Android is not "reasonably POSIX-compliant" unless some things are changed. If you change enough software (but I think you can't with stock unrooted Android) you get Windows Phone. If you add to Windows NT you get "Unix" (compatible, Unix-like) :) comp.arch (talk) 14:54, 16 April 2014 (UTC)

1. You overly concentrate on rooting issue, but it is merely security policy. Android has the same security model as every other Unix-like: you can't administrate it beyond some extent unless you gain root permissions. Things work exactly the same way with any other Unix-like system, where you can do whatever you want at $HOME and need special permissions to perform administrative tasks elsewhere. "Android rooting" as a topic is a strict subset of "privelege elevation on Linux".

2. Sure you can add whatever to your Android phone. I am not sure you can do it with standard software, but it has nothing to do with OS family – it's mere package management deficiency. FWIW older Unix systems didn't have any kind of package management, so Android isn't even the most limited in this regard.

3. Wrong. AOSP is just one of numerous Android distributions, just as Ubuntu is one of GNU/Linux distributions. You should also note, that if you want to pretend that Android operating system is defined with AOSP, you'll have to admit that most "Android phones" don't run Android – all of vendors ship more or less customised firmware, and this customization goes far beyond skins and vendor apps.

4. Nonsense. If I do the same on my Arch installation, it will still be Archlinux, Linux-based Unix-like operating system. Why same isn't true for Android? Sure, you may make up your own personal definition of Android that would have all the properties you want it to have, but reality won't change: Android is another Unix-like system.

— Dmitrij D. Czarkoff (talk•track) 17:28, 16 April 2014 (UTC)

Having read and considered the arguments above, I would say that Android is indeed Unix-like. A quick google found at least one RS source that seems to agree too: "both Apple‘s iOS (and OSX come to think of it) and Google‘s Android are variations of the basic Unix operating system." (Forbes) --Nigelj (talk) 18:09, 16 April 2014 (UTC)

1. The difference with regular Unix[-like], is that you are allowed (if you have permission) to gain root. On Adroid you are not allowed even with apps with all permissions they are can't do anything BY DESIGN, if they could break out of the sandbox it would be a privilege escalation: "exploiting a bug, design flaw".

2. Yes, you used to just compile from source, programs were (mostly at least) source code compatible, you can't compile (or cross-compile) regular Unix programs (let alone X Windows applications, but let's not go there) APK-files - the only "programs" allowed in. At least without porting: "porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed."

3. Google's Android (AOSP) is THE official "distribution". To be called Android (get the trademark) you have to be compatible, and I assume it also means with the security restrictions, see above. What is changed with the "clones", like Fire OS and Nokia's is just a new store. If anything they are more locked out (eg. Fire OS). There might be exceptions, "Android-based" but not "Android". I admit, this article is a little schizophrenic, trying to describe AOSP, the source code (FLOSS, not proprietary) and "practical Android", what you get as "binaries" (includes proprietary).

4. You can add a lot to an operating system (or other things) and it's still the "same thing". Doesn't mean you can remove stuff (or restrict) and still claim it's the same thing or similar enough. A typical Linux distribution is Unix-like, not if you remove everything except the Linux kernel, that alone is not Unix-like. They added stuff back, enough for some (most of) POSIX compatibility usually associated with Unix-like, but left out stuff eg. POSIX.2 it seems. The main point is that Android is meant to be different. See also Unix philosophy. comp.arch (talk) 22:35, 16 April 2014‎

I think what we have here is people saying "It's Unix-like" and one person replying, "But it's not full-blown UNIX". Yeah, it's been locked down, trimmed down, and turned into a phone or a tablet. The point still is that it has a Unix-like kernel, and trimmed-down Unix-like is still Unix-like in that all kinds of other Unix-like things could be added back (but why would you want to? It's a phone, FFS). Here's another ref: http://www.levenez.com/unix/ - you'll see Android appear, forked out of Linux 2.6.23, in 2007. --Nigelj (talk) 22:12, 16 April 2014 (UTC)

I actually make some use of command line on my phone. — Dmitrij D. Czarkoff (talk•track) 23:24, 16 April 2014 (UTC)

"Note 1: an arrow indicates an inheritance like a compatibility". Android is compatible with the Linux kernel (there might be a caveat, maybe not best link but would this break Unix-like illution?), that is not a full OS. "Note 2 : this diagram shows complete systems and [micro]kernels like Mach, Linux". The Linux kernel is not a complete system (OS), I have no objection to saying "Linux kernel-based". Would you say the Tivo is Unix-like? It can be made to if hacked, and the rest of the OS added. comp.arch (talk) 15:48, 17 April 2014 (UTC)

1. Plain wrong: superuser priveledge management app for Android is accepted on Google Play. Obviously Google disagrees with your point about no root by design.

2. FYI there are many Unix-like systems that have the same properties: all BSD install media, Linux and Busybox-based initrd combination, etc. All of these constitute proper Unix-like environments. Also note, you may install terminal emulator on any Android device from Play Store, compile any Unix application using Android NDK, package it into APK, install via default installer for third-party APKs and use this application.

3. You mistake branding for operating system. Ironically, the term "Unix-like" was coined specifically to circumvent "UNIX" branding while describing OSs.

4. Every OS ever was meant to be different. Most Unix-like OSs aren't fully POSIX-compatible. Android is less POSIX-compatible then MacOS X, but more compatible then AT&T Unix System V. In all other aspects Android is as much Unix-like as MacOS X is.

— Dmitrij D. Czarkoff (talk•track) 23:24, 16 April 2014 (UTC)

Thanks for pointing this out.

1. See about that app: "!!! SuperSU requires a rooted device !!!" comp.arch (talk) 15:48, 17 April 2014 (UTC)

You've missed the point: SuperSU is accepted to Google Play, resides there for ages and enjoys popularity. Obviously Google doesn't regard it as something going against Android design, because it would not be allowed otherwise (see 4.4 in Google Play Developer Distribution Agreement). — Dmitrij D. Czarkoff (talk•track) 23:50, 17 April 2014 (UTC)

I'm not sure what this program does on a non-rooted device ("Android"), probably nothing, it can't by design. On those devices it is no threat. It need a rooted device (modified Android, that in my view is not "Android"). "development or distribution of Products, that interferes with, disrupts, damages, or accesses in an unauthorized manner the devices" is about Google Play (that comes often with Android, but is not part of Android (AOSP)), not Android OS (design) per se. comp.arch (talk) 16:18, 18 April 2014 (UTC)

2. "you may [..] compile any Unix application using Android NDK, package it into APK". Is this really true? There are two possibilities: a) As Unix predates GUIs, we are talking about Unix-like programs that work on text files or streams, such as "wc", "sed", or applications such as "vi" or "emacs". [b) If you would count X Windows applications as Unix-like, there would be huge amount of porting.] Can you compile wc into an APK in install, and sed into an APK ind install (and maybe also vi). Can you then run "ls |wc -l" or "ls |sed "something" |wc -l" eg. ? That is the Unix way. My doubt is that you can do this. And in addition see the comment from the link you provided: "It's reasonably common to launch native executables from Android apps, but you should be aware that it's frowned upon by the Android architects. They keep making threats to disable that facility in future, as they're unable to regulate the resource usage of those processes as precisely as they do for the main app process." I suspect this running "Unix-binaries" only applies to limitted cases and only for porting, and then you are really running Android applications, supporting my assertion the Android is its own "OS Family" ["http://www.roman10.net/how-to-build-ffmpeg-for-android/]. comp.arch (talk) 17:51, 18 April 2014 (UTC)

1. You are still missing the point: if Android doesn't allow user privelage elevation, SuperSU is not Android software. The fact that Google accepted it to Play is Google's unambiguous statement that you are wrong.
2. AOSP includes mksh – POSIX-compliant Unix shell, – so you can do "ls | wc -l" and every other Unix shell scripting tricks. You can use vi. (It was preinstalled on all phones I used. I assume it is included with AOSP.) The fact that Google wants to remove support of direct executable calling from Dalvik says nothing about Android as OS – it only says something about Dalvik. (And AOSP ships with many software pieces that have nothing to do with Dalvik.) You don't need to port software to Android – only recompile it (for proper linking). And even if you had to port software to Android, it wouldn't be anyhow different from other Unix-like systems: you have to port software from Linux to BSDs or OSX, and porting graphical OSX software to other Unix-like systems means complete rewrite in most cases, which doesn't stop MacOS X from being fully POSIX-compatible certified Unix.

Do your homework. — Dmitrij D. Czarkoff (talk•track) 18:16, 18 April 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)

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)

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.[4] 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)

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)

Clumsy and long introduction

Won't someone take the time to thoughtfully can clearly rethink, and then rewrite the whole intro?