[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 > > >> 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 | > 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.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
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 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 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)
>>>
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 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:
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 > >> >> 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 >>> >>>> 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 sy
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
>
>> 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 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
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
>>
>>> 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
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 > >> 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 >> > > -- 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 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
[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
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, 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
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 > 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] 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
[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
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
[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
