ice cream sandwich bug on a500

[idroids]

A500 ICS ROTATION PROBLEM SOLVED!

1-Install free AutoRotate Switch app.

2-Click on the app to switch ON auto-rotate.

3-Turn the A500 off.

4-Turn the A500 on.

5-Auto-rotation works perfectly!

There has apparently been a breakthrough on at least one of the sensor driver problems by a developer working on the ICS leak at xda-developers. I am hopeful that this may be related to the auto rotation lockup problem many are seeing (described above), and that this fix gets passed into the official Acer source if it is the solution. See: [ICS PATCH][CWM] Dear XDA, I present to you...the rotation fix - xda-developers.

If someone at Acer already fixed it, then that's great also.

 

[idroids]

A500 ICS ROTATION PROBLEM SOLVED!

1-Install free AutoRotate Switch app.

2-Click on the app to switch ON auto-rotate.

3-Turn the A500 off.

4-Turn the A500 on.

5-Auto-rotation works perfectly!

Excellent info. double and triple check that SCREEN LOCK SWITCH - slide it back and forth afew times. If it doesn't feel right check it properly.

 

[Mrhelper]

A500 ICS ROTATION PROBLEM SOLVED!

1-Install free AutoRotate Switch app.

2-Click on the app to switch ON auto-rotate.

3-Turn the A500 off.

4-Turn the A500 on.

5-Auto-rotation works perfectly!

This does nothing more than your screen orientation lock switch does. It would only be useful if your orientation lock switch were physically broken, so you could possibly use it to test for that condition, but you do not need an app on the a500 to do this if your hardware is intact.

I have tested this app, and observed that it apparently uses the OrientationListener or OrietationEventListener class to disable and reenable events from the sensor. It cannot resolve any a500 ICS related screen rotation problems unless caused by a broken switch.

This appears to be an advertisement by the app developer.

 

[Greg_E]

I have to wonder if you have a problem with those chips, something that may have been fixed in previous and later batches of this tablet. The big question could still be is this an issue with the sensor or an issue where some bit of code gets stuck in the main processor which causes the sensor to not initialize. The only way to find out would be to look at the schematic and see how the reset switch is handled. it could pull all reset lines low causing all sensors to do a hard reset, or it could only pull the main cpu to reset which then sends out a reset to each other module.

I'm surprised that Acer is not interested in getting your tablet back for testing, it seems so easily repeated that they should be able to locate the issue and make sure it never happens on future devices. Have you contacted them to see what they can do?

 

[Mrhelper]

Thank you so much for your highly relevant and well reasoned comments.

I have to wonder if you have a problem with those chips, something that may have been fixed in previous and later batches of this tablet.

That seems possible. I have to note though that when the MPU does initialize during a power up boot or reset, the sensors operate normally, and for me that is now most of the time (getting closer to 99%). Now that I'm not actively testing for the problem and increasing the frequency of triggering it, I am just not seeing the problem under "normal" conditions.

I'm thinking this is less of a hardware defect than an artifact of what may be trivial variance in a500 system hardware builds, for which the ICS code changes relative to initialization timing may have changed just enough to make it more visible to some. A certain amount of boot timing change is inevitable in new OS builds, where functionality may be added, moved or otherwise modified. Some very marginal timing and/or boot order changes may have exposed this problem for some number of owners, and not for others. The differences between HC and ICS in the init timing could be merely in milliseconds, or as long as seconds. I never observed this issue with Honeycomb, and I had tested with that OS very thoroughly, including regular/frequent monitoring/analysis of system logs, starting from when I first bought the tablet. Various reports in this and other forums, where the problem comes and goes for some, stays for some, and does not appear to occur at all for others makes me think that this may be due to slight hardware build differences, affected by marginal timing within the boot sequence -- i.e., it appears to be an initialization tuning issue.

The big question could still be is this an issue with the sensor or an issue where some bit of code gets stuck in the main processor which causes the sensor to not initialize. The only way to find out would be to look at the schematic and see how the reset switch is handled. it could pull all reset lines low causing all sensors to do a hard reset, or it could only pull the main cpu to reset which then sends out a reset to each other module.

