Database Users

Researcher To Release Web-Based Android Attack

I hope we get 2.2
http://it.slashdot.org/story/10/11/05/0229205/Researcher-To-Release-Web-Based-Android-Attack
"The attack targets the browser in older, Android 2.1-and-earlier versions of the phones."

http://forums.t-mobile.com/t5/Samsung-Vibrant/Security-vulnerability-in-2-1/td-p/535335
And the thread appears to have already been locked.
EDIT: My bad, the link icon isn't a lock icon.

What an ass. So he figures out something and now hes going to release it?
So is his intensions to piss people off or force Googles hands to fix it?

kizer said:
What an ass. So he figures out something and now hes going to release it?
So is his intensions to piss people off or force Googles hands to fix it?
Click to expand...
Click to collapse
I think its the latter. That, or to light a fire under the OEMs & network operators to get 2.2 out to more devices. Just my $0.02...
Sent from my SGH-T959 using XDA App

The current OEM vendor/carrier model is one of the worst parts of Android. Google attempted to break this model via the Nexus One. Hopefully it does light a fire to improve the security model for these phones.
Google may be forced to rein in some of the rampant variances to secure the platform via enforcing a minimum level of compliance to security updates or else revoke a phone makers ability to use the Android trademark.
The problem has already been fixed with 2.2, so the onus is on the OEMs to get their act together.

Some things make me want to respect this guy, then again it affects me since we have yet to recieve 2.2. But yes I believe all android phones should be running current software.

I wonder if you need to be rooted in order to fall the vicitm, unless you can push superuser.apk via the exploit and run it.
Have to give him props for trying, and like seeing that he is using linux based OS to develop on

lqaddict said:
I wonder if you need to be rooted in order to fall the vicitm, unless you can push superuser.apk via the exploit and run it.
Have to give him props for trying, and like seeing that he is using linux based OS to develop on
Click to expand...
Click to collapse
Youre right! Maybe he works for T-mobile and is secretely making all our phones go back to stock and unrootable. Which in turns means they will never release 2.2 hahaha. <- By the way do not take this as actual fact I know how the paranaoid are here on the forums lol

lqaddict said:
I wonder if you need to be rooted in order to fall the vicitm, unless you can push superuser.apk via the exploit and run it.
Have to give him props for trying, and like seeing that he is using linux based OS to develop on
Click to expand...
Click to collapse
No, this a generic exploit within WebKit. The actual exploit itself doesn't have superuser access, it can only access what the web browser is able to access. It can't make phone calls or generate SMS messages, but it can access files like photos and whatever else is available to non-rooted apps.

I don't know why you guys think this guy is a douche. This is how it always worked. When people find security vulnerbilities, they tell the company, but the company usually doesn't move it up to the top of the list to fix. So they mention the type of security flaw there is, sends the information to the company, and sometimes even mention it at conferences. After publicly announcing it, they give the company time to fix it, otherwise it's the company's fault for not getting their ass in gear to fix the security issue.

DKYang said:
I don't know why you guys think this guy is a douche. This is how it always worked. When people find security vulnerbilities, they tell the company, but the company usually doesn't move it up to the top of the list to fix. So they mention the type of security flaw there is, sends the information to the company, and sometimes even mention it at conferences. After publicly announcing it, they give the company time to fix it, otherwise it's the company's fault for not getting their ass in gear to fix the security issue.
Click to expand...
Click to collapse
I do no see how he is a douche.
Ignoring the issue does not make it disappear, and he clearly has done his work to make the issue public in hopes it gets addressed.
Releasing a code with a security hole that you have to use something to circumvent the security of the device to fix is douche (apple vs jailbreakme.com anyone)

kizer said:
What an ass. So he figures out something and now hes going to release it?
So is his intensions to piss people off or force Googles hands to fix it?
Click to expand...
Click to collapse
I was paranoid by this too. My Vibrant will shackled from having sex with the web until it gets 2.2 Maybe that researcher wants them to release Froyo soon so use this to leverage against them to release ASAP?

I don't think he's a douche. I honestly want to believe that google would push carriers to be on the same OS. Just the fact that not all android phones can handle the 2.2 OS - And so people stuck with those phones and would be affected by this flaw is pretty crappy. But I really hope this makes carriers want their phones updated and running the latest and greatest. Only time will tell.

[Documenting] Google's Nexus 10 MALI GPU memory leak *NOW RESOLVED*

