Slashdot Mirror

It's been a while since I've done Android, so I had to look it up again. This is what I was talking about.

Approx. 2 month cycle for minor versions. 12 months for major versions. Bug fix versions out in a week or two. That is some aggressive development.

http://tools.android.com/download/studio/stable

But can it do HOSTS files without rooting the phone?

Approx. 2 month cycle for minor versions. 12 months for major versions. Bug fix versions out in a week or two. That is some aggressive development.

http://tools.android.com/download/studio/stable

I'm slightly surprised at that, as last time I looked a lot of Android users were still on 2.x, which ships with Android Browser, not Chrome.

I suspect you haven't looked for a little while. Google's dashboards suggest that only 4% of users are still on 2.x (poor things!):

http://developer.android.com/a...

You also probably need to combine the counts of "Chrome for Android" and "Chrome" in those stats the parent posted to get the total chrome market share for Android.

a good chunk of those are still on gingerbread or Froyo even

Which is of course horse shit. A mere 4% of users are on pre-4.0 versions of the OS, and their devices are likely not powerful enough to run any game that actually cares about API features from later versions.

Android had over 80% of the market in 2014, and rising. Even if any given Android user spends only 1/5th as much on apps, it's still as lucrative as iOS.

Finding a few games that are not out on Android means nothing. There are popular Android games not out on iOS. There are many games that can never come out on iOS due to content restrictions. The reasons why games don't always come out on every platform are complex, and looking at the AAA titles that are available on Android it's obvious that there is no problem developing or making money on the platform.

I don't understand one thing. You mention that the matching of livescans against templates is done in an area which can't be altered or interfered with. And yet, at some point that hardware (I'm assuming it's all hardware) must send a positive signal to the software that it's OK to unlock the screen.

Yup.

Surely I could compromise the code that accepts that signal to simply always be a positive signal?

Certainly... except for other code running in the area which can't be altered or interfered with.

This is the reason that Android 6.0's fingerprint matching is required to be done in the Trusted Execution Environment (TEE), because that matching signal is used not just by the regular OS to unlock your screen, but also by other code in the TEE to unlock access to cryptographic keys which are presumably used to protect the most important stuff on your phone.

For example, using the new features in Android Marshmallow's hardware-backed keystore (especially this one, your bank's app could set up an ECDSA signing key that is used to authenticate to their servers, providing access to your banking information. That key could be configured to be unlocked by your fingerprint. If the fingerprint matching were provided in the regular OS then any compromise of the regular OS would enable access to your bank account, because the TEE-based ECDSA key would be relying on a signal from the regular OS to tell it to unlock the key. But because the TEE-based ECDSA key relies on a signal from the TEE-based fingerprint matcher, a compromise of the regular OS won't get the attacker in to your bank account (not unless you're around to put your finger on the scanner).

FYI, for Marshmallow the password authentication has also been moved into the TEE, and TEE-based keys can also be access controlled with password auth. So your bank could do the same sort of thing, but require you to enter your device password rather than present a fingerprint.

Or am I completely off base here?

Nope, what you said made perfect sense, you were just missing some pieces.

I should mention that for Android 6.0 the Compliance Definition Document (which specifies what it means to be Android) makes all of the TEE stuff "strongly recommended", but not "mandatory" for Marshmallow devices. However, it is all mandatory for devices that have fingerprint readers. The CDD also warns that it will become mandatory for N. In spite of not being mandatory for Marshmallow, though, it looks like nearly all major device vendors will have the new TEE stuff in their new devices (those launching with Marshmallow).

I don't understand one thing. You mention that the matching of livescans against templates is done in an area which can't be altered or interfered with. And yet, at some point that hardware (I'm assuming it's all hardware) must send a positive signal to the software that it's OK to unlock the screen.

Yup.

Surely I could compromise the code that accepts that signal to simply always be a positive signal?

Certainly... except for other code running in the area which can't be altered or interfered with.

