Related
Just a thought:
The manufacturer of an Android device only has to support android updates for that devices for a limited period of time. It is in their interest and the interest of the cell carriers, that each handset has a limited lifespan.
Cyanogen's (and others) rom's are pro-longing the life of handsets by allowing users to bypass the limits on a device's supported android versions imposed by the manufacturers and cell carriers.
E.g. say if HTC decide not to release an official Android 2.0 or higher version rom for the existing HTC G1. The only possible way for users to have such a rom, would be if a member of the community rolled their own and made it available.
This is really only a conspiracy theory, but maybe the manufacturers / cell carriers have spotted the above issue and started pressuring Google to halt community roms. Google needed an excuse to do so, and used the distribution of closed applications in the roms!
Just a thought.....
donster80 said:
Just a thought:
The manufacturer of an Android device only has to support android updates for that devices for a limited period of time. It is in their interest and the interest of the cell carriers, that each handset has a limited lifespan.
Cyanogen's (and others) rom's are pro-longing the life of handsets by allowing users to bypass the limits on a device's supported android versions imposed by the manufacturers and cell carriers.
E.g. say if HTC decide not to release an official Android 2.0 or higher version rom for the existing HTC G1. The only possible way for users to have such a rom, would be if a member of the community rolled their own and made it available.
This is really only a conspiracy theory, but maybe the manufacturers / cell carriers have spotted the above issue and started pressuring Google to halt community roms. Google needed an excuse to do so, and used the distribution of closed applications in the roms!
Just a thought.....
Click to expand...
Click to collapse
yeah that is good point but i think the limited hard where the g1 is whats going to kill it. i have been 3 through 3 already
We really don't need more threads on this, this has already been brought up in multiple threads.
Hello,
Im currently writing an academic paper on android and openness in my master's programme. If all goes well, it will be submitted for a conference soon.
I'm looking for your opinions on having an android device open for operating system level modifications or not. As you may know, some phones have a signed bootloader such as the Motorola Milestone, t-mobile g2 (who made the phone reinstall stock OS when breached), and probably many others. Google however, make their devices open, even though they are sold as consumer devices. Many others do not bother to install circumvention mechanics.
Obviously, the people here will be biased towards allowing modification to the OS, therefore, i would like to get a discussion going, to discern what problems and possibilities you see in the long run for hardware manufacturers.
1. Does the possibility of making OS level modifications affect your willingness to purchase an android product? i.e. do you check if it can be modified before buying? And how much of an impact does it make on your desicion?
2. Why do you think hardware manufacturers put in measures to prevent custom android OS builds to be installed? Put on the corporate hat and try to see their strategy.
3. Do you think manufacturers have anything to gain by making devices open and free for modification, with source code for drivers and the like publically available?
I would really appericiate your opinions and discussion!
1. Does the possibility of making OS level modifications affect your willingness to purchase an android product? i.e. do you check if it can be modified before buying? And how much of an impact does it make on your desicion?
As a beginner app developer, this has yet to bother me. I do enjoy being able to add apps that add functionality to my phone but I haven't bothered to get down into the "root" area. So no I do not check nor does it impact my decision...I own a Samsung fascinate by the way
2. Why do you think hardware manufacturers put in measures to prevent custom android OS builds to be installed? Put on the corporate hat and try to see their strategy.
My opinion on measures to prevent changes is all about PR and performance. If enough people hacked a phone and the hack caused the phone to work below is ability then the only news report you will see is the phone sucks.
3. Do you think manufacturers have anything to gain by making devices open and free for modification, with source code for drivers and the like publically available?
This is also a give and take if question 2 is not of a concern to them, then its def a gain for the company and to all of the developers out there that do search for the best phone and nick pick around until they find it.
Are there enough of those kind of people out there to affect a companies buttom line. Maybe not yet but in another couple of years who knows.
1. Does the possibility of making OS level modifications affect your willingness to purchase an android product? i.e. do you check if it can be modified before buying? And how much of an impact does it make on your desicion?
It hasnt yet been a deciding factor on which device to get, primarily because sooner or later they all get cracked open.
2. Why do you think hardware manufacturers put in measures to prevent custom android OS builds to be installed? Put on the corporate hat and try to see their strategy.
One reason could be that the carriers demand it as a way to keep any revenue that they get from the preinstalled bloatware.
3. Do you think manufacturers have anything to gain by making devices open and free for modification, with source code for drivers and the like publically available?
The percentage of people that actually tinker in this area is very slim, so the manufacturers most likely don't see that as a big market opportunity.
Don't have any answers, but would like to read your paper when done...sounds interesting and a Masters Thesis is always fun to read! LOL
It's not a thesis, just a short article. I might make a survey for it but I need to ask the right questions.
Not all devices get fully customized, root is common, but in my phone for example it is not possible to load a custom kernel, as the bootloader checks for signed code (Motorola's secret key). There's been a massive uproar from the owners of the Milestone, as people didn't expect to be hustled like that when getting an android phone. The main problem is of course, that Motorola takes a long time to release updates. Even as of today, Froyo has still not been released for my phone by Motorola.
While I am not sure about it, I suspect Sony Ericsson X10i owners are in the same boat, and they will get a really rotten deal, seeing as 2.1 has been officially declared the last version the device will recieve. Yet, an enthusiast could release a perfectly fine version of 2.3 if the phone accepted custom firmware and he had access to drivers etc.
So basically, you buy a piece of hardware that is very capable, but The Company decides for you which software you could run.
Imagine if you bought a Windows Vista PC right before Windows 7 was released, and the only way you could get Windows 7 on it was if that particular PC manufacturer released an official update containing all it's bloatware and applications you don't want. Since the update needs to go through all kinds of verifications and approvals, it might be delayed for a half a year, or maybe 9 months, after the new OS release. Why do we accept this on our phones and tablets?
Hi,
1. Does the possibility of making OS level modifications affect your willingness to purchase an android product? i.e. do you check if it can be modified before buying? And how much of an impact does it make on your desicion?
For me personally, yes, most definately. I like to be able to get in and play, see how things work, change stuff. And i think custom ROMs IMO are a big drawcard of Android.
2. Why do you think hardware manufacturers put in measures to prevent custom android OS builds to be installed? Put on the corporate hat and try to see their strategy.
To try and ensure the device works as they want it to. Minimise support costs etc.
3. Do you think manufacturers have anything to gain by making devices open and free for modification, with source code for drivers and the like publically available?
Definately. Encourages improvement of existing features, and development of new stuff beyond the manufacturers initial product scope, which can be integrated in future products.
Android OS its self is an example of this - the developer community is writing apps, logging bugs, and contributing code to the benefit of future releases of Android, which in turn benefits device manufacturers.
- jc
my two cents
1. Does the possibility of making OS level modifications affect your willingness to purchase an android product? i.e. do you check if it can be modified before buying? And how much of an impact does it make on your decision?
>> Personally, I feel like the ability to modify my phone at the core level is something I as a power user can use to tailor my phone's experience in the way I need to make it the most efficient device it can be. This is especially necessary as my phone is my primary connectivity device (I really only use my laptop for things the phone just really isn't capable of handling yet, such as video conversion)
2. Why do you think hardware manufacturers put in measures to prevent custom android OS builds to be installed? Put on the corporate hat and try to see their strategy.
I think this is less the decision of the manufacturers and more of the carriers themselves. This really is because each device has to be tailored to be sold to the average user, rather than power users (read: 85-90% of people who will read this reply) and as a result is designed with an experience in mind. To the suits, anyone who take a phone that is supposed to have a specific experience in mind, and changes that, it becomes a different phone, and anyone who looks at that phone will see that. This means, TMo/HTC can't sell a G2, because everything that my office mates will see when they look at my phone is my android customizations, not a G2. my office mate, who is shopping for a phone, can get an android phone anywhere... but they can only get a /G2/ from TMo/HTC. Similarly, if I like my G2 experience, when i get a new phone, i will be more inclined to continue enjoying that experience with a G3, rather than buying any on sale android phone and making it just like my last one. Hence the need to have a G2 experience on every G2 phone. Just my 2 cents. I am not a businessman, lawyer, or doctor.
3. Do you think manufacturers have anything to gain by making devices open and free for modification, with source code for drivers and the like publically available?
Yes, but nowhere near as much as they can get by keeping their cards close to their hand. see my answer to number 2.
Vulnerability Allows Attackers to Modify Android Apps Without Breaking Their Signatures
This might be the reason why the new MF2 and ME6 are not downgradable and why the 4.2.2 update was delayed.
Source->http://www.cio.com/article/735878/V...ndroid_Apps_Without_Breaking_Their_Signatures
IDG News Service — A vulnerability that has existed in Android for the past four years can allow hackers to modify any legitimate and digitally signed application in order to transform it into a Trojan program that can be used to steal data or take control of the OS.
Researchers from San Francisco mobile security startup firm Bluebox Security found the flaw and plan to present it in greater detail at the Black Hat USA security conference in Las Vegas later this month.
The vulnerability stems from discrepancies in how Android apps are cryptographically verified, allowing an attacker to modify application packages (APKs) without breaking their cryptographic signatures.
When an application is installed and a sandbox is created for it, Android records the application's digital signature, said Bluebox Chief Technology Officer Jeff Forristal. All subsequent updates for that application need to match its signature in order to verify that they came from the same author, he said.
This is important for the Android security model because it ensures that sensitive data stored by one application in its sandbox can only be accessed by new versions of that application that are signed with the original author's key.
The vulnerability identified by the Bluebox researchers effectively allows attackers to add malicious code to already signed APKs without breaking their signatures.
The vulnerability has existed since at least Android 1.6, code named Donut, which means that it potentially affects any Android device released during the last four years, the Bluebox researchers said Wednesday in a blog post.
"Depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet," they said.
The vulnerability can also be exploited to gain full system access if the attacker modifies and distributes an app originally developed by the device manufacturer that's signed with the platform key -- the key that manufacturers use to sign the device firmware.
"You can update system components if the update has the same signature as the platform," Forristal said. The malicious code would then gain access to everything -- all applications, data, accounts, passwords and networks. It would basically control the whole device, he said.
Attackers can use a variety of methods to distribute such Trojan apps, including sending them via email, uploading them to a third-party app store, hosting them on any website, copying them to the targeted devices via USB and more.
Some of these methods, especially the one involving third-party app stores, are already being used to distribute Android malware.
Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said.
However, if an attacker tricks a user to manually install a malicious update for an app originally installed through Google Play, the app will be replaced and the new version will no longer interact with the app store. That's the case for all applications or new versions of applications, malicious or non-malicious, that are not installed through Google Play, Forristal said.
Google was notified of the vulnerability in February and the company shared the information with their partners, including the members of the Open Handset Alliance, at the beginning of March, Forristal said. It is now up to those partners to decide what their update release plans will be, he said.
Forristal confirmed that one third party device, the Samsung Galaxy S4, already has the fix, which indicates that some device manufacturers have already started releasing patches. Google has not released patches for its Nexus devices yet, but the company is working on them, he said.
Google declined to comment on the matter and the Open Handset Alliance did not respond to a request for comment.
The availability of firmware updates for this issue will differ across device models, manufacturers and mobile carriers.
Whether a combination of device manufacturers and carriers, which play an important role in the distribution of updates, coincide to believe that there is justification for a firmware update is extremely variable and depends on their business needs, Forristal said. "Ideally it would be great if everyone, everywhere, would release an update for a security problem, but the practical reality is that it doesn't quite work that way, he said."
The slow distribution of patches in the Android ecosystem has long been criticized by both security researchers and Android users. Mobile security firm Duo Security estimated last September, based on statistics gathered through its X-Ray Android vulnerability assessment app, that more than half of Android devices are vulnerable to at least one of the known Android security flaws.
Judging by Android's patch distribution history so far, the vulnerability found by the Bluebox researchers will probably linger on many devices for a long time, especially since it likely affects a lot of models that have reached end-of-life and are no longer supported.
Click to expand...
Click to collapse
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Key phrase here is "for apps not installed through the google store". Hence not an issue for a large fraction of users. Total case of FUD. Someone must be wanting to sell some av software.
Sent from my GT-N7100 using Tapatalk 4 Beta
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
Well, X-Ray scanner either does not detect this latest security flaw or N7100 (as of DM6) is allready patched.
Kremata said:
I really thought more people would be interested in knowing this. I would really like to know what you guys think about this.
Click to expand...
Click to collapse
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literally hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
djmcnz said:
This is the first link I found for XDA on this.
I think it's not that interesting because it's old, old news and exactly why it's being touted as a "new" discovery is beyond me, it's far from new.
We here at XDA have been using this method for years to modify stock Android and OEM system apps with great success. Here's an example by me from 2011: http://forum.xda-developers.com/showthread.php?t=994544 there's a literry hundreds of examples all over XDA.
The real question here is how Bluebox security got everybody to act as a PR machine for them. If they turn up at Black Hat with this "amazing discovery" they're going to get laughed off the stage.
Click to expand...
Click to collapse
Ahh! Thats the answer I was waiting for (and from a Recognized Developer). I knew XDA Devs were using this method. My new question is.. If they fix it will it be harder to create Mods? Will it slow down development?
Shouldn't this be posted in the generals forum?
Kremata said:
If they fix it will it be harder to create Mods? Will it slow down development?
Click to expand...
Click to collapse
I suspect so. If they fix it properly it would become impossible to change any aspect of the app without signing it again. If you wanted to maintain compatibility with the original then you'd need the developer's keys.
At the moment really only the manifest and some metadata within the apk is signed, if they extended that to the entire contents of the apk many mods (think themes for stock Google apps etc) are screwed unless users are happy to relinquish Play Store links and updates (i.e. backward compatibility).
Google may not go this far and may only choose to authenticate the code (smali) rather than all of the apk contents (graphics, strings etc), this approach would leave room for some mods to survive. Remains to be seen.
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
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