Note: This was meant to be more of a "how to read the dumpsys alarm output"
question, than a "help me find problems in my code" question.
But the code might be also relevant (and problematic), so here it is. Sorry
for C# :)
Calendar calendar = Calendar.Instance;
// Constructs a new instance of t
Note: This was meant to be more of a "how to read the dumpsys alarm output"
question, than a "help me find problems in my code" question.
But the code might be also relevant (and problematic), so here it is. Sorry
for C# :)
Calendar calendar = Calendar.Instance;
// Constructs a new instance of t
Raymond,
Any suggestions for me?
Problem is alarm is set from my Activity, and the alarm is received only if
Activity is currently running. Otherwise it will not.
Regards,
Sunil
On Fri, May 9, 2014 at 8:12 PM, Sunil K wrote:
> No, made it work. But now the real problem is alarm is raised
No, made it work. But now the real problem is alarm is raised only when my
activity is running, otherwise it will not. Currently trying to make my
alarm activity as background service but no luck still.
Any suggestion?
On Wed, Apr 23, 2014 at 10:57 PM, Raymond Rodgers
wrote:
> Is the alarm wo
Is the alarm working while the screen is on, but it's failing when the
screen is off? If so, you may need to implement a wakelock or partial
wakelock for it to work properly.
On 04/19/2014 09:11 AM, Sunil.K wrote:
Tried all possibilities, but no SUCCESS. Experts, please point my
mistake I'm k
Tried all possibilities, but no SUCCESS. Experts, please point my mistake
I'm kind of stuck here :(
On Friday, 18 April 2014 18:16:30 UTC+5:30, Sunil.K wrote:
>
> Hello,
>
> I am developing an app related to alarm service and facing an issue of
> Intent not being called.
> I have registered for
3.0. it in the release notes
On Wednesday, May 29, 2013 9:05:31 PM UTC+3, RichardC wrote:
>
> If you kill your application with the standard build-in Task-Killer and
> you are on Android 4.1+ (I think that's the version might be 3+) then you
> Application will not be run again until manually sta
You are right !
Thanks a lot.
I killed the app with "kill " and this time, the alarm started at
expected time.
I didn't knew this feature but it makes sense.
thanks again.
Mike
Le mercredi 29 mai 2013 20:05:31 UTC+2, RichardC a écrit :
>
> If you kill your application with the standard build-i
If you kill your application with the standard build-in Task-Killer and you
are on Android 4.1+ (I think that's the version might be 3+) then you
Application will not be run again until manually started by an end-user.
If you exit normally (press back) then your alarms should work as expected.
On Sat, May 19, 2012 at 11:45 AM, Bill Michaelson
wrote:
> For one, would the notification icon remain?
Only between your calls to startForeground() and when the service goes away.
> Also, would it be
> advantageous in the event that my Service is in a period of short
> duration pauses such as 5
Bingo. My fog enveloped the precise use of Intents, as you
undoubtedly inferred. The alarm is being caught in the receiver now.
I thank you for your very direct, clear identification of the problem
and the equally clear solution,
Further to the broader scope of the application:
The application
Hi,
I have similar question.
I want to make an alarm clock app. This app will have few activities,
such as list of alarms, settings of alarms, options, etc. Should I
make a service for it which will start android AlarmManager or I can
do it in one of the activities?
Pawel
--
You received this me
Have you considered using a MediaPlayer instead of just a straight Ringtone
object? You can pass the URI of the Ringtone to the MediaPlayer and have
better functionality.
I use the MediaPlayer and create a MediaPlayer.OnCompletionListener to watch
for the end of the playing. This doesn't always
On Mon, Oct 24, 2011 at 1:57 AM, John Goche wrote:
>
> Well, here is what I am doing now: I acquire a wakelock inside the
> broadcast receiver
> and release it from my activity. The only problem I have is that the play()
> method is
> asynchronous. I would like to be notified when the sound stops
Well, here is what I am doing now: I acquire a wakelock inside the broadcast
receiver
and release it from my activity. The only problem I have is that the play()
method is
asynchronous. I would like to be notified when the sound stops playing via a
callback
but I see no method for doing so here:
h
Hi,
I have done some more testing. It is working much better now in that each
time there is an
alarm a window pops up. In one last case though only after sliding the phone
guard up I did
find that the alarm window started to play late, so it is as though indeed
the phone went back
to sleep right a
Thanks Kostya,
I changed my wakelock from partial wakelock to full wakelock and that seems
to have fixed things, albeit
somewhat strangely. I now see the screen light up on each timer expiration.
I am going to do some more
testing and if things go wrong I will try releasing the wakelock from insid
I would still recommend you repeat your test with a Notification
(possibly with a sound), as the system should take care of holding the
wake lock(s) as needed for the duration of the sound.
As for implementing the wake locks in your code, to display an alert:
First, take a look at the docs, th
Not sure this is it, but I noticed on this line of your code:
pendingIntent = PendingIntent.getBroadcast(ctx, 0, intent,
PendingIntent.FLAG_UPDATE_CURRENT);
You are sending a 0 as the second argument, try sending something other than
0 there. I've noticed in my own experience that this doesn't
Kostya,
Thank you for your reply.
However left me give an update on the testing I have carried out. I have
reinstalled the app
from scratch and set alarms to expire every five minutes (each time an alarm
goes off it sets
up the next one for the next five minutes). Here is what I have observed:
-
Not sure why you use a "static" PendingIntent - if it's for optimization
reasons, that's really not necessary. I wonder if that, by itself, could
cause the behavior you're describing.
You can use "dumpsys alarm" in adb shell to see the actual alarms set in
the system, and verify that your code
Thank you for your reply but cal.getTimeInMillis() returns the right thing.
It has been
suggested before that this might be returning the wrong value but whenever I
attach
my device via USB cable I always see all alarms being set as you can see one
of them
below (others omitted). I regret that I ca
What does cal.getTimeInMillis() in the following statement return?
Maybe the problem is there.
alarmManager.set(AlarmManager.RTC_WAKEUP, cal.getTimeInMillis(),
pendingIntent);
I use the following statement while setting alarms:
this.am.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
SystemClock.elapsedR
On Wed, Jul 13, 2011 at 3:57 AM, Satya wrote:
> yes am referring to AlarmManager is there any way where i can stored this
> in my app?
>
I suppose you are free to track the alarms you've set on the AlarmManager.
Why purpose this would serve, I don't know.
---
thanks for replying
yes am referring to AlarmManager is there any way where i can stored
this in my app?
On Jul 13, 10:03 am, TreKing wrote:
> On Tue, Jul 12, 2011 at 10:51 PM, Satya wrote:
> > Can any one tell me how to get all previously set alarm list.
>
> If you're referring to the alarms se
Oops :-) I supposed to be till the device get Re-Boot.
2011/6/23 Károly Holczhauser
> Yahe :D five start :D
>
> On jún. 23, 16:24, Yahel wrote:
> > > Where I can use Alarm Service, looks like the schedule information will
> be
> > > persisted only till the device gets boot up.
> >
> > The drunk
Yahe :D five start :D
On jún. 23, 16:24, Yahel wrote:
> > Where I can use Alarm Service, looks like the schedule information will be
> > persisted only till the device gets boot up.
>
> The drunk coder from India strikes again :)
>
> If you wonder how these messages gets here :
>
> Prakash gets d
> Where I can use Alarm Service, looks like the schedule information will be
> persisted only till the device gets boot up.
The drunk coder from India strikes again :)
If you wonder how these messages gets here :
Prakash gets drunk, then comes home :
"My wife that B..ch.I'll have a boat one
Thank you, you answered all of my questions
On Dec 29, 10:52 am, Dianne Hackborn wrote:
> On Tue, Dec 28, 2010 at 11:56 PM, b_t wrote:
> > Hmm, so there is no possibility to display "real-time" information in
> > a widget? For example a compass widget?
>
> Correct, app widgets are not intended t
On Tue, Dec 28, 2010 at 11:56 PM, b_t wrote:
> Hmm, so there is no possibility to display "real-time" information in
> a widget? For example a compass widget?
>
Correct, app widgets are not intended to be continually refreshing.
> What is an acceptable refresh rate?
>
Less is better. For pol
Hmm, so there is no possibility to display "real-time" information in
a widget? For example a compass widget?
What is an acceptable refresh rate?
And the main question, why does the alarmmanager send alarms in sleep
mode
when I use RTC instead of RTC_WAKEUP?
Thanks
On Dec 29, 5:25 am, kernelpan
On Dec 28, 8:00 pm, Mark Murphy wrote:
> On Sat, Dec 25, 2010 at 3:54 PM, b_t wrote:
> > In an appwidget I declare a repeating alarm to refresh a widget in
> > every 10 seconds:
>
> Please don't.
yeah really - not on my phone you won't
--
You received this message because you are subscribed
That's really janky. I'd strongly recommend only posting one alarm, for the
next event you have in time, and upon processing that post a new alarm for
the following event. This is how most apps work. Your code here is really
problematic in how it manages its alarms -- for example if you have an
Thanks to all for your response,
I have solved that problem by passing unique id which is depend on
current time:-
final int intent_id= (int) System.currentTimeMillis();
PendingIntent pendingIntent =
PendingIntent.getBroadcast(getApplicationContext
Ecommerce and Shopping cart Web portal Solutions at
www.infocuswebdesigning.com
We offer complete web services like, web designing, web development, Flash
websites, Flash Intros, E-commerce sites (os commerce, zen cart
sites) and much more at very cheap cost. For More Details & completed
Projects
PendingIntent.FLAG* should help you.
On Aug 16, 12:44 pm, Kostya Vasilyev wrote:
> Setting an alarm cancels any previous alarms that have the same intent
> as the new one.
>
> In your code, the old and new intents only differ by their extras, which
> are not considered (I believe).
>
> What you
nomi wrote:
> Hi all,
>
> In my application i have created pending intent which calls another
> activity (after 20mins of alarm off) with the help of alarm manger. It
> should happen each time for each new pending intent or when I call
> that activity.
> But when i create one pending intent and a
Hi,
I found the culprit. My task was sublaunched using the
Intent.FLAG_ACTIVITY_NO_HISTORY. Clearing this flag solved the
problem.
cheers
guich
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to andro
Hello Guich,
Which phone are you testing your app on? Have you tested your app on
other phones as well?
Alarms do mess up on some phones.
On May 28, 9:41 am, guich wrote:
> Its not related. Well, i have no more ideas
>
> guich
--
You received this message because you are subscribed to the
Its not related. Well, i have no more ideas
guich
--
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
Hi,
I just found something in the logs that may help.
When the alarm is loaded or when a call is received, i see:
"couldn't save which view has focus because the focused view
totalcross.Launcher4A has no id"
How can i set an id to my view?
thx
guich
--
You received this message because y
Hi,
Thanks for the answer.
> Any time your activity isn't in the foreground, it may be removed from
> the stack if the system thinks it needs the resources.
Shouldn't the app be removed before the alarm is triggered? It doesn't
make sense for me that the app is removed after the alarm is gone. I
On May 28, 2:16 am, guich wrote:
> When the alarm is dismissed, my app receive the events onClose and
> onDestroy.
Any time your activity isn't in the foreground, it may be removed from
the stack if the system thinks it needs the resources. This is a
normal part of the activity lifecycle, and I
Can anyone on this mailing list help me out ??
On Fri, Apr 30, 2010 at 6:48 PM, Uander wrote:
> Hi All ,
>
> Issue I mentioned here works fine in cupcake android 1.5 .
> it refers to a OHA issue 3985:
>
>
> http://code.google.com/p/android/issues/detail?id=3985
>
> Please suggest how to fix it
Hi All ,
Issue I mentioned here works fine in cupcake android 1.5 .
it refers to a OHA issue 3985:
http://code.google.com/p/android/issues/detail?id=3985
Please suggest how to fix it .
in Alarms.java file , I used DateFormatSymbols(Locale.getDefault()) instead
of simple DateFormatSymbols() i
> I have the wake lock defined as a static member of the broadcast
> receiver. I think I lifted a bunch of code from an article that you
> wrote, so I am probably not needing the service. I guess I could just
> launch the application directly. Declaring the wake lock as a static
> member of the
Hi Mark,
I have the wake lock defined as a static member of the broadcast
receiver. I think I lifted a bunch of code from an article that you
wrote, so I am probably not needing the service. I guess I could just
launch the application directly. Declaring the wake lock as a static
member of the
I'll look into that, thanks for your input.
On Jan 15, 5:09 pm, Mark Murphy wrote:
> JimmyHoffa wrote:
> > Thanks Mark, I didnt realise that they need re-esablishing so that's
> > good to know.
>
> > I'm concerned whether the alarms can be removed individually, as in
> > the SDK it appears that
JimmyHoffa wrote:
> Thanks Mark, I didnt realise that they need re-esablishing so that's
> good to know.
>
> I'm concerned whether the alarms can be removed individually, as in
> the SDK it appears that they are removed by calling remove and passing
> in an Intent, which suggests, if one alarm is
Thanks Mark, I didnt realise that they need re-esablishing so that's
good to know.
I'm concerned whether the alarms can be removed individually, as in
the SDK it appears that they are removed by calling remove and passing
in an Intent, which suggests, if one alarm is removed, they all are
and ther
IF as mark told u need to use an alarm manager class,here is an
example:
Intent alrm_intent=new Intent(this,alarmreceiver.class);
/*alarmreceiver.class-->this is another class which receives the alarm
broadcast which we are going to broadcast*/
AlarmManager alm=(AlarmManager)getSystemService(A
no way there is ?
On Dec 18, 8:46 pm, Jags wrote:
> Now that i am able to successfully fire alarms, I need a case where if
> i delete a record in my db the corresponding alarm should be
> cancelled. i send recid which is primary key for my table with the
> pendingintent through putExtra. can i ca
Yeah the repercussions of neglecting wake locks is largely luck -- for
example it is not uncommon for the device to be synchronizing in the
background, or receiving data, or doing something else that holds its own
wake lock, allowing you to run, Also when plugged in to USB a wake lock is
held so t
Thanks, that clears things up. I guess I was somehow lucky that this
worked for me, maybe the device wasn't going back to sleep quickly
enough in my case. I'll implement the broadcast receiver and wakelock
to ensure this always works.
On Dec 18, 4:25 pm, Dianne Hackborn wrote:
> A wake lock is n
android:theme="@android:style/Theme.Dialog"
android:launchMode="singleTask" /
this worked ... :)
On Dec 17, 11:15 am, Jags wrote:
> or may be can I show an alertDalog from an intent ?
>
> On Dec 17, 8:41 am, Jags wrote:
>
> > nobody attempted it before ? how can i get t
or may be can I show an alertDalog from an intent ?
On Dec 17, 8:41 am, Jags wrote:
> nobody attempted it before ? how can i get the source code for alarm
> clock app ? is that in java for android ?
>
> On Dec 16, 10:06 pm, Jags wrote:
>
> > how is alarm clock showing its ui in android then ?
>
ok, i did it by starting an activity after the service.
Intent fireAlarm = new Intent(context,
AlarmActivity.class);
fireAlarm.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(fireAlarm);
but Can I make this wh
nobody attempted it before ? how can i get the source code for alarm
clock app ? is that in java for android ?
On Dec 16, 10:06 pm, Jags wrote:
> how is alarm clock showing its ui in android then ?
>
> little baffling though.
>
> On Dec 16, 10:35 pm, Jags wrote:
>
> > I dont understand even if m
how is alarm clock showing its ui in android then ?
little baffling though.
On Dec 16, 10:35 pm, Jags wrote:
> I dont understand even if my application is not gone to background or
> finished, still, the alert is not showing up !
>
> On Dec 16, 8:42 pm, Jags wrote:
>
> > well more surprise. toa
I dont understand even if my application is not gone to background or
finished, still, the alert is not showing up !
On Dec 16, 8:42 pm, Jags wrote:
> well more surprise. toast does not seem to work from AppService, but
> it works from OneTimeAlarmReceiver
>
> am i doing something stupid here ?
>
anybody there ? for the time being I will be better off just showing
an alert or at the very least a toast.
On Dec 16, 8:42 pm, Jags wrote:
> well more surprise. toast does not seem to work from AppService, but
> it works from OneTimeAlarmReceiver
>
> am i doing something stupid here ?
>
> On Dec
well more surprise. toast does not seem to work from AppService, but
it works from OneTimeAlarmReceiver
am i doing something stupid here ?
On Dec 16, 7:57 pm, Jags wrote:
> to help with a little code
>
>
>
> public class AppService extends WakefulIntentService {
>
to help with a little code
public class AppService extends WakefulIntentService {
public AppService() {
super("AppService");
}
private void showMePopup(Row rec) {
final FrameLayout fl = new FrameLayout(this);
Now that I am able to send an sms from inside AppService, I am unable
to show an alert upon an alarm.
i get the exception 12-16 19:41:37.890: DEBUG/RemindMe(5317): Unable
to add window -- token null is not for an application
am I not allowed to show alert in AppService ?
I understand Mark opined
Ok ! Now that I am able to fire up the alarm, how can I fire up the
alarm with a little more context ? Like for example, I want to have my
alarm give me a record id when it wakes me up ! How can I acheive that
in a broadcast receiver ?
regards
Jagat
On Dec 9, 7:14 pm, Jags wrote:
> very bad, bla
very bad, blackberry allows this but. this is where blackberry scored
better than android :)
On Dec 9, 5:10 pm, "Mark Murphy" wrote:
> > but it invokes the mail ui of android, cant I silenly send email as i
> > am sending sms ?
>
> Not unless you bundle in your own email JAR and use that. The onl
> but it invokes the mail ui of android, cant I silenly send email as i
> am sending sms ?
Not unless you bundle in your own email JAR and use that. The only
built-in ways to send emails in Android will involve user input.
--
Mark Murphy (a Commons Guy)
http://commonsware.com
Android App Develop
thanks i loked at your alarmmanager code to send sms from a separate
service, and bingo, it worked.
I need to send email similarly, i found this
http://www.vidyut.com/sunit/android/android_sendmail.html
but it invokes the mail ui of android, cant I silenly send email as i
am sending sms ?
regard
> aha what i can or cannot do from the broadcastreceiver ? I am
> trying to send an sms , and i get an exception
> android.app.ReceiverRestrictedContext !
That exception would suggest you cannot send an SMS from a
BroadcastReceiver. :-)
Seriously, I do not know if there is an official list of
aha what i can or cannot do from the broadcastreceiver ? I am
trying to send an sms , and i get an exception
android.app.ReceiverRestrictedContext !
public class OnetimeAlarmReceiver extends BroadcastReceiver {
private AlarmExample currentContext = null;
@Override
publ
> Now, that i m able to display this oast, how can I start my activity ?
> like the normal way we call one activity from another ?
I do not recommend starting an activity from a BroadcastReceiver or
Service. Users will get rather irritated if, in the middle of doing
something else, your activity
Now, that i m able to display this oast, how can I start my activity ?
like the normal way we call one activity from another ?
regards
On Dec 8, 8:25 pm, Jags wrote:
> hmm I was right at guessing that, i miss something in manifest. Thanks
> a lot
>
> i had to add this to have it worked
>
>
>
hmm I was right at guessing that, i miss something in manifest. Thanks
a lot
i had to add this to have it worked
regards
Jagat
On Dec 8, 8:01 pm, "Mark Murphy" wrote:
> > I was doing alarm manager and stuff.
>
> > i did like below
>
> > public class AlarmExample extends Activity {
> > pr
On Nov 18, 1:55 pm, Cédric Berger wrote:
> I meant not when the user requested it, but when the system went
> really too low on memory : as I understand the system may eventually
> have to kill some services (even if it is not a full "force stop") ?
> (And if not, what happens when it is reall
On Wed, Nov 18, 2009 at 22:45, Dianne Hackborn wrote:
> 2009/11/18 Cédric Berger
>> Are there situations where it is done by the system (automatically) ?
>> (ie. in case it is too low on memory).
>
> Nope, definitely never ever. The user must explicitly request this.
>
>>
>> Or can I be sure th
2009/11/18 Cédric Berger
> So now that (I think) I understand what this "force stop" is really
> about (completely and definitely stopping an app) :
>
> Are there situations where it is done by the system (automatically) ?
> (ie. in case it is too low on memory).
>
Nope, definitely never ever.
On Wed, Nov 18, 2009 at 18:53, Dianne Hackborn wrote:
> I'm not sure which UI you are talking about. The "force stop" button that
> has been around since 1.5 does everything we have been talking about:
> killing processes, unregistering alarms, etc. The new running services UI
> -only- stops a
On Wed, Nov 18, 2009 at 12:18 PM, jotobjects wrote:
> If the system is slow due to CPU contention then an Activity running
> in the background would also be part of the problem. If the system is
> low on memory the System can also kill Services. But I get it that
> too many Services thrashing h
On Nov 18, 9:53 am, Dianne Hackborn wrote:
> On Wed, Nov 18, 2009 at 8:27 AM, jotobjects wrote:
> > Don't you care just as much about Activities that have threads running
> > the background?
>
> No, the system can freely kill those processes when it needs memory. Thus
> this isn't the cause of
On Wed, Nov 18, 2009 at 8:27 AM, jotobjects wrote:
> Don't you care just as much about Activities that have threads running
> the background?
>
No, the system can freely kill those processes when it needs memory. Thus
this isn't the cause of the main problem, the overall system becoming slow
b
On Nov 17, 4:05 pm, Dianne Hackborn wrote:
> 2.0 includes a UI showing you which -services- are running and the resources
> they are using. This is what you really care about
Don't you care just as much about Activities that have threads running
the background?
Two more questions about all th
On Nov 17, 7:54 pm, String wrote:
> On Nov 17, 7:43 pm, Dianne Hackborn wrote:
>
> > I will probably make this API a no-op, since it violates the principle of
> > one app not being able to break another app
>
> +1
>
> Especially with the Running Services UI in 2.0, I'd suggest this is
> the bes
2009/11/17 Cédric Berger
> In fact if you can have more control in 2.0, this will just help to not
> have all this task killers used so blindlessly by everyone.
>
Unfortunately I think that is unlikely -- I can't count the number of places
I have seen on the web suggesting to people to install a
In fact if you can have more control in 2.0, this will just help to not have
all this task killers used so blindlessly by everyone.
So removing this API will be become less important. And this one still may
be usefull in some cases. Just have to be used more wisely.
thanks dianne for the explanati
On Nov 17, 7:43 pm, Dianne Hackborn wrote:
> I will probably make this API a no-op, since it violates the principle of
> one app not being able to break another app
+1
Especially with the Running Services UI in 2.0, I'd suggest this is
the best solution.
String
--
You received this message b
On Tue, Nov 17, 2009 at 4:55 PM, todd wrote:
> In
> our case our bg service only watches a particular directory waiting
> for new files to be added. It's not *running*, it's waiting. Users go
> off and kill our app then wonder why it doesn't work any more.
>
Are you saying you have a Service alw
Personally I would like to see this API go away. I'm finding we now
have to code around task killing applications, which shouldn't be the
case. Being a good Android citizen and following the rules, allowing
the OS to do the work it was designed to do is the way to go. Users
are confused when the ap
2.0 includes a UI showing you which -services- are running and the resources
they are using. This is what you really care about, not whatever random
processes are being kept around by the system in case it needs them later.
(Fwiw, the worst that can happen is a bad app sits there spinning the CPU
On Fri, Oct 16, 2009 at 00:07, Dianne Hackborn wrote:
> If you kill the process, it will not impact the alarms, the same as it won't
> impact notifications etc.
>
> What these programs are doing is using the API that is tended to force stop
> -everything- about the application: stop all services,
On Tue, Nov 17, 2009 at 11:41 AM, jotobjects wrote:
> Use Jason's solution. Also if the system kills the Process the
> system will later restart the Process if it had a Service running but
> it is up to the service to reset its own state.
>
Not when using this API, which kills -everything- abo
On Tue, Nov 17, 2009 at 11:36 AM, jotobjects wrote:
> On Oct 15, 3:07 pm, Dianne Hackborn wrote:
> > What these programs are doing is using the API that is tended to force
> stop
> > -everything- about the application: stop all services, cancel all alarms,
> > remove all notifications, etc. Thi
On Oct 13, 8:09 pm, EboMike wrote:
> Task killers aside, what about if the OS decides to stop a process
> because memory is low? Say an app has an alarm set to happen in 2
> hours, and the user decides to run Google Maps for a minute. Android
> might kill said app because memory runs low. Ten mi
That's not the purpose of this API, which is to allow the user to force stop
an application right now, immediately, I don't care what the damn app wants.
:}
There is a UI in 2.0 for the user to explicitly stop any currently running
services.
On Tue, Nov 17, 2009 at 5:15 AM, Bo wrote:
> I think
On Oct 15, 3:07 pm, Dianne Hackborn wrote:
> What these programs are doing is using the API that is tended to force stop
> -everything- about the application: stop all services, cancel all alarms,
> remove all notifications, etc. This is all working as intended, the apps
> are just abusing this
I think it would be nice if the to-be-killed/restarted apps/services
get a chance to say what it is doing. It's normal apps/services
obligation to provide such information; it's task manager apps
obligation to collect them and present to users.
Or make it a system service (may be some dialogs) to
If you kill the process, it will not impact the alarms, the same as it won't
impact notifications etc.
What these programs are doing is using the API that is tended to force stop
-everything- about the application: stop all services, cancel all alarms,
remove all notifications, etc. This is all w
When I use the method above. Even after I kill my app and service with
task manager my alarms still trigger. I believe its because the
AlarmManager service has been given a pending intent that will
relaunch my service which handles the alarms.
Both alarmmanager and the pending intent are allocat
On Oct 15, 4:34 pm, "Jason B." wrote:
> Using that approach works great for my app. That way it doesn't
> matter if my app ever gets killed. The alarm will trigger in the
> future and the intent will restart my service
I believe the point of this thread is that Task Killer apps will kill
all
I know this thread is talking a lot about task management. I think
the original post was about making alarms that still occur even if the
app is closed. This is how I do it:
1) Use AlarmManager service to schedule PendingIntents in the future
(I.e. xx min from now)
2) Creat an intent/PendingIn
On Tue, Oct 13, 2009 at 9:09 PM, EboMike wrote:
> Task killers aside, what about if the OS decides to stop a process
> because memory is low?
It doesn't do what these apps are doing. As I said, what these apps are
doing (especially the ones that do this stuff behind the user's back) is
abusing
1 - 100 of 123 matches
Mail list logo
