Related
JBQ posted:
Setting up AOSP support for Crespo meant that I had to drop Dream and
Sapphire. That opened up more possibilities about using AOSP on retail
devices: the only variants of Dream and Sapphire that were designed
for AOSP work were the ADP1 and ADP2, which are rare, whereas any
retail Nexus S can be unlocked. Nexus S gives you both the openness
that comes with the ability to unlock it and the security that comes
with the ability to lock it back.
Click to expand...
Click to collapse
(emphasis mine)
Could the ability to unlock and relock the bootloader have been planned by El Goog? Is this a part of a business model? Does Google find this to be ideal? Are they, perhaps, recognizing the developer community, and showing a commitment to be even more open?
Samsung has had some "oversights" lately. I want to say there was something with the Galaxy S and rooting, but I'm not remembering well. I know that the Vibrant came with AT&T frequencies, yet was launched on TMo. There was a very simple way to enable those frequencies, because the unlock codes were stored on the phone. Now we've got the ability to unlock and relock a bootloader on the S. The unlocking of frequencies could be an oversight, as well as the bootloader. Or is this something that's been planned, with input from Google? Could Google have found a partner who's willing to be as open as possible?
I just found it a very interesting comment. Perhaps I make too much of it...
Thought for sure I'd get a response out of this. No one finds it interesting?
The Nexus One has "fastboot oem unlock" but not lock.
I'm guessing Google just told Samsung to add a lock command and will most likely tell all future "Nexus" handset manufacturers to do the same.
Very doubtful these commands will ever make it to any other Android device aside from the Nexus line.
I suppose they saw that they were getting tons of N1s returned with unlocked bootloaders and they repaired them anyways, so they probably decided to just allow the "lock" function to be used...
Although it really doesn't change anything tbh, and if it works like the lock, it will wipe everything on the phone which kinda sucks
As it was said, it is very doubtful we will see that kind of easy unlocking on other devices! This is a dev device, so it has to be "more open" to allow devs more flexibility.
I don't think Google ignores the dev community and I'm pretty sure they are happy it exists, because it makes Android better (I wouldn't be surprised if some of the official features were inspired from here and there )
I think you're correct in Google is simply making it easier for developers to root and flash custom Android builds to the phone. "Fastboot oem unlock/lock" are planned features of this phone according to Tim Bray, so there is no question.
One of the points made during the "Is Android Open" debate around the blogs/twitter was that the OS may be open, but there isn't much hardware that is. They probably paid attention to the debate seeing as Andy Rubin himself weighed in, as such we continue to see the Google experience phone as being open (enough).
On a side note: when the NS was released, every blog I saw (Engadget too) ran a headline about how quickly the phone was rooted.. If you run an Android-specific blog and held this opinion, seriously check yourself cause you're an idiot. I've been trying since January to find a "go to" Android specific blog and it doesn't exist. Still best just letting Engadget/BGR/Lifehacker filter the BS
crachel said:
I think you're correct in Google is simply making it easier for developers to root and flash custom Android builds to the phone. "Fastboot oem unlock/lock" are planned features of this phone according to Tim Bray, so there is no question.
One of the points made during the "Is Android Open" debate around the blogs/twitter was that the OS may be open, but there isn't much hardware that is. They probably paid attention to the debate seeing as Andy Rubin himself weighed in, as such we continue to see the Google experience phone as being open (enough).
On a side note: when the NS was released, every blog I saw (Engadget too) ran a headline about how quickly the phone was rooted.. If you run an Android-specific blog and held this opinion, seriously check yourself cause you're an idiot. I've been trying since January to find a "go to" Android specific blog and it doesn't exist. Still best just letting Engadget/BGR/Lifehacker filter the BS
Click to expand...
Click to collapse
I like this one:
http://www.androidpolice.com/
Paul22000 said:
The Nexus One has "fastboot oem unlock" but not lock.
[snip]
Click to expand...
Click to collapse
That's not entirely true. Nexus One's with S-OFF can use the fastboot oem lock command to re-lock their bootloaders. It's just that there's not many of them floating around!
I found this article VERY interesting, and thought some of you may enjoy it.
Posted by Google themselves; http://android-developers.blogspot.com/2010/12/its-not-rooting-its-openness.html
If you don't understand that, the people at digimoe made it more clear...
http://digimoe.com/google-says-andr...droid-os-is-made-for-rooting-nexus-s-included
As a developer phone, that's certainly true. I don't know. I mean Samsung doesn't have a reputation for locking their phones down hard, even on the non-google line. A reputation for **** development and longterm support, perhaps. And maybe that was google's thinking in choosing them as the Nexus 1 follow up. Certainly google has plenty to gain by helping Samsung out on the Galaxy S line. We'll see what the future brings.
But it's also easy for Google to talk about openness while sitting in the comfy confines of Mountain View. Can anyone go find me Google's support number for the Nexus S?
Not exactly Google's number, but there is this:
http://www.google.com/nexus/#/help
Google provides the OS, but Samsung is the manufacturer and the one in charge of quality control is responsible for support. This is as it should be.
They do provide a direct support phone number, it is just for Samsung.
good read.
T313C0mun1s7 said:
Not exactly Google's number, but there is this:
http://www.google.com/nexus/#/help
Google provides the OS, but Samsung is the manufacturer and the one in charge of quality control is responsible for support. This is as it should be.
They do provide a direct support phone number, it is just for Samsung.
Click to expand...
Click to collapse
My point was that it's easy to call for openness when you don't care about the consequences. Would you rather Tmobile/Samsung provide a link to root your phone at the time of purchase that also immediately voids your warranty? I doubt most here would take that offer.
I like Google's talk about openness, as selective as it may be. But I suspect the manufacturers and carriers roll their eyes when they get these lectures, and I don't necessarily blame them.
WoodDraw said:
My point was that it's easy to call for openness when you don't care about the consequences. Would you rather Tmobile/Samsung provide a link to root your phone at the time of purchase that also immediately voids your warranty? I doubt most here would take that offer.
I like Google's talk about openness, as selective as it may be. But I suspect the manufacturers and carriers roll their eyes when they get these lectures, and I don't necessarily blame them.
Click to expand...
Click to collapse
Except for 1 thing, they are choosing to of their own free will sell a device that is based on a free, open source operating system that has a license that states a requirement of openness, and even that their source modifications are required to be submitted back to the source tree.
The drivers are proprietary, and that is fine - even if it is the reason for the requirement for us to use leaked ROMs to get all the hardware to work. Rooting does not change the drivers, and this discussion ended at rooting. That said even after rooting the parts that get changed are just the open source parts that the devs have the source for because it is in the AOSP depository.
If they don't want to support your changes to the OS that is their prerogative, but they still have a responsibility to support the hardware for defects.
At some point I would like to see someone with the money, time, and conviction sue their carrier when they refuse to honor the warranty because it was rooted. See that clause breaks many of the original licenses that make up the various parts of the OS. In fact they are required to provide a copy to the GPL or at least a link to it AND the source itself. They know they can't win this, which is why I think they like to say it voids the warranty, but as long as the phone looks like it is stock (which is more about not supporting errors you introduced) then they don't really look too hard.
If they don't want to let people exercise their rights under the various open source licenses, then they should stick to devices with enforceable, proprietary operating systems like iOS, Windows Mobile, Symbian, and Web OS.
"Openness" is an excuse, obviously.
I like how Google is trying to save face, and that other site is trying hard to help them along.
People these days seem to just be less concerned about security.
Actively fixing security holes doesn't matter for an OS that cannot be esily pushed out to users as updates. Does it really matter if you fix security holes, but half o fyour users never recieve those fixes?
Well, yea, it does... Just not as much as they think it does.
Also the sandboxing thing is a joke, studies have been conducted and lots of Android apps are sharing data with each other foe the benefit of Advertisers, etc.
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.
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
As seen here
https://www.reddit.com/r/LineageOS/...ect_trebel_devices/?utm_source=reddit-android
LineageOS team state that project treble is in its baby shoes and completely dependant on google to optimize it even more since as of now gsi rom requires certain adjustments for each device, so will project treble successed?
any1 has an insight please share.
I think it needs more adjustment. The kernel should be universal and updateable along with the OS, it's pretty universal as it is at the moment. Drivers should also be standard and updateable, at least for standard items. There should be a driver model where possible to support other devices, and any phone specific changes could be done through manufacturer supplied drivers. There's really no reason why it can't be done, it would be along the lines of how Windows works. Of course, it can be tailored to suit phones.
System updates should realistically come from Google, it would mean all phones and devices would be up to date with the latest security updates. The phone can also check with the manufacturer for specific updates. If Google keeps them apprised of any changes they can update their specific updates in time. This model would mean individual service testing for a new OS update etc wouldn't be a problem since it should at least be compliant with the base model.
Don't forget Google tracks down security leaks in other OS like Windows, which isn't even a direct competitor, and releases the security leak information if it isn't patched within 30? days. How many Android devices are updated with security patches within 30 days by the manufacturer? It's very much a double standard. Google really needs to think of an even more universal model like I just depicted for Android 10 Quinoa Slice (or whatever they call it).
Will Treble succeed? It's a step in the right direction, but needs more work. Not only should something like I just described be done, it should be made mandatory for all new devices. It doesn't mean custom versions are out, but custom versions would have to have OTA updates and be updated quickly along with the standard OS.
To say whether it succeeded or not, I think you'd first need to define what's its goal.
I still don't even know the answer as of today.
Some people say that the goal is to have a system image controlled and updated by Google.
But I don't see this happening any time soon. Google would need to test their GSIs on many devices, and they didn't even test P GSI over O-MR1 Pixels!
It seems to me that their goal was simply to make updates easier to OEMs. Considering Essential PH-1 getting Pie day-one, this might seem a success.
But we'll need to compare Oreo adoption rate to Pie's to confirm.
Oooh someone made a thread so i can moan cheers
The main problem with treble for me is that it's splintered between a plethora of devices, so one dev will release a treble rom and a multitude of device owners will flash it, each with their own subjective problems and issues, requests and wants.
And there lies the problem, it's difficult even when it's a dedicated rom thread for a particular device to get help at times.
So when you have a bunch of users talking about completely different devices you haven't got a hope in hell.
I think there should be branches to each thread for each specific device, that way help threads can be more linear rather than the chaos that it is at the moment.
Least that's my thoughts
My only rom i've flashed is RR and besides a few missing features, Fingerprint, Stereo and NFC i think it's brilliant.