This is the reason that Android 6.0's fingerprint matching is required to be done in the Trusted Execution Environment (TEE), because that matching signal is used not just by the regular OS to unlock your screen, but also by other code in the TEE to unlock access to cryptographic keys which are presumably used to protect the most important stuff on your phone.

For example, using the new features in Android Marshmallow's hardware-backed keystore (especially this one, your bank's app could set up an ECDSA signing key that is used to authenticate to their servers, providing access to your banking information. That key could be configured to be unlocked by your fingerprint. If the fingerprint matching were provided in the regular OS then any compromise of the regular OS would enable access to your bank account, because the TEE-based ECDSA key would be relying on a signal from the regular OS to tell it to unlock the key. But because the TEE-based ECDSA key relies on a signal from the TEE-based fingerprint matcher, a compromise of the regular OS won't get the attacker in to your bank account (not unless you're around to put your finger on the scanner).

FYI, for Marshmallow the password authentication has also been moved into the TEE, and TEE-based keys can also be access controlled with password auth. So your bank could do the same sort of thing, but require you to enter your device password rather than present a fingerprint.

Or am I completely off base here?

Nope, what you said made perfect sense, you were just missing some pieces.

I should mention that for Android 6.0 the Compliance Definition Document (which specifies what it means to be Android) makes all of the TEE stuff "strongly recommended", but not "mandatory" for Marshmallow devices. However, it is all mandatory for devices that have fingerprint readers. The CDD also warns that it will become mandatory for N. In spite of not being mandatory for Marshmallow, though, it looks like nearly all major device vendors will have the new TEE stuff in their new devices (those launching with Marshmallow).

Note that if verification fails at any stage, the user must be visibly notified and always be given an option to continue using the device at their own discretion. (source: https://source.android.com/dev...)

So everything I expected could be rendered useless will actually still have a chance to run. *Exales in relief*

"But go get ... reaches out and..." Stop. go get isn't part of the Go langauge; it's the default Go build environment. And yes, it lacks many features you'd want in a so-called "professional" build system (whatever that means this week).

I get the impression that Go was perhaps intended to be used with repo, a tool principally used for managing the Android project, but also used elsewhere inside Google to manage large numbers of independent Git repositories. With repo, you establish a common branch or tag name across all the repositories that comprise your project, then "repo sync" to them. Poof! Build and version management. (Sorta.)

Who verifies it?

http://source.android.com/devi...

http://source.android.com/devi...

It's a hardware key. The good news is that you can unlock it if you want.

When you transition from a locked state to an unlocked state, the device is wiped. If the device is unlocked, there is a warning on the boot screen.

So, if an evil organization tries to backdoor your phone (or you just want to flash another OS on it), the data is lost and a warning comes on. You are free to do as you want with the device. Should you wish to re-sell the phone, you can restore it to factory.

If you can replace the keys, the NSA can too.

Who verifies it?

http://source.android.com/devi...

http://source.android.com/devi...

It's a hardware key. The good news is that you can unlock it if you want.

When you transition from a locked state to an unlocked state, the device is wiped. If the device is unlocked, there is a warning on the boot screen.

So, if an evil organization tries to backdoor your phone (or you just want to flash another OS on it), the data is lost and a warning comes on. You are free to do as you want with the device. Should you wish to re-sell the phone, you can restore it to factory.

If you can replace the keys, the NSA can too.

Want Android? Pay M$.

Wrong. Head over here and grab Android, no payment necessary to anybody.

Want Apple? You're probably paying M$.

Wrong again.

Want a PC? Unless you build it yourself, you're paying M$.

Nope. Still wrong. Even from the biggest vendors you can buy Linux laptops and there are plenty of ChromeOS-based systems from laptops to desktops. Even if you buy a PC pre-loaded with Windows you can contact the manufacturer for a refund of the license cost.

Even if you don't, they're still controlling the hardware specs.

No. No they aren't.

This is extortion and monopolization at its finest.

No it isnt extortion and certainly in today's realm of personal computing that includes everything from smartphones to tablets to PCs Microsoft does not have a monopoly by any definition. There are a wealth of personal computing options: Windows, various Linux distros, OSX, iOS, Android, Windows Phone, FirefoxOS, ChromeOS, etc.

Meanwhile, my blood ran cold when I read this knowing that LadyAda sold out. I guess she needed the money. So much for Adafruit.

Nobody "sold out", you're just upset at choice and competition. Competition is a good thing, we have it in personal computing and we should have it in the embedded space too. If you don't like Windows on embedded devices then by all means choose Linux instead, nobody is stopping you.

No, fake contacts doesn't solve the problem. The problem is you need a better model is. Funny fact Android already has one:

http://developer.android.com/r...

A similar model was adopted by FirefoxOS from the start:
"Web Activities are a way to extend the functionality of HTML5 apps without having to access the hardware on behalf of the user. In other words, you don’t need to ask the user to access the camera or the phone, but instead your app asks for an image or initiate a call and the user then picks the app most appropriate for the task. In the case of a photo the user might pick it from the gallery, the wallpapers or shoot a new photo with the camera app. You then get the photo back as a file blob. The code is incredibly simple:"

https://hacks.mozilla.org/2013...

It's a form of the https://en.wikipedia.org/wiki/...

Actually, it's not that bad.

Google Photos app on the iPhone for pictures, and iTunes to transfer contacts and music will be enough for most people.

This was even available many years ago when I moved from the iPhone 3G to the Nexus S.

Actually I bet they do let a similar app from Google in the store, should Google ever put one out, simply for the reason that it would be less of a PR headache and would save them from potential litigation.

  Granted, the nature of such an app would probably mean that the app really needs to come from Samsung or HTC or LG or something and they might tell those guys to fuck right off but if Google does it they might allow it

Well, according to the Switch to Android instructions, while it's not one app, Google recommends you switching to the cloud to do it. As in you install the full suite of Google applications to help migrate your contacts, photos and email to Google's cloud services, at which point your Android device will pick it all up automatically.

So it's not quite one app, and it will be very inconvenient to use on iOS because of the way the OS protects users privacy. E.g., when the app migrates contacts, the user will be asked if the app can access their contacts. When the app migrates photos, they get prompted for location services (because photos can be a proxy for GPS location - take a photo, then try to access it to get GPS. iOS still treats it as the app is trying to get location information without trying to use the GPS). Email and messages, I'm not entirely sure if iOS even lets apps access that stuff...

Then again, given the general poor quality of Google's apps, I'm sure Apple will love to approve it and have Google deal with the users who have the app crash, or failed to transfer their contacts and stuff.

Heck, given the number of obvious crashing issues in Google's apps, one almost thinks Apple just gives Google a green light and doesn't even bother reviewing them.

You said it was 1:1 routing. That means if you have 12 PCs connected to your phone, the carrier is giving you 12 IPs, plus one for the phone itself I guess.
You also said that most phones weren't able to do NAT.

Why is CONFIG_NF_NAT=y enabled by default on base Android configuration then?

https://source.android.com/dev...

It looks to me that NAT is enabled on all Android devices, and chances are it's probably being used for the hot spot function. Otherwise Google would list it as an optional/recommended feature.
For the phone CPU, handling over all the packets to the radio, or NAT/routing them, make no difference in terms of battery or CPU usage. We are not talking about a lot of packets here, nor a gigabit link.

Its predecessor, Lollipop, clawed it way to 18.1% share in just 9 short months! In fact, Android versions released since October 2013 (KitKat) account for a whopping 57.4 share! With quick adoption like that, you should plan to upgrade your current phone to Marshmallow any day now.

(Achievement unlocked: I typed that whole thing with a straight face.)

So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?).

yes, people do it all the time. you can start here:
https://source.android.com/sou...

So, can you really expect to compile that and end up with something that you can load into your phone (and have it work?). No.

Yes, actually. The AOSP builds should work out of the box in the sense that you can load them onto an Android-compatible phone (with an unlocked bootloader) and run normal Android applications with the stock Android user interface. Some additional functionality may require the installation of closed-source drivers, most notably accelerated graphics and Wi-Fi. The closed-source drivers needed to run AOSP with full functionality on various Nexus devices are distributed for free by Google.

