Oh. I wonder where could be the problem. One possible location could be in my AndroidManifest.xml. Here is how it looks like :
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android"; package="com.smartaddress"> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> <application android:icon="@drawable/icon"> <activity android:name=".SearchMap" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <receiver android:name=".BootCompletedIntentReceiver"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <category android:name="android.intent.category.HOME" /> </intent-filter> </receiver> </application> </manifest> Do you think this is ok ? On Wed, Jul 16, 2008 at 5:56 AM, hackbod <[EMAIL PROTECTED]> wrote: > > It is not an issue I am aware of. That facility is used extensively > by our own apps, and I don't know of them having a problem with it. > > On Jul 15, 3:01 am, "Jaikishan Jalan" <[EMAIL PROTECTED]> wrote: > > Hello, > > > > As I mentioned in my last email about the random behavior of my > application, > > I have observed that my application many times does not receive > > BOOT_COMPLETED action. Due to this my background process does not get > > started. Is this a known bug that it is not definite that your > > intentreceiver (listening to BOOT_COMPLETED) will not get executed > everytime > > when you launch the emulator? I have verified this by simply printing a > log > > message. Sometimes the message is logged ( when my application receive > the > > intent ) and many times it does not. Can anyone from Google Android team > > confirm this? > > > > > > > > On Tue, Jul 15, 2008 at 3:21 PM, hackbod <[EMAIL PROTECTED]> wrote: > > > > > On Jul 14, 6:31 pm, Mark Murphy <[EMAIL PROTECTED]> wrote: > > > > To make sure I'm interpreting this correctly...the IntentReceiver > that > > > > is the recipient of the Intents raised by the AlarmManager must be > one > > > > registered in AndroidManifest.xml (vs. one registered via > > > > registerReceiver()), or else it will fall out of memory if/when the > > > > service does. And at that point, the AlarmManager is (presumably) > still > > > > set up to send Intents to a non-existent IntentReceiver. > > > > > Yep. So it will just broadcast the Intent, there will be nobody > > > around to receive it, and *poof* that is the end of it. > > > > > > I hadn't thought that all the way through, but it makes sense. That's > a > > > > facet of top-level IntentReceivers that I hadn't appreciated -- > they're > > > > "wired into" the Android runtime in such a way that they're always > > > > registered, regardless of memory conditions. > > > > > Yep, this is one of the key uses of receivers, they allow your > > > application to declare events it is interested in finding out about > > > even when it is not running. (Also they are a little cleaner to use > > > with the alarm manager, since because they are published in the > > > manifest, they are associated with an actual component, so the Intent > > > you make can be explicitly targeted at that component rather than > > > defining an ad-hoc action name.) > > > > > > Question: for Jaikishan's scenario, does he need the service? In > other > > > > words, does the IntentReceiver that handles Intents from the > > > > AlarmManager have any particular speed requirement? I was under the > > > > impression that IntentReceivers tied to activities might run on the > UI > > > > thread and so had to get their task done quickly...but will an > > > > AlarmManager-triggered IntentReceiver have that same limitation? Or > can > > > > it do some network I/O and such before returning from > onReceiveIntent(), > > > > without impacting any foreground activity? > > > > > The onReceive() function does run on the main thread, so you can't > > > spend a lot of time in it. Currently, even if your main thread is not > > > being asked to do other things like handle input events, if the > > > receiver takes more than 10 seconds then the user will get an > > > Application Not Responding dialog. So if you are going to do a longer- > > > running (or asynchronous) thing, you will need to have that wrapped in > > > a service. Of course networking stuff definitely falls in this > > > category. > > > > > > I'm just trying to figure out the right pattern for this case. I > don't > > > > think it's a stretch to say that a fair number of Android apps will > be > > > > of the poll-network-for-changes-and-do-something pattern, and so this > is > > > > an important area for us to get a best practice down pat. > > > > > The "Alarm Service" sample code in ApiDemos at > > > > >http://code.google.com/android/samples/ApiDemos/src/com/google/androi. > .. > > > is intended to provide the best practices for this. The current > > > example is a little overly complex because of the need of the > > > intermediate receiver. In a future SDK where you can have the alarm > > > manager directly start a service, this is a lot cleaner. > > > > > > Heck, I'm > > > > hoping we'll work up a common service or something, where activities > can > > > > register URLs to be polled and Intents to be fired if/when those > > > > documents change, so we can optimize network access and minimize > battery > > > > consumption. > > > > > Yeah this would be a useful facility. > > > > -- > > Thanks, > > Jaikishan > > > -- Thanks, Jaikishan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
