my tablet was updated, still with the constant reboots and freezes the screen.
I do factory reset?
my tablet was updated, still with the constant reboots and freezes the screen.
I do factory reset?
New member, long time android user.
So for a while I thought that the update from asus was causing the issue, like something within asus's programming.
I decided to decompile our ota of ics and found a few items that seem to conflict with the transformers hardware.
Namely the magnetic sensor that tells the system when the lid is closed (docking station). It appears that the sensor no long functions under ics, instead of shutting off the screen, it turns it on.
Normally, this wouldn't be any issue since many of us don't have the dock, but it's causing a wake lock issue which causes the tablet to go into a loop.
I've also noticed in the programming that there is a tell, in regards to when it will "spaz-out". The speakers will crackle or sputter as if something was attempting to play. This is the time to reboot on your own, because within 20 minutes or less, it will boot loop.
Notice this however. This is not an asus ICS issue. I'm running CyanogenMOD 9, and it still happens (albeit much less). From what I can ascertain, its an incompatibility within ics itself and the hardware. My acer iconia has yet to have this issue, running ics.
I will be re-developing the ota ics for the tf101.
Any suggestions are welcome. LOGCATs are also very useful so send the my way if you can. (once I get the chance, I'll make this discovery its own thread)
An analogy is to think of drivers provided by hardware manufacturers for their brand versus drivers provided by say Microsoft for integration with the operating system maintenance paths. The first is highly specific and caters to just about every variance except those that are obsolete (with the caveat of minor versus major update paths) while the second provides a generic approach which caters to the required instruction sets for compatibility and operating. This is why (for example) in the past issues arose with generic windows drivers for Nvidia mobility type GPU's as the different ranges of those GPU's sometimes contained different versions of handlers embedded as well as contained different instruction sets depending on which OEM they were delivered to. Ultimately this resulted in the case where mobility chipsets are recommended to always use OEM provided drivers. Which can be very specific, and which can take ages for a release and which tend to be rarely maintained for long. I realise many people are avid fans of Nvidia, unfortunately should Asus be required to engage in a specific extra development track with Nvidia then I will not be holding my breath as the history of Nvidia is abundant with examples of where such relationships had structurally imposed limitations (typically under the influence of decisions towards favoring user upgrade paths in technology).
Android as a platform is effectively catering to such an enormous range of hardware component combinations that under the current circumstances the development relation between OS vendor and manufacturer is roughly at a comparative point in development. Roughly, because it is only by analogy of conditions rather than circumstances, something which particularly in regards to QA and Batch Testing presents a need to think outside of the box. Suffice to say however that Google as a Vendor has limitations in being aware of all the possible minute variances both for components as well as programming embedded (think of chipsets), and while a linux operating environment should in theory be able to cope with that, that is something which (unfortunately) does not apply as this part is where the manufacturer and its own development comes in. Think of it as a specialised focus required complementing the basic release cycle.
It's something which is particularly visible in regards to battery issues, but perhaps even more so in circumstances of system configuration states where a setting is configured for all revisions in the update but which sticks only in some, but not in others. Sometimes even with differences within a revision depending on regional model. The programming is the same, the sole difference is the hardware and its embedded programming. Yes, we should take care to make clear that there are differences here between issues that are derivative of combinations of other issues (think of memory management issues culminating in secondary issues of instructions not being passed correctly) but that is something which stands seperate from primary issues that arise. Consider for example of how the dock battery queries are simply a gint series of bad calls on an OS level indicating an interest lack of programming integration (incidentally, directly tied to the many cases we've found of units refusing to boot while docked but unplugged as reporting to be under the 3% battery level while tests of the battery itself indicated the battery still having its correct charge and thus not being empty).
It all makes sense really, just consider for a moment the technology update paths for hardware combinations Asus has followed across its revision strategies. There are good commercial reasons why some have B50 units purchased while others later on find themselves with B90 units. Where potential instability surfaces however is when software development tracks are seperated from hardware development tracks. Keep in mind here that there is more than one "level" of integration required there. Google does Android, Manufacturer does tailoring, component suppliers also do their own programming, and so forth. Minor variances on a chipset level in the very common "PC" industry have a long history of headaches for system integrators as well as OS and software developers. Asus with its focus on adapting manufacturing selection and production processes post release is something which poses a risk here. Yes, it also has advantages but it has its limitations as it is limited to the level of secondary components, and not integration or major components. Hence why for example Asus cannot "fix" the core GPS challenge with the TF201 while manufacturing is active, but also why Asus can reduce costs by swapping out one type of component for another, and also why in some TF101 revisions WiFi signal strength is better than in other revisions due to different components (and sometimes even different embedded programming version differences).
In simple terms: while Google provides Android and Asus utilises Third Party manufacturers for major hardware elements it is Asus which does the integration and the required tailoring of these processes. As Asus "on the way" integrates subtly different component versions while taking (so to speak) the "generic" approach to software integrations on that level you end up with a situation where (so to speak) both the OS and a system level driver can say one thing, without that one thing really affecting what it should affect. Considering the complexities of any OS/hardware, it is then no surprise that instabilities and differences in effective functioning arise. Any manufacturer which foregoes this industry certainty and allows its customers to face that chaos will always find itself forced firstto choose between fighting the battle of messaging versus fighting the battle of accepting the messaging. Depending on that, it will find itself either losing customers and brand value alike or face the choice of fighting the battle against symptoms or that of against causes.
It is interesting to observe that Asus is no exception to this phenomenon in economic history. Asus went from trying to mitigate the claims towards negating the complaints towards dealing with the spreading of both, followed by samples of marketing blurbs with internal confusion and even attempts to consider issues while simultaneously pointing towards the customer with swords like "yeah well we tried but none of y'all customers gave us something we could actually verify" (seriously, that occurance on XDA should have resulted in severe internal auditing as that is at minimum a very double edged blade in both marketing and sales) and onwards to finally giving in to publicly accepting user test groups to where we are currently.
Not that this detail level complexity challenge is something which Asus will publicly investigate, as it is something which will have considerable consequences for their manufacturing and supply procedures, but I do suspect that they will eventually go in depth with this particular challenge. In the mean time the biggest lesson of all for Asus is that consumers cannot be used as multi step test bed during manufacturing cycles. Apple did that a few times, and it was quite costly for them, even with their lock-in market model. It is ironic in some ways that Android due to its wide distribution is starting to see some limitations to address which one can also observe in the past in the more common PC industry.
I don't doubt that Asus will get a fix out, but the first upcoming fix will not be the required fix to address causes. Simple math in resource allocation makes clear quickly that currently Asus and its relations are limited to addressing symptoms. For most consumers that is currently acceptable, due to circumstances, but it is not something the manufacturer can repeat (and thus unleash once more on the consumer) as that will cost it its brand value as the messaging reflexively always reaches back to the most recent calamity. Welcome to the human species, it's a pretty terrible one. So short term: symptoms, long term ... a tough choice for Asus to make.
Last edited by macmeijers; 04-08-2012 at 06:15 AM.
Wow Mac, that's quite an epistle
I *think* I followed it through...
PLEASE Search for existing threads before posting a new one. Thanks.
Your opinion matters. But should you disagree - please try not to be disagreeable
Android device personal pantheon - SGS; Motoroloa Razr; CnM Touchpad II; Asus TF101; Lenovo A1; Motorola Xoom 2 ME; Samsung Tab 2 7.0
How will Asus respond to the current product debacle????
It will depend on how well Asus as a company -- from Management down to the rank-and-file employees -- implements their Company Virtues to bring back customer confidence...
(My apologies for the divergence of post content from the main topic. )
I guess I spoke too soon. Literally 3 hours after posting above, I come back to find it rebooted while sleeping. Mind you, it had just downloaded a few app updates before putting it to sleep....
I wrote to Asus 3 times asking for an outright refund. Still no response (of course). Talk about a disgruntled consumer. I will never purchase and stringently tell people never to purchase an Asus product so long as I live.
So the reboots are only at night when humans are asleep. This is good to know )
Phone model: Transformer TF101
Android version: 4.0.3 (ICS) - testing .24
Build number: HTK75.WW_epad-126.96.36.199
Total memory: 29852422144
It's a complicated situation, but not simply just for Asus. Perhaps people remember the days when notebooks first entered the realm of consumer sales (as opposed to business sales). As entertainment became a factor this was something which resulted in interesting situations among OEM's and suppliers of hardware elements and operating system softwares alike. After all, the GPU market had only barely been born and already there was a secondary market branching off.
To make a long story short, both OS vendors (which at the time had already pretty much been narrowed down to Microsoft catering to open markets and Apple catering to its own lock-in market) found themselves in a situation where they faced limitations in their developer relations with hardware suppliers. For Apple it was a little easier since they only had to deal with their own market and thus had much more control, but for Microsoft operating in the open market (once upon a time created by IBM's crazy ideas of simply engaging open standard concepts leaving market venues open to just about anyone with an idea) the situation was more difficult. Not only did Microsoft have to deal with developer relations on a software level, but also on a hardware level. I am sure many of us still remember the days where hardware pieces came with disks and later cd's with driver libraries and all that, which while functioning for the hardware they were created for could easily result in instabilities once integrated into pc machinery. Creative Labs was at times a fun one with that, but also many a modem (yes, those things once existed) manufacturer. Ultimately Microsoft basically enforced a two tiered approach providing certification paths, requirements and more of that. These days we don't even raise an eyebrow for that, but for hardware products which had a foot in the so called mobility market segments issues still lingered.
Even today. Pick an HP notebook up somewhere, chances are there will be a decent entertainment GPU inside, but the drivers are always at minimum recommended and often required to be provided by the OEM, in the case of this example being HP. There are OEM's as for example Dell which integrate such development tracks with sales paths and thus have a more vested interest in being more "on the ball" than others, and some (Dell also does this) have become much more careful in selections of mobility components to include in manufacturing so they can make direct use of drivers and other programming elements which the suppliers of those components already have a vested interest in to run consistent maintenance cycles. Consider for example Dell picking a specific type of a GPU to put in a specific notebook type as the mobility version of that GPU does not differ in handlers or instruction sets embedded (chipsets, roms, etc) in the hardware so the user can simply use the drivers from the supplier of that GPU and not depend on Dell doing a load of irregular extra work which is rarely guaranteed to be in sync with mainstream driver versions / updates / etc.
Android is pretty young in many ways. Don't get me wrong, it has been around for a bit, but while being quite well spread out with reach across market types and generally quite stable (and even well maintained by its vendor) it has not matured a lot in regards to the complexities that an open market model exposes the vendor and ALL its affiliate relations to.
As an operating system Android serves many types of products, across different market segments and is put on market by a pleathora of OEM's and manufacturers. Effectively speaking one of the elements of maturing as an OS is very much the same as some elements MS Windows went through (and before Apple chose its own model its own early OS).
Asus is one of those parties connected to that complexity. Google provides it with the operating system and a bunch of connected services, but as a manufacturer Asus has to face a lot of requirements in development tracks. As Asus is one of those manufacturers which provides regional specific versions of its hardware, but also changes manufacturing details for hardware combinations over time (what we know as Revisions) this is something which simply adds to the complexities involved. And this is something where Google is pretty much limited to providing expertise on an OS level as it is Asus which makes its selections on component level. Do not forget, many hardware elements today are not simply "passive" pieces of boards and chips, they tend to contain their own instructions, sometimes come with specific API's, and so forth.
The Tegra GPU integrated into the Transformer, is a good example of that. But it is also a good example of the innate complexities that we also can see in the divergence between mainstream and mobility computing paths as mentioned before in the general PC industry. I'm not an Nvidia fanboy, nor do I hate them (though I can understand why their insurance company had a beef with them over some eh unfresh decision and communication tracks when Nvidia decided to unload below standard manufacturing steps in mobility hardware series of GPU's to OEM's), but Nvidia is a big piece of the pie here where it comes to figuring out the root causes of particularly the driver level issues. Historically Nvidia has a tendency to release and not look back for mobility products through focusing more on marketing than maintenance. Commercially that also makes sense in the economies of today and the past decade alike. But for an emerging market such as Android is designed for that is a very dangerous mindset. Particularly for OEM's of today, like Asus, which have a VERY deep dependancy on Nvidia as a supplier.
As I said, we've seen Asus go through the usual cycle of messaging. That never changes really, it has causes in simple commercial strategy which nobody can blame them for since it is our behaviour as consumers which dictates that even more than general business concepts. The good part in the current circumstances is that Asus has decided to not follow that typical cycle into oblivion (so to speak). Instead they have stopped to look around, and have started to take notice and even communicate with consumer level scenarios through user testing (for example the initiative on XDA, but they are also doing that in other places). Sure, there is an argument to make about whether it is good that you use your customers as a testbed. And yes, there is a definite argument to make in regards to QA standards and practices. On the other hand, considering all the complexities involved the alternative would have been much worse. Consider Asus going back to its own unit testing with its own existing conditions and thus only being able to find a small selection of issues in unit behaviour under some circumstances and having to wait around for component suppliers to do the very same thing elsewhere as well and then figure out any next steps. Commercially that results in to very high costs which in the relatively low margins of open market models simply cannot last for very long. Historical results of that generally are update paths which serve only recent hardware version users while the rest blunders on and kills the brand with its messaging. Not healthy thus, neither for us as customers nor for them as a company.
Sure, they are careful in these initiatives and they won't admit to a bunch of things. That is normal, because for them too is a big road of waking up internally to different signals in messaging. And because they cannot control what people think (fortunately) so they have to be careful because people tend to reflexively make up their own minds and run with it. That's everyone's right ofcourse, but in business we must factor potential influences on that in as it is part of business risk management.
To be blunt, Android and the OEM's catering to markets with it are at a point where they have to start splitting off paths of complexity into seperate paths from OS and hardware elements. If you look at the deployment process for example of ICS, sure Apps can be backed up and restored and much more, but quite simply that is a step which at one point was handy but which now causes more issues than it is worth. Why? Because neither Google nor Asus can control the update cycles of Apps, and forget about quality control of third party Apps. As we have seen, the initial reports of issues following the update(s) were heavily polluted by real issues with incompatible Apps as well as issues by Apps getting in each others ways AND Apps being perceived as the root cause quite simply because there are so many of them out there and that the complexity of all of that was quickly perceived as the most likely cause.
In fact, Apps are a cause of instability. The mods here have been very sharp to point out to and get people to check in on incompatible Apps, as well as on possible signs of Apps not corresponding properly to expected behaviour when using other Apps. So back to the deployment process. Consider Asus splitting off the Apps part. The Tablet gets an OS update, the Apps are contained individually before update the unit is brought back to factory settings and condition and after the update the unit is first tested for compliancy and required behavioral patterns under those conditions. Only after that, the user can start (and take the responsability, which really IS ours as we pick Apps) to get our Apps back. And if Asus were a smart OEM there, it would first advise, perhaps even force a compatibility or version check on individual Apps as we select to get them back on our tablet. That may seem like a long process, but it really isn't when you work it out in timing for deployment and post deployment steps versus the potential madness that we have seen with the ICS update related to "Apps Madness".
Asus does have other lessons to draw as well though. Its manufacturing and sales model of adapting while releasing is something which while commercially very viable is not very likely to provide stable revenue paths with risk to brand value over time. After all, you essentially create more complexities to handle (both when things go "normal" as when Murphy visits) for yourself. That consists of types of hidden and visible debt which ultimately simply piles up. The hidden types of debt accumulated however are carried on across product ranges and thus connect directly to the brand perception and thus sales. Very simple. It is one of the limits you can find in open market models. It is very common to see manufacturers change component selections over time during manufacturing cycles, but when you have such complex dependancies while developer relations are very segmented you pretty much guarantee yourself issues. The customer is the first one to pay the cost for that, and that is never right. It is sometimes necessary, particularly to break in to market opportunities, but it is never something to continue for long. Asus is one of the few OEM's which has a real potential at becoming a dominant market factor for what people tend to call tablet and general mobility computing paths, so it would be in their interest to learn from the current circumstances and take steps to move away from the causes. It will cost in the short to medium term, that is historically always the case, but as long as the marketing follows the quality and innovation focus in a stable and consistant pace history shows the ease of becoming dominant in the long term. And long term is not a decade anymore these days, far from. You're looking at 2 to 4 years.
So in a nutshell, the OS itself needs elements of stabilisation to safeguard against the multitude of complexities imposed through the presence of tons of different manufacturers on both product and component and software level. The hardware products themselves need to get tuned in to such a stabilised path (certification, specification requirements, etc) and seperated from the actual user level of software paths. That's not something specific to Android though. Consider for a moment how Apple "extends" ios through its focus on devices while maintaining its own paths there (sure, easy for them since they have no competitors in their markets or products or services) but you can see how the road in many wys for them is more smooth for the perception of the user (who is the customer). Sure, it's also a piece of marketing and often ios is inherently unstable, and sure the argument can be made that it is only seemingly more smooth because you can only do what is decided for you to be allowed / enabled to do, but that's a different debate. Simple observation is that the different major dependancies need to be stabilised and seperated through much more strict requirements than currently. The first mobility OS which can pull that off with its OEM's will be the one to "win" the open markets and contain (if not constrict) the lock-in markets.
Company virtues, values, whichever. You have a point there. And historically Asus does put those in to practice. Fact of the matter is that it is a simple commercial relation. All economy is based in trust (not "on" btw, subtle difference), without that relation there is no continuity to economy. There are forms of economy possible for the short term without it, as we have seen in the recent global banking crisis :P , but the gains of that tend to be very specific while the costs always come back somewhere. A company which provides both products and services with physical roots is a dead company if it tries that. I do believe that Asus will learn lessons, and will take steps to adapt. The trouble is that right now it is effectively locked down with these issues as they not only "cost" affected consumers but also the brand and the investments Asus has ongoing in further products.
What does it mean for us John and Jane Doe owner of a Transformer? We can probably expect a next patch focused on a selection of specific issues, considering the occurance of types of those my guess is towards display activation, battery queries and wifi activation. That will however not be a patch to "serve" everyone. That will undoubtedly have to wait for the results of Asus having made preliminary adaptations after going over the results of the units from test groups of customers they have set up recently in several online communities. If I understand it correctly, selected users are currently going through swaps of owned units for Asus supplied units so that would be something to probably really be under way in a few weeks from now. Considering that Asus is currently at risk of reputation damage I suspect that we will see another OS update following later on, but probably timed with an OS version update (as that gives more room for addressing the "active" components level across the currently available and wide range of different revisions and regional models). I do think that the most pressing (visible!) issues will be addressed in the patch before that, but as I said the puzzle of different unit behaviour across different component and software elements is a giant puzzle so that will have to follow a patch that focuses on a big impact "first step". We will get our TF's stable in regular use again.
For the long run I do think that the next Transformer will benefit from lessons learned. Less revisions, with the first one consisting of very specific component selections through more strict and higher volume acquisitions with suppliers, possibly with more vested developer relations and collaborative unit testing. Maybe we'll see an OS path more focused on "factory state" stability, that would be a good idea for both Google and Asus. But as I said, Android has to mature, and has to mature "now". That is not so much a case of enforcing "rules", it is more a case of specifying conditions and requirements strictly. For one thing, I would hope that Google would take a good look at the programmative support for secondary batteries :P
As a finishing comment, I strongly suggest to everyone to (in spite of it perhaps in light of frustrations being a bit too much to ask) make effort to report specific issues with as much information as possible to Asus. This forum is one place, but Asus support tickets are currently also a good way to pass on information (even if feedback is often very limited, but rest assured that Asus does collect the data and study it). Perhaps a mod can put together a sticky on how to set up logcat for people, or maybe another user can do that, with quick links on where to go for what (incidentally, this thread should really also be a sticky).