By contrast, while there are some open-source components in iOS, they only extend up to the UNIX core (Darwin) and do not include any of the user interface components. If you tried to build the open-source parts of iOS the result would not only be lacking support for various standard hardware (with no drivers available, open source or otherwise), it wouldn't even be an image you could load on your iPhone, and even if you manage to get a loadable image it wouldn't have a user interface. AOSP may lack the proprietary Google applications and open-source versions of some device drivers, but it otherwise comprises a complete operating system.

it is oss as far as the os goes, but many of google's apps and their underlying service frameworks are closed source. so what you do is compile the os for your device and obtain an archive of the google apps/services exactly like cyanogenmod, et. al. do.

So, it is Open Source in the same way that OS X and iOS are. Darwin is Open Source. Many Frameworks are Open Source; but then...

Where can I download the iOS source code? Oh wait you can't. But you can download the Android source code

The only broken part of Android is when other device manufactures get their hands on it. They are the ones that are updating their devices. I have a Nexus 6 which gets updates right from Google. This is no different the someone having an iPhone and getting updates right from Apple.

Any app with the mic permission can listen -- it does not need to be signed by the OEM/system/rom. What they can't do is leverage a lower power dedicated processor such at that on the Moto X. But any app can turn on the mic with the correct permission granted.

http://developer.android.com/r...

It sure is nice for you that you can make billions of dollars by exploiting a Linux kernel made for free by volunteers and rebrand it Android

Nothing wrong with making money from free software. And so long as the changes are contributed back Linus himself is in favor of Tivoization with respect to the Linux kernel.

but where's my Bash shell, Google?

Right here.

Why do you have to use Free Software to deny me my Freedom, Google? Hey!! FUCK YOU, Google.

Here is your freedom, go nuts.

Sure, it's right here. Check out XDA devs, there are tons of ROMs built off of AOSP.

Any other uninformed comments you want to make, Crapple shill?

So why isn't this whole StageFright vulnerability a non-issue? (Which it isn't).

Because pretty much most of the whole Android Userbase DOESN'T even know what ROOTING is, let alone how to do it, or how to install a custom ROM without borking their device.

So, even if there ARE custom ROMs available (that you can trust!!!) for a given device, only a vanishingly small percentage of the Android Userbase knows how to take advantage of them.

Sure, it's right here. Check out XDA devs, there are tons of ROMs built off of AOSP.

Any other uninformed comments you want to make, Crapple shill?

One. My mobile phone supports Vorbis as do all Android devices.

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

You must feel so smart listing all those UNIX operating systems. You know so many!

Is Edge going to be portable to non Windows operating systems like GNU/Linux, FreeBSD, Solaris, OS X, HP-UX, OpenServer X, Haiku OS, AIX, Android and Firefox OS?

Android, you don't have the source to reproduce the software environment that actually ships with your phone, so what has it really accomplished?

You don't what the what, now?

That is how Android is dealing with ART. https://source.android.com/dev...

JAVA (Dalvik) the ideal ISA, dex2oat converts the java bytecode to native ISA (intel or ARM).

Similar to pNaCL in Chrome, where at least historically the LLVM IR (effectively the ISA) would be pushed to the chrome devices which would then complete the conversion to native code.

According to the Play Store, it allows me to install it on all my Lollipop devices:

My T-Mobile LG G2, my Sony Xperia Z Ultra, and my Nexus 9.

May be, they're doing a staged rollout thing. Staged rollouts are a good idea from a technical perspective. The marketing department hates them, but on a popular app they can avoid you thousands of negative ratings/reviews because there is always someone, whether it's an impatient higher up or an impatient developer, that tries to make one tiny little change to the final build that doesn't have the time to go through proper testing.

The most common version is now KitKat with 39.8%. Jelly Bean is second with 39.2% and Lollipop has just under 10%.

https://developer.android.com/...

Keep in mind that a lot of Android users have low incomes and/or live in countries where an over the air OS update would be a significant cost to the average person. We might think that a smartphone is useless without at least a 1GB per month data plan, but hundreds of millions of users in the developing world think otherwise.

Older applications not targeting M, will show permissions at install time and be granted by default, but the user will be able to revoke them, the platform will just give empty data or fail. From the preview documentation

Note: On devices running the M Developer Preview, a user can turn off permissions for any app (including legacy apps) from the app's Settings screen. If a user turns off permissions for a legacy app, the system silently disables the appropriate functionality. When the app attempts to perform an operation that requires that permission, the operation will not necessarily cause an exception. Instead, it might return an empty data set, signal an error, or otherwise exhibit unexpected behavior. For example, if you query a calendar without permission, the method returns an empty data set.

If you are worried that old applications can use the permissions immediately after installation, before you have time to disable the permissions, take into account that applications are installed on a stopped state, there is no programmatic way for it to auto start itself. Start on boot may work but it is not precisely immediately. So I think the best action is to go to those old applications just after install and remove every permission you don't want to grant before starting it.

Java is dead

Um, wut? https://developer.android.com/... Java as a language isn't dead. I'm positive that if Google thought their move of disabling Java plug-ins would have killed off interest in the language, they would be moving their SDK away from it. And before you say it, no, NaCl is NOT an adequate replacement.

Not with Lollipop. It uses the ART runtime as the default, and precompiles all apps for the local architecture.

https://source.android.com/dev...

I would rather see most apps just use intents:

http://developer.android.com/g...

Need an image because you are the QR-code app ? Ask the image 'app'. The user can pick to choose the camera app and make a picture if he/she wants or grab an image from the image gallery app.

Need a contact ? Ask the contact 'app'.

Now most apps don't need any permissions any more. And the user knows what data the app gets because the user chooses the data and the app the data came from.

In the past, Steam was full of defects that caused it to often lose the cached receipts* that allow offline mode to work. The earliest versions (in the Half-Life 2 era) wouldn't even try to download these receipts for offline use unless the user chose "Go Offline" while online. Even the current version still has bugs that appear to require the purchase of a UPS according to Valve's page about offline mode:

Stored information that is required for offline mode to function may be lost when forcing Steam to close instead of exiting Steam correctly. Always manually close Steam before shutting your computer down or running out of battery life if you wish to use offline mode for an extended period of time.

If the required offline mode data is lost, there is no way to start Steam without an internet connection.

* "Receipts" are what the OUYA IAP system calls the associations between an item that can be purchased and a user account. Google Play Licensing calls it a cached licensing status. The terminology might differ for Steam.

I'm not sure you have your facts straight.

https://source.android.com/sou...
Code name Version API level
Lollipop 5.1 API level 22
Lollipop 5.0 API level 21
KitKat 4.4 - 4.4.4 API level 19
Jelly Bean 4.3.x API level 18

http://en.wikipedia.org/wiki/A...
Latest release 5.1 "Lollipop" / March 10, 2015; 32 days ago

LOL no, that won't help you understand any better.

Then what would help me understand better? I'm trying to be sincere here. How do apps normally avoid loss of the most recently entered data in case of a shutdown that effectively already happened, such as the last keystrokes before the app is killed? The sequence is supposed to be pause, stop, destroy, but I've read that the OOM killer occasionally skips these steps when under severe memory pressure.

Well, then your assumption is invalid wherever the app doesn't require a login. So if you have to concede that my point is sometimes valid, you can then also address your arguments about it to the cases where it is valid.

Apps that do not require any login whatsoever are likely to be read-only. Read-only apps can use ad-hoc encryption and signing of responses tunneled over cleartext HTTP. I concede this.

But I still see no evidence for your claim of being able to communicate using cleartext HTTP without the INTERNET permission. An answer to this question states that HttpURLConnection requires INTERNET. Google's networking tutorial mentions techniques that require INTERNET. The answer to this question states regarding INTERNET: "Any application that accesses the internet for any reason will have to request this permission."