I Agree. Your note states very well an aspect of this that I've been thinking about also. User behavior relative to timing is apparently an improtant factor in whether or not this can even be detected. I found that I've changed my behavior in a way that has all but eliminated the problem for me. I have stopped trying to trigger this, and while I still check at every boot, I did not see it again for a few days now. I really doubt that I would notice this at all without actively checking for it, or would see it as a rare fluke if I did, and ignore it.

After reading your note, I started thinking about the timing aspect again. This morning I tried to cause it once again with a different test. I realized that I had been pressing the power button for only 2-3 seconds, and releasing _before_ the little vibrate. I was doing this because that was what I had read in the "read me first" sheet. What I did this morning was test about a 10 times by holding the power button until the vibrate had occured, using very short cycles from power off to power on, and I did not see a single incident. I then switched the strategy back to my typical behavior, and pressed the button for only 2-3 seconds. The problem was immediately back! I tried this a few times more, and found that using the longer power button press seemed more reliable, and that using the shorter button press resulted in occasional sensor init failures. I am skeptical of this observation though, because the test samples are very small, and more lengthy testing would be required to confirm the results.

I don't want to wear out the power button by taking several years of life out of it in a few days though, so I have no plan to use my tablet as the test subject anymore. I'm generally satisfied for now with the solution that I have, and have been updating my posts on the topic primarily in case this information can help others.

I'm surprised that Acer is not interested in getting your tablet back for testing, it seems so easily repeated that they should be able to locate the issue and make sure it never happens on future devices. Have you contacted them to see what they can do?

This is such a brilliant device, and I am in awe of the vast and portable functionality it provides. Again, I don't want to continue using my tablet as a test subject. I understand your point completely though, and I agree. One problem though is that it takes considerable effort anymore to get support from any vendor that is not based on canned responses. I completely understand the value of that level of service, and even applaud it -- i.e., it makes devices like this much more affordable.

At this point, this problem from my perspective is not worth the investment of time required to directly engage Acer and actually get support for such a complex issue. My results/data are readily available here and in other locations, and it seems likely that folks at Acer have even seen the issue already. It's almost certain that the number of people actually posting to forums is much smaller than those having problems. I'm clearly not the only person working on this, and I've noticed that various developers have been discussing aspects of this relative to ICS for months now. If it gets worse/better with a future OS update, or for some other reason, I may comment on that. I'll also keep one eye out for the results of others I see working this same problem. ...and certainly, if you have any more thoughts on this or other issues, I am pleased to discuss them. Thanks again for your response.

 

[K9CHP]

I tried pressing on the power button till after the vibration but my screen stayed locked. What seems to work for me is to delay pressing on the power button by a few minutes. Wiggling the screen lock button helped too, sometimes, but I believe it was just because it took more time till I powered the unit back up.

Amir K9CHP Sent from my A500 using Android Tablet

 

[Mrhelper]

I tried pressing on the power button till after the vibration but my screen stayed locked. What seems to work for me is to delay pressing on the power button by a few minutes. Wiggling the screen lock button helped too, sometimes, but I believe it was just because it took more time till I powered the unit back up.

That's still how I get the most consistent results also -- keeping several minutes between power down and power up. I tried the hold-until-vibrate trick again a few times today on short power down/up cycles, and it did not work once. I suspect that it may have to do with how high the voltage is at the time I test. I had been running on battery for several hours when the hold-power-until-vibrate worked the last time. When I tried today, it was fully charged, still plugged into the charger, and I got the screen lock and code 26 errors every time. I had to do a reset to get out of it (because I did not want to wait 5 minutes). Hey, thanks for the post! Good information.

 

[Acer_Iconia_A500]

WE SHOULDN'T HAVE TO DO THIS THOUGH !!!! AAARRGH

 

[Mrhelper]

WE SHOULDN'T HAVE TO DO THIS THOUGH !!!! AAARRGH

You are absolutely right. We should not have to work around a problem like this.

I infer from the large bold type and the angry red emoticon that you must be seeing this problem more often than some. If you haven't yet looked at your logs when this is happening, you should probably do that to confirm it is the same problem. If this happens to your a500, and your screen rotation lock switch is slid all of the way to the left, and you see the MLUpdateData error (code 26) in the log (using something like aLogcat), then your tablet has the same problem discussed above.

If you do not see error code 26 messages in the log, you may be waiting for a fix that can never come from Acer. You may then need to look for another cause, such as a misbehaving app.

If what you see is indeed a problem delivered by Acer, and not an app, then it only seems reasonable to give them some time to fix it. All in all, compared to what I've seen on forums for other devices realtive to ICS updates, this experience is not that bad. I understand I was one of the early ones to get the official ICS update in NA on April 27th, and it is only May 22nd, not even a month later. It takes singificant time to sort out the order of problems to work, and then to provide the best balance of soutions that will satisfy the greatest number of users. I am certain there are several problems they are working, and most relatively minor. Acer will release a patch containing fixes at some point, but it's going to take more than a few days, and maybe a month or so.

This particular problem is apparently high on your list, but may not be for many others. I know a few users like myself who rarely use portrait mode anyway, and some who always keep the tablet locked in landscape mode. I leave mine unlocked just so I can see when the problem occurs, but otherwise, I would probably rarely even notice it when it did actually occur. The symptoms you see may be worse, and I'm not trying to project my experience over yours to make it seem trivial, because I realize that this can be a huge inconvenience for some and not others. I also expect Acer to fix any significant problems that they delivered.

 

[Douvie]

Maybe we should compare serial numbers to see if there is really a difference btw my A500 and yours Mrhelper. We can do it in a private message if you like.

 

[Mrhelper]

That is an interesting idea. I like where you're going with this. I don't see how comparing just two serial numbers would provide enough information to conclude anything though, unless we knew the numbering scheme. If you know someone who could provide that, then that might be handy. The date of manufacture seems important for this issue. My tablet was manufactured in June 2011. It's the 32GB version, and the model number is XE.H6LPN.001.

 

[Douvie]

That is an interesting idea. I like where you're going with this. I don't see how comparing just two serial numbers would provide enough information to conclude anything though, unless we knew the numbering scheme. If you know someone who could provide that, then that might be handy. The date of manufacture seems important for this issue. My tablet was manufactured in June 2011. It's the 32GB version, and the model number is XE.H6LPN.001.

Usually, but not always, production runs start from a lower serial number to a higher serial number. Therefore, using this understanding, we can get an estimate of where some issues may lie in terms of components. Also I would suggest, the idea is forming as I'm tapping this, that we try get one or two other A500 users, say one from the EU and another from say the Asian block or from South America, to compare notes so we get a better grasp on how the units are pushed out and how the updates arrive.

I think your idea of manufacture date and model number is good which can be obtained from ABOUT TABLET in SETTINGS.

DOM: April 2011
PN/MODEL NO: XE.H6LAN.010
MODEL: A500
FLEX Ver/Build No: Acer_AV041_A500_1.031.00_WW_GEN1
32GB ROM

I had to get some of the info from the Box the ACER came in. Maybe the info should be displayed in the way above. The FLEX Version and the BUILD number appears to be the same.

 

[Mrhelper]

Thanks for the info. This helps me get closer to understandng something that I have been suspicious about.

There are certainly some differences in the hardware model number and the OS build number. I appear to have a newer build of ICS than you do. I applied mine on April 27th. I read that you applied your update a few weeks later, but it appears that you got an earlier and possibly more stable version. That makes me wonder if they had to reverse a little on the builds because of problems they had encountered -- e.g., the sensor init issue that I and some others see. That is sometimes a necessary practice when difficult to isolate problems are found in a development cycle.

I am now leaning more toward a difference in OS builds as being more of a factor in why some people see problems when others do not. Your model number appears to be associated with AU and NZ, while mine is associated with the US. I'm guessing that the differences in the model numbers are likely due to differences in regulatory compliance test processes required down there vs. up here, possibly in the area of "green" rules. The hardware may actually be identical, but the testing process requirements may be different. Just guessing on that, so I can't entirely rule out hardware.

This is very interesting. If you could post (or send private) the content of your /system/build.prop file, I would like to compare some of the other properties -- e.g., ro.opengles.version, because I also see some occasional odd transition flashes/distortion in displays that I had not seen on HC. There is no private info in there, it comes straight from the build.

Here is my a500 info in your format, and adding the build date:

DOM: Jun . 2011
PN/MODEL NO: XE.H6LPN.001
MODEL: A500
FLEX Ver/Build No: Acer_AV041_A500_1.033.00_WW_GEN1
ro.build.date=Fri Apr 6 23:50:30 CST 2012
32GB ROM


#################
##########Raw data
app_104@android:/ $ cat /system/build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=IML74K
ro.build.display.id=Acer_AV041_A500_1.033.00_PA_CUS1
ro.build.version.incremental=1333727375
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0.3
ro.build.date=Fri Apr 6 23:50:30 CST 2012
ro.build.date.utc=1333727430
ro.build.type=user
ro.build.user=pandora
ro.build.host=pandora03
ro.build.tags=release-keys
ro.build.sku=PA_CUS1
ro.product.model=A500
ro.product.brand=acer
ro.product.name=a500_pa_cus1
ro.product.device=picasso
ro.product.board=picasso
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=Acer
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=tegra
# ro.build.product is obsolete; use ro.product.device
ro.build.product=picasso
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=a500_pa_cus1-user 4.0.3 IML74K 1333727375 release-keys
ro.build.fingerprint=acer/a500_pa_cus1/picasso:4.0.3/IML74K/1333727375:user/release-keys
ro.build.characteristics=tablet
# end build properties
ro.opengles.version=131072
wifi.interface=wlan0
keyguard.no_require_sim=1


ro.dinfo.version=1.0
ro.cpu.vendor=nVidia
ro.cpu.speed=1.0 GHz
ro.cpu.version=T20


ro.sf.lcd_density=160


#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.config.notification_sound=OnTheHunt.ogg
ro.config.alarm_alert=Alarm_Classic.ogg
ro.error.receiver.system.apps=com.acer.android.nidus
acer.sync.adb.mode=ENABLED
ro.setupwizard.mode=DISABLED
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=256m
ro.com.google.clientidbase=android-acer
drm.service.enabled=true
ro.product.modelalias=A500
ro.tether.denied=true
ro.com.google.gmsversion=4.0_r1
dalvik.vm.dexopt-flags=m=y
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt

 

[Douvie]

I'll give you the info as soon as I get at it.

This upgrade/downgrade of different components I've seen some years ago in a software package called VIDEO STUDIO where there were some issues with DVD burners. After an update some modules went up, some went down, and some didn't change. After another update those modules that went up in the other update went down, some that didn't change the last time went up and some down. And others that went down went up and others down. A real dog's breakfast.

a

 

[Douvie]

MrHelper

Here is the build.prop that you were after.



# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=IML74K
ro.build.display.id=Acer_AV041_A500_1.031.00_WW_GEN1
ro.build.version.incremental=1333032611
ro.build.version.sdk=15
ro.build.version.codename=REL
ro.build.version.release=4.0.3
ro.build.date=Thu Mar 29 22:51:13 CST 2012
ro.build.date.utc=1333032673
ro.build.type=user
ro.build.user=pandora
ro.build.host=pandora03
ro.build.tags=release-keys
ro.build.sku=WW_GEN1
ro.product.model=A500
ro.product.brand=acer
ro.product.name=a500_ww_gen1
ro.product.device=picasso
ro.product.board=picasso
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
ro.product.manufacturer=Acer
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=tegra
# ro.build.product is obsolete; use ro.product.device
ro.build.product=picasso
# Do not try to parse ro.build.description or .fingerprint
ro.build.description=a500_ww_gen1-user 4.0.3 IML74K 1333032611 release-keys
ro.build.fingerprint=acer/a500_ww_gen1/picasso:4.0.3/IML74K/1333032611:user/release-keys
ro.build.characteristics=tablet
# end build properties
ro.opengles.version=131072
wifi.interface=wlan0
keyguard.no_require_sim=1

ro.dinfo.version=1.0
ro.cpu.vendor=nVidia
ro.cpu.speed=1.0 GHz
ro.cpu.version=T20

ro.sf.lcd_density=160

#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.config.notification_sound=OnTheHunt.ogg
ro.config.alarm_alert=Alarm_Classic.ogg
ro.error.receiver.system.apps=com.acer.android.nidus
acer.sync.adb.mode=ENABLED
ro.setupwizard.mode=DISABLED
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=256m
ro.com.google.clientidbase=android-acer
drm.service.enabled=true
ro.product.modelalias=A500
ro.tether.denied=true
ro.com.google.gmsversion=4.0_r1
dalvik.vm.dexopt-flags=m=y
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt




There are some significant changes between my version and yours.