[android-developers] Android First install launch issue
I am facing issue with my android app. If a user installs my app through apk file. After installation a window appears with two buttons *open* and *done* which is part of android os. When user taps on *open,* it opens my launcher activity. Which is great... After landing to Launcher activity if user go to some other activity of my app from launcher activity and the he decide to minimize my app by pressing android home button key. My app appears in the app stack... After some time when user press to the launcher icon of my app, though the app is in apps stack but it starts again from the launcher activity rather continue from the last activity where user minimize the app. This only happens when user first open the app after installation from the android popup of done or open button. However if user kills the app from apps stack and re open the app this never happen again. Note: In my Manifist i do not put any launchmode. I have only one launcher activity Please guide me Thanks -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/cbb5e493-c265-4f95-b15b-415bbbd761e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [android-developers] Unsubscribe
Dianne, did you have any luck with that sample APK and reproducing the issue? Thanks On Friday, July 27, 2012 12:47:17 PM UTC+1, Kostya Vasilyev wrote: 2012/7/27 Jim Graham spook...@gmail.com javascript: On Thu, Jul 26, 2012 at 10:35:18PM -0700, Andy dev wrote: Anyone made any progress with this issue, I still cannot pinpoint what causes it? It's like life after death - no-one who knows for sure is able to share his knowledge :) It's nothing new...e-mail lists have been plagued with unsubscribe requests sent to the list despite very specific instructions given to users of the list since the day they signed up. As to why people do that, I'm going to be nice and not answer that part. Another mystery in the same category: a refund request for an in-app purchase from a user claming he didn't buy it (and no, neither he or his phone is being held captive). Later, --jim -- THE SCORE: ME: 2 CANCER: 0 73 DE N5IAL (/4) | There it was, right in the title bar: spook...@gmail.com javascript: | Microsoft Operations POS. Running Mac OS X Lion | ICBM / Hurricane: | Never before has a TLA been so appropriately 30.44406N 86.59909W| mis-parsed. (alt.sysadmin.recovery) Android Apps Listing at http://www.jstrack.org/barcodes.html -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send email to android-d...@googlegroups.comjavascript: To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com javascript: 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
Re: [android-developers] Unsubscribe
Anyone made any progress with this issue, I still cannot pinpoint what causes it? On Tuesday, July 24, 2012 3:03:41 PM UTC+1, Larry Meadors wrote: This is at the bottom of EVERY post to the list: 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* -- 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
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Here's a link to the binary:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Thanks!
On Tuesday, July 24, 2012 8:05:53 AM UTC+1, Dianne Hackborn wrote:
Could you include a binary? I just want to see what the platform is
doing; I don't need to look at the code. Thanks!
On Mon, Jul 23, 2012 at 10:40 PM, Andy dev andrewpmo...@gmail.com wrote:
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for
the new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash,
restart and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code
for you to look at to try and recreate the issue. Let me know if you can't
get it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the
broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in
the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.BinderProxy.*
*transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ApplicationThreadProxy.**scheduleReceiver(**
ApplicationThreadNative.java:**767)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processCurBroadcastLocked(**BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
BroadcastQueue.**processNextBroadcast(**BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**finishReceiver(**ActivityManagerService.java:*
*13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.app.**
ActivityManagerNative.**onTransact(**ActivityManagerNative.java:**346)
07-21 23:57:40.286: W/BroadcastQueue(309): at com.android.server.am.**
ActivityManagerService.**onTransact(**ActivityManagerService.java:**
1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at android.os.Binder.**
execTransact(Binder.java:367)
07-21 23:57
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Dianne, I've created a very cut down version of my app where I'm still
getting the issue. I've uploaded it to google drive here:
https://docs.google.com/open?id=0B9RsW3kcQ9jPem9PLVIxdWdlQlU
Basically, build and install the code and switch on accessibility for the
app. Run the app and then change focus to a home screen or another app etc.
Then receive a text message. You'll see the logcat line showing up for the
new text message.
Then use the tasklist to swipe away the app.
Get another text message and as it arrives the service will crash, restart
and you won't see the logcat message appear in the logs.
The code is a little hacked together just to try and minimize the code for
you to look at to try and recreate the issue. Let me know if you can't get
it working or having any questions.
On Sunday, July 22, 2012 8:19:23 AM UTC+1, Dianne Hackborn wrote:
TransactionTooLarge means that the data being sent through the IPC call is
too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given your
position in the android team. I'll try and work on cutting down my code
into a manageable example as it's several hundred classes at the moment
(it's the app Light Flow in the market). I do hold quite a bit in static
variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.TransactionTooLargeException in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only a
few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that is
if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.com wrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Kostya, is there any chance of sending me your small test? I'm hoping I can
try compare that with my code and make some progress, or at least help me
get together a small example for Dianne. If you do, could you send it to
andrew at rageconsulting dot com
Andrew
On Sunday, July 22, 2012 1:05:48 PM UTC+1, Kostya Vasilyev wrote:
2012/7/22 Andy dev andrewpmo...@gmail.com
Kostya, after tracking mine down more, it seems to be exactly the same.
It doesn't actually get killed until I get a broadcast. I'm not sending
them I'm receiving them from things like the SMS service, the battery level
the screen state etc, but any of those I've registered for cause the issue.
Well, my code sends broadcasts between the app's components, which is very
nearly synchronous, so I could not tell the difference.
I actually created and ran a small test, and can confirm this
behavior with 100% certainty.
-- K
I'm not exactly sure which transaction is even going on at this point.
Dianne, thanks for your reply I really appriciate it, especially given
your position in the android team. I'll try and work on cutting down my
code into a manageable example as it's several hundred classes at the
moment (it's the app Light Flow in the market). I do hold quite a bit in
static variables, does any of that make a difference in this situation?
On Sunday, July 22, 2012 11:14:16 AM UTC+1, Kostya Vasilyev wrote:
I'm also seeing my application get killed even while it has a foreground
service.
It appears to happen on the next sendBroadcast() - which is an
implementation detail of how some of my components interact, and has
nothing to do with the service's startForeground() state. The service
remains in foreground state at this point (and is supposed to last about a
dozen seconds more).
Instead, the process gets killed, and I'm also seeing an
android.os.**TransactionTooLargeException
in the logcat.
The exception looks to me like an unfortunate and unexpected side effect
of the process getting killed.
The broadcast in question is sent farly often, its data payload is only
a few dozen bytes, and so it never triggers this exception under normal
circumstances.
-- K
2012/7/22 Dianne Hackborn hack...@android.com
TransactionTooLarge means that the data being sent through the IPC call
is too large.
I just checked my test case and verified that this doesn't kill the
service's process *if* it is in the foreground (with
Service.startForeground()). I'm not sure what may be different in your
situation... one thing to keep in mind is that when the user removes a
task, and it is not safe to kill a process associated with it, then that
process is marked as having a pending kill, and as soon as it becomes safe
it will be killed. So for example at whatever point after that you are no
longer foreground, your process will be killed.
There was a change in JB to make this interaction better about finding
processes associated with the app and killing them. If your service isn't
running in the main process of the app, its process should always be
killed
now, where before it may not have been.
However in all cases it is only killed if it is safe to do so -- that
is if the process is at an oom_adj level that is safe to kill by the OOM
killer. Just running a background service means it is safe to kill; the
service itself will be restarted if you have indicated this is what you
want. This is not a new situation that your app needs to deal with -- its
process could always have been killed while in this state if memory was
needed elsewhere (for example if the user launches a game that uses a lot
of RAM).
Back to the exception you mention, I wouldn't like to see this in the
logs... if you can give me steps to reproduce it, it is something I would
like to investigate.
That said, your initial description is not actually a system problem as
you describe it -- yes your process gets killed, but this is a normal part
of operation you should be dealing with, and if you can't recover when it
is restarted then that is something that needs to be fixed in the app.
On Sat, Jul 21, 2012 at 4:01 PM, Andy dev andrewpmo...@gmail.comwrote:
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the
broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in
the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION
!!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending
broadcast to ComponentInfo{com.example.**android.app/com.example.**
android.app.receiver.**SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309): android.os.**
TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Ok, I've found out a little more information. It seems that the crash
doesn't happen when the task is swiped away, it's when one of the broadcast
receivers tries to fire after the app has been swiped away. It works find
beforehand, but it's cleared from the task list I'm also seeing this in the
logs:
07-21 23:57:40.286: E/JavaBinder(309): !!! FAILED BINDER TRANSACTION !!!
07-21 23:57:40.286: W/BroadcastQueue(309): Exception when sending broadcast
to
ComponentInfo{com.example.android.app/com.example.android.app.receiver.SmsReceiver}
07-21 23:57:40.286: W/BroadcastQueue(309):
android.os.TransactionTooLargeException
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.BinderProxy.transact(Native Method)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ApplicationThreadProxy.scheduleReceiver(ApplicationThreadNative.java:767)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processCurBroadcastLocked(BroadcastQueue.java:220)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:750)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.finishReceiver(ActivityManagerService.java:13281)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:346)
07-21 23:57:40.286: W/BroadcastQueue(309): at
com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1611)
07-21 23:57:40.286: W/BroadcastQueue(309): at
android.os.Binder.execTransact(Binder.java:367)
07-21 23:57:40.286: W/BroadcastQueue(309): at
dalvik.system.NativeStart.run(Native Method)
07-21 23:57:40.286: W/ActivityManager(309): Scheduling restart of crashed
service com.example.android.app/.service.MainRunningService in 5000ms
To be honest, I've tried to read about the TransactionTooLargeException,
but I don't feel any wiser!
On Friday, July 20, 2012 11:23:11 PM UTC+1, Andy dev wrote:
Thanks. I'll keep looking for a solution then!
On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote:
Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy
Nexus).
-- K
2012/7/21 Andy dev andrewpmo...@gmail.com
Anyone at least confirm what I'm doing looks ok - even if you don't know
the reason why. Just as a sanity check?
On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote:
I've got a service running (an accessibility service called
MainRunningService) and also use an alarmmanager within my app.
On ICS when a user pulled up the task list and swiped the app away the
service kept running, but the user interface was cleared from the stack.
On jelly bean I'm finding this to be a little different. It seems like
it kills off the service and then restarts it even if I've got an icon in
the notification bar and I've got the app set to run in the foreground.
This is killing off all my current app state and causing it to stop
working.
I'm seeing this in the logs
07-19 21:47:42.213: I/ActivityManager(307): Killing
834:com.example.android.**appname/u0a72: remove task
07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus
client died
07-19 21:47:42.236: I/AudioService(307): AudioFocus
abandonAudioFocus(): removing entry for android.media.AudioManager@**
41a42020com.example.android.**appname.service.**
MainRunningService$1@41963ec0android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0
07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of
crashed service
com.rageconsulting.android.**appname/.service.**MainRunningService
in 5000ms
For the persistent Icon I'm doing the following:
Notification foregroundNotification;
foregroundNotification = new Notification(R.drawable.iconx,**Example
starting notification,System.**currentTimeMillis());
Intent i=new Intent(this, MainUIActivity.class);
i.setFlags(Intent.FLAG_**ACTIVITY_CLEAR_TOP|Intent.**
FLAG_ACTIVITY_SINGLE_TOP);
foregroundNotification.flags|=**Notification.FLAG_NO_CLEAR;
startForeground(9642, foregroundNotification);
Is there something I'm doing wrong? I've never had a problem in the
past with this code, but it's not very good on jelly bean.
--
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
--
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
[android-developers] Re: Jelly bean swiping task away from task list kills service
Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,Example starting notification,System.currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- 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
Re: [android-developers] Re: Jelly bean swiping task away from task list kills service
Thanks. I'll keep looking for a solution then! On Friday, July 20, 2012 11:04:13 PM UTC+1, Kostya Vasilyev wrote: Yep, I can confirm this with my own foreground service on 4.1.1 (Galaxy Nexus). -- K 2012/7/21 Andy dev andrewpmo...@gmail.com Anyone at least confirm what I'm doing looks ok - even if you don't know the reason why. Just as a sanity check? On Thursday, July 19, 2012 10:19:22 PM UTC+1, Andy dev wrote: I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.**appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@** 41a42020com.example.android.**appname.service.** MainRunningService$1@41963ec0android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.**appname/.service.**MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,**Example starting notification,System.**currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_**ACTIVITY_CLEAR_TOP|Intent.** FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=**Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- 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 -- 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] Jelly bean swiping task away from task list kills service
I've got a service running (an accessibility service called MainRunningService) and also use an alarmmanager within my app. On ICS when a user pulled up the task list and swiped the app away the service kept running, but the user interface was cleared from the stack. On jelly bean I'm finding this to be a little different. It seems like it kills off the service and then restarts it even if I've got an icon in the notification bar and I've got the app set to run in the foreground. This is killing off all my current app state and causing it to stop working. I'm seeing this in the logs 07-19 21:47:42.213: I/ActivityManager(307): Killing 834:com.example.android.appname/u0a72: remove task 07-19 21:47:42.236: W/AudioService(307): AudioFocus audio focus client died 07-19 21:47:42.236: I/AudioService(307): AudioFocus abandonAudioFocus(): removing entry for android.media.AudioManager@41a42020com.example.android.appname.service.MainRunningService$1@41963ec0 07-19 21:47:42.244: W/ActivityManager(307): Scheduling restart of crashed service com.rageconsulting.android.appname/.service.MainRunningService in 5000ms For the persistent Icon I'm doing the following: Notification foregroundNotification; foregroundNotification = new Notification(R.drawable.iconx,Example starting notification,System.currentTimeMillis()); Intent i=new Intent(this, MainUIActivity.class); i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP|Intent.FLAG_ACTIVITY_SINGLE_TOP); foregroundNotification.flags|=Notification.FLAG_NO_CLEAR; startForeground(9642, foregroundNotification); Is there something I'm doing wrong? I've never had a problem in the past with this code, but it's not very good on jelly bean. -- 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: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
Thanks, I'm aware of that. Is was me who raised it :-) On Tuesday, July 17, 2012 7:42:15 AM UTC+1, Pent wrote: Now if I could only find out the reason why since ice cream sandwich accessibility has caused some phones to start talking to them as soon as the accessibility service of my app is enabled even though talkback is off and I don't use any TTS in the app. In case you didn't see it: http://code.google.com/p/android/issues/detail?id=23105 Pent -- 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: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
There's no harm trying :-) On Tuesday, July 17, 2012 9:53:52 AM UTC+1, Pent wrote: Ah, you were subtly side-promoting, very good :-) Pent -- 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: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
Thanks Mark, your answer was perfect!
After playing around the solution that worked for me was to use the bool
flags with the values-v16 directory and subclassing the service with with a
MainRunningServicePreJellyBean class.
Although compiling didn't complain with using the same service class twice,
the jelly bean version just didn't work (which was declared 2nd in the
file) so I guess it found the first reference and just set it to disabled.
I agree on the documentation though. The SDK samples are for v16 and open
source projects like talkback have a pre and post ice cream sandwich set of
apps, so there wasn't any examples to go off.
Now if I could only find out the reason why since ice cream sandwich
accessibility has caused some phones to start talking to them as soon as
the accessibility service of my app is enabled even though talkback is off
and I don't use any TTS in the app.
On Sunday, July 15, 2012 11:51:22 PM UTC+1, Andy dev wrote:
I've got an app in the market which uses the accessibility service. For it
to work correctly in Jelly bean I need to add
the android.permission.BIND_ACCESSIBILITY_SERVICE permission to the service
declaration in the android manifest file.
Doing this is fine and gets things working for jelly bean, but then going
back to my gingerbread Nexus One, it ends up crashing with the following
error:
07-15 22:15:56.090: E/ACRA(1168): Caused by: java.lang.SecurityException: Not
allowed to start service Intent { cmp=com.example/.MainRunningService (has
extras) } without permission android.permission.BIND_ACCESSIBILITY_SERVICE
I can't think how to get around this. Any suggestions. I would have thought
it would have got silently ignored in older builds.
--
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: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
I think that would have been ok, but I wanted to use some new features from
v16
On Monday, July 16, 2012 7:51:07 PM UTC+1, Streets Of Boston wrote:
I'm just guessing here: What if you set thee android:targetSdkVersion to
a value less than 16?
On Monday, July 16, 2012 2:43:47 PM UTC-4, Andy dev wrote:
Thanks Mark, your answer was perfect!
After playing around the solution that worked for me was to use the bool
flags with the values-v16 directory and subclassing the service with with a
MainRunningServicePreJellyBean class.
Although compiling didn't complain with using the same service class
twice, the jelly bean version just didn't work (which was declared 2nd in
the file) so I guess it found the first reference and just set it to
disabled.
I agree on the documentation though. The SDK samples are for v16 and open
source projects like talkback have a pre and post ice cream sandwich set of
apps, so there wasn't any examples to go off.
Now if I could only find out the reason why since ice cream sandwich
accessibility has caused some phones to start talking to them as soon as
the accessibility service of my app is enabled even though talkback is off
and I don't use any TTS in the app.
On Sunday, July 15, 2012 11:51:22 PM UTC+1, Andy dev wrote:
I've got an app in the market which uses the accessibility service. For
it to work correctly in Jelly bean I need to add
the android.permission.BIND_ACCESSIBILITY_SERVICE permission to the service
declaration in the android manifest file.
Doing this is fine and gets things working for jelly bean, but then
going back to my gingerbread Nexus One, it ends up crashing with the
following error:
07-15 22:15:56.090: E/ACRA(1168): Caused by: java.lang.SecurityException:
Not allowed to start service Intent { cmp=com.example/.MainRunningService
(has extras) } without permission
android.permission.BIND_ACCESSIBILITY_SERVICE
I can't think how to get around this. Any suggestions. I would have thought
it would have got silently ignored in older builds.
--
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
Re: [android-developers] Re: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
I tried setting back to a targetSdkVersion of 15, but when I've got that and my app directs to the accessibly settings page, my app isn't listed in the accessibility list. As soon as I change it to 16 it shows up. On Monday, July 16, 2012 11:04:33 PM UTC+1, Mark Murphy (a Commons Guy) wrote: On Mon, Jul 16, 2012 at 5:00 PM, Streets Of Boston flyingdutc...@gmail.com wrote: The targetSdkVersion value only determines the compatibility mode of your app (depending on the device it is running on), which influences the default theme or your app, default behavior of permissions, etc. The only way this would have an impact is if they are only checking that permission for apps with targetSdkVersion 16 or higher. That's entirely possible, but it is not documented either way. Though I should have thought of that -- thanks, Streets! -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Android Training in NYC: http://marakana.com/training/android/ -- 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] Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
I've got an app in the market which uses the accessibility service. For it
to work correctly in Jelly bean I need to add
the android.permission.BIND_ACCESSIBILITY_SERVICE permission to the service
declaration in the android manifest file.
Doing this is fine and gets things working for jelly bean, but then going
back to my gingerbread Nexus One, it ends up crashing with the following
error:
07-15 22:15:56.090: E/ACRA(1168): Caused by: java.lang.SecurityException: Not
allowed to start service Intent { cmp=com.example/.MainRunningService (has
extras) } without permission android.permission.BIND_ACCESSIBILITY_SERVICE
I can't think how to get around this. Any suggestions. I would have thought it
would have got silently ignored in older builds.
--
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: Jelly bean accessibility service needing android.permission.BIND_ACCESSIBILITY_SERVICE. Backwards compatibility
Forgot to say my versions in the manifest are set as follows: android:minSdkVersion=8 android:targetSdkVersion=16 Plus I've updated to the latest android-support-v13.jar file in the project -- 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