Hi everyone, I'm not sure how useful this thread will be - but I hope it will be useful. As I've watched new N10 users come into the fold of finding and wanting to learn more about "the reboot problem" I realize the information on this topic is spread all over the place. I've tried to gather the information, as well as present it in a good fashion, such that there is a link/thread that can be easily referenced. I'm not the most technical of this crowd (I mean c'mon I am here at XDA!) so please forgive me and notify me of any needed corrections or clarifications.
---[Documenting] Google's Nexus 10 MALI GPU memory leak *UNRESOLVED*---
The Nexus 10, henceforth N10, is an Android tablet made by Samsung for Google. At launch in November 2012 the N10 was shipped with Android 4.2.0
*
Included in the N10 is a SOC (system-on-a-chip) from the Exynos line:
http://en.wikipedia.org/wiki/Exynos_(system_on_chip)
*
The Exynos uses a GPU made by ARM. The GPU component is the ARM Mali-T604.
http://en.wikipedia.org/wiki/Mali_(GPU)
*
Starting immediately after the N10’s launch there were reports of “random reboots”. At first not much was known about the exact cause of these reboots. The audience participating in these reports experienced varying degrees of testing results, especially as 4.2.1 and 4.2.2 updates rolled out. The majority of this discussion is captured in two threads:
https://productforums.google.com/forum/#!topic/mobile/VFYnt7uN9d0[1-25-false] *
and
http://forum.xda-developers.com/showthread.php?t=1998496
(*Note that the Google thread was erroneously marked ‘Answered’ after one of the OTA roll outs.)
*
The community was able to flush out that the memory/RSS use of Android’s surfaceflinger process seemed to be the victim of a memory leak, and that by monitoring the RSS value one could predict when the tablet would experience the degraded performance. Viktor.M then created this open issue report that focuses in on that:
https://code.google.com/p/android/issues/detail?id=54757
*
About that time a user named apstrand, who appears to either be an ARM developer or at the very least someone who is extremely knowledgeable in this area had found more exact and detailed info on this, and he posted it here:
https://code.google.com/p/android/issues/detail?id=52579
*
Matthew Fry began contacting Samsung, then in turn ARM, as he posted in one of the Google threads. Eventually he was able to get this response: "I can confirm that we were able to reproduce the issue in the stock Nexus 10 4.2.2 provided by Google. We were, however, unable to reproduce it with our release driver.
We will test the application again when the next release of the firmware for Nexus 10 is published."
*
From this point, knowing ARM has code that avoids the error, people began looking into working on the code themselves, and asking ARM for assistance. ARM has posted source code components for the T-6xx series of drivers here:
http://malideveloper.arm.com/develo...n-source-mali-t6xx-gpu-kernel-device-drivers/
However ARM has also stated, “these components are not a complete driver stack. To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard ARM commercial licence to all Mali GPU customers.” This means Samsung has an ARM DDK (Driver Development Kit), but to date has not released it/aspects of it to the public.
*
For now there appears nothing anyone can do without access to the ARM DDK.
*
EDIT/UPDATE: Since my original post here, a lot of activity happened in a short period of time. Many comments below capture this. I will add the history into this thread, but the big news is 4.3 is out for the N10 now and the community is testing. Like each time a new Android version has rolled out, community testing is "all over the place" with different people reporting different results. People who know how to measure the exact parameters on this bug are reporting it looks like it may be fixed! Its noteworthy though that there is some suspicion of other issues. Because I want to keep this first post based only on facts, I am going to wait a while and see the community results before posting an update that cant be backed up by actual data.
***
FINAL UPDATE: Ok, looks like its fixed now. I'm not saying they didn't morph it somehow to another issue, but I am saying the exact situation we were all focused on here is no longer going on w/ the 4.3 (4.3.x if you want to include the 3mb update.)

bigmatty said:
Hi everyone, I'm not sure how useful this thread will be - but I hope it will be useful. As I've watched new N10 users come into the fold of finding and wanting to learn more about "the reboot problem" I realize the information on this topic is spread all over the place. I've tried to gather the information, as well as present it in a good fashion, such that there is a link/thread that can be easily referenced.
Click to expand...
Click to collapse
Nice overview of the problem. I would add that one of the Android bugs you link to is marked as assigned, by none other than Jean-Baptiste Queru, the technical lead of the Android Open Source Project at Google. He also renamed the other issue, so it appears that Google is finally aware of the problem and working on it. Hopefully, this means a fix is forthcoming in the upcoming Android 4.3 release, but that is merely a hope on my part: I have no inside info.

bigmatty said:
Hi everyone, I'm not sure how useful this thread will be - but I hope it will be useful. As I've watched new N10 users come into the fold of finding and wanting to learn more about "the reboot problem" I realize the information on this topic is spread all over the place. I've tried to gather the information, as well as present it in a good fashion, such that there is a link/thread that can be easily referenced. I'm not the most technical of this crowd (I mean c'mon I am here at XDA!) so please forgive me and notify me of any needed corrections or clarifications.
Click to expand...
Click to collapse
Thank you, this thread was sorely needed. This seems like a really big mess-up on Google's part. Has there been a memory leak this bad before for any other device?

patsmike said:
Thank you, this thread was sorely needed. This seems like a really big mess-up on Google's part. Has there been a memory leak this bad before for any other device?
Click to expand...
Click to collapse
I don't think so. My Dad has a Nexus 7 and it doesn't have this issue at all. I really hope that 4.2.3 or 4.3 fixes this - it's making me completely lose patience with the device and I'm getting tempted to sell it. First the light leak issue and now this. Come on Google, you really are taking the piss here. I'm not sure how they could get it so wrong?!

bigmatty said:
...This means Samsung has an ARM DDK (Driver Development Kit), but to date has not released it/aspects of it to the public.
Click to expand...
Click to collapse
So this fix requires Samsung to do it.
Almost hate to say it but I really don't see it being fixed anytime soon...

I confirm that surfaceflinger is f***ed up on my Nexus 10 too.
It screws up very, very fast when connected with USB debugging and I start to code OpenGL ES 2.0-based live wallpapers.
---------- Post added at 10:04 PM ---------- Previous post was at 09:58 PM ----------
espionage724 said:
So this fix requires Samsung to do it.
Almost hate to say it but I really don't see it being fixed anytime soon...
Click to expand...
Click to collapse
Not that bad. If it was HTC, we'd be screwed forever. With Samsung, we have a tiny (well, like, really tiny ) hope that something will be done in this regard.

I have been reading that Nexus owners may get 4.3 this month - anyone think the problem may be addressed?
In this thread http://productforums.google.com/forum/#!topic/mobile/VFYnt7uN9d0[476-500-false] - some dude from Google acknowledges that they know it's a problem - but he hasn't said anything in 6 months.
Really hope it is sorted out - I am keeping my fingers crossed.

bruce_aisher said:
I have been reading that Nexus owners may get 4.3 this month - anyone think the problem may be addressed?
In this thread http://productforums.google.com/forum/#!topic/mobile/VFYnt7uN9d0[476-500-false] - some dude from Google acknowledges that they know it's a problem - but he hasn't said anything in 6 months.
Really hope it is sorted out - I am keeping my fingers crossed.
Click to expand...
Click to collapse
As a comment above suggests, the bug has been assigned by Jean Baptiste-Queru little more than a week ago. We can only hope that it was fixed and merged into 4.3.

starkilling said:
As a comment above suggests, the bug has been assigned by Jean Baptiste-Queru little more than a week ago. We can only hope that it was fixed and merged into 4.3.
Click to expand...
Click to collapse
From what I read the developer of the surface finger driver already has an in-house fix and acknowledged that they reproduced the issue with the stock ROM. Those two comments give me hope.
Sorry but I do not have a link. I also have no idea why fixed drivers have not been released considering every ROM (stock and custom) must use the same proprietary drivers. It is likely that they require Google to distribute the fix.

I really hope to see this fixed soon, the random reboots really make the tablet unreliable. I can't do much serious work on the thing since every couple of hours or so the thing resets, losing all my work.

tbosje said:
I really hope to see this fixed soon, the random reboots really make the tablet unreliable. I can't do much serious work on the thing since every couple of hours or so the thing resets, losing all my work.
Click to expand...
Click to collapse
I use RasBeanjelly and I have not had a single random reboot. No reboots on mrRobinson's AOKP as well. You do have to reboot every couple of days, though. It really depends from ROM to ROM. Stock really rebooted on me like a motherf***er though.

I saw that one of the Google staff responded to the google product support thread the other day, a sign of progress?
starkilling said:
I use RasBeanjelly and I have not had a single random reboot. No reboots on mrRobinson's AOKP as well. You do have to reboot every couple of days, though. It really depends from ROM to ROM. Stock really rebooted on me like a motherf***er though.
Click to expand...
Click to collapse
I've spent so much time customising my apps and launcher, flashing my whole unit is such a hassle. Guess I might have to though :/

tbosje said:
I saw that one of the Google staff responded to the google product support thread the other day, a sign of progress?
I've spent so much time customising my apps and launcher, flashing my whole unit is such a hassle. Guess I might have to though :/
Click to expand...
Click to collapse
You can back them up, you know.

Posted by Matthew Fry on Google Product forums earlier today :good:
Ladies and gentlemen, I have the most amazing news. Pretty much the best news I can think of.
I have finally received word back from the Mali Developers. They revisited the issue and found that the fault was indeed in the Mali drivers.
"Following previous emails, the Nexus 10 issue that you have been mentioning has been fixed in the latest versions of the Mali driver."
It is, unfortunately, Google's responsibility to release this new driver version with the next Nexus 10 factory image. We can only hope that the fact that I/O has come and gone and the recent release of the Google Edition S4 and One on 4.2.2 does not mean that JB 4.3 or KLP are a long ways out.

chinmaysk said:
Posted by Matthew Fry on Google Product forums earlier today :good:
Ladies and gentlemen, I have the most amazing news. Pretty much the best news I can think of.
I have finally received word back from the Mali Developers. They revisited the issue and found that the fault was indeed in the Mali drivers.
"Following previous emails, the Nexus 10 issue that you have been mentioning has been fixed in the latest versions of the Mali driver."
It is, unfortunately, Google's responsibility to release this new driver version with the next Nexus 10 factory image. We can only hope that the fact that I/O has come and gone and the recent release of the Google Edition S4 and One on 4.2.2 does not mean that JB 4.3 or KLP are a long ways out.
Click to expand...
Click to collapse
Link, please? I can't find it.
Edit: found it, nvm. there were lots of pages

Can one of the mods please pin this thread in the forum? It seems like every week someone comes in and asks about this issue. Once a fix is released, this thread can be unpinned.

6 Month and Samsung and Google havent resolved that.....
Hope 4.3 comes out soon

kswiss86 said:
6 Month and Samsung and Google havent resolved that.....
Hope 4.3 comes out soon
Click to expand...
Click to collapse
Well, I hope the driver didn't come out from Mali too late to make the 4.3 release.

Funny thing is I even said to myself that I'll never buy anything from Samsung again, how wrong I was thinking the Nexus 10 would be different because it's from Google.

With 4.3 out next week (possibly) I do hope Google decide to put this emergency fix in. It really gets on my nerves that this tablet just randomly reboots because I know how much potential this tablet has and I feel this is holding it back.
Sent from my Nexus 10 using xda app-developers app

Marshmallow Defect Corrections Release?

It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...

The marshmallow update give me some new features and better battery life (though I do own the X Style, not pure). Unless you are dead set on being intentionally obtuse, then this isn't considered an alpha update.
Also the 6.0.1 update is quite minor, the largest change being some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's: http://www.androidheadlines.com/2015/12/google-posts-android-6-0-1-changelog.html

I know the label "alpha" is not not the official label for something like 6.0. But with so many substantial defects, and multiple forthcoming revisions to correct those defects a certainty, that's really what it is IMO. Maybe "public release alpha" would be a better description, since pre-release revisions go through even more defect-ridden levels including pre-release alpha, prior to public release.
Similar situation with previous Android versions, and in fact most software foisted on the public these days (I'm looking at you, Microsoft and Apple). Look at Lollipop and the multiple public release revisions it took to iron out most of the substantial defects, finally, with 5.1.1.
6.0.1 is not just "...some ART performance improvements, the rest is adding bands to the Nexus line and some emoji's...", it also includes defect corrections. (Bluetooth, anyone?) And if the changelog doesn't list a significant number of defect corrections, that doesn't necessarily mean it is already polished at 6.0.1. The fragmented Android ecosystem and separation between Google, phone manufacturers, carriers, and users guarantees a plethora of various non-trivial defects in the ecosystem, many of which Google will address only slowly or even never for most phones.
For example, the memory leak defect in LP was not fixed until 5.1.1. How may revisions and months did that take? How many phones still run pre-5.5.1 with this defect?
One reason I bought the MXPE was the idea that it would be one of the first to get the updates. That turned out to be overly optimistic. It looks like Nexus is the only one still close enough to the source to get timely updates, and it also looks like Google is not pursuing Android defect corrections with any kind of urgency at all nowadays, maybe because the hardware ecosystem is becoming way too diverse to adequately support any more (or maybe because the profits roll in no matter what). Motorola phones, with the Moto alterations to Android, outsider status with carriers, and now hollowed-out Motorola support, appear to be no closer to adequate Android support from Google than any other non-Nexus phone.
"Obtuse"? A "bug" is a euphemism for a defect. Let's stop being obtuse, and call it what it is.
Any other info also appreciated.

You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.

MattBooth said:
You're being obtuse by insisting that we're all public alpha testers.
You obviously have no idea about software development, nor about Android Open Source development. Not your fault, but running your mouth is.
You bemoan the memory leak fix took several revisions to fix. So, you think that Google dedicated the whole team to fixing that one bug? What then? No other bugfixes or features are introduced in the meantime? The likely case is (and this is from experience) that bug took some revisions to fix, in the meantime, Google were also pushing ahead with other fixes. Regardless to what the uneducated (about SW development), throwing 15 developers onto one problem doesn't solve it any quicker. 5.0.1 came, adn 5.0.2 came, then 5.1 came in the meantime. While that memory leak was being worked on, more releases come fixing other things. Be grateful they didn't listen to you and leave it at 5.0 for several months while they fixed one issue.
Whatever bluetooth fixes that you think are in 6.0.1 are pure fantasy, because none exist in AOSP 6.0.1: http://aosp.changelog.to/android-6.0.0_r5-to-android-6.0.1_r1.html <-- That's the FULL changelog of commits between 6.0.0_r5 and 6.0.1_r1.
It is not Google's job to fix a problem in anything other than their own devices. At all. Google's job is to make AOSP run smoothly on Nexus devices and release the source. Samsung, HTC, LG, Motorola et al all take the source code, just like CM, AICP, Slim and the rest do, and make modifications for their devices, using the sources given to them by their hardware partners and themselves. So if BT works in Nexus devices, but not others, then it's not Google's problem (usually). An AOSP issue will persist several devices, including Nexii devices.
Google also have taken on the quite large undertaking of monthly security updates for their devices, which I can tell you will be taking up some of the development teams time (it's what, 3-4 months into that project?).
No software ever released on this planet comes without bugs and issues. This is software development. You can check the status of AOSP development here: https://android-review.googlesource.com/#/q/status:open and feel free to download, code and submit your own features.
Click to expand...
Click to collapse
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...

Tinkerer_ said:
t
No new or useful information there. Thanks anyway, despite the ad hominem. I guess that comes with the territory (forums).
Yep, the Google-Android-(independent hardware makers) ecosystem is seriously flawed. Too much disconnect between the OS owner (Google), the hardware makers, the carriers, and the customer. And the first three in the chain (not including the customer) have different incentives/disincentives, and there are a bazillion hardware variations, of course it is broken. We know all this.
Reminds me of the original PC/Windows mess. Except worse because the carriers interpose an additional dysfunctional layer hindering OS updates/support. (Before anyone says "just DIY with one of the many available ROMs, I started this "Q" thread about stock MM, not third party ROMs.)
Still hoping for any useful information on anything happening to fix the MM defects, to get an idea when it might be past public beta and worth installing to MXPE.
TIA...
Click to expand...
Click to collapse
What ad hominem? Your uneducated state affects your ability to understand the nature of Android and software development. It's a perfectly legitimate response to your position. You lack the ability to understand and therefore your argument is flawed. I'm not attacking you, I actually tried to give you some insight into how it works, but you're not really interested and would rather insist on this "public beta" bull.
As far as fixing any "defects" you suppose, you haven't actually listed any so no-one is going to be able to help you with temporary work around without a list of what you feel is broken. I also showed you the changelog, so you can do your own homework to see if your supposed defects are fixed in 6.0.1.
The various hardware configurations doesn't even matter because Android is built to deal with it. So long as the hardware vendors of chips and modules support them properly and give out functioning binaries to OEM's, or proper source code, it's irrelevant. The exact opposite of what you said is true, Google has a very close relationship with it's partners (anyone signed up to their Google programs, to preinstall Google apps). The problem is carriers, who really shouldn't have a say in software on the phones, but that seems to be a chiefly North American problem.
Google doesn't need to have any connection to Android users as customers. Google does not sell Android, therefore you are not Google's customer unless you use a Nexus phone. Google sell the Google Experience, with the Nexus. You are Motorola's customer, and you are using Motorola's branched version of Android. Google doesn't owe Motorola any fixes or patches for their device. Motorola must maintain their own device tree and maintain their own relationships with their partners.
EDIT:
Also, Motorola's problem is resources. They have four version of the Moto X 2015 to deal with, three versions of the Moto X 2014, the new X Force, then the various versions of the G and E to deal with, along with two smart watches, and so forth. Their line up is increasing whist I imagine their development team is not. There was outrage (rightly so) when news broke that the Moto G 2015 wasn't getting the MM update, despite being a couple of months old, and Motorola listened and OTA's are rolling out.

I am asking if anyone can offer any info on anything being done to move toward MM revision with the many significant defects of 6.0 corrected. Read the forums, there are way too many defects with 6.0, it is patently a de facto public alpha, and we are tracking the usual pattern where it takes 3 to 5 revisions before an OS major rev is ironed out enough that upgrading will not cause more problems than it fixes.
There are always excuses made for why there are so many defects in software. There is a euphemism for "defect" everybody uses, "bug". Everyone has been making excuses for so long about shoddy workmanship and inadequate testing and correction of software, with the "bug" euphemism to minimize the reality that these are defects, that we are all just to suppose to accept systems ridden with faults without complaint. It's unacceptable. It can be done better. Part of why it doesn't get better is because everybody says "that's just the way it is, deal with it". With mountains of byzantine excuses and even ad hominem attacks (as here).
This thread was not started to start a tit for tat ad hominem back and forth, nor to post long essays detailing excuses for the pathetic status quo of the fragmented Android ecosystem with respect to defect causes and distributions. It was started looking for any info about work being done to fix the stock MM defects. Still seeking info.
TIA.

You should probably check the definition of ad hominem. There was no attack on you as a person, just pointing out that your uneducated state with regards to knowledge about software development affects your ability to call judgement on this.
But you haven't listened to a single word I've said and still maintain a shoddy position, so I would suggest to anyone else who reads this to simply ignore you as a troll.

Tinkerer_ said:
It looks like Marshmallow is following the usual pattern of Android "x.0" alpha release to the public, followed by "x.0.1" beta release with initial defect ('bug") corrections starting with Nexus beta testers (I.e. Nexus users in general).
Reading about the MM 6.0 problems on MXPE, I'm sitting out the 6.0 alpha testing on the sideline with LP 5.1.1. Most trouble-free phone I've had yet, and I don't yet need the only compelling feature I see with MM on the MXPE (T-Mobile Band 12 support).
Any noises yet about MM beyond 6.0.1? (I know I can look for this elsewhere too, but thinking maybe some of the XDA community may have inside info from the Android community.)
TIA...
Click to expand...
Click to collapse
I think we'll close this debate. There are no real "Android" insiders on XDA, so asking for update info which is privy to Google is perhaps somewhat futile.
On a related note, XDA have a few dedicated "Android Fora", such as this complete Category where non-device specific discussion and indeed conjecture takes place. Perhaps you could take a look there and see what transpires?
Thanks

N6F26R 7.1.1 February image posted

As title...
https://developers.google.com/android/ota#shamu - OTA full image
https://developers.google.com/android/images#shamu - full image

Is the microphone issue fixed?
Sent from my Nexus 6 using Tapatalk

Same bootloader, same radio. FYI

FLaMpeR said:
Is the microphone issue fixed?
Sent from my Nexus 6 using Tapatalk
Click to expand...
Click to collapse
I have the same question. This bug is annoying.

Demonoid_i_am said:
I have the same question. This bug is annoying.
Click to expand...
Click to collapse
Yes it's fixed for me.
Sent from my Nexus 6 using XDA-Developers Legacy app

buge boyo said:
Yes it's fixed for me.
Sent from my Nexus 6 using XDA-Developers Legacy app
Click to expand...
Click to collapse
Glad we can fix it...is dirty flash from 7.1.1 alright?
Sent from my Nexus 6 using Tapatalk

Strange. Just swapped phones with my wife and the loudspeaker echoes horribly, so I guess it's not fixed for me, unless I'm misunderstanding the problem...
Edit: Half an hour later, after dinner and a flash of Yoinx's speaker fix, both my wife's Nexus 5 and my Nexus 6 are clear as a bell, both of them on loudspeaker. I therefore say that the Google image does not contain the loudspeaker fix - not from where I sit, anyway. Anyone else?
"is dirty flash from 7.1.1 alright?"
Yes. I flashed the OTA directly over the existing N6F26Q and it works fine.

Best way to tell is if someone could pull the mixer file and diff it to see any changes ... I would but I'm not in front of my setup right now.

Well, from where I sit the best way is to call someone, switch on your N6 loudspeaker, and see if they can hold a conversation with you... Which I did. And it didn't work until I flashed Yoinx's zip.

Google will most likely not fix it. Any new updates will most likely just be security patches. If you want the fix then I would flash the zip or grab a custom roms that has it fixed for ever. Never can say I ever had this issue as I don't use speaker phone ever. Unless completely alone it is considered rude.

The nerve. Why in the world would they leave such a feature broken. I know some people don't use it but the purpose of a phone is to freaking work. Doesn't matter if you use that feature or not. Others do. I use speaker all the time because I work from home. Stock software shouldn't have this problem. Period. It's been over a month and still no fix from Google. Meanwhile our guys fixed it almost immediately. This is just plain negligence and disrespectful at this point. I guess it's a sign they want us to get a new device so they completely fu**ed this phone by breaking what is a core and even basic feature of all phones. Ridiculous and ******y practices. At this point there literally is nothing that's making me more mad.

MysticKing32 said:
The nerve. Why in the world would they leave such a feature broken. I know some people don't use it but the purpose of a phone is to freaking work. Doesn't matter if you use that feature or not. Others do. I use speaker all the time because I work from home. Stock software shouldn't have this problem. Period. It's been over a month and still no fix from Google. Meanwhile our guys fixed it almost immediately. This is just plain negligence and disrespectful at this point. I guess it's a sign they want us to get a new device so they completely fu**ed this phone by breaking what is a core and even basic feature of all phones. Ridiculous and ******y practices. At this point there literally is nothing that's making me more mad.
Click to expand...
Click to collapse
What do you expect. The device is EOL which means anything broken will stay broken. Then add in that the OS was coded for 64 bit devices and had to be ported to our device to begin with. Also really if you are not willing to dig in and fix the issue then you miss the whole point of owning a nexus. It's a developer device.
And yes some people use it and some don't. That is the way it is with all features.
Getting upset about it is really pointless.

AOSP commits from 7.1.1_r13\N6F26Q to 7.1.1_r17\N6F26R
.
project bionic/
e046081 Check for bad packets in getaddrinfo.c's getanswer.
project build/
8a89878 N6F26R
e225344 Update Security String to 2017-02-05 on nyc-dev
8e84b75 Update Security String to 2017-02-01 on nyc-dev
project device/htc/flounder/
a37d1ee Fix security issue in Visualizer effect
project external/libavc/
cf606f3 Decoder: Fix in checking for valid profile flags
project external/libgdx/
c156e72 Fix security vulnerability
project external/libhevc/
3a64694 Fixed handling invalid chroma tu size for error clips
f22345d Fixed out of bound reads in stack variables
e20f6b8 Fix in Chroma SAO for non-multiple of 8 height
project frameworks/av/
048ba59 Fix security vulnerability: potential OOB write in audioserver
bab10e4 Effect: Use local cached data for Effect commit
project frameworks/base/
593144f [DO NOT MERGE] Fix vulnerability in MemoryIntArray - fix build file
de5747d Fix vulnerability in MemoryIntArray
a66099e DO NOT MERGE. Retain DownloadManager Uri grants when clearing.
4df434d DO NOT MERGE: Check provider access for content changes.
project frameworks/native/
541b1eb Correct overflow check in Parcel resize code
74dae33 Fix security vulneratibly 31960359
509fb5c Fix SF security vulnerability: 32706020
project hardware/libhardware/
9f0e940 Fix security vulnerability: potential OOB write in audioserver
project libcore/
c55ce33 Fix URL parser may return wrong host name
project packages/apps/Bluetooth/
379e7b6 Remove MANAGE_DOCUMENTS permission as it isn't needed
project packages/apps/Messaging/
1bb11f3 resolve merge conflicts of eafd58a to nyc-dev
13f739b 32807795 Security Vulnerability - AOSP Messaging App: thirdparty can attach private files from "/data/data/com.android.messaging/" directory to the messaging app.
86e5bf5 32322450 Security Vulnerability - heap buffer overflow in libgiftranscode.so
project packages/apps/UnifiedEmail/
1fc7b01 Don't allow file attachment from /data through GET_CONTENT.
project system/core/
7f94bb4 change /data/bugreports to /bugreports
project system/sepolicy/
54a3eec label /bugreports

dahawthorne said:
As title...
https://developers.google.com/android/ota#shamu - OTA full image
https://developers.google.com/android/images#shamu - full image
Click to expand...
Click to collapse
Is there a TWRP flashable version? Those of us with root ava TWRP need to extract the zip and flash system. IMG, boot.img etc. Using ADB?

zelendel said:
What do you expect. The device is EOL which means anything broken will stay broken. Then add in that the OS was coded for 64 bit devices and had to be ported to our device to begin with. Also really if you are not willing to dig in and fix the issue then you miss the whole point of owning a nexus. It's a developer device.
And yes some people use it and some don't. That is the way it is with all features.
Getting upset about it is really pointless.
Click to expand...
Click to collapse
Okay so you're telling me it's perfectly fine for a manufacturer to leave a device in a broken state because the device reached the end of its life? This is what's wrong with the world lol. And no I'm not missing the whole point of the nexus line. This is my first Nexus device however. But that's not the point. You don't leave major bugs like this unfixed. Not sure about you but if I pay for something EVERYTHING on the phone should work correctly. Of course there'll be a few minor hitches here and there. I expect that from betas and custom roms. But that's what BETAS and custom roms are for. The point of the nexus line is to play with custom software. Of course if some things from that doesn't work then of course you can't expect google support. You buy a nexus (or at least you used to) to get pure Android without skins like TouchWiz or HTC sense. And of course to experiment with custom software. Just because google allows custom software on the device does not give them the right to fu** us on an update then leave it to the community to fix it. Luckily we have a terrific community that fixed it in no time. But still I expect that google fixes the mistake they made. Because it was in fact their mistake. They released an official update. Not a beta. This is supposed to be stable!

sanumaj said:
Is there a TWRP flashable version? Those of us with root ava TWRP need to extract the zip and flash system. IMG, boot.img etc. Using ADB?
Click to expand...
Click to collapse
No, you don't need to do all that. You can if you want, but the OTA is a one-button solution - sideload via ADB, reboot, job done. You'll need to reroot.

zelendel said:
The device is EOL which means anything broken will stay broken.
Click to expand...
Click to collapse
I wouldn't argue with zelendel on technical matters, but I can on matters of policy and principle.
This is no different from taking your phone in for repair and finding that they've fixed what you asked them to fix but have broken another component. You could argue that the difference here is that the ROM upgrade is free; I refute that by saying that I paid a great deal of money (£549/$800) on the understanding that I would receive ongoing support. That support does continue to come, and I welcome it, but the bottom line here is that Google broke a function and are therefore morally obliged to repair it. And since this is the company whose motto at the beginning was (is it still...?) "Don't be evil" I think I'm entitled to get upset, no?

For me its simple. Google broke it so Google needs to fix it. EOL or not, they brought out an official security update that has a error in it. But to be honest, i don't believe that Google even cares about the N6, to them its an old phone not worth putting much time and energy in.

Well it's a punch in the face to all of us who purchased the Nexus 6. This year Nexus 6p and 5x will suffer the same fate and next the Pixel phones. Great way to keep trust. The speakerphone is really important while driving or when using in a conference call which the latter is in my case. They've spent way to long time without fixing it. I'm grateful for the custom ROM community but Google should have fixed it long time ago for those who depends on running stock. Because of issues like this and conducts like this, people will move on to a different OEMs. In a marketing side of view, Google will loose customers in the long run.

TMG1961 said:
For me its simple. Google broke it so Google needs to fix it. EOL or not, they brought out an official security update that has a error in it. But to be honest, i don't believe that Google even cares about the N6, to them its an old phone not worth putting much time and energy in.
Click to expand...
Click to collapse
EOL does matter though. Google broke a core function of our device on the last official Android update we will get. One could argue it was not intended to make us buy a newer device, but Google's behavior on it leaves much open to speculation.
And to the anyone defending Google, would it be OK if auto manufacturers updated your car's radio on the first service appointment after the warranty had expired, and said update disabled all but one of your speakers? That's essentially what Google has done to the N6. To top it off, seeing the defense of Google is like going back to work after your service appt, and when you complain about the broken speaker functionality at the water cooler, your co-workers tell you you should give Ford some slack, after all, you're outside the warranty period, and they didn't the have to update anything for you.

Vuneralable software should be removed from xda

Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...

Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
What's the vulnerability?

Plain and simple the software needs removed.. doesn't that apply to the devs policy's which they agreed to here on xda not to publish anything which may be a threat to someone... So you know what should of happened is the devs should of removed the software right away. That never happened so I've lost all faith in theses devs and publishers of official software threads...

I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened

sliding_billy said:
I ignore all posts where the word "of" is used instead of the correct "have" or at least the contraction ending in 've that sounds like of.
...should of happened
Click to expand...
Click to collapse
I ignore all posts that don't make sense like the OP's and this thread.

Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
First, there are no Oreo roms. Secondly, the devs who support our phones for free owe you nothing. Lastly, you need more than 12 posts to be taken seriously about anything around here. And, you can never post enough to attain the right to throw around accusations about the devs who, again, support our phone for free.

Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
Tell us how you really feel!

Windows people ?
Sent from my Pixel using XDA-Developers Legacy app

Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
If this is the case all root and bootloader exploits need removing also.
Any bootloader exploits or method of rooting without and unlocked bootloader is a SIGNIFICANTLY large security risk.
Sent from my Pixel using Tapatalk

Are we going to remove ALL the old ROMs from XDA? SHEESH.

In before the lock.

One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.

Pixelxluser said:
One thing I've found out over the years with hacking Android you eventually get tired of doing just hacking so you move onto security... Well that's the case with me anyways. Getting rid of vuneralable software is actually a good thing...
There's a reason why malware is successful with Android, and it's one that still hasn't been addressed: most phones are using old software and haven't been patched against it.
Google does a lot of work to make Android secure and keep it that way. It pays people to find security exploits, works with hardware vendors like Qualcomm or NVIDIA to fix them if needed, then writes a patch that can be injected into the existing version with no fuss. If you have a Pixel or Nexus or BlackBerry product, you'll then get these patches. If you have any other phone you roll the dice and hope the people who made it care enough.
Click to expand...
Click to collapse
Nobody hacks individual phones. They hack companies and clouds.

****! Hey, can y'all hold it for just a moment? Need to run to the store real quick. I'm out of popcorn.
Seriously, though, just simply rooting your phone is a security risk. Also, from what i've seen, the majority of ROM users are smart about what they download. It's the general public that downloads mischevious apps that spread viruses. And as someone else mentioned, the malware and viruses don't target one person's phone. They are free floating and latch onto whatever moron downloads it. Your phone is not exactly the best place to download all your porn
But seriously, there are exploits with every security patch...it's the reason we get them every month, lol. Android is great and I love it but the OS itself is full of holes that malware developers consistently take advantage of.

Couldnt say this better myself..
Security is engineered into everything we do
Our goal is to make Android the safest computing platform in the world. That's why we invest in technologies and services that strengthen the security of devices, applications, and the global ecosystem.
It's also one reason Android is open source. Being open allows us to tap into a global network of security talent full of innovative ideas that help make Android safer every day. Security experts around the world can review our code, develop and deploy new security technology, and contribute to Android’s protections.
As the Android ecosystem evolves, we continue to invest in leading-edge security ideas. And we want to share our knowledge openly with you. Explore below to learn about the latest technologies and information that help secure Android.
Adrian Ludwig
Director of Android Security

Pixelxluser said:
Now it's clear there's a security problem with the official build of Oreo before Sept builds.. now all the Oreo roms and official roms have this vuneralablity... If you're gonna continue to publish them without replacing them with the sept security patch you may as well put a damn virus in you're roms cause that's basically what you're doing...
Click to expand...
Click to collapse
With some custom ROMs whether or not the have the Sept security patch is probably the least of your problems, if security is a concern of yours... you should be more concerned with things like;
- what keys are they using to sign their ROM (Apks included). Did they generate their own private signing keys and platform keys, or did they just use a devkeys or keys provided in the SDK?
- what changes have they made to aosp sources or not integrate (or revert) that could reduce security?
- have they messed with android's security or permissions model?
- have they included legacy code (like forward porting), that may have been dropped in the first place do to being insecure (legacy mediaserver without seccomp integration).
- have they modified selinux policies in ways that potentially could open up attack vectors.
- does the ROM have odexing enabled? The fact is, odexing while useful for booting/loading programs faster, also has the side benefit of making an apk harder to tamper with...
- have any changes that have been made been audited, or verified for correctness?
...and the list goes on. You are worried about a monthly security patch, with a handful or two of fixes for CVEs, yet make no mention of far bigger concerns that may be present in XYZ custom ROM.
Just saying.

contribute to Android’s protections. Is one thing which is lacking from what I see... I hope you understand that there are underaged people who don't know any better about what's best for them and come running off to try to be the cool kids by rooting or adding unsecured software on their phones.. rooting is so crazy to do now a days you're all really going to the extremes by bypassing security features just so you can have root... That's not the message the younger generation should be taught... They should be taught the importance of how security works not 50 ways to bypass it... There's not a feature out there which Google wouldn't consider adding officially but also Google doesn't go off and use unofficial code to pull features from it would look bad for their business..

And as long as there's a community of underaged people who do go off and root and install unsecured software you might wanna lead by example and provide them with the best security you can... A child with unsecured software is scary that someone would open up security holes for them to be a possible victim and the best you're actually willing to do is try to remove yourself from the responsibility of being responsible for it by saying if you install our software you are responsible for any damages. You can't just publish something then go out and say you take no responsibility when by law you're still responsible for any damages cause you never legally got you're software that way...

Since you're the ones distributing the software you're liable for damages if there was a defect in you're product which was distributed.. security flaws and security bypasses count as defects in a product..
Distributorship and Liability
Even though the distributor is not responsible for manufacturing a product, it can be held liable in the event of defects. Under strict product liability laws, the seller, distributor, and manufacturer of a defective product can be held liable if a person is injured due to the defect. Though manufacturers are typically most responsible since they created the product, the liability can also fall to those that distribute or sell the defective items.
This liability law prevents the plaintiff from the need to prove the chain of supply. In order for any entity in the line of distribution to prove it has no fault, it would need to show which entity is actually responsible for the defect

I suggest you stick with Windows dude
The only thing your posts are good for is making people spit their coffee with humour, and embarrassing yourself.
Sent from my Pixel using XDA-Developers Legacy app