I just installed SDK 2.0 and tested a stable app on a 2.0 AVD to make
sure it's still ok. It isn't. I'm trying to debug this, but the
problem, whatever it is, looks to be happening in Android, not in my
app.
App starts fine, flowing through the entire onCreate() and
initializing everything. I tested this with by attaching the debugger
to the emulator and setting breakpoints throughout. Good so far. Then
the application resumes, calling the onCreate() again. This continues,
presumably forever or until I kill the app.
On every iteration I am getting log messages with the tag UsageStats.
The messages I'm seeing include:
W UsageStats Something wrong here, didn't expect *packagename* to be
resumed
W UsageStats Unexpected resume of com.android.launcher while already
resumed in *packagename*
The first of these messages appears for every iteration. The second
one appeared only once.
The app I'm testing isn't too fancy, but I have had 6-figures worth of
user downloads and no one has ever reported a problem like this.
I did some additional testing on the 2.0 AVD, including numerous
project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large
swaths of code. The problem persists. Yet other apps I have work fine
on 2.0.
I peppered logs in each of the major life cycle methods I implement,
and this is what I get:
10-29 20:33:23.561: DEBUG/tag(502): onCreate
10-29 20:33:24.271: DEBUG/tag(502): onResume
10-29 20:33:26.101: DEBUG/tag(502): onSaveInstanceState
10-29 20:33:26.214: DEBUG/tag(502): onPause
10-29 20:33:26.311: DEBUG/tag(502): onCreate
10-29 20:33:26.561: DEBUG/tag(502): onRestoreInstanceState
10-29 20:33:26.571: DEBUG/tag(502): onResume
10-29 20:33:27.081: DEBUG/tag(502): onSaveInstanceState
10-29 20:33:27.130: DEBUG/tag(502): onPause
10-29 20:33:27.211: DEBUG/tag(502): onCreate
10-29 20:33:27.601: DEBUG/tag(502): onRestoreInstanceState
10-29 20:33:27.611: DEBUG/tag(502): onResume
10-29 20:33:28.162: DEBUG/tag(502): onSaveInstanceState
10-29 20:33:28.201: DEBUG/tag(502): onPause
10-29 20:33:28.541: DEBUG/tag(502): onCreate
10-29 20:33:28.951: DEBUG/tag(502): onRestoreInstanceState
10-29 20:33:28.960: DEBUG/tag(502): onResume
10-29 20:33:29.631: DEBUG/FatCalc(502): onPause
I finally kill it with the back key, though it sometimes takes a few
tries because the timing is critical.
Elsewhere in the log, I found something in the logs put out by the
system process that from their timestamp may be correlated with the
uninstall/install process initiated by ADB:
10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain
package for resource number 0x7f060000
10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain
package for resource number 0x7f060001
These correspond to string resources in the app, both of which appear
to display normally when the app runs, in the momentary glimpses of
the app's UI display before it gets destroyed.
This really has me puzzled. Any help appreciated.
On Oct 29, 12:06 pm, Nmix <nepean...@gmail.com> wrote:
> I just installed SDK 2.0 and tested a stable app on a 2.0 AVD to make
> sure it's still ok. It isn't. I'm trying to debug this, but the
> problem, whatever it is, looks to be happening in Android, not in my
> app.
> App starts fine, flowing through the entire onCreate() and
> initializing everything. I tested this with by attaching the debugger
> to the emulator and setting breakpoints throughout. Good so far. Then
> the application resumes, calling the onCreate() again. This continues,
> presumably forever or until I kill the app.
> On every iteration I am getting log messages with the tag UsageStats.
> The messages I'm seeing include:
> W UsageStats Something wrong here, didn't expect *packagename* to be
> resumed
> W UsageStats Unexpected resume of com.android.launcher while already
> resumed in *packagename*
> The first of these messages appears for every iteration. The second
> one appeared only once.
> The app I'm testing isn't too fancy, but I have had 6-figures worth of
> user downloads and no one has ever reported a problem like this.
Nmix wrote: > I did some additional testing on the 2.0 AVD, including numerous > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large > swaths of code. The problem persists. Yet other apps I have work fine > on 2.0.
> I peppered logs in each of the major life cycle methods I implement, > and this is what I get: > 10-29 20:33:23.561: DEBUG/tag(502): onCreate > 10-29 20:33:24.271: DEBUG/tag(502): onResume > 10-29 20:33:26.101: DEBUG/tag(502): onSaveInstanceState > 10-29 20:33:26.214: DEBUG/tag(502): onPause > 10-29 20:33:26.311: DEBUG/tag(502): onCreate > 10-29 20:33:26.561: DEBUG/tag(502): onRestoreInstanceState > 10-29 20:33:26.571: DEBUG/tag(502): onResume > 10-29 20:33:27.081: DEBUG/tag(502): onSaveInstanceState > 10-29 20:33:27.130: DEBUG/tag(502): onPause > 10-29 20:33:27.211: DEBUG/tag(502): onCreate > 10-29 20:33:27.601: DEBUG/tag(502): onRestoreInstanceState > 10-29 20:33:27.611: DEBUG/tag(502): onResume > 10-29 20:33:28.162: DEBUG/tag(502): onSaveInstanceState > 10-29 20:33:28.201: DEBUG/tag(502): onPause > 10-29 20:33:28.541: DEBUG/tag(502): onCreate > 10-29 20:33:28.951: DEBUG/tag(502): onRestoreInstanceState > 10-29 20:33:28.960: DEBUG/tag(502): onResume > 10-29 20:33:29.631: DEBUG/FatCalc(502): onPause
> I finally kill it with the back key, though it sometimes takes a few > tries because the timing is critical.
> Elsewhere in the log, I found something in the logs put out by the > system process that from their timestamp may be correlated with the > uninstall/install process initiated by ADB:
> 10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain > package for resource number 0x7f060000 > 10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain > package for resource number 0x7f060001
> These correspond to string resources in the app, both of which appear > to display normally when the app runs, in the momentary glimpses of > the app's UI display before it gets destroyed.
> This really has me puzzled. Any help appreciated.
Something in your onResume() would appear to be triggering behavior reminiscent of a screen rotation or other configuration change.
I'd start by commenting out everything in onResume() and seeing if the problem persists.
Apart from a Log.d() that I just added to produce the logcat trace and
the super call, there was just one line of code (an 'if' with a
condition which isn't satisfied) which is pretty boring. Regardless, I
commented that out. No change in behavior. Thanks for the suggestion,
Mark, but I am beginning to think that something quite a bit more
subtle is going on.
Now I'm getting quite worried about when 2.0 shows up in OTA updates
because it may/will break my app and I have no idea what to do. Up to
1.6 the app is solid as a rock.
On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> Nmix wrote:
> > I did some additional testing on the 2.0 AVD, including numerous
> > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large
> > swaths of code. The problem persists. Yet other apps I have work fine
> > on 2.0.
> > I finally kill it with the back key, though it sometimes takes a few
> > tries because the timing is critical.
> > Elsewhere in the log, I found something in the logs put out by the
> > system process that from their timestamp may be correlated with the
> > uninstall/install process initiated by ADB:
> > 10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain
> > package for resource number 0x7f060000
> > 10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain
> > package for resource number 0x7f060001
> > These correspond to string resources in the app, both of which appear
> > to display normally when the app runs, in the momentary glimpses of
> > the app's UI display before it gets destroyed.
> > This really has me puzzled. Any help appreciated.
> Something in your onResume() would appear to be triggering behavior
> reminiscent of a screen rotation or other configuration change.
> I'd start by commenting out everything in onResume() and seeing if the
> problem persists.
On Oct 29, 4:04 pm, Nmix <nepean...@gmail.com> wrote:
> Now I'm getting quite worried about when 2.0 shows up in OTA updates
> because it may/will break my app and I have no idea what to do. Up to
> 1.6 the app is solid as a rock.
If it's easily repeatable, please file a bug on b.android.com. If the
APK is okay for free download (or can be modified to be), attach it to
the bug report.
Ok, I found it -- it's my bug. Mark, you were partly right, and that
helped. It was related to the configuration. Here is the guilty code,
which is in onCreate():
There should not be a call to setToDefaults(). I don't remember now
what I was thinking at the time, and the Android doc is very
uninformative for this method. Possibly I copied an example from
somewhere. Removing this line solved the problem.
Funny thing is that the bad code works fine pre-2.0 releases. However,
once I found it I carefully scoured the logcat on a 1.6 AVD and I did
find the same warning log spit out from the system process. Of course,
since nothing was broken and there was no way to relate the log to my
process, I had no idea.
I know now because it breaks in 2.0 by forcing a restart of the
activity that resembles a config change. I don't know if the 2.0
behavior is right or wrong since the write-up for setToDefaults() says
very little.
fadden: I did consider filing a bug, but that seemed premature when I
wasn't able to localize the problem. I didn't want to simply point to
the app on Android Market. Now the point is moot. Thanks.
On Oct 29, 7:04 pm, Nmix <nepean...@gmail.com> wrote:
> Apart from a Log.d() that I just added to produce the logcat trace and
> the super call, there was just one line of code (an 'if' with a
> condition which isn't satisfied) which is pretty boring. Regardless, I
> commented that out. No change in behavior. Thanks for the suggestion,
> Mark, but I am beginning to think that something quite a bit more
> subtle is going on.
> Now I'm getting quite worried about when 2.0 shows up in OTA updates
> because it may/will break my app and I have no idea what to do. Up to
> 1.6 the app is solid as a rock.
> On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> > Nmix wrote:
> > > I did some additional testing on the 2.0 AVD, including numerous
> > > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large
> > > swaths of code. The problem persists. Yet other apps I have work fine
> > > on 2.0.
> > > I finally kill it with the back key, though it sometimes takes a few
> > > tries because the timing is critical.
> > > Elsewhere in the log, I found something in the logs put out by the
> > > system process that from their timestamp may be correlated with the
> > > uninstall/install process initiated by ADB:
> > > 10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain
> > > package for resource number 0x7f060000
> > > 10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain
> > > package for resource number 0x7f060001
> > > These correspond to string resources in the app, both of which appear
> > > to display normally when the app runs, in the momentary glimpses of
> > > the app's UI display before it gets destroyed.
> > > This really has me puzzled. Any help appreciated.
> > Something in your onResume() would appear to be triggering behavior
> > reminiscent of a screen rotation or other configuration change.
> > I'd start by commenting out everything in onResume() and seeing if the
> > problem persists.
> Ok, I found it -- it's my bug. Mark, you were partly right, and that
> helped. It was related to the configuration. Here is the guilty code,
> which is in onCreate():
> There should not be a call to setToDefaults(). I don't remember now
> what I was thinking at the time, and the Android doc is very
> uninformative for this method. Possibly I copied an example from
> somewhere. Removing this line solved the problem.
> Funny thing is that the bad code works fine pre-2.0 releases. However,
> once I found it I carefully scoured the logcat on a 1.6 AVD and I did
> find the same warning log spit out from the system process. Of course,
> since nothing was broken and there was no way to relate the log to my
> process, I had no idea.
> I know now because it breaks in 2.0 by forcing a restart of the
> activity that resembles a config change. I don't know if the 2.0
> behavior is right or wrong since the write-up for setToDefaults() says
> very little.
> fadden: I did consider filing a bug, but that seemed premature when I
> wasn't able to localize the problem. I didn't want to simply point to
> the app on Android Market. Now the point is moot. Thanks.
> On Oct 29, 7:04 pm, Nmix <nepean...@gmail.com> wrote:
> > Apart from a Log.d() that I just added to produce the logcat trace and
> > the super call, there was just one line of code (an 'if' with a
> > condition which isn't satisfied) which is pretty boring. Regardless, I
> > commented that out. No change in behavior. Thanks for the suggestion,
> > Mark, but I am beginning to think that something quite a bit more
> > subtle is going on.
> > Now I'm getting quite worried about when 2.0 shows up in OTA updates
> > because it may/will break my app and I have no idea what to do. Up to
> > 1.6 the app is solid as a rock.
> > On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> > > Nmix wrote:
> > > > I did some additional testing on the 2.0 AVD, including numerous
> > > > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large
> > > > swaths of code. The problem persists. Yet other apps I have work fine
> > > > on 2.0.
> > > > I finally kill it with the back key, though it sometimes takes a few
> > > > tries because the timing is critical.
> > > > Elsewhere in the log, I found something in the logs put out by the
> > > > system process that from their timestamp may be correlated with the
> > > > uninstall/install process initiated by ADB:
> > > > 10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain
> > > > package for resource number 0x7f060000
> > > > 10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain
> > > > package for resource number 0x7f060001
> > > > These correspond to string resources in the app, both of which appear
> > > > to display normally when the app runs, in the momentary glimpses of
> > > > the app's UI display before it gets destroyed.
> > > > This really has me puzzled. Any help appreciated.
> > > Something in your onResume() would appear to be triggering behavior
> > > reminiscent of a screen rotation or other configuration change.
> > > I'd start by commenting out everything in onResume() and seeing if the
> > > problem persists.
Does that drawable exist for the configuration you're running on? (For
example, do you see the same behavior when running 2.0 on an HVGA,
mdpi browser).
Regards,
Justin
Android Team @ Google
On Nov 11, 7:08 pm, Alexey Volovoy <avolo...@gmail.com> wrote:
> I have same issue cause by this line of code i onCreate();
> iconView.setImageResource(R.drawable.mylogor);
> On Oct 29, 9:18 pm, Nmix <nepean...@gmail.com> wrote:
> > Ok, I found it -- it's my bug. Mark, you were partly right, and that
> > helped. It was related to the configuration. Here is the guilty code,
> > which is in onCreate():
> > There should not be a call to setToDefaults(). I don't remember now
> > what I was thinking at the time, and the Android doc is very
> > uninformative for this method. Possibly I copied an example from
> > somewhere. Removing this line solved the problem.
> > Funny thing is that the bad code works fine pre-2.0 releases. However,
> > once I found it I carefully scoured the logcat on a 1.6 AVD and I did
> > find the same warning log spit out from the system process. Of course,
> > since nothing was broken and there was no way to relate the log to my
> > process, I had no idea.
> > I know now because it breaks in 2.0 by forcing a restart of the
> > activity that resembles a config change. I don't know if the 2.0
> > behavior is right or wrong since the write-up for setToDefaults() says
> > very little.
> > fadden: I did consider filing a bug, but that seemed premature when I
> > wasn't able to localize the problem. I didn't want to simply point to
> > the app on Android Market. Now the point is moot. Thanks.
> > On Oct 29, 7:04 pm, Nmix <nepean...@gmail.com> wrote:
> > > Apart from a Log.d() that I just added to produce the logcat trace and
> > > the super call, there was just one line of code (an 'if' with a
> > > condition which isn't satisfied) which is pretty boring. Regardless, I
> > > commented that out. No change in behavior. Thanks for the suggestion,
> > > Mark, but I am beginning to think that something quite a bit more
> > > subtle is going on.
> > > Now I'm getting quite worried about when 2.0 shows up in OTA updates
> > > because it may/will break my app and I have no idea what to do. Up to
> > > 1.6 the app is solid as a rock.
> > > On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> > > > Nmix wrote:
> > > > > I did some additional testing on the 2.0 AVD, including numerous
> > > > > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large
> > > > > swaths of code. The problem persists. Yet other apps I have work fine
> > > > > on 2.0.
> > > > > I finally kill it with the back key, though it sometimes takes a few
> > > > > tries because the timing is critical.
> > > > > Elsewhere in the log, I found something in the logs put out by the
> > > > > system process that from their timestamp may be correlated with the
> > > > > uninstall/install process initiated by ADB:
> > > > > These correspond to string resources in the app, both of which appear
> > > > > to display normally when the app runs, in the momentary glimpses of
> > > > > the app's UI display before it gets destroyed.
> > > > > This really has me puzzled. Any help appreciated.
> > > > Something in your onResume() would appear to be triggering behavior
> > > > reminiscent of a screen rotation or other configuration change.
> > > > I'd start by commenting out everything in onResume() and seeing if the
> > > > problem persists.
ok for starters im pretty sure im not doin this right but i wanted to throw
an idea at anyone who would take the time to read/listen for upgrades to
come if it cant make the cut for the next one. I would like to see this done
in an upgrade instead of an app only because i feel that this is somthin
everyone would enjoy. BIG PICTURES i feel that When ur favorite
contacts/friends call and u have a customized ring tone and possibly an
assigned contact photo would it be askin to much to utilize the 3.2-inch
TFT-LCD flat touch-sensitive screen with 320 x 480 (HVGA) resolution for
that photo. Very simple yes i know however we are limited to that small
picture with out even being givin the option as to weather you' like it that
small or not.
just a thought i've had for some time now that i wanted to share thanks for
listening follow android but more specificly G1 users
On Thu, Nov 12, 2009 at 11:44 AM, Justin (Google Employee)
<j...@google.com>wrote:
> Does that drawable exist for the configuration you're running on? (For
> example, do you see the same behavior when running 2.0 on an HVGA,
> mdpi browser).
> Regards,
> Justin
> Android Team @ Google
> On Nov 11, 7:08 pm, Alexey Volovoy <avolo...@gmail.com> wrote:
> > I have same issue cause by this line of code i onCreate();
> > iconView.setImageResource(R.drawable.mylogor);
> > On Oct 29, 9:18 pm, Nmix <nepean...@gmail.com> wrote:
> > > Ok, I found it -- it's my bug. Mark, you were partly right, and that
> > > helped. It was related to the configuration. Here is the guilty code,
> > > which is in onCreate():
> > > There should not be a call to setToDefaults(). I don't remember now
> > > what I was thinking at the time, and the Android doc is very
> > > uninformative for this method. Possibly I copied an example from
> > > somewhere. Removing this line solved the problem.
> > > Funny thing is that the bad code works fine pre-2.0 releases. However,
> > > once I found it I carefully scoured the logcat on a 1.6 AVD and I did
> > > find the same warning log spit out from the system process. Of course,
> > > since nothing was broken and there was no way to relate the log to my
> > > process, I had no idea.
> > > I know now because it breaks in 2.0 by forcing a restart of the
> > > activity that resembles a config change. I don't know if the 2.0
> > > behavior is right or wrong since the write-up for setToDefaults() says
> > > very little.
> > > fadden: I did consider filing a bug, but that seemed premature when I
> > > wasn't able to localize the problem. I didn't want to simply point to
> > > the app on Android Market. Now the point is moot. Thanks.
> > > On Oct 29, 7:04 pm, Nmix <nepean...@gmail.com> wrote:
> > > > Apart from a Log.d() that I just added to produce the logcat trace
> and
> > > > the super call, there was just one line of code (an 'if' with a
> > > > condition which isn't satisfied) which is pretty boring. Regardless,
> I
> > > > commented that out. No change in behavior. Thanks for the suggestion,
> > > > Mark, but I am beginning to think that something quite a bit more
> > > > subtle is going on.
> > > > Now I'm getting quite worried about when 2.0 shows up in OTA updates
> > > > because it may/will break my app and I have no idea what to do. Up to
> > > > 1.6 the app is solid as a rock.
> > > > On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> > > > > Nmix wrote:
> > > > > > I did some additional testing on the 2.0 AVD, including numerous
> > > > > > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out
> large
> > > > > > swaths of code. The problem persists. Yet other apps I have work
> fine
> > > > > > on 2.0.
> > > > > > I finally kill it with the back key, though it sometimes takes a
> few
> > > > > > tries because the timing is critical.
> > > > > > Elsewhere in the log, I found something in the logs put out by
> the
> > > > > > system process that from their timestamp may be correlated with
> the
> > > > > > uninstall/install process initiated by ADB:
> > > > > > These correspond to string resources in the app, both of which
> appear
> > > > > > to display normally when the app runs, in the momentary glimpses
> of
> > > > > > the app's UI display before it gets destroyed.
> > > > > > This really has me puzzled. Any help appreciated.
> > > > > Something in your onResume() would appear to be triggering behavior
> > > > > reminiscent of a screen rotation or other configuration change.
> > > > > I'd start by commenting out everything in onResume() and seeing if
> the
> > > > > problem persists.
> --
> 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
// want to set (force) czech language on english phone
Logger.i(TAG, "set CS lang");
Locale loca = new Locale("cs"); // cs_CZ not work too
// !!! THIS LINE DO CYCLE !!!
conf.locale = loca;
res.updateConfiguration(conf, dm);
as I commented in code, line 'conf.locale = loca;' cause repeating
whole creating and destroying cycle as wrote Nmix in first post. And
also I have to say, than this code worked perfectly until 2.0 SDK. Any
suggestion? I'm using this for ability to choose app language
different from system lang. Thank you very much ...
> I just installed SDK 2.0 and tested a stable app on a 2.0 AVD to make
> sure it's still ok. It isn't. I'm trying to debug this, but the
> problem, whatever it is, looks to be happening in Android, not in my
> app.
> App starts fine, flowing through the entire onCreate() and
> initializing everything. I tested this with by attaching the debugger
> to the emulator and setting breakpoints throughout. Good so far. Then
> the application resumes, calling the onCreate() again. This continues,
> presumably forever or until I kill the app.
> On every iteration I am getting log messages with the tag UsageStats.
> The messages I'm seeing include:
> W UsageStats Something wrong here, didn't expect *packagename* to be
> resumed
> W UsageStats Unexpected resume of com.android.launcher while already
> resumed in *packagename*
> The first of these messages appears for every iteration. The second
> one appeared only once.
> The app I'm testing isn't too fancy, but I have had 6-figures worth of
> user downloads and no one has ever reported a problem like this.
On Oct 29, 1:08 pm, Nmix <nepean...@gmail.com> wrote:
> Elsewhere in the log, I found something in the logs put out by the
> system process that from their timestamp may be correlated with the
> uninstall/install process initiated by ADB:
> These correspond to stringresourcesin the app, both of which appear
> to display normally when the app runs, in the momentary glimpses of
> the app's UI display before it gets destroyed.
I am curious about these "Resources don't contain package for resource
number" messages. What do they mean? I am seeing them on my Droid.
On Tue, Dec 1, 2009 at 4:58 PM, Matt Kanninen <mathias...@gmail.com> wrote:
> I am curious about these "Resources don't contain package for resource
> number" messages. What do they mean? I am seeing them on my Droid.
They mean someone (and it is typically the system process) is trying to
retrieve resource identifiers that don't exist. For most of them, this is
attempting to retrieve an application's resources (0x7f......) from a
resources object that only has system resources (0x01......). This
shouldn't need to be something app developers worry about, though they are
annoying.
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.
I have the same problem in 2.0 and 2.0.1, the very same code is working perfect in 1.5, 1.6 and 2.1. My implementation[1] is pretty much the same as Menions. I also tried to set the permission 'CHANGE_CONFIGURATION' that I believe is needed when done from an Activity but without luck.
Is there a workaround or do I need to disable this option for 2.0.x?
On Fri, Nov 13, 2009 at 1:15 PM, Menion <menion.as...@gmail.com> wrote: > Hi, I have very similar problem, but still not successfully resolved. > In first activity during onCreate() I have this code
> // want to set (force) czech language on english phone > Logger.i(TAG, "set CS lang"); > Locale loca = new Locale("cs"); // cs_CZ not work too > // !!! THIS LINE DO CYCLE !!! > conf.locale = loca; > res.updateConfiguration(conf, dm);
> as I commented in code, line 'conf.locale = loca;' cause repeating > whole creating and destroying cycle as wrote Nmix in first post. And > also I have to say, than this code worked perfectly until 2.0 SDK. Any > suggestion? I'm using this for ability to choose app language > different from system lang. Thank you very much ...
> -- > 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+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
Found a solution for this, guess I mixed up CHANGE_CONFIGURATION with android:configChanges="locale" that should be added to the activity element in the Manifest. Adding this solves the problem.
On Wed, Mar 24, 2010 at 7:29 PM, Johan Nilsson <markupart...@gmail.com> wrote: > Did you manage to find a workaround for this?
> I have the same problem in 2.0 and 2.0.1, the very same code is > working perfect in 1.5, 1.6 and 2.1. My implementation[1] is pretty > much the same as Menions. I also tried to set the permission > 'CHANGE_CONFIGURATION' that I believe is needed when done from an > Activity but without luck.
> Is there a workaround or do I need to disable this option for 2.0.x?
> On Fri, Nov 13, 2009 at 1:15 PM, Menion <menion.as...@gmail.com> wrote: >> Hi, I have very similar problem, but still not successfully resolved. >> In first activity during onCreate() I have this code
>> // want to set (force) czech language on english phone >> Logger.i(TAG, "set CS lang"); >> Locale loca = new Locale("cs"); // cs_CZ not work too >> // !!! THIS LINE DO CYCLE !!! >> conf.locale = loca; >> res.updateConfiguration(conf, dm);
>> as I commented in code, line 'conf.locale = loca;' cause repeating >> whole creating and destroying cycle as wrote Nmix in first post. And >> also I have to say, than this code worked perfectly until 2.0 SDK. Any >> suggestion? I'm using this for ability to choose app language >> different from system lang. Thank you very much ...
>> -- >> 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+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en
> Found a solution for this, guess I mixed up CHANGE_CONFIGURATION with > android:configChanges="locale" that should be added to the activity > element in the Manifest. Adding this solves the problem.
> Regards, > Johan Nilsson
> On Wed, Mar 24, 2010 at 7:29 PM, Johan Nilsson <markupart...@gmail.com> > wrote: > > Did you manage to find a workaround for this?
> > I have the same problem in 2.0 and 2.0.1, the very same code is > > working perfect in 1.5, 1.6 and 2.1. My implementation[1] is pretty > > much the same as Menions. I also tried to set the permission > > 'CHANGE_CONFIGURATION' that I believe is needed when done from an > > Activity but without luck.
> > Is there a workaround or do I need to disable this option for 2.0.x?
> > On Fri, Nov 13, 2009 at 1:15 PM, Menion <menion.as...@gmail.com> wrote: > >> Hi, I have very similar problem, but still not successfully resolved. > >> In first activity during onCreate() I have this code
> >> // want to set (force) czech language on english phone > >> Logger.i(TAG, "set CS lang"); > >> Locale loca = new Locale("cs"); // cs_CZ not work too > >> // !!! THIS LINE DO CYCLE !!! > >> conf.locale = loca; > >> res.updateConfiguration(conf, dm);
> >> as I commented in code, line 'conf.locale = loca;' cause repeating > >> whole creating and destroying cycle as wrote Nmix in first post. And > >> also I have to say, than this code worked perfectly until 2.0 SDK. Any > >> suggestion? I'm using this for ability to choose app language > >> different from system lang. Thank you very much ...
> >> -- > >> 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
> To unsubscribe from this group, send email to android-developers+ > unsubscribegooglegroups.com or reply to this email with the words "REMOVE > ME" as the subject.
