Re: [android-developers] Re: Android Team: Please give help on serious OnSensorChanged()-not-called-in-standby bug
Ping. Someone please reply with the status of this issue so that we can figure out how to work around it, or when it might be fixed. I am sorry, it is a huge issue for us, and I have not been able to get any additional information. Thank you, Artem On Thu, Jan 14, 2010 at 10:36 AM, BGA bruno.albuquer...@gmail.com wrote: So I went ahead and did some further testing using a Motorola Milestone and here are my results: 1 - My workaround, as mentioned by Artem, works with it. In other words, re-registering the sendor listening in stand by mode makes the sensor works again. 2 - Acquiring the dim lock after the screen goes off (also as described by Artem) does not work with it. On the plus side, the screen does not turn on when you acquire it. ;) 3 - The HTC Tattoo screen turning on when acquiring the dim lock seems to be a bug on it. The documentation clearly states that the screen will not turn on when you do that unless you explicitly ask for it by also using the ACQUIRE_CAUSES_WAKEUP flag. 4 - All HTC phones (except for the G1) seem to shut down the orientation sensor (at least) completely when entering standby mode. As a bonus, I also noticed the following: 1 - On the Motorola Milestone, there is no need to hold a CPU lock in the service. Somehow it works without that (and it does not drain the battery it seems). 2 - The G1 does not shut down the orientation sensor as, as long as you hold a CPU lock, you still get orientation changes when in standby. To me it looks like phone manufacturers are doing whatever they want concerning this subject. This is either because what is supposed to be done is not specified or because they are simply not following the specs. This ends up becoming a nightmare for developers and, for obvious reasons, this is not a good thing. I am not sure what can be done to sort this up but it seems that, at the very least, a way to say I want to use this sensor even in standby mode would solve most of the problems (as long as device manufacturers would abide to this). -Bruno On Jan 14, 12:42 pm, Artem - WorkSmart Labs p.ar...@gmail.com wrote: Hi Dianne and other Android Team Members, Please provide some kind of comment on this long-standing and serious bug: http://code.google.com/p/android/issues/detail?id=3708(one of top bugs right now) OnSensorChanged() is no longer called in standby mode since last Firmware upgrade A lot of serious developers have looked at this, and we can't seem to find a good solution that works for example on the HTC Hero. The best work on this done by Bruno unfortunately still does not work for many handsets. I have looked into this carefully, but the issue seems very hard to track down. I can repro this on the HTC Tattoo as well. The only work-around seems to be to intercept the ACTION_SCREEN_ON event, and then to again re-grab the DIM_SCREEN lock, which causes the screen to turn on again. This unfortunately drains the battery like mad. The latest comment on this (from Dianne) said we have to hold a partial wake lock, however we are all already doing this and this does not help. This breaks all pedometer and similar applications right now, and our users are really sad. Please please help, or at least comment on the status. Artem -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Android WVGA support
Right, you have to use -v4 for that of course. It's similar to what Dianne
had suggested above (using both -v4 and -v5), except v5 is actually v6. It
just seems that somewhere deep in this part of the Eclair code there is
something that makes it think that the sdkVersion is 6, not 5. Dianne, could
you please comment since this is the only workaround that works so far?
I would love to find this out myself, but since the Eclair code is not yet
available, it's hard to figure this out. I'm assuming the code drop is
coming soon.
I have verified that by using both -v4 and -v6, I can get things to work on
every platform.
For those interested, to avoid duplicating actual pngs/jpgs, I am using an
ugly hack. Here is an example
Folder drawable-160dpi:
example_image.png (the mdpi version of image)
Folder drawable-240dpi-v4:
XML file example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-240dpi-v6:
Same example_image.xml with the following inside:
bitmap xmlns:android=http://schemas.android.com/apk/res/android;
android:src=@drawable/example_image_hdpi
/
Folder drawable-nodpi:
example_image_hdpi.png (the hdpi version of image)
Yes, it's very ugly. Any better ideas are very welcome.
Artem
On Fri, Oct 30, 2009 at 1:36 PM, webmonkey webmonke...@gmail.com wrote:
drawable-hdpi-v6 does indeed work in the 2.0 emulator but not in a 1.6
emulator. And because it is not exactly clear what the problem is I do
not recommend using it.
I am still hoping to find a solution where I can just use drawable-
hdpi
On Oct 30, 8:49 am, Nikolay Ananiev devuni...@gmail.com wrote:
YES drawable-hdpi-v6 works for me too. I'll use it in my next release as
a
workaround
Thanks Artem!
On Fri, Oct 30, 2009 at 7:15 AM, Artem Petakov p.ar...@gmail.com
wrote:
This will sound crazy, but -v6 works for me. There must be a strange
reason
why this works, or maybe there is a subtle reason why this workaround
does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com
wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5 version
in
there does not help (as webmonkey reported). I don't have my head
around
this fully, but I think Android somehow prefers the regular drawable
directory (which I have for the Cupcake crowd). What is the
recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn
hack...@android.comwrote:
Dammit yeah that would be broken. I'll make sure this is fixed in
the
next version; for now i guess you will need to include both -v4 and
-v5
resources.
On Thu, Oct 29, 2009 at 7:25 PM, Artem p.ar...@gmail.com wrote:
Trying to help by digging up the code.
I found this:
http://www.google.com/codesearch/p?hl=ensa=Ncd=1ct=rc#uX1GffpyOZk/...
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an !=
here.
Hopefully, this is not the right code. Or perhaps there is new code
in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually,
we
had
made a mistake and originally forgot the v4, which screwed up
Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem?
Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking
Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey
webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK
with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion
[android-developers] Re: Android WVGA support
Dianne, I am sorry to say it also does not work for me. Actually, we had made a mistake and originally forgot the v4, which screwed up Cupcake, but now we added the v4 (and make no other changes), and it stopped working. Am I missing something? Or is there perhaps a serious problem? Please reply back so we can take action -- we need to publish a new APK for the Cupcake users, but we can't figure out how to do that without breaking Eclair. Artem On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com wrote: Hi Dianne, The v flag does indeed not work, I am using the Android 2.0 SDK with the following AndroidManifest settings: uses-sdk android:minSdkVersion=3 android:targetSdkVersion=5 / Running on a WVGA854 emulator with density 240 and API 5, I get the following results: drawable-hdpi-v4 is ignored drawable-hdpi-v5 is ignored, very strange drawable-hdpi works, but we can't use that On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote: I am pretty positive it works. Nothing changed in 2.0 -- this has been the same since 1.0, if the platform's SDK version is the resource version, then the resource is ignored. On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote: Looks like -v4 flag doesn't work in Android 2.0. Any ideas? On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote: This is how I made my app resolution-independent and with Android 1.5 legacy support: Why did I put my high-dpi images in the drawable-hdpi-v4 folder and not in drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi and tries to use these images instead of the ones in the res/drawable folder. The -v4 flag is only meaningful for Android 1.6 and works perfect. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5 version in
there does not help (as webmonkey reported). I don't have my head around
this fully, but I think Android somehow prefers the regular drawable
directory (which I have for the Cupcake crowd). What is the recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn hack...@android.comwrote:
Dammit yeah that would be broken. I'll make sure this is fixed in the next
version; for now i guess you will need to include both -v4 and -v5
resources.
On Thu, Oct 29, 2009 at 7:25 PM, Artem p.ar...@gmail.com wrote:
Trying to help by digging up the code.
I found this:
http://www.google.com/codesearch/p?hl=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=787
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an != here.
Hopefully, this is not the right code. Or perhaps there is new code in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the -hdpi
and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Android WVGA support
This will sound crazy, but -v6 works for me. There must be a strange reason
why this works, or maybe there is a subtle reason why this workaround does
not work. Can anyone confirm?
On Thu, Oct 29, 2009 at 11:22 PM, Artem Petakov p.ar...@gmail.com wrote:
Ah, that's too bad. Bugs happen.
I am trying to understand the solution... Somehow having a -v5 version in
there does not help (as webmonkey reported). I don't have my head around
this fully, but I think Android somehow prefers the regular drawable
directory (which I have for the Cupcake crowd). What is the recommended set
of drawable directories at this point?
Artem
On Thu, Oct 29, 2009 at 10:29 PM, Dianne Hackborn hack...@android.comwrote:
Dammit yeah that would be broken. I'll make sure this is fixed in the
next version; for now i guess you will need to include both -v4 and -v5
resources.
On Thu, Oct 29, 2009 at 7:25 PM, Artem p.ar...@gmail.com wrote:
Trying to help by digging up the code.
I found this:
http://www.google.com/codesearch/p?hl=ensa=Ncd=1ct=rc#uX1GffpyOZk/include/utils/ResourceTypes.hq=ResTable_configl=787
// Return true if 'this' can be considered a match for the
parameters in
// 'settings'.
// Note this is asymetric. A default piece of data will match
every request
// but a request for the default should not match odd specifics
// (ie, request with no mcc should not match a particular mcc's
data)
// settings is the requested settings
inline bool match(const ResTable_config settings) const {
...
if (version != 0) {
if (settings.sdkVersion != 0 sdkVersion != 0
sdkVersion != settings.sdkVersion) {
return false;
}
if (settings.minorVersion != 0 minorVersion != 0
minorVersion != settings.minorVersion) {
return false;
}
}
return true;
}
Of course I am not sure where this is used, but I only see an != here.
Hopefully, this is not the right code. Or perhaps there is new code in
Eclair that is not available yet, that makes this better.
Thanks for the help.
Artem
On Oct 29, 9:12 pm, Artem Petakov p.ar...@gmail.com wrote:
Dianne, I am sorry to say it also does not work for me. Actually, we
had
made a mistake and originally forgot the v4, which screwed up Cupcake,
but
now we added the v4 (and make no other changes), and it stopped
working.
Am I missing something? Or is there perhaps a serious problem? Please
reply
back so we can take action -- we need to publish a new APK for the
Cupcake
users, but we can't figure out how to do that without breaking Eclair.
Artem
On Thu, Oct 29, 2009 at 11:00 AM, webmonkey webmonke...@gmail.com
wrote:
Hi Dianne,
The v flag does indeed not work, I am using the Android 2.0 SDK with
the following AndroidManifest settings:
uses-sdk
android:minSdkVersion=3
android:targetSdkVersion=5
/
Running on a WVGA854 emulator with density 240 and API 5, I get the
following results:
drawable-hdpi-v4
is ignored
drawable-hdpi-v5
is ignored, very strange
drawable-hdpi
works, but we can't use that
On Oct 29, 3:45 pm, Dianne Hackborn hack...@android.com wrote:
I am pretty positive it works. Nothing changed in 2.0 -- this has
been
the
same since 1.0, if the platform's SDK version is the resource
version,
then the resource is ignored.
On Wed, Oct 28, 2009 at 5:28 PM, Jeff codesec...@gmail.com
wrote:
Looks like -v4 flag doesn't work in Android 2.0. Any ideas?
On Oct 22, 8:38 am, Nikolay Ananiev devuni...@gmail.com wrote:
This is how I made my app resolution-independent and with
Android 1.5
legacy
support:
Why did I put my high-dpi images in the drawable-hdpi-v4 folder
and
not
in
drawable-hdpi? Because the Android 1.5 OS can't handle the
-hdpi and
tries
to use these images instead of the ones in the res/drawable
folder.
The
-v4
flag is only meaningful for Android 1.6 and works perfect.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have
time to
provide private support, and so won't reply to such e-mails. All
such
questions should be posted on public forums, where I and others can
see
and
answer them.
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email
