Welcome to the new AT&T Community
We've got a fresh look! Take the tour to see what's new.
I love my Galaxy SIII! It has never given me any freezes, GPS has always worked wonderfully, never had trouble with downloads and is a nice looking unit.
Thanks for your response Evandela, but we all already understand the process flow.
I think @ECERRL's concern is more along the lines of the end result of your process taking so long (much longer than the rest of your industry, by the way) to deliver one very time-sensitive aspect of this- security fixes. Every major release of Android (and iOS, and Windows Phone, etc.) contain security fixes and patches for known and potential threats, and the longer the corrective measures (contained in the updates) are delayed, the greater and more risk is introduced- which is a dangerous situation for all involved.
So let's talk about risks, and risk management. The risk begins initially with the device and user infected, placing the user's privacy and personal data/files at risk; which is a situation that is able to be handled effectively when it is one customer, or a handful of customers- but remember, the entire population of non-updated devices are actually at risk of infection. Now consider that at some point, a malware author will realize this, and as he/she always works to infect as many devices as possible, he/she might begin to look for commonalities between the devices; there's the base software the devices are all running, but there is also one common network (with the same protocols and underlying language) connecting all of these devices. So the formula for maximum delivery would become very simple at that point- infect a device, then penetrate the network to spread the infection. The scale could be immense, and while it has not happened yet, the risk is present, and every delay is playing with fire. Now I am sure you have backend support in place to prevent such a wildfire from occuring, but I would caution that your firewalls and anti-viral packet analyses are very likely focused on if the network itself is the end target, but what if it were simply the means of delivery, and the infection could pose as an upload to an url or something along those lines - would the backend support be effective (most likely not, or Dropbox would not work over your network)?
I do not point all of this out to scare anyone, but I work in risk management and am merely concerned that AT&T's view on this issue has been particularly one-sided, if we take the cookie-cutter narrative that the update process stalls because of error and problem and network deterioration factor testing at face value. Ironically by focusing only on the update package as released by the manufacturer (before infection risk can even really be known), the process is actually exponentially increasing infection risk in the name of protection! You see AT&T's protection is centered around the network itself, and NOT its end-users- the subscribers (customers who are paying for protected access to the service the network provides) with the devices who actually face the risk of infection and of privacy compromise.
<Legal discussions are not permitted per the Guidelines>
I could never let my company face such a potentiality as this (or I would be and should be fired), and am frankly surprised that this situation exists at all.
So what is my answer? Revamp your process (a mirror of Google's and Twitter's own):
First receive the update file from the OEM, do the initial network compliance tests, and push on to subscribers while also initiating internal vulnerability testing (focusing on the devices itself), then release low-level security patch updates as risks are discovered and solved. Rinse and repeat...
"pushing" the update really has to involve nothing more than hosting the file at the specified url, and having the software know where to look for it.
Divide the testing engineers into teams focused on aspects such as application compatibility, network compatibility, and infection/penetration risk, and working concurrently in the issue identification phase (only the actual solutions are part of the entire ecosystem).
set regular deadlines for solution releases
I think you would find a quicker (and more importantly) and more protective and effective solution, and would find that you had the support and loyalty of a much happier customer base (who are not constantly weighing the cost of an ETF vs. living in the fear of how unsafe your device actually is)
Lastly, I could buy the whole "...[software update] that is done right" argument if they were released without major bugs, but I actually have yet to experience that. It really does not seem that the users are the real focus of this whole process.
@Evandela - Sorry, I actually did think you worked for AT&T, so sorry about that! you are correct in that Google is trying to correct this, but I think bigger guns than Google will soon be getting involved over this issue. The FCC is currently re-writing their Online Safety Initiative under Consumer Safety, and the rumor is there is a good deal more about smartphones and malware now that smartphones have penetrated a significant part of the internet usage market.
thanks again for the clarification
The tmobile firmware update has also been ported over to the att variant of the sIII.. why does THEIR software work on YOUR device that supposedly "needs to be tested"
If only I could give 100 kudos to this post! Unfortunately, AT&T has a habit of dragging their feet when it comes to Android updates. The HTC One X just got the 4.1.1 update in the beginning of March. Although AT&T apologists will state that "AT&T must test the firmware extensively...", this is clearly a case where lack of urgency is the culprit. Every major (as well as a few minor) carrier in the U.S. has rolled out the update. Obviously, it works just fine with their networks. I do not buy the "testing" excuse.
In the U.S as you are aware, the carriers must first test the software before they release it because they assume responsibility if something goes wrong, not the manufacturer.
Perhaps it's high time that carriers stopped meddling in the update process (read as: infesting updates with bloatware) and allowed the manufacturers to do what they should be doing in the first place? Clearly, the carriers do not control the update process for the benefit of the consumer. They control it for their own benefit only. I've been very public on this forum, as well as several others, that my Galaxy S3 is the last carrier variant phone I ever purchase. As such, I have absolutely no reason to renew my contract with AT&T. Am I going to leave? Maybe, maybe not. However, I certainly won't be tied to them. There is no excuse for dropping the ball on a flagship device.
Just how long are you people going to complain about AT&T's proven track record of not releasing updates in a timely manner? Fact of the matter is, you can expect similar delays with most, if not all other carriers, and even if some random update for some random device has been pushed to everyone but us, is it really any surprise? You know what the definition of insanity is, right?
You want updates straight from Google's mouth? Get a Nexus.
You want it NOW NOW NOW? Root your device and flash it yourself. Samsung was even kind enough to make ODIN available to the public.
You're tired of being tied down by a contract? There's plenty of pay-as-you-go options out there.
Crying about matters whilst doing absolutely nothing to remedy your situation should never be an option.
Amen to that. With my last device, I had to unlock the bootloader, root, and flash a custom rom just so I could get it updated and remove all the bull they had preloaded on it. Now, I have a Nexus 4 that runs as smooth as butter and I don't have to wonder if it is gonna be updated.
Let's be honest with ourselves here and just say that ALL ROMs, whether OEM or cooked, have bugs. As for major features being left our by various chefs, you can find .apks for just about anything now, including carrier specific apps, so that's not an issue either.
Sorry, but I stand by my previous point.
No, I am suggesting you take some ownership over your situation and try to remedy something yourself, since it would seem that you're not going to be getting the official response you desire anytime soon. If that is beyond you, then that's your problem, not mine.
With the public availability of ODIN from Samsung, bricking your phone is pretty much impossible.
Also, I had never mentioned anything about installing an individual .apk to "quell a bug." What I had mention was that ALL ROMs come with bugs, either cooked or OEM. The adding of an OEM .apk would be a solution to reinstalling some native app a particular chef might have left out of a particular ROM.
You really should do more research on a subject before speaking out on it.
Yes, you had mentioned that already. My last post wasnt addressed to you. I'm sorry, I should have quoted the poster I was addressing.
Sign up now to post, reply, and join the conversation.
© 2014 AT&T Intellectual Property© 2014 AT&T Intellectual Property link. This link will open a new window All rights reserved. AT&T, the AT&T logo and all other AT&T marks contained herein are trademarks of AT&T Intellectual Property and/or AT&T affiliated companies. AT&T 36USC220506