[android-developers] Random rare OOM errors
I have an app that very rarely throws this error or one like it. java.lang.OutOfMemoryError: array size too large(Heap Size=3395KB, Allocated=3065KB, Bitmap Size=0KB) -- look at that small heap or Caused by: java.lang.OutOfMemoryError: bitmap size exceeds VM budget (from the stacktrace on this, it seemed to be on initial view layout. Again, very rare) I do have some icons allocated(none are leaked), and when I run the app, the heap shown by DDMS never seems to grow very big(2-3 megs total). I even did a dumpsys meminfo and checked the native memory allocations. Nothing large or alarming. I've also never experienced the OOM myself in any sort of testing on various phones and the emulator. I saw the Google+ app crash once the same way on app launch on my Nexus S(I peeked at it's stack traces), so at least I'm in good company. It seems like there wasn't enough RAM at the time for the app allocation, and the foreground app died w/ an OOM instead of a background app being shutdown to free RAM. Has anyone else seen this? Robert -- 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] What exactly happens during an upgrade?
The problem is the upgrade process seems like it has some race conditions in it. Mostly things around resources being non-existent, even though they are definitely there in the drawable directory. Even more disconcerting is a stack trace that is in the old code, but is very definitely running a few pieces of new code at the same time. An example. I had a crash while accessing resources(that are definitely present) in a service. It was on a blank line in the new codebase, and matched up in the old. The crash was reported via ACRA, which sources its destination from the app's application class. In this particular upgrade, I changed the destination in the application class due to an acra upgrade.. So the old crash should have gone to the old destination, while new version crashes should goto the new place. However, I received a old version crash report at the new destination. It's not just ACRA through, I've received user reported crashes via the market with the same stacktraces with almost all the comments mentioning that it crashed right after they upgraded. On Sun, May 1, 2011 at 5:29 PM, Dianne Hackborn hack...@android.com wrote: Allowing applications to include any information is a really tricky subject. Even the stack crawls can been a concern -- for example there was an issues raised in the past about a health care about that could throw an exception that would have some user information in the exception message. People often don't realize just how complicated a lot of this stuff is outside of just writing some code and releasing it. On Sun, May 1, 2011 at 5:45 PM, TreKing treking...@gmail.com wrote: On Sun, May 1, 2011 at 4:14 PM, Dianne Hackborn hack...@android.com wrote: Just to be aware -- the logging information is pretty sensitive. Agreed. I should clarify - the logging information I collect is specifically for my own app, not the system log. In release mode I write to my own, internal log file and submit that if there is a crash. If I get a crash report and can't figure it out from the exception, I throw in some logging with the next update and am able to better investigate the problem next time it happens. After the issue is fixed, I just take out the logging for the next update. I do give the user the *option* to include the system log, though in retrospect I've never actually needed the extra information to fix any problems. We've found it hard enough to keep the platform and its apps clean about logging personal information (pretty much every release has had last-minute fixes for personal information being logged), and when you add in manufacturers and third party apps, it is just impossible. For example there was the manufacturer who released devices whose soft keyboard logged each key pressed, and it is just scary what one sees various third party apps. Agreed again. I've debugged some apps by viewing the LogCat while I run them and it's fairly absurd what some apps leave in release mode. There has also been significant pressure to do something stronger, such as not allow third party apps access to the logs at all or only to the data they have written to the log. I don't know if that will actually happen, but it is enough of a concern to be a possibility. That would be fantastic. If the system could direct each app's logs to it's own location and include only that to the developer in the Market console, it would be infinitely more useful. This is also why Android Feedback does not currently make the logs available, because of the kinds of personal information likely to be in them. Understood - but it does make them fairly unusable for all but the most obvious of crashes. This is why I opted for my own solution. I would never have identified and fixed the number of issues I have already by solely relying on the Market crash reports. (It also doesn't help that very few people actually report the issues and the ones that do provide little to no explanation). - TreKing - Chicago transit tracking app for Android-powered devices -- 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 -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups Android Developers group. To post to this group, send
Re: [android-developers] What exactly happens during an upgrade?
On Thu, Apr 28, 2011 at 12:39 AM, Robert Macaulay robert.macau...@gmail.com wrote: I have Acra in my app to report on crashes(I will be removing it in favor of the market one soon). Why would you move to a worse solution? Mainly for simplicity. One less thing to deal with. But I do like the new version(upgraded after posting) If that is what happens, how is the code being mingled at runtime? No idea - but I think many of us have seen strange, seemingly-impossible exceptions being generated after updates. There's definitely something wonky there. Glad then it's not just me. Wish I could protect better against it. Users do actually see the crash after upgrades because of these random events. -- 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] What exactly happens during an upgrade?
I have Acra in my app to report on crashes(I will be removing it in favor of the market one soon). I've recently changed the form that it posts to during an upgrade(so the new app version will post to the new form, the old version will remain on the old form). However, I've witnessed old code, throwing an exception about resources being null, being reported to the new form. Acra attaches an uncaughtException Handler to the application class. In this case, since I've switched destination forms, it implies that Android is replacing the code in place in the same process. The exceptions I get are in the old code, usually accessing resources from the context. An example is: onCreate() in my launch activity sets up a tab host. It assigns a selectorDrawable to the tab(an xml resource, referring to 2 valid png files, all in the drawable directory). It gets a ResourceNotFound Exception - stack trace at the end. The line numbers indicate it is being thrown in old code. However, the user has installed the new version since I see the exception on the new form. It seems that there is a race condition during upgrades where pieces of the old app are still around while the new one is being placed in. I've also seen very similar things in a Service that has an AsyncTask that gets the AppWidgetManager.getInstance(this). In this case, it throws an NPE in there - stack also at end.. In the end, a solution would be to enforce a new process for the new instance of the app. Is this possible? If that is what happens, how is the code being mingled at runtime? Could the user be launching my app while it is installing, and thus get pieces of the old one still? Thanks Robert Stack trace showing the tab host failure: Caused by: android.content.res.Resources$NotFoundException: File res/drawable/ic_tab_alert.xml from drawable resource ID #0x7f020010 at android.content.res.Resources.loadDrawable(Resources.java:1725) at android.content.res.Resources.getDrawable(Resources.java:590) at com.zomut.watchdog.library.Main.onCreate(Main.java:168) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2701) ... 11 more Caused by: java.lang.NullPointerException at android.graphics.drawable.DrawableContainer$DrawableContainerState.addChild(DrawableContainer.java:349) at android.graphics.drawable.StateListDrawable$StateListState.addStateSet(StateListDrawable.java:265) at android.graphics.drawable.StateListDrawable.inflate(StateListDrawable.java:173) at android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:796) at android.graphics.drawable.Drawable.createFromXml(Drawable.java:737) at android.content.res.Resources.loadDrawable(Resources.java:1722) ... 15 more Stack trace showing the AppWidget.getInstance() failure: java.lang.NullPointerException at android.appwidget.AppWidgetManager.init(AppWidgetManager.java:230) at android.appwidget.AppWidgetManager.getInstance(AppWidgetManager.java:221) -- 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] Null pointer in AppWidgetManager.getInstance()
I'm getting a null pointer in app widget manager. I believe it is when the user is upgrading the app while a background intent service is running, possibly right before the widget is updated. The background service updates a database and the appWidgets right before it terminates. This is from 2.2 java.lang.NullPointerException at android.appwidget.AppWidgetManager.init(AppWidgetManager.java:230) at android.appwidget.AppWidgetManager.getInstance(AppWidgetManager.java:221) I've looked at the code above, and it seems to be context.getResources.getSomething where it Null pointering. The context is non-null, since the getInstance was called with this. So its probably the resources being null at that point Is there a broadcast intent that I could catch to tell my intent service to shut down? The docs are a bit confusing in the PACKAGE_RESTART, PACKAGE_REMOVED, and PACKAGE_REPLACED usage. REPLACED seems to be sent to the new instance of the app only. Are any of these sent to the old version of the app prior to it being upgraded? Is Application.onDestroyed() guaranteed to be called on clean shutdown due to upgrade? I also get occasional database locked, also right around the time I release the update. Its probably caused by the same thing(old version running concurrently). Thanks! -- 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: Alarms after an update ?
The eclipse plugin denies the existence of the authority attribute.
No resource identifier found for attribute 'authority' in package 'android'
receiver android:name=.OnPackageChangeStarter
intent-filter
action android:name=android.intent.action.PACKAGE_REPLACED /
data android:scheme=package android:authority=your.package.name /
/intent-filter
/receiver
On Wed, Jun 30, 2010 at 11:35 AM, Dianne Hackborn hack...@android.com wrote:
You should use android:authority=your.package.name
On Thu, Jun 24, 2010 at 10:12 AM, Robert Macaulay
robert.macau...@gmail.com wrote:
On Thu, Jun 24, 2010 at 11:56 AM, mac-systems jens.h...@gmx.de wrote:
Ok, i thought i have to do this.
Is there any Intent which get broadcasted on update ? Or simlar
mechanism ?
You can add a receiver for PACKAGE_REPLACED
receiver android:name=.OnPackageChangeStarter
intent-filter
action
android:name=android.intent.action.PACKAGE_REPLACED /
!-- This doesn't work
data android:scheme=package
android:path=your.package.name /
--
/intent-filter
/receiver
and in the OnPackageChangeStarter, add an if
if(!
intent.getDataString().startsWith(package:your.package.name)){
return;
}
At least on 2.1 Droid, the intent.getData().getPath() portion of
the intent is null, so the intent-filter doesn't seem to work.
Including it gets my receiver called for every package change.
The package name is in the intent.getData().getSchemeSpecificPart()
Anyone know if this is a bug? Or is this the right way to accomplish this?
--
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
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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] Preferred mechanism for shared access to a Sqllite database.
My initial version of my app used sqlite databases directly, opening and closing on create/destroy. However, I received occasional crashes with the message database is locked. I looked into it, and found that sqlite databases really only can handle one writer at a time. I had converted my service to be alarmManager fired, which resulted in a service spawned thread interacting with the database along with the UI. I've converted to a contentProvider model of database access to see if this would help centralize my data access. The data is all private, and all but one table would make any sense to anyone else. I have a few questions: 1) Does Android create a singleton instance of the contentProvider on the phone? If its used externally, I assume there is just the single instance in my app process. 2) Are accesses to the content provider done in a means not requiring synchronization? If I have a UI performing queries while a service is performing updates, will I run into any database locked errors? The database accesses inside the provider will be done transactionally, so I'm not worried about partial reads. 3) Is a contentProvider overkill for this? Would a properly synchronized singleton provide the same safety from locked databases without the overhead? Is there much overhead for content providers? Thanks! -- 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: Alarms after an update ?
On Thu, Jun 24, 2010 at 11:56 AM, mac-systems jens.h...@gmx.de wrote:
Ok, i thought i have to do this.
Is there any Intent which get broadcasted on update ? Or simlar
mechanism ?
You can add a receiver for PACKAGE_REPLACED
receiver android:name=.OnPackageChangeStarter
intent-filter
action
android:name=android.intent.action.PACKAGE_REPLACED /
!-- This doesn't work
data android:scheme=package
android:path=your.package.name /
--
/intent-filter
/receiver
and in the OnPackageChangeStarter, add an if
if(!
intent.getDataString().startsWith(package:your.package.name)){
return;
}
At least on 2.1 Droid, the intent.getData().getPath() portion of
the intent is null, so the intent-filter doesn't seem to work.
Including it gets my receiver called for every package change.
The package name is in the intent.getData().getSchemeSpecificPart()
Anyone know if this is a bug? Or is this the right way to accomplish this?
--
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] AlarmManager ceasing to function. Dropping single shot alarms.
I swapped all the alarmManager set calls to setRepeating. The alarms have been working perfectly since. I just added code to deal with the extra alarms that get delivered on wakeup. -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
Well, the 10 ms check didn't help. dumpsys alarm just shows that it used to run, but nothing currently scheduled. I have no exceptions logged, and the reschedule is in a finally block. I'm going to try a setRepeating now to see if it manages to survive. -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
On Fri, Jun 18, 2010 at 1:57 PM, Mark Murphy mmur...@commonsware.comwrote: On Fri, Jun 18, 2010 at 2:54 PM, Robert Macaulay robert.macau...@gmail.com wrote: Well, the 10 ms check didn't help. dumpsys alarm just shows that it used to run, but nothing currently scheduled. I have no exceptions logged, and the reschedule is in a finally block. What is the approximate duration between your alarms (the ones you have been doing with set())? I'd like to take a shot at trying to reproduce your problem. Also, what device(s) are you testing this on? The device is a Moto Droid The current set logic is like this: X = uptimeMillis() The current interval is 2 minutes, ELAPSED, no wakeup. on the alarm intent, I attach 12(2 minutes), and X, set with FLAG_CANCEL_CURRENT to get the new extras pushed in. In non sleep case, I wake up, do a uptimeMillis(), assert it's been 95% of the desired poll time(12*.95 + X) and continue. At the end, it reschedules based on same logic The trick happens when the device is sleeping. If the CPU is off, the uptimeMillis() does not advance, I didn't want to wakeup. So when the alarm fires early(in awake time), I check the uptimeMillis() and see its been no where near the desired 2 minute sleep, and reset the alarm to the missing delta time - I added a ms = ms 10 ? 10 : ms; to ensure non-negative. For example X=0 uptimeMillis(); poll=12 schedule alarm wakeup(its been 2 minutes wall clock, the phone has been sleeping) Y = 1 uptimeMillis() This is 11 uptimeMillis early, so go back to sleep for 11ms I'm going to attach a file debug print to my scheduling operations and service operation cycle and see if I can get a log of the problem. Can I use setRepeating for the same logic? I see that it will deliver the same way as the set will, the thing that is not clear is when it will deliver the repeat. For example, if I schedule an alarm for now+120,000 with a 10,000 delay and the phone sleeps for 149,000 and wakes up, what will happen? Will the repeat happen in 10,000 ms from the delivery of the late alarm, or will it deliver it immediately after the late alarm is serviced? The docs seem to indicate it will hit the next interval. So if the late alarm is delivered seconds before the interval, you'd get 2 intents delivered back to back. Thanks -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
On Fri, Jun 18, 2010 at 2:39 PM, Mark Murphy mmur...@commonsware.comwrote: On Fri, Jun 18, 2010 at 3:35 PM, Robert Macaulay robert.macau...@gmail.com wrote: For example, if I schedule an alarm for now+120,000 with a 10,000 delay and the phone sleeps for 149,000 and wakes up, what will happen? Dunno. I've only used AlarmManager for _WAKEUP alarms. That's part of the reason why I was trying to determine your algorithm. I think I might know the problem. The service that is being scheduled is an IntentService. The code runs in the onHandleIntent. The onHandleIntent is surrounded by a Wakelock Can this be killed mid-stream? Am I making an incorrect assumption regarding its usage? -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
On Fri, Jun 18, 2010 at 3:34 PM, Mark Murphy mmur...@commonsware.com wrote: Well, Android could kill anything mid-stream by terminating your process, if it needs to reclaim memory. However, if your service is brand new (e.g., had been previously destroyed in your last poll cycle), that is unlikely. However, the device might fall asleep before onHandleIntent() gets invoked. Take a look at WakefulIntentService for some code to work around this: http://github.com/commonsguy/cwac-wakeful I actually need to submit you a bug on that. I had an underlocked error thrown from the wakeful intent service in the finally block. java.lang.RuntimeException: WakeLock under-locked But looking at the WakefulIntentService, this shouldn't be able to happen. I'm thinking this is possibly related to my problem. I actually don't mind if it sleeps between, as it SHOULD run on the next wakeup. Since I'm using single shot alarms, this is OK to happen, since the service will just continue running on next wakeup. My service is only interested in elapsed wake time, wall clock is irrelevant. I have the entrance and exit logging setup. There is no way out of the service without a finally block logging the exit. -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
On Fri, Jun 18, 2010 at 3:49 PM, Mark Murphy mmur...@commonsware.com wrote:
On Fri, Jun 18, 2010 at 4:41 PM, Robert Macaulay
robert.macau...@gmail.com wrote:
I actually need to submit you a bug on that. I had an underlocked
error thrown from the wakeful intent service in the finally block.
java.lang.RuntimeException: WakeLock under-locked
But looking at the WakefulIntentService, this shouldn't be able to
happen.
I made a patch that addressed this issue a few weeks ago, when
somebody brought it to my attention.
I reproduced it. Its not a thread death
The code looks like this(pseudo code)
try{
print Runtime
if(!valid)
print NotValid;
return;
}
print Valid Run
Do stuff
}finally{
print end
schedule alarm
print rescheduled for 12
}
The last output was:
18:11:15 RunTime
18:11:15 Valid run
18:11:15 end
18:11:15 rescheduled for 12
So the alarm is being set for 12ms in the future and never running
again. Seems to be an AlarmManager bug. Going to be tricky to
reproduce it for a bug report. In the meantime, I'm thinking of
swapping to either a WAKEUP alarm, or a repeating one. WAKEUP will be
the most compatible change, but slightly less efficient.
It is definitely is related to device sleep related sleep though. Wish
there was more info I could gather.
--
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] The linked program is no longer installed on the phone
Someone upgraded my app, and receive this message The linked program is no longer installed on the phone What did I do wrong to cause this? The app and the upgrade were signed with the same key as far as I know. Some of the builds were on a linux machine, and other were on Windows. Could that cause this message? Thanks -- 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: The linked program is no longer installed on the phone
On Thu, Jun 17, 2010 at 7:58 PM, Robert Macaulay robert.macau...@gmail.comwrote: Someone upgraded my app, and receive this message The linked program is no longer installed on the phone Google results with your phone subbed for the phone seem to indicate it's a SenseUI problem. So it seems this is not relevant. Thansk -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
I recently converted my long lived service(setForeground) app to one triggered by the AlarmManager. The nature of the work is I want to be woken up on intervals, but do not want to wake up the phone if it's not awake. And I don't want the duplicate alarms that you'd get with setRepeating. So according to the docs, the best way was to reschedule yourself each time with set. The call I'm making is this PendingIntent pi=PendingIntent.getBroadcast(this, 0, i, PendingIntent.FLAG_CANCEL_CURRENT); mgr.set(AlarmManager.ELAPSED_REALTIME, SystemClock.elapsedRealtime()+msTillNext,pi); I'm using CANCEL_CURRENT because I am encoding setExtra data in the intent that is different for each call. Its waking an IntentService(specifically Mark's WakefulIntentService) This works, I see my app run over and over. I see my app being killed, and respawned via alarmReceiver. This all works great, but it randomly ceases. No exceptions in the log. I luckily have the log showing the last running of the service. The service runs, exits cleanly, and never runs again. I originally thought it could be that my msTillNext was negative, but the docs say that if the time is in the past, it will run immediately. It is a moto droid, running 2.1. Any suggestions? I'm about to write an alarm watchdog alarm to reschedule. or use setRepeating and store something in the DB to notice the dupes. Thanks -- 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] AlarmManager ceasing to function. Dropping single shot alarms.
On Wed, Jun 16, 2010 at 8:43 PM, Mark Murphy mmur...@commonsware.comwrote:
On Wed, Jun 16, 2010 at 9:23 PM, Robert Macaulay
robert.macau...@gmail.com wrote:
This works, I see my app run over and over. I see my app being killed,
and
respawned via alarmReceiver. This all works great, but it randomly
ceases.
No exceptions in the log. I luckily have the log showing the last running
of
the service. The service runs, exits cleanly, and never runs again. I
originally thought it could be that my msTillNext was negative, but the
docs
say that if the time is in the past, it will run immediately.
You may want to test that anyway. For example, make sure that
msTillNext is at least, say, 10, rather than smaller or negative. It
wouldn't be the first time that the docs were wrong, and it shouldn't
have any material impact on your actual app functionality.
I'll add that check. The only reason I didn't was the javadoc. It does seem
to happen when the phone is sleeping, and my code is woken up early. I'd
LOVE an alarm based on SystemClock.uptimeMillis(). It would make my logic
port from a Thread.sleep() easy.
You could try adb shell dumpsys. Redirect the output to a file, then
look for the line starting with:
DUMP OF SERVICE alarm:
You may see signs of your alarms in there. See if you can determine
any patterns of what the dump looks like when the next alarm will
succeed versus when it will fail.
What does the numbers in Alarm stats mean here? I'm assuming its the alarm
count totals, but not sure on the time or the flg parts.
From a failed state.
Nothing under Elapsed realtime wakeup
Alarm Stats:
51759ms running, 0 wakeups
142 alarms: flg=0x4
--
restarted the alarms, working state
under Elapsed realtime wakeup
ELAPSED #1: Alarm{454d4188 type 3 com.zomut.watchdoglite}
type=3 when=156397679 repeatInterval=0 count=0
operation=PendingIntent{454d4178: PendingIntentRecord{454d4100
com.zomut.watchdoglite broadcastIntent}}
Alarm Stats:
com.zomut.watchdoglite
51813ms running, 0 wakeups
144 alarms: flg=0x4
--
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: Service gets killed (due to activity ?)
On Thu, Jun 10, 2010 at 7:20 PM, Mark Murphy mmur...@commonsware.comwrote: Generally speaking, your goal is to not have your code run and not have your code be in memory. The more your code runs, the more battery you consume. The more memory you take up, the more difficult it is for other applications to run. And, as Ms. Hackborn mentioned, your service will eventually be destroyed, anyway. The best way to do polling operations in Android is to use the AlarmManager and an IntentService. However, that does not work well with interfaces where you have to register listeners, such as SensorManager. I'm restructuring my app now to get rid of my persistent service. Initially due to users asking for the notification icon to be removed, followed by my own desire to get out of RAM, then reading Mark's articles. I have the onBoot receiver schedule the alarmManager. How do you schedule the alarm prior to the first boot? I could schedule it on activity launch, but it would do it for every launch - even after it successfully scheduled on a boot. My initial idea is a preference for first run, so I know I'd need to schedule it. But that would be destroyed by a task killer. The other idea is a last run date that the activity could check but that would be vulnerable to race conditions. Am I missing the list alarms method? Thanks -- 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] about making charts in android
On Mon, Jun 14, 2010 at 4:06 PM, Jose Luis Montes jlmont...@gmail.comwrote: I want to make some statistical charts in my android app and I dont know how to do them or what technology or library I can use. I have seen aiCharts ( http://www.artfulbits.com/android/aicharts.aspx ) but it is not free software (it's a payment solution) so I cannot use it. My goal is making free apps and I have no money for this. I ran into this library yesterday. Haven't even looked much at it, but marked it for later review. http://achartengine.org/ http://achartengine.org/ -- 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