I concede that I haven't read the entire Android API docs from cover to cover. Is that required before you're willing to begin to help me? If not, what level of familiarity is required?

it is actually pretty well officially documented by google these days. making something "hard to accidentally trigger by someone who doesn't read documentation and who we think is too stupid to know what it will do" is not quite an easter egg...though close. :)

I do try to purchase Google products, like the Xoom Tablet, it needs replaced and I'm waiting for Googles offer. Google doesn't care if you root (Jail break) their products and once rooted you don't want to use any device that isn't.

I was on top of the updates (Xoomforums.com) yet had to ask how to access the developers section, it's required to access the USB to PC connection to use ADB. Documentation for anything Android is lacking for the newest versions.

ADB = http://developer.android.com/t...

I don't know if you need to clean your glasses, but the page you linked to specifically mentions the GPL'd code bits but if you need more information, this should inform you.

http://source.android.com/sour...

What are you guys even talking about? Android is released under the Apache license.

In typical MS fashion it didn't get good until 3 versions later, IE4, before getting proprietary vendor lockin with that piece of shit IE6.

If IE6 was such a piece of shit, as you put it, that implies that the other browsers at the time were much worse than that. You've inadvertently made a profound statement about the browser landscape of the day. IE6 rightfully earned infamy in its unnaturally long life even more repugnant is rampant revisionism. IE introduced a feature that is the foundation of today's web, some of you might be aware of the XMLHttpRequest object, for the non-developers it's like the force now, all around us. JavaScript support and performance, CSS support. Unfortunately this period had to occur, and it will occur again once these lessons are forgotten; Without the stranglehold IE6 eventually obtained, and more importantly stagnated the web with, the choices we have today wouldn't exist.

Their stupidity of not being able to down-grade IE or simultaneously install different versions so web developers could test ALL the various versions, forcing people to rely on hacks like SandBoxie, was absolutely retarded.

As much as it pains me to say Microsoft wasn't unique in this regard, as an aside, try installing multiple versions of Safari. Even the easy mode package managers don't support multiple versions of browsers out of the box (not to say it's difficult). Internet Explorer 6 released in 2001 following the launch of Windows XP. For those unfamiliar with their history, Web Development of that era revolved around IE and Netscape. With IE being the Chrome of its day (as in "works here, onward!") since the browser market was 90%+ IE and IE6 was supported on Windows 98, NT, and 2k. Low usage for potential targets results in a chicken and the egg problem. Low single digits just aren't a priority for many shops, see Opera.

Sandboxie came out in 2004ish and has its uses, especially on 32bit machines. However, for web development involving IE it's much easier to use MultiIE which has been around since 2006. IETester is worth another mention. Not to mention there are alternatives due to the ever growing number of devices and variants released year after year, requiring a different approach such as farms that show screenshots from targeted browsers. Regarding the hassle of Sandboxie, limiting yourself to one tool is pretty silly.

This is a little off topic. Since this criticism is being framed as a Microsoft issue you might be shocked to discover how apps and to a lesser extent websites, are developed and tested in 2015 on devices manufactured and supported by multiple vendors. This process requires physical devices, in many cases multiple to support the popular OS versions on them (there are other OS, but they're less than 8%). Think it's a hack to wrangle Sandboxes or multiple installations, try wrangling devices that let you only upgrade! But what about device simulators, one might ask? Oh yes, they do exist and they're improving but there isn't a substitute for deploying and testing on device. IE variants are a dwindling piece of the very large fragmentation pie.

Microsoft writing the browser from scratch, is too little, too late.

Too late for whom? W

No user of any popular tablet or smartphone today, Android or otherwise, is exposed to the kinds of internal implementation details you mentioned. The APIs provided by both iOS and Android are very much geared to the per-app/sandbox model used by apps on those systems, and even on Android, you wouldn't normally be messing around with a FHS-style directory tree the way Linux desktop or server applications would.

Anyway, I don't know whether you are wilfully missing the point just to troll or you really can't understand that there are fundamental differences between tablet/smartphone and desktop/laptop use cases beyond the cosmetic details of their shells, but further discussion here seems unlikely to get us anywhere useful.

From day one Android has had a system of screen grouping based on physical size and DPI. You produce a UI layout for each group, and Android loads the appropriate one for the device.

https://developer.android.com/...

According to Android Developers Dashboards more than 92% of the present activated devices run some version of android past 4.0.3 (ICS), with the grand majority being Jelly Bean and Kit Kat devices. Thus if you develop for ICS or Jelly Bean you'll target most of the devices accessible by the Play Store.

I think what tends to be the greatest hurdles in compatibility right now are devices with either low ram, or low internal memory (since Kit Kat in several devices does not allow apps to get "moved to sd card" without rooting, effectively hampering stuff like HQ games and the likes...

Download the Android source from the official site for free: https://source.android.com/sou...

Android includes proprietary drivers and other code that you don't get to access unless you're a big OEM giving Google money, branding agreements, etc. Android also includes other code that does make it into the public release, but delayed for many months (often over a year).

The repository you linked isn't Android. It's an old version of stripped-down Android that no one can use to create a competitive high end device. Google does this because of what Amazon did with the Kindle line, and because of what they fear Samsung could do. (Hint: Fork Android, have your own store, and cut Google out of the picture.)

This is why Google made their apps separate (and not free) for OEMs. People want Google's apps, but they don't care about Android Caramel Apple when they're already on Lemon Meringue. By tying those apps to a CASH MONEY license or a branding / no fork / first born's soul agreement, Google always gets a piece.

This is also why Google doesn't want to patch old devices. Doing so just means people have less incentive to run the latest version of Android, which is the version Google can guarantee it gets paid for. Carriers have similar motivation - testing/pushing out the updates is costly, and NOT doing so encourages people to buy a new device and extend their contract.

Phones with 512MB can, however, be upgraded to KitKat 4.4, which reduced the minimim required RAM back to 512MB.

I have a rooted phone running 4.3. I use Chrome for browsing, but realize other apps may use webview and be vulnerable. In fact they make it easy for developers to do so.

http://developer.android.com/g...

I'm wondering if I can simply disable it by deleting/renaming a library or something similar, or will that make the entire OS unstable? I don't care if it breaks apps - those would only the vulnerable ones anyway. Absent that, it looks like it is possible to remove access to individual apps through their manifest files.

http://developer.android.com/g...

But of course as I said that would break them.

I'm not a developer, but maybe a script that will search out all manifest files (as root of course) and neuter any vulnerable apps by altering them would be useful. Once you know which ones are broken you can set about safely fixing them.

Any thoughts?

I have a rooted phone running 4.3. I use Chrome for browsing, but realize other apps may use webview and be vulnerable. In fact they make it easy for developers to do so.

http://developer.android.com/g...

I'm wondering if I can simply disable it by deleting/renaming a library or something similar, or will that make the entire OS unstable? I don't care if it breaks apps - those would only the vulnerable ones anyway. Absent that, it looks like it is possible to remove access to individual apps through their manifest files.

http://developer.android.com/g...

But of course as I said that would break them.

I'm not a developer, but maybe a script that will search out all manifest files (as root of course) and neuter any vulnerable apps by altering them would be useful. Once you know which ones are broken you can set about safely fixing them.

Any thoughts?

Download the Android source from the official site for free: https://source.android.com/sou...

You might be thinking of the Play store and other Google apps, which as you say are not free. You can download and install them for free as a user, but if you want to ship them pre-installed on a device then there are licence agreements. Nothing in those agreements about having to launch a flagship phone or nonsense like that... Android is winning because it is available on everything from low cost low end devices to the very top tier hardware.

As for the costs, Cyanogen seems to prove that they can be pretty low. They support a lot of devices with very little funding to do so, partly because they are open source and rely on volunteers. Some companies pay them for support, which seems like a reasonable way to do long term updates.

You should never buy a phone from a carrier. Always get it unbranded and unlocked.