About AlarmManager life cycle

            
First curse Fang Xingbing soon to die, even the "cycle" can not GOOGLE, their early graves were dug, his descendants were killed.
Consult Great God
AlarmManager in ACTIVITY in a statement. When this process is forced to stop, AlarmManager's Repeating still in a job?

I know that after being forced to stop its process broadCast, broadCast still at work.


Reply:
Why not add Log to see them?

If the Activity ends off, directly cancel out the AlarmManager it.

Presumably, it should work.
Reply:

Able to work properlyHas been added to alarmmanagerservice inside, alarm running with the current activity is alive does not matter much, mainly intent alarmmanagerservice and when it added
Reply:

reference to the second floor ningzhiyu reply:

to be working properlyHas been added to alarmmanagerservice inside, alarm running with the current activity is alive does not matter much, mainly alarmmanagerservice and intent when it added

Top, to work, to live as long as system_server
Reply:
Thank you for pointing upstairs. Looks like there is on a network alarmmanagerservice various interpretations, there is that end of the process alarmmanagerservice lost their lives, but also said the process will not end alarmmanagerservice end of life.
I declare a alarmmanagerservice to repeat a SERVICE in activity in the after end of the process, service is not reflected in the. Of course, perhaps the service was over, so the service is not reflected. I verify
Reply:
Assuming alarmmanagerservice Once declared, the detachment process exists. So with alarmmanagerservice call a SERVICE FLAG should be set to become similar to NEW_TASK this. But specifically how to code, I do not know. Common ACTIVITY call SERVICE, to set FLAG to NEW_TASK, I know.
Reply:
http://bbs.csdn.net/topics/370038197

alarmmanagerservice is a service running on system_server process, alarmmanager a client, running in your process.
Reply:
There is no doubt that you can continue to work.
ams (alarmamanagerservice, the same below) is running on system_server process, when you sign up for a ams alarm to go, as long as you do not take the initiative and cancel his time not to, then it will certainly be within your callback time to develop pendingintent.

Because all of your intent of the content stored in a hashmap activitymanagerservice of mIntentSenderRecords of, and not because of the end of your process destroys, as long as you are registered to ams while there is no initiative to cancel, when you see it will execute your pendingintent

You can look this article
http://blog.csdn.net/vicluo/article/details/8484939
Reply:
In Settings -> Applications -> forcibly stopped, this time, AlarmManager will be kill off ah. . .