Related
I don't own a smartphone yet, but I'm thinking about getting an Android phone soon. It will be my first smartphone. I’m also new to XDA-Developers. Please help me, as I have questions about Android security and though I’ve posted this message to several other web sites--android.stackexchange.com, Quora.com, and Reddit--no one has answered all of my questions completely and thoroughly. I’ve only gotten short responses that are a few sentences long and only talk about one or two things. I really need more help than that, and I’m hoping that I can get it here!
I know that this message is long, but please, if anyone can read through it and then try to answer all of my questions, I would REALLY appreciate it!
Here are my questions.
1. Is Android’s stock browser updated directly by Google, or do updates to it have to go through phone manufacturers (Samsung, HTC, etc)?
2. If I buy a phone that runs a manufacturer-customized version of Android, such as the TouchWiz version of the S4 or the Note II, will keeping Android’s stock web browser--as well as any other browser I choose to use--up to date keep me safe from web-based exploits, even if that phone’s manufacturer is slow to deliver updates? (Edit: I want to add that I'm interested in technical details.) By “updates” I mean updates to everything provided by or customized by the phone’s OEM: the customized version of Android, the manufacturer’s pre-installed apps, etc. (Edit: what I'm asking here is whether the OS needs to be kept up to date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date, whatever web browser it is).
3. I have read that OEMs are often slow to update their devices, and because of that I have limited myself to only looking at Nexus devices and Google Play Edition devices. But I really need to know if I SHOULD limit myself to Nexus and GPE devices for the sake of web security. (Again, I'm interested in technical details.) I don't want to buy a phone from a manufacturer that takes months to release security updates, leaving me vulnerable to web browser exploits and malware in the interim. But if I am wrong about ANY of this, please tell me so, because I would like to be able to consider devices that run manufacturer-customized versions of Android, such as the Touchwiz version of the S4 or the Note II (or maybe the future Note III).
(Edit: the answer to question #3 would depend on the answer to question #2; if the answer to #2 is ‘no, the underlying OS does not need to be kept up-to-date to protect you from web browser exploits’, then I guess the answer to #3 would be that I can consider buying a device that runs a manufacturer-customized version of Android that won’t receive OS updates as quickly as a Nexus does. If, on the other hand, the answer to #2 is ‘yes, to protect yourself from web browser exploits you need to keep both your browser AND your OS up-to-date’, then I guess for maximum web security I’d need to buy either a Nexus or a Google Play Edition device.)
4. I’ve read that in-app advertising can be a security risk. I’m really hoping that someone here will explain this to me. (Edit: again, I'm interested in the technical details, but keep in mind that I'm new when it comes to smartphones.)
I’d like to add a few comments:
1. I will only get my apps from the official app store--Google Play--or maybe Amazon.com’s Appstore for Android.
2. I'm concerned about web security and in-app advertising.
3. I don't plan on rooting my phone. I'm not saying I won't, I'm just saying that I don't plan on it.
1. Only nexus devices are updated directly by google. Even htc one Google edition will be updated by htc, so as the browser since it's a part of the software.
2. Manufacture updates are slower than Google. Most of the good apps available should receive updates and solve security issues.
3. If you want to disable advertising then use adaway, notice that you will need root.
1. The stock browser I believe does get updated when the OS is updated. I've read about people getting OS updates to find the stock browser is then faultering and assume this then gets updated. The update of the OS is usually done by the device manufacturer unless you are using a custom rom. Whomever creates the rom used on the device, is responsible for the internal updates for it, to whatever level they wish to support it. I have read that google don't mainstream care about the stock browser as they are pushing Chrome for the win and a separate team deals with the stock browser.
2. The world and his hedgehog are not safe from hack exploits. The quality of protection out there in any sense is mirrored by the quality of hacker. If you have a crap security level, any old hacker can exploit it. If you have the worlds most renowned secure, then the best hackers will break in at some stage while the wannabe hackers struggle to threaten their way out of a paper bag. However with some people, they need gold bullion and jail style security while others wonder why they need it. People can recommend you do this or do that, and some recs are excellent while others are not quite but almost hilarious but at the end of the day, if a child can hack into high security places, our devices are not so hard to get into. That said... we can run paranoid while there may be no threat at all. If you are concerned, just be careful of what you do with your device. Myself, I use it for every day communication and have not yet used a credit card on it with no real need to.
3. Even the greatest have not updated their OS. The Motorola Xoom promised one from purchase yet people were moaning long after the stock sold out that it never came. Granted it surely must be true that certain companies are quicker to advocate update releases than others. But the higher paying vs the cheap low end thing isn't something to run with either. I have a very cheap quad core tablet and that has just had a firmware update from last week and as far as I can see, it's an almost brand new device, market wise so it seems the update from them was fluid. Again, that said, the updates seem to be more about the OS running well, with the hardware and app capabilities than security although I dare say there are some inevitable security fixes in there too. My quad tablet was sluggish to some extent and a bit crashy but so far, it is fine after the update although I have only done it a few hours ago... everything me and the kids have tried, has either worked better of been flawless. No sign of lag yet anyway.
4. In-app advertising can be dangerous for a few reasons i guess. but the reality again, is I think any file can have dangerous code attached and configured in a way that the OS or security cannot smell it. Of course there is the ability of spam links to scam sites. There is also false flag things that are or maybe are possible too. For example, using x file with y file and requesting a cup of tea from z file can make a security team think your couch is about to disappear and your granny is about land bump on the floor, when indeed an app just wanted to execute a command using an ancient method of pressing Q. This is something I learned in windows based operating systems where using certain dll files with certain other files can trigger an alarm, as innocent as the intentions were. I built a website not so long ago and called some iFrames in that had no < head > or < body > tags. the pages worked perfectly but some chinese company employed to protect a british isp flagged the site as a security risk and blocked any visitors from viewing it. Thankfully, long gone are the days that visiting a website would fry your motherboard.
On your remaining comments.. seems like wise advice as of course there are scammers out there who will give your granny that bumpy ride off the disappearing couch onto the floor or steal your account and all those types of greed based madness which is a shame because it ruins the experience of say if a friend is trying to build an app and they ask you to give it a go, you are somewhat rightfully not willing to play ball.
FYI I have been around computers for a long time but am by no stretch of the imagination an android expert at all. I hope what I have wrote above is helpful and not by any means, wrong. I have not long posed the question about rooting and security as I do not qualify understanding the realm at all. I dare say it is a huge question, to some extent.
Also, security risk aside as no smartphone tablet or computer escapes that realm, Android for me is the best device, then IPhone, then Windows Phones, then Crapberry. I would never purchase the latter three.
Hi codQuore,
Thank you for your responses to my questions. I need to clarify two of my questions in my original post. (I have edited my original post to include these clarifications.) In question #2, I was attempting to ask whether the OS needs to be kept up to date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date (whatever web browser it is). In question #3 I asked whether I should only look at Nexus and Google Play Edition devices for the sake of web security, and the answer to that would depend on the answer to question #2; if the answer to #2 is ‘no, the underlying OS does not need to be kept up-to-date to protect you from web browser exploits’, then I guess the answer to #3 would be that I can consider buying a device that runs a manufacturer-customized version of Android that won’t receive OS updates as quickly as a Nexus does. If, on the other hand, the answer to #2 is ‘yes, to protect yourself from web browser exploits you need to keep both your browser AND your OS up-to-date’, then I guess for maximum web security I’d need to buy either a Nexus or a Google Play Edition device.
What are your answers to those two questions?
Truth_Seeker1 said:
What are your answers to those two questions?
Click to expand...
Click to collapse
At a guess I would say, for browsers that are built in to the OS, there will be two ways this can update, via the OS update and independently. The OS update would be a total OS replacement that is not automated and you would need to use a built in checking feature (if available) or manually check yourself periodically. Browsers that you add yourself will be offered updates from notification unless the ability to auto update is allowed then it should happen seamlessly of course letting you know. Google "android chrome update" to see something along the lines of what the update history shows.
Yes, you would want to update but I would recommend having a read first as on any computer device, an update can be flawed or give more problems than it's worth. Although more often than not, an update should be an improvement on performance and stability and of course for security.
If you are working blind, then do an update and assume security improvements are happening and go for it. If not, then you will know what is happening. I have never gone to the lengths of checking an update list before updating for android, but with pcs I do depending on what is updating, check what the update is worth and how people are getting on with the update. I did beta testing for years (hence the knowledge of flawed updates and reluctance to do the updates) so for me it's one of those do you risk it scenarios.
Sadly as I said above, we are never safe from hacks but with some hindsight and genuine attempt to protect, we are safe from the majority. For me it's 90% "what are you worried about?" and 10% "I don't blame you for being paranoid!"
As for the preference of buying google branded devices, the foundation of an android release is surely never set for these devices "out of the box" so to speak. I would assume that the team who look after these devices have the same process of having to streamline the OS thereafter before they can release it for their device update. This is somewhat proven by people wanting to put a custom rom on their Nexus and such. For some reason, people aren't happy with the normal rom and want or need to replace it. naturally, it is easy to think a nexus device for example, is closer to home and should by rights get updated a bit quicker than my Ampe tablet but in some respects I think this could be a bit of swings and roundabouts, again depending on the company and their apportioned team force to output the update. Yes you should be better off with a more directly linked device, to google but in my opinion, the concern is not a great one. You would be better off thinking about your budget, what you can save and ultimately do with the extra cash alongside the knowledge of which devices and companies actually do spend an effort on looking after them.
I'm in no position to afford these devices and if I were, I would rather throw my money in the bin (or spend it on my loved ones) than give it to the highest bidder.
So in the end, yes updates are 99/100 important and should be done. Be careful of what you browse and do all secure data passing before you go out on the internet highway and risk getting robbed. It is probably safer to "remember my password" to avoid future keysniffers than worry about indepth data mining. Of course, anyone can give you a sniffer but data mining is more clinical, I would say.
Finally, i wouldn't worry about these things too much but as concerned as you are, do some research. But do remember that in one hand, the UK government said "the internet isn't safe so we don't use it" yet on the other, the majority of secure usage is 'watched' by paid professionals for banking and such and is alot safer than you may think aswell as protection for credit card fraud and such.
Thanks again codQuore. I understand your point that there is no such thing as 100% bullet-proof security, but I still need to know whether both the OS and the browser need to be kept up-to-date to protect against web-based exploits, or is that accomplished solely by keeping the web browser up-to-date (whatever web browser it is).
You are most welcome, TS. I would say generally yes, to both, to be on the safe side. I'd like to guarantee the OS update will update the browser if it has been updated in the update and that the browser can be updated on it's own. However, I think I am right in saying you have to check for OS updates yourself and the same for certain apps whilst some apps will auto offer the update. You may be able to force this auto update for all apps, but how this is done per different version of android, escapes me. I do remember seeing the option come up after a factory reset or buying a new device and running the first time setup of playstore and such. There's an option for it somewhere. but I don't think the OS itself offers an auto update, it has to be checked for, in my experience. I have just done my tablet and it required installing some software on my pc from the tablet manufacturer and getting that to update the firmware/os. It was a 525MB download and everything was in chinese lol. I managed it with the help of google translate but it also helped that I had previously done the same thing on a t-mobile vivacity for my daughter after her OS died and got stuck at the rotating t-mobile logo on first boot.
It is essential to update but across the board it's not majorly important to check every minute, so to speak. You'll be fine. For the record though, my quad core tablet cost £70 from singapore and I knew I was taking a bit of a gamble but was protected by returns if all went wrong and get my money back. A similar tablet is something like £120. I plan on doing the same thing for my next phone upgrade too... but I don't have a contract phone running, I am on pay as you go and all I use is internet, no calls. Incidentally, I pay £20 for 6months net from t-mobile and the only limit is 1gb per month on video. when that expires, youtube and such stops working, some video sites carry on and everything else, FB mail, tethering, ftp via pc and stuff, all still works. I have even streamed radio from my android phone, flawlessly.
codQuore said:
I'd like to guarantee the OS update will update the browser if it has been updated in the update and that the browser can be updated on it's own.
Click to expand...
Click to collapse
LOL, I had to read that sentence several times in order to process it because you used the word "update" so many times :laugh:
If I remember what you said earlier, I think you said that the stock browser doesn't get updated on its own, but only as part of big OS updates? So it won't receive security patches as vulnerabilities are discovered, and won't be updated until the next version of Android arrives?
If this is true, then I'll use a different browser. But even if I use a different browser, is code from the stock browser used in other things, meaning that it is STILL a security risk if it isn't kept up-to-date?
It also occurred to me that if an OEM is slow to release OS updates for its phones, will it be just as bad at keeping its pre-installed apps up-to-date, and if so, does that pose a security risk.
Haha, looking back I can't believe I wrote that and am wondering if its a valid statement. I'll leave it for someone else to contradict lmao.
The core of the os and apps that run built are updated I guess separately and together. EG, say the browser gets an update to 1.1 the next update of the OS will most likely carry that updated version but if it doesn't it should still offer an update after you hit the playstore setup. naturally, these apps use core parts of the OS and i think some updates for apps will carry their own additional bypass of outdated os core, where applicable. That said, the bypass could be more secure in one sense and less secure in another. I'm guessing this is even possible. One thing I am yet to see, knowing how windows and linux works a little, is android have to update x- because something app wise has been installed that requires it. Alot of software on windows, requires things like framework to be added, linux is or can be the same.
The chances are you will be 99% secure in any event. The core defence for mobile phones is the phone companies themselves as that is in the realms of trillions of dollars at risk. They've been cracked before and they know it, so there is some possible reassurance for the devices, from that angle.
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
ZuEma said:
Is there a cm rom version that will work on Archos 45 plat?? Or any other good rom??
Click to expand...
Click to collapse
In case you might want to give it a try, you could start with rooting according to this thread:
http://forum.xda-developers.com/showthread.php?t=2573743
NOTE:- Archos 45 Platinum too has similar device specifications. The same CWM version worked for @best98 who is using an Archos 45 Platinum.
Click to expand...
Click to collapse
I guess there is a need now to step up to KitKat or newer, if the Webos security hole is not hashed out by other ways on devices running JB 4.3 or lower
Tod Beardsley
Google No Longer Provides Patches for WebView Jelly Bean and Prior
Gepostet von Tod Beardsley in Metasploit auf 12.01.2015 00:19:38
Over the past year, independent researcher Rafay Baloch (of "Rafay's Hacking Articles") and Rapid7's Joe Vennix have been knocking out Android WebView exploits somewhat routinely, based both on published research and original findings. Today, Metasploit ships with 11 such exploits, thanks to Rafay, Joe, and the rest of the open source security community. Generally speaking, these exploits affect "only" Android 4.3 and prior -- either native Android 4.3, or apps built with 4.3 WebView compatibility. sadjellybeans_t.png
WebView is the core component used to render web pages on an Android device. It was replaced in Android KitKat (4.4) with a more recent Chromium-based version of WebView, used by the popular Chrome browser.
Despite this change, though, it’s likely there will be no slow-down of these Android security bugs, and they will probably last a long time due to a new and under-reported policy from Google's Android security team: Google will no longer be providing security patches for vulnerabilities reported to affect only versions of Android's native WebView prior to 4.4. In other words, Google is now only supporting the current named version of Android (Lollipop, or 5.0) and the prior named version (KitKat, or 4.4). Jelly Bean (versions 4.0 through 4.3) and earlier will no longer see security patches for WebView from Google, according to incident handlers at [email protected].
Up until recently, when there's a newly discovered vulnerability with Android 4.3, the folks at Google were pretty quick with a fix. After all, most people were on the "Jelly Bean" version of Android until December of 2013. Jelly Bean's final release was just over a year ago in October of 2013. This is why this universal cross-site scripting bug was fixed, as seen in the Android changelog and Rafay's blog, Rafay Hacking Articles.
Google on Patching pre-KitKat
However, after receiving a report of a new vulnerability in pre-4.4 WebView, the incident handlers at [email protected] responded with this:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves, but welcome patches with the report for consideration. Other than notifying OEMs, we will not be able to take action on any report that is affecting versions before 4.4 that are not accompanied with a patch.
So, Google is no longer going to be providing patches for 4.3. This is some eyebrow-raising news.
I've never seen a vulnerability response program that was gated on the reporter providing his own patch, yet that seems to be Google's position. This change in security policy seemed so bizarre, in fact, that I couldn't believe that it was actually official Google policy. So, I followed up and asked for confirmation on what was told to the vulnerability reporter. In response, I got a nearly identical statement from [email protected]:
If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.
When asked for further clarification, the Android security team did confirm that other pre-KitKat components, such as the multi-media players, will continue to receive back-ported patches.
Sorry, Jelly Bean, You're Too Old
Google's reasoning for this policy shift is that they "no longer certify 3rd party devices that include the Android Browser," and "the best way to ensure that Android devices are secure is to update them to the latest version of Android." To put it another way, Google's position is that Jelly Bean devices are too old to support -- after all, they are two versions back from the current release, Lollipop.
On its face, this seems like a reasonable decision. Maintaining support for a software product that is two versions behind would be fairly unusual in both the proprietary and open source software worlds; heck, many vendors drop support once the next version is released, and many others don't have a clear End-Of-Life (EOL) policy at all. (An interesting side note: neither Google nor Apple have a published EOL policy for Android or iOS, but Microsoft and BlackBerry provide clear end of life and end of sales dates for their products).
Most Android Devices Are Vulnerable
While this may be a normal industry standard, what's the situation on the ground? Turns out, the idea that "pre-KitKat" represents a legacy minority of devices is easily shown false by looking at Google's own monthly statistics of version distribution:
As of January 5, 2015, the current release, Lollipop, is less than 0.1% of the installed market, according to Google's Android Developer Dashboard. It's not even on the board yet.
The next most recent release, KitKat, represents about two fifths of the Android ecosystem. This leaves the remaining 60% or so as "legacy" and out of support for security patches from Google. In terms of solid numbers, it would appear that over 930 million Android phones are now out of official Google security patch support, given the published Gartner and WSJ numbers on smartphone distribution).
The Economics of Upgrading
Beside the installed bases, I posit that the people who are currently exposed to pre-KitKat, pre-Chromium WebView vulnerabilities are exactly those users who are most likely to not be able to "update to the latest version of Android" to get security patches. The latest Google Nexus retails for about USD$660, while the first hit for an "Android Phone" on Amazon retails for under $70. This is a nearly ten-fold price difference, which implies two very different user bases; one market that doesn't mind dropping a few hundred dollars on a phone, and one which will not or cannot spend much more than $100.
Taken together -- the two-thirds majority install base of now-unsupported devices and the practical inability of that base to upgrade by replacing hardware -- means that any new bug discovered in "legacy" Android is going to last as a mass-market exploit vector for a long, long time.
Here Come the Mass-Market Exploits
This is great news for penetration testers, of course; picking company data off of Android phones is going to be drop-dead easy in many, many cases, and I fully expect that handsets will be increasingly in-scope for penetration testing engagements. Unfortunately, this is great news for criminals for the simple reason that, for real bad guys, pretty much everything is in scope.
Open source security researchers routinely publish vulnerability details and working exploits with the expectation that this kind of public discussion and disclosure can get both vendors and users to take notice of techniques employed by bad guys. By "burning" these vulnerabilities, users come to expect that vendors will step up and provide reasonable defenses. Unfortunately, when the upstream vendor is unwilling to patch, even in the face of public disclosure, regular users remain permanently vulnerable.
Roll Your Own Patches?
It's important to stress that Android is, in fact, open source. Therefore, it's not impossible for downstream handset manufacturers, service providers, retailers, or even enthusiastic users to come up with their own patches. This does seem to happen today; a 4.3 vulnerability may affect, say, a Kyocera handset, but not a Samsung device with the "same" operating system.
While this is one of the core promises of open source in general, and Android in particular, it's impossible to say how often this downstream patching actually happens, how often it will happen, and how effective these non-Google-sourced patches will be against future "old" vulnerabilities.
The update chain for Android already requires the handset manufacturers and service carriers to sign off on updates that are originated from Google, and I cannot imagine this process will be improved once Google itself has opted out of the patching business. After all, is AT&T or Motorola really more likely to incorporate a patch that comes from some guy on the Internet?
No Patches == No Acknowledgement
To complicate matters, Google generally does not publish or provide public comment on Android vulnerabilities, even when reported under reasonable disclosure procedures. Instead, Android developers and consumers rely on third party notifications to explain vulnerabilities and their impact, and are expected to watch the open source repositories to learn of a fix.
For example, Google's only public acknowledgement of CVE-2014-8609, a recent SYSTEM-level information disclosure vulnerability was a patch commit message on the Lollipop source code repository. Presumably, now that Google has decided not to provide patches for "legacy" Android WebView, they will also not be providing any public acknowledgement of vulnerabilities for pre-KitKat devices at all.
Please Reconsider, Google
Google's engineering teams are often the best around at many things, including Android OS development, so to see them walk away from the security game in this area is greatly concerning.
As a software developer, I know that supporting old versions of my software is a huge hassle. I empathize with their decision to cut legacy software loose. However, a billion people don't rely on old versions of my software to manage and safeguard the most personal details of their lives. In that light, I'm hoping Google reconsiders if (when) the next privacy-busting vulnerability becomes public knowledge.
Click to expand...
Click to collapse
Hi everyone,
I always thought that Nexus devices comes with a pure AOSP version with some little closed-source extras, like GApps (Google Mobile Services, Play Store, Gmail, YouTube, Maps...) or hardware drivers. And for a "librist" like me, it seems fine : OS and main userspace parts are opensourced, and Google services are closed-source. All was fine in my beautiful world.
But with some search, I discovered that every time that Google push an AOSP apps on the Play Store, it is actually a closed-clone of the AOSP one.
For example :
AOSP Keyboard is not Google Keyboard (=missing gesture)
Camera is not Google Camera (=missing Photosphere)
Launcher is not "Google Experience Launcher (GEL)" (=missing Google Now Integration, normal, but also transparency)
Music is not Play Music
Search is not Google Now
recently : Email (not Gmail)
etc.
I was not worried about "additionnal closed source services/app of Google in Android" as they are what they are : additionnal.
But the new politic of Google seems to be "we have our Touchwizz/Sense of our own, now".
The main problem is : as far as I can see on the GIT source and with Android Emulator, when Google begins to develop his "alternative closed source apps of an AOSP opensource apps", the AOSP apps seems to be abandonware.
You can compare the look of Google Search (and disable Google Now, to compare properly without Google closed services) and AOSP Search. AOSP Search seems to be from FroYo design... The same with Music player.
What's your point of this situation? Does Google try to make his own front-end interface to AOSP Android like Samsung Touchwiz or HTC Sense?
What devices comes with AOSP by default and not "Android by Google" now, if Nexus is no more the case?
BONUS : Jean-Baptiste Queru, head of AOSP, resigns from Google. I don't know what happens to replace him...
Note : I am French so, if my English is not easily-readable, please forgive me .
*bump*
Here is a point of view of an official Android developers from Google (source : arstechnica[DOT]com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/?comments=1&post=26199423)
There is a good discussion to be had about Microsoft using Android, and a lot of good reasons for them to not do so... which makes it especially unfortunate that instead this was turned into yet another article here of increasingly specious and misleading claims about the "open-sourceness" of Android and Google's hidden plan to Control Android And Then The World.
First, let's make a clear statement. If Android was to be in the same position as Windows is in the PC industry, we'd have a radically more open computing environment, where it is a lot easier for small players to compete against the dominant platform on a more level playing field. I don't think anyone can argue against this. When we were designing and implementing Android at Google, this was actually one of our goals -- to create a more level playing field for everyone -- and that design perspective hasn't significantly changed over the years.
So let’s start with the setup:
Quote:
Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
Already we see the clear bias that the article is going to take. There is however another way to state this: Google provides a lot of value on top of Android, with an ecosystem that is difficult to compete with, of cloud-based applications and services that are useful to users and developers. This is at least as true a way to describe as the quoted statement from the article, and I will argue it more accurately states the situation.
The arguments start out soft, but still misleading:
Quote:
The first is the Android Open Source Platform (AOSP) codebase. This provides the basic bones of a smartphone operating system: it includes Android's version of the Linux kernel, the Dalvik virtual machine, and portions of the basic user interface (settings app, notification panel, lock screen).
AOSP is far more than the basic bones of a smartphone operating system. It is a complete smartphone operating system. The examples you provide for what it includes are very misleading -- what about the launcher, contacts app, dialer and phone app, calendar app, camera and gallery and on? The fact is, if you build AOSP today and put it on a phone, you will have a pretty fully functioning platform.
The thing you don’t have is stuff related to cloud services, and this is not an evil secret plan of Google, but a simple fact we have been clear about from the initial design of the platform: Android as an open-source platform simply can’t provide any cloud services, because those don’t run on the device where the platform code runs. This is a key point that seems to be completely missed. If you want to understand what Android is, how it is designed, and how the pieces fit together, you must understand this point.
One of the things that is interesting about platforms today vs. the traditional desktop is that these cloud services are becoming increasingly central to the core platform experience. This presents a special challenge to an open-source platform, which can’t really provide such cloud services as part of the standard platform implementation. In Android our solution to this is to design the platform so that cloud services can plug-in and integrated with it in various ways. These may be stand-alone apps like Google Play Music, they may be plug-in services like the calendar and contacts sync providers, they may be Google proprietary APIs on top of the platform like Google Play services.
Note, however, that in all of these cases the platform has been designed to provide an open, flexible, and rich enough API that these Google services can be delivered using the same standard SDK that other app developers use. This is part of the goal of creating a more level playing field for everyone. (There are some exception where things are very difficult to safely expose to developers, but they are rare -- the Play Store’s privileges for managing your apps is one, and even there we do provide in the platform side-loading APIs so that other app stores can be implemented.)
So, GMS is Google’s proprietary code implemented on top of Android for interacting with Google’s services. There is nothing nefarious about it being proprietary -- it is interacting with Google’s proprietary back-end services, so of course it is proprietary.
Thus this makes perfect sense:
Quote:
The split between AOSP and GMS is not constant, either. Google has slowly been migrating more and more functionality to GMS. For example, in the latest Nexus 5, the core phone user interface—the thing that you use to launch apps and show icons—has been rolled into the GMS Search app.
What has happened here? Google now has their own launcher that integrates with Google’s back-end services. And what is wrong with this? Why is this worse than Facebook or Yahoo doing their own proprietary launcher? It is bizarre to complain about this, especially when Google has open-sourced everything else in their launcher except the parts that are specific to their proprietary services!
And this is the same thing:
Quote:
Similarly, APIs have made the move. AOSP contains a location API, but GMS contains a newer, better one, with additional features. Google encourages developers to use the GMS API, and the AOSP Location API mostly dates back to Android 1.0, and hasn't seen any substantial changes since Android 1.5.
First, it s very misleading to act like the platform’s location manager has been unmaintained since Android 1.5. Important features like passive providers and criteria-based updates were added much later than that; but, even ignoring verifiable facts, the Google Play services location APIs didn’t appear until last year, so what you are actually implying with this is that Google basically didn’t do any significant improvements to location from 2009 to 2013. Probably not true.
The reason for the introduction of Google’s location API, however, is again because of back-end services. Location has become increasingly dependent on cloud services: for a while now network-based location, but increasingly more things. We went for a long time with parts of the platform’s LocationManager basically not implemented because it couldn’t be, with the need for some proprietary thing to be dropped in on top of it to have a fully functioning API. As time went on this became an increasingly bad situation because we don’t want our platform to be defining APIs that it can’t also provide an implementation of, to serve as the basis for everyone to share and a reference for how it should work. So, the decision was made that Google should take responsibility of further evolution of that API since that evolution is increasingly tied to cloud services.
Quote:
Each new release increases the level of integration with Google's own services, and Google is moving more and more new functionality to GMS, leaving AOSP a barebones husk.
This is such an exaggeration that it is really hard to know how to address. AOSP is a barebones husk? Please. AOSP is far richer and more powerful today than it was in 1.0, 1.5, 2.0, or 3.0. And most importantly, one of the things we have been doing over the years is providing increasingly rich facilities for any cloud services provider to plug in to the platform. For example, in the most recent 4.4 release we have our very extensive new storage framework API, which Google uses to provide their Google Drive services to any application, and allows any other cloud storage provider to do the same thing, operating on equal footing with Google.
Quote:
That's not a small category, either, since features such as in-app purchasing are in GMS.
This gets emphasized as a significant point, but, honestly, how would you propose that in-app purchasing not go through GMS? Some general platform API to allow the app to do an in-app purchase with whoever wants to be a “purchase provider?” I can’t imagine this being a solution that people will be happy with.
Quote:
Technically, however, a company with sufficient development resources could provide its own GMS replacement. The overhead would be not insignificant, especially as—to ensure optimal compatibility—the replacement would have to replicate not just correct functioning, but any bugs or quirks of the GMS implementation.
Of course, the vast vast vast majority of the work here is implementing the back-end services in the cloud, not the proprietary glue code that runs on the device. Failing to address this is deeply missing about what is going on.
Quote:
There are also lots of little awkward aspects of the GMS API; it includes such capabilities as "share with Google+" which few companies have any real counterpart to.
In other words you don’t have your own social network, so you can’t implement Google’s API for sharing to its social network? Okay, then just have the API do nothing? Or heck, share to Facebook?
Quote:
Another example: there is an API for handling turn-based multiplayer gaming. A company could implement this API and have its own server infrastructure for managing the gaming sessions, but obviously these gaming sessions would be completely separate from Google's gaming sessions, fragmenting the player base in a way that game developers are unlikely to be keen on.
Now this could be taken as just a good argument for why Microsoft wouldn’t get as much of a competitive advantage by using AOSP, since they would still be competing with Google’s cloud services. But then it is immediately followed by:
Quote:
As an added bonus, should the ultimate resolution of Google's long-running legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of wholesale reimplementation of GMS would become legally actionable. Google could, if it chose to, shut it down through the courts.
Where in the world did this come from? Google is the one fighting against that. Microsoft actually filed an amicus brief supporting Oracle. Yet you write this almost as if this case would serve part of Google’s evil plan to control Android?
Quote:
The second option—AOSP with a few extra custom extras—has the upside of providing an opportunity for Microsoft to integrate its own services… It would certainly mean omitting any high-profile title using in-app purchasing, so, say, Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out.
It’s strange to focus on in-app purchasing here. The issue is that you don’t have the Google Play store, so you need to get app developers to publish their apps on your own store. In fact providing a compatible in-app purchasing API and otherwise making it easy for them to publish their app without changing it is probably the lesser problem.
Quote:
Google has pushed very significant pieces of functionality into GMS, including messaging and the Chrome browser. The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained. If a company wants to use AOSP without GMS, it has a lot of work to do if it wants to produce a high quality experience. The open source parts just aren't good enough.
Again the exaggerations. Chrome is available open-source as Chromium (of course without the integration with Google’s back-end services, but why in the world would Microsoft want those?). What parts of AOSP are “buggy” compared to Google’s stuff? In fact a lot of Google’s proprietary apps are built on top of the corresponding AOSP app -- that includes Google’s Launcher, Calendar, Email, and even Gmail now. Messaging has diverged from Hangouts, but Hangouts is deeply integrated into Google services, and there is a similar situation with Music. It would be nice if some of these apps were better maintained, but (a) there are lots of equivalent apps (often based off the AOSP version) that people have written which you could license and use, and (b) implementing these apps is pretty small potatoes compared to all the cloud services Google provides.
Quote:
For Microsoft, the effort required to build a GMS workalike on top of AOSP is going to be comparable to the effort required to build the Windows Phone shell and APIs on top of Windows.
Again, the vast majority of work here is providing the back-end cloud services. Not, as keeps being implied, the proprietary bits that Google has running on Android.
Quote:
Moreover, it still implicitly gives Google control over the platform. Various aspects of how Android is used are determined by the underlying APIs: sharing between applications, for example, is done in a particular Android way. Any platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose.
Okay this is just weird. Yes, the Android platform has a well-defined sharing facility, and if you want to have an Android-compatible platform you will want it to work the same way. Just like, I don’t know, Ubuntu has a C library and you probably don’t want to change that. How in the world is this different from every other open-source platform in the world? How is Google being all controlling here?
Quote:
The fourth option—use AOSP with an entirely new software stack on top—gives freedom and flexibility, but to what end? The kernel isn't the important bit.
Wait, what? The only way I can figure out how to interpret this is to suggest that they use Linux (the kernel) but nothing above it. That can’t be what you mean, right? I honestly have no idea what this is supposed to be saying, except that it again seems to be implying Google is being all nefarious.
Quote:
If Android were an open platform in the way that Firefox OS or Ubuntu for smartphones were an open platform, the forking suggestion would make more sense.
I’ll admit I am not super-familiar with these two, so I have a question: what are the things that they have that are not in AOSP?
And finally we have further blanket statements about how Google’s goal is to make Android increasingly closed, AOSP isn’t real open source, etc, etc. I’ll just leave with the final sentence:
Quote:
Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform.
Actually, I don’t think you have an understanding of how Google has built Android. I have been actively involved in designing and implementing Android since early on, and it was very much designed to be an open-source platform. Part of that design was to allow Google (or anyone) to build integrated cloud-based services on top of it, and that aspect of Android design has gotten richer as the years go on. What you are concerned about is not a design problem in Android, but the richness of Google’s cloud-based services.
At least Android creates a much more equal playing field for others to compete with Google’s services than is provided by the proprietary platforms it is competing with. I also think a good argument can be made that Android’s strategy for addressing today’s need to integrate cloud services into the base platform is an entirely appropriate model for a “real” open-source platform to take.
Click to expand...
Click to collapse
I know it sounds like a base question since we're talking about security but I wonder in what instances are security patches really helping.
For example, suppose I only use the device with my data plan and my wifi at home (no public networks). Also suppose that I don't download 3rd party apps except those created by established companies like Microsoft (SwiftKey or Outlook). And suppose I don't visit many websites on my device (and especially no pr0n). In this instance, are security patches really necessary? Unlike most people, I don't do everything on my phone (no browsing the net, banking). I only use it for navigation, WhatsApp, and for calls.
I'm asking this question because I'm thinking about getting an Android phone. I'm currently an iPhone user and I want to break out of the Apple ecosystem. The problem is that some companies like HTC and LG seem to be slow to provide security patches or simply ignore them. https://www.youtube.com/watch?v=eDxUjSfp17E&t=6m35s
I'm interested in buying the LG V35 but the internet is full of comments about LG's horrendous support. I am mainly interested in keeping my emails and personal information safe. The only thing I value in the iPhone is the long-term support Apple provides but I'm willing to switch to Android if this isn't a concern if I use my phone exactly as I described above.
Thanks
Mity85 said:
I know it sounds like a base question since we're talking about security but I wonder in what instances are security patches really helping.
...
I'm interested in buying the LG V35 but the internet is full of comments about LG's horrendous support. I am mainly interested in keeping my emails and personal information safe. The only thing I value in the iPhone is the long-term support Apple provides but I'm willing to switch to Android if this isn't a concern if I use my phone exactly as I described above.
Thanks
Click to expand...
Click to collapse
First of all, welcome to Android ?
To answer your questions, security patches are indeed necessary, because if one day you lose your phone, potential flaws that would be patched with security update would be grand opened to hacker that want your personal data (like photos, videos, emails, contacts,...).
Even though it's very rare, that's more secure to have an updated phone.
Now, if you want long term services (updates from Google with the latest features and security patches) you should definitely go for a Google Pixel. Plus those are powerful and have the best camera on the phone market right now (machine learning helps a lot).
If your price range is around 400 $, then go for the Pixel 3a, if you're around 800 $ then go for a Pixel 3.
If you can wait a bit, wait until the Pixel 4 release, I don't know if it'll be a good phone (probably) but what I know is the more recent your phone is, the longer it'll be updated.
But if you are below that, check out the Android One series, that's not Pixel devices, but they get as well the long term support.
Hope it helps
I'd like to expand on this question a bit.
I have a friend who is experiencing "severe security concerns" at the moment. I'm actually kind of worried about this particular friend. This friend seems to primarily have concerns over "being tracked", so I'm trying to find the best approach to at least putting these concerns in the proper frame so that knowledge and education of the device and what it does, and how to control it would be more attainable to said friend.
I know that the security updates are important, but how do you advise someone who isn't rich, and is looking for a new phone, but is willing to dabble with rooting, even to the extent of removing / not installing Gapps? This friend seems willing to learn, so I'd like to think that taking the big picture of "best security practices" into account is an option (ie. don't open suspicious email attachments, learn how to identify phishing scams, only install apps you trust, etc...).
In my experience, apart from kernel and driver level flaws that leave gaping wide-open back doors, security mostly comes down to "being wise with how the device is used". Is that a fair statement?
Yes, security is a combination and balance of user knowledge & usage, oem hardware security, software security, country laws, etc.
Thanks @galaxys
Is there anything about rooting that makes a typical Android device less secure?
Or more to the point, does the ability to omit Gapps provide any natural security enhancement?
I'm asking from the point of view of a "moderately experienced" individual who knows how to spot suspicious attachments/files and phishing scams, and knows how to do some bare-minimum vetting of where apps are installed from. For the sake of argument, let's say this user has no Gapps, and gets their apps from FDroid or ApkPure, or ApkMirror.
I'm posting here because I can't post at the development forum.
With the advent of cellphone addiction, the market for dumbphones has increased. People looking for ways to end their addiction to social media and gaming are supporting projects like Light Phone and Mudita Pure.
Unfortunately, these devices are pricy due to the relatively low demand and the fact that they are not produced in China.
I believe that there's a big opportunity for those developers looking forward to starting something new, like creating a "Dumb" Android version with less complexity, that would have only basic and productivity features such as:
Call, SMS, flashlight, camera, calculator, shopping list (todo list), hotspot only (no mobile data or wifi on the phone), music player.
Must not have: playstore, browser
Name suggestions: DumbDroid, AA, Antidote
I hope someone reads this and brings this idea to life.
Thanks :fingers-crossed:
@tijuco2
You are confusing Android OS - including device drivers - and applications, IMHO.
And, it's on the user to decide what applications lastly are installed ( used ) on an Android device.
jwoegerbauer said:
@tijuco2
You are confusing Android OS - including device drivers - and applications, IMHO.
And, it's on the user to decide what applications lastly are installed ( used ) on an Android device.
Click to expand...
Click to collapse
I'm not a developer. I know what the demand is, not how to achieve what I suggested. I'm talking about addiction when the user lost the ability to control their impulse.