I couldn't fit the concept completely in the title, but here it is:
Would it be a good idea for Google to redesign Android in such a way that it allows for OEMs as HTC and Samsung to more easily add their layers Sense and TouchWiz upon it - perhaps even in the form of a single apk?
Considering the fact updates take extremely long because the newly released Android versions, in this case Jelly Bean, need to be altered by HTC and Samsung and others before Jelly Bean can be even released onto the brand devices, not to mention an even longer delay for those who decide to purchase their phone by the major source of destruction of innovation, that is, the carrier. If Key Lime Pie, the next Android version, is designed in such way that the OEM skins and Android itself remain seperate, would it be possible to update to a newer revision of Android without having to be dependent on the OEM and carrier? It would then be the OEMs responsibility to update their skin as soon as possible to maintain a proper experience, as obviously a new Android revision has new elements that could possibly remain unskinned yet at release.
I personally think a strategy in this way forces OEMs more to bring out updates as soon as possible, thereby driving competition up - which is ALWAYS a good thing, while Android updates remain independent of OEM and carrier.
Of course, there will be issues with such strategy, such as required updates to drivers. Skin updates are non-essential, while it would still be nice to at least have a functioning device after an update. How would that work out for devices by HTC automatically receiving updates to Android? Remember, the whole point of this idea is to bypass the need for OEMs and carriers altogether. While I even doubt thát is possible, I'd like to hear a discussion trying to achieve this point as closely as possible.
I even believe this thread, if it does result in great ideas, could be forwarded to Google to look at - but I might just be completely wrong with such idea and as such, I'd also like to hear why.
Discuss away.
They're already working on it.
[Note: This information is ~18 months old, probably. I haven't kept up to date on the projects.]
T-Mobile built a theme engine, which is included in CyanogenMod. However, there are aspects of it that Google does not quite like. Sony-Ericson is also putting forth an alternative approach, which Google likes better. So, T-Mobile is working to merge the best of both worlds.
The "big difference" between the approaches is:
- T-Mobile's themes are user selectable at run-time.
- SE's themes are set by OEM (need to flash a new ROM to change)... but they are more deeply/cleanly/??? integrated with the Android core.
It's both a technical and political matter.
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
The Future of Android is becoming uncertain; more and more news about android 7 being the last version of android is upsetting, then being named android Nougat... Clearly, something new is needed; xda has proven itself to be the epicenter of android development; so, it would be fitting that xda would carry on Android after google, proper voting of new features, control of an OS by the consumers, and others affected! The OS could be incredible; hence why a petition needs to be brought up, for a software that we have all been waiting for! A software made for all devices, full control! If you want simple customization abilities or the most advanced they've ever been! Features perhaps like: your own boot screen, your own selection of colours and designs for your home screen settings and notification panel and play store, write sd as internal to be seamless and open as possible: take an sd of your current phone's set up and make copies of it; media and all! Plus, being able to put it in any phone/tablet that has twrp/cwm and have your other device instantly! A universal limitless, fully compatible OS made by you, made by me, made by all of us! A new android, a new developer/consumer OS. Perhaps XDA OS or maybe Android X?! We'd all decide! What do you think? The future of tech is waiting.
philsim1212 said:
The Future of Android is becoming uncertain; more and more news about android 7 being the last version of android is upsetting, then being named android Nougat... Clearly, something new is needed; xda has proven itself to be the epicenter of android development; so, it would be fitting that xda would carry on Android after google, proper voting of new features, control of an OS by the consumers, and others affected! The OS could be incredible; hence why a petition needs to be brought up, for a software that we have all been waiting for! A software made for all devices, full control! If you want simple customization abilities or the most advanced they've ever been! Features perhaps like: your own boot screen, your own selection of colours and designs for your home screen settings and notification panel and play store, write sd as internal to be seamless and open as possible: take an sd of your current phone's set up and make copies of it; media and all! Plus, being able to put it in any phone/tablet that has twrp/cwm and have your other device instantly! A universal limitless, fully compatible OS made by you, made by me, made by all of us! A new android, a new developer/consumer OS. Perhaps XDA OS or maybe Android X?! We'd all decide! What do you think? The future of tech is waiting.
Click to expand...
Click to collapse
Please read the description and Sticky threads for XDA Assist.
This is not the place for this post.
Thread closed.
I thought it would be cool for us moto G 3 users to share our opinions of what we all expect from android P to bring.. new features, more UI changes? Is there more that can be added to android software to make the update worth it? Are we reaching the end of the innovative era, and all we will see from now on are little, unimportant changes?
Is project treble going to stop fragmentation since android 8? Guess we'll discover it this year. Share your thoughts
When it's out, OEMs that don't want to support Treble would ship with Nougat (Google could prevent that by forbidding this practice) or Tizen OS (customers would be unhappy with Tizen) but that wouldn't work so Treble will eventually be supported on all new Android devices.
Android P might be the one Android release to finally support themes/at least a built-in system dark theme.
And let's start guessing Android P's name: Popsicle? Or how about Pie?
Pez will finally have a working "feed me breakfast in bed" button.
Android 10 brings a lot of changes to the Android ecosystem. The re-branding ends the era of dessert names and Google has officially gone all-in on gesture controls. However, despite these new directions, Android remains the same OS we all know and love.
Google’s big themes for Android 10 were gesture controls, additional security, and enhancing existing features. The update as a whole feels a lot like a continuation of Android Pie. However, there is still a marked difference between Android Pie and Android 10, compared to Android Marshmallow and Android Oreo.
These are the top Android 10 features you should know
We’ve already gone over the entire OS in our Android 10 overview video (above) and all of our articles (just below). We recommend reading and viewing those so we don’t have to rewrite the wheel here. You can also check out the Easter egg instructions here, and Google has its own Android 10 features page as well. If you’re interested in the big rebranding that came with the launch of Android 10, David Imel took a trip to Google to learn all about it and you can read it here.
Finally, this Android 10 review is based off the software update that landed on the Pixel 3a. Your Android 10 experience may differ from device to device.