अलार्म शेड्यूल करें

अलार्म में ये सुविधाएं होती हैं:

• इनकी मदद से, सेट किए गए समय और/या इंटरवल पर इंटेंट ट्रिगर किए जा सकते हैं.

• ब्रॉडकास्ट रिसीवर के साथ इनका इस्तेमाल करके, अन्य कार्रवाइयां करने के लिए जॉब या WorkRequests को शेड्यूल किया जा सकता है.

• ये आपके ऐप्लिकेशन के बाहर काम करते हैं. इसलिए, इनका इस्तेमाल करके इवेंट या कार्रवाइयां ट्रिगर की जा सकती हैं. भले ही, आपका ऐप्लिकेशन न चल रहा हो और डिवाइस स्लीप मोड में हो.

• इनकी मदद से, ऐप्लिकेशन के लिए ज़रूरी संसाधनों को कम किया जा सकता है. टाइमर या लगातार चलने वाली सेवाओं पर निर्भर हुए बिना, कार्रवाइयां शेड्यूल की जा सकती हैं.

अनुमानित समय पर बजने वाला अलार्म सेट करना

जब कोई ऐप्लिकेशन अलार्म के लिए सटीक समय सेट नहीं करता, तो सिस्टम आने वाले समय में किसी समय अलार्म को ट्रिगर करता है. इनऐक्ज़ैक्ट अलार्म, अलार्म बजने के समय के बारे में कुछ गारंटी देते हैं. साथ ही, ये बैटरी बचाने से जुड़ी पाबंदियों का पालन करते हैं. जैसे, बैटरी बचाएं.

डेवलपर, एपीआई की इन गारंटी का इस्तेमाल करके, अलार्म बजने के समय को अपनी ज़रूरत के हिसाब से सेट कर सकते हैं.

किसी तय समय के बाद अलार्म बजाना

अगर आपका ऐप्लिकेशन set(), setInexactRepeating() या setAndAllowWhileIdle() को कॉल करता है, तो अलार्म, ट्रिगर के लिए सेट किए गए समय से पहले कभी नहीं बजता.

Android 12 (एपीआई लेवल 31) और इसके बाद के वर्शन पर, सिस्टम अलार्म को दिए गए ट्रिगर समय के एक घंटे के अंदर शुरू करता है. हालांकि, ऐसा तब होता है, जब बैटरी की बचत से जुड़ी कोई पाबंदी लागू न हो. जैसे, बैटरी सेवर या बैटरी बचाएं.

किसी समयावधि के दौरान अलार्म बजाना

अगर आपका ऐप्लिकेशन setWindow() को कॉल करता है, तो अलार्म कभी भी ट्रिगर होने के लिए सेट किए गए समय से पहले नहीं बजेगा. अगर बैटरी बचाने से जुड़ी कोई पाबंदी लागू नहीं है, तो अलार्म को तय की गई समयसीमा के अंदर ट्रिगर किया जाता है. यह समयसीमा, ट्रिगर के लिए दिए गए समय से शुरू होती है.

अगर आपका ऐप्लिकेशन Android 12 या इसके बाद के वर्शन को टारगेट करता है, तो सिस्टम, टाइम-विंडो वाले इनएग्ज़ैक्ट अलार्म को ट्रिगर करने में कम से कम 10 मिनट की देरी कर सकता है. इस वजह से, 600000 के तहत windowLengthMillis पैरामीटर वैल्यू को आम तौर पर 600000 पर क्लिप किया जाता है. सिस्टम, छोटे विंडो को भी शामिल कर सकता है. खास तौर पर, तब जब अलार्म को आने वाले समय में ट्रिगर करने के लिए शेड्यूल किया गया हो.

नियमित अंतराल पर बार-बार बजने वाला अलार्म सेट करना

अगर आपका ऐप्लिकेशन setInexactRepeating() को कॉल करता है, तो सिस्टम कई अलार्म ट्रिगर करता है:

1. पहला अलार्म, तय की गई समयावधि के अंदर बजता है. यह समयावधि, ट्रिगर के लिए तय किए गए समय से शुरू होती है.
2. आम तौर पर, इसके बाद के अलार्म, तय की गई समयावधि बीत जाने के बाद बजते हैं. अलार्म के लगातार दो बार बजने के बीच का समय अलग-अलग हो सकता है.

एग्ज़ैक्ट अलार्म सेट करना

सिस्टम, आने वाले समय में किसी तय समय पर एग्ज़ैक्ट अलार्म को ट्रिगर करता है.

ज़्यादातर ऐप्लिकेशन, अनुमानित अलार्म का इस्तेमाल करके, टास्क और इवेंट शेड्यूल कर सकते हैं. इससे इस्तेमाल के कई सामान्य उदाहरण पूरे किए जा सकते हैं. अगर आपके ऐप्लिकेशन का मुख्य फ़ंक्शन, एग्ज़ैक्ट अलार्म पर निर्भर करता है, तो एग्ज़ैक्ट अलार्म का इस्तेमाल किया जा सकता है. जैसे, अलार्म क्लॉक ऐप्लिकेशन या कैलेंडर ऐप्लिकेशन.

इस्तेमाल के ऐसे उदाहरण जिनमें एग्ज़ैक्ट अलार्म की ज़रूरत नहीं होती

यहां उन सामान्य वर्कफ़्लो की सूची दी गई है जिनके लिए एग्ज़ैक्ट अलार्म की ज़रूरत नहीं होती:

ऐप्लिकेशन के लाइफ़टाइम के दौरान, टाइमिंग ऑपरेशन शेड्यूल करना

Handler क्लास में, टाइमिंग से जुड़े ऑपरेशन को मैनेज करने के कई अच्छे तरीके शामिल हैं. जैसे, ऐप्लिकेशन के चालू रहने के दौरान, हर n सेकंड में कुछ काम करना: postAtTime() और postDelayed(). ध्यान दें कि ये एपीआई, सिस्टम के सक्रिय समय पर निर्भर करते हैं, न कि रीयल-टाइम पर.

बैकग्राउंड में होने वाले शेड्यूल किए गए काम, जैसे कि आपके ऐप्लिकेशन को अपडेट करना और लॉग अपलोड करना

WorkManager, समय के हिसाब से संवेदनशील और समय-समय पर होने वाले काम को शेड्यूल करने का तरीका उपलब्ध कराता है. flexInterval (कम से कम 15 मिनट) और रिपीट इंटरवल की वैल्यू देकर, टास्क के रनटाइम को बारीकी से तय किया जा सकता है.

उपयोगकर्ता की ओर से तय की गई कार्रवाई, जो किसी खास समय के बाद होनी चाहिए. भले ही, सिस्टम कुछ समय से इस्तेमाल न किया जा रहा हो

अनुमानित समय वाले अलार्म का इस्तेमाल करें. खास तौर पर, setAndAllowWhileIdle() पर कॉल करें.

उपयोगकर्ता की ओर से तय की गई कार्रवाई, जो किसी खास समय के बाद होनी चाहिए

अनुमानित समय वाले अलार्म का इस्तेमाल करें. खास तौर पर, set() पर कॉल करें.

उपयोगकर्ता की ओर से तय की गई कार्रवाई, जो तय की गई समयावधि में हो सकती है

अनुमानित समय वाले अलार्म का इस्तेमाल करें. खास तौर पर, setWindow() पर कॉल करें. ध्यान दें कि अगर आपका ऐप्लिकेशन Android 12 या इसके बाद के वर्शन को टारगेट करता है, तो विंडो की कम से कम अवधि 10 मिनट होनी चाहिए.

एग्ज़ैक्ट अलार्म सेट करने के तरीके

आपका ऐप्लिकेशन, इनमें से किसी एक तरीके का इस्तेमाल करके एग्ज़ैक्ट अलार्म सेट कर सकता है. इन तरीकों को इस तरह से क्रम में लगाया गया है कि सूची में सबसे नीचे मौजूद तरीके, ज़्यादा समय लेने वाले टास्क को पूरा करते हैं. हालांकि, इनके लिए सिस्टम के ज़्यादा संसाधनों की ज़रूरत होती है.

setExact()

आने वाले समय में, अलार्म को करीब-करीब सटीक समय पर ट्रिगर करना. हालांकि, ऐसा तब ही होगा, जब बैटरी बचाने के अन्य तरीके लागू न हों.

एग्ज़ैक्ट अलार्म सेट करने के लिए, इस तरीके का इस्तेमाल करें. हालांकि, अगर आपके ऐप्लिकेशन का काम उपयोगकर्ता के लिए समय के हिसाब से ज़रूरी है, तो इस तरीके का इस्तेमाल न करें.

setExactAndAllowWhileIdle()

आने वाले समय में, अलार्म को करीब-करीब सटीक समय पर ट्रिगर करना. भले ही, बैटरी बचाने की सुविधा चालू हो.

setAlarmClock()

आने वाले समय में किसी सटीक समय पर अलार्म ट्रिगर करना. ये अलार्म, उपयोगकर्ताओं को साफ़ तौर पर दिखते हैं. इसलिए, सिस्टम इनके ट्रिगर होने के समय में कभी बदलाव नहीं करता. सिस्टम, इन अलार्म को सबसे ज़रूरी अलार्म के तौर पर पहचानता है. साथ ही, अलार्म बजाने के लिए, ज़रूरत पड़ने पर बैटरी बचाने वाले मोड को बंद कर देता है.

सिस्टम के संसाधनों का इस्तेमाल

जब सिस्टम आपके ऐप्लिकेशन से सेट किए गए एग्ज़ैक्ट अलार्म ट्रिगर करता है, तो डिवाइस बैटरी लाइफ़ जैसे कई संसाधनों का इस्तेमाल करता है. ऐसा खास तौर पर तब होता है, जब डिवाइस बैटरी सेव करने वाले मोड में हो. इसके अलावा, सिस्टम इन अनुरोधों को आसानी से बैच नहीं कर सकता, ताकि संसाधनों का ज़्यादा बेहतर तरीके से इस्तेमाल किया जा सके.

हमारा सुझाव है कि जब भी संभव हो, तय समय से थोड़ा आगे-पीछे बजने वाला अलार्म सेट करें. ज़्यादा समय तक चलने वाले काम को शेड्यूल करने के लिए, अपने अलार्म के BroadcastReceiver से WorkManager या JobScheduler का इस्तेमाल करें. जब डिवाइस बैटरी बचाने वाले मोड में हो, तब काम करने के लिए, setAndAllowWhileIdle() का इस्तेमाल करके अनुमानित समय वाला अलार्म बनाएं. इसके बाद, अलार्म से कोई काम शुरू करें.

एग्ज़ैक्ट अलार्म की सही अनुमति का एलान करना

अगर आपका ऐप्लिकेशन Android 12 या इसके बाद के वर्शन को टारगेट करता है, तो आपको "अलार्म और रिमाइंडर" के लिए खास ऐप्लिकेशन ऐक्सेस की अनुमति लेनी होगी. इसके लिए, अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में SCHEDULE_EXACT_ALARM की अनुमति का एलान करें. इसके बारे में यहां दिए गए कोड स्निपेट में बताया गया है:

<manifest ...>
    <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

अगर आपका ऐप्लिकेशन Android 13 (एपीआई लेवल 33) या इसके बाद के वर्शन को टारगेट करता है, तो आपके पास SCHEDULE_EXACT_ALARM या USE_EXACT_ALARM अनुमति का एलान करने का विकल्प होता है.

<manifest ...>
    <uses-permission android:name="android.permission.USE_EXACT_ALARM"/>
    <application ...>
        ...
    </application>
</manifest>

SCHEDULE_EXACT_ALARM और USE_EXACT_ALARM, दोनों अनुमतियां एक जैसी सुविधाएं देती हैं. हालांकि, इन्हें अलग-अलग तरीके से दिया जाता है और ये अलग-अलग कामों के लिए इस्तेमाल की जाती हैं. आपके ऐप्लिकेशन को एग्ज़ैक्ट अलार्म का इस्तेमाल करना चाहिए. साथ ही, SCHEDULE_EXACT_ALARM या USE_EXACT_ALARM अनुमति का एलान सिर्फ़ तब करना चाहिए, जब आपके ऐप्लिकेशन में उपयोगकर्ता के लिए उपलब्ध किसी फ़ंक्शन को सटीक समय पर कार्रवाई करने की ज़रूरत हो.

USE_EXACT_ALARM

• अपने-आप मिली अनुमति
• उपयोगकर्ता इसे रद्द नहीं कर सकता
• Google Play की आने वाली नीति के मुताबिक
• इस्तेमाल के सीमित उदाहरण

SCHEDULE_EXACT_ALARM

• उपयोगकर्ता ने अनुमति दी है
• इस्तेमाल के ज़्यादा उदाहरण
• ऐप्लिकेशन को यह पुष्टि करनी चाहिए कि अनुमति वापस नहीं ली गई है

Android 13 (एपीआई लेवल 33) और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को पहली बार इंस्टॉल करने पर, SCHEDULE_EXACT_ALARM की अनुमति पहले से नहीं दी जाती है. अगर कोई उपयोगकर्ता बैकअप और रीस्टोर की प्रोसेस के ज़रिए, Android 14 वाले डिवाइस पर ऐप्लिकेशन का डेटा ट्रांसफ़र करता है, तो नए डिवाइस पर SCHEDULE_EXACT_ALARM की अनुमति नहीं दी जाएगी. हालांकि, अगर किसी मौजूदा ऐप्लिकेशन के पास पहले से ही यह अनुमति है, तो डिवाइस को Android 14 पर अपग्रेड करने पर, उसे यह अनुमति पहले से ही मिल जाएगी.

ध्यान दें: अगर एग्ज़ैक्ट अलार्म को सेट करने के लिए, OnAlarmListener ऑब्जेक्ट का इस्तेमाल किया जाता है, जैसे कि setExact एपीआई के साथ, तो SCHEDULE_EXACT_ALARM अनुमति की ज़रूरत नहीं होती.

SCHEDULE_EXACT_ALARM अनुमति का इस्तेमाल करना

USE_EXACT_ALARM के उलट, SCHEDULE_EXACT_ALARM अनुमति उपयोगकर्ता को मैन्युअल रूप से देनी होती है. उपयोगकर्ता और सिस्टम, दोनों ही SCHEDULE_EXACT_ALARM की अनुमति को रद्द कर सकते हैं.

यह देखने के लिए कि आपके ऐप्लिकेशन को अनुमति दी गई है या नहीं, एग्ज़ैक्ट अलार्म सेट करने से पहले, canScheduleExactAlarms() को कॉल करें. जब आपके ऐप्लिकेशन के लिए SCHEDULE_EXACT_ALARM की अनुमति वापस ले ली जाती है, तो आपका ऐप्लिकेशन काम करना बंद कर देता है. साथ ही, आने वाले समय के लिए सेट किए गए सभी एग्ज़ैक्ट अलार्म रद्द कर दिए जाते हैं. इसका मतलब यह भी है कि canScheduleExactAlarms() से मिली वैल्यू, आपके ऐप्लिकेशन की पूरी लाइफ़साइकल के दौरान मान्य रहती है.

जब आपके ऐप्लिकेशन को SCHEDULE_EXACT_ALARMS की अनुमति मिल जाती है, तो सिस्टम उसे ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED ब्रॉडकास्ट भेजता है. आपके ऐप्लिकेशन को ब्रॉडकास्ट रिसीवर लागू करना चाहिए, जो ये काम करता है:

1. इससे यह पुष्टि होती है कि आपके ऐप्लिकेशन के पास अब भी खास ऐप्लिकेशन ऐक्सेस है. ऐसा करने के लिए, canScheduleExactAlarms() को कॉल करें. इस जांच से आपके ऐप्लिकेशन को उस स्थिति से सुरक्षा मिलती है जिसमें उपयोगकर्ता आपके ऐप्लिकेशन को अनुमति देता है और फिर तुरंत उसे वापस ले लेता है.
2. आपके ऐप्लिकेशन की मौजूदा स्थिति के आधार पर, उन सभी एग्ज़ैक्ट अलार्म को फिर से शेड्यूल करता है जिनकी आपके ऐप्लिकेशन को ज़रूरत है. यह लॉजिक, आपके ऐप्लिकेशन के ACTION_BOOT_COMPLETED ब्रॉडकास्ट मिलने पर की जाने वाली कार्रवाई से मिलता-जुलता होना चाहिए.

उपयोगकर्ताओं से SCHEDULE_EXACT_ALARM की अनुमति देने के लिए कहें

अगर ज़रूरी हो, तो उपयोगकर्ताओं को सिस्टम सेटिंग में मौजूद अलार्म और रिमाइंडर स्क्रीन पर भेजा जा सकता है. पहली इमेज में यह दिखाया गया है. ऐसा करने के लिए, यह तरीका अपनाएं:

1. अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में, उपयोगकर्ता को बताएं कि आपके ऐप्लिकेशन को एग्ज़ैक्ट अलार्म शेड्यूल करने की ज़रूरत क्यों है.
2. ऐसा इंटेंट शुरू करें जिसमें ACTION_REQUEST_SCHEDULE_EXACT_ALARM इंटेंट ऐक्शन शामिल हो.

बार-बार बजने वाला अलार्म सेट करना

दोहराए जाने वाले अलार्म की मदद से, सिस्टम आपके ऐप्लिकेशन को बार-बार शेड्यूल के हिसाब से सूचना दे सकता है.

खराब तरीके से डिज़ाइन किए गए अलार्म की वजह से, बैटरी जल्दी खत्म हो सकती है. साथ ही, सर्वर पर ज़्यादा लोड पड़ सकता है. इस वजह से, Android 4.4 (एपीआई लेवल 19) और इसके बाद के वर्शन पर, बार-बार बजने वाले सभी अलार्म, इनएग्ज़ैक्ट अलार्म होते हैं.

बार-बार बजने वाले अलार्म की ये विशेषताएं होती हैं:

• अलार्म का टाइप. ज़्यादा जानकारी के लिए, अलार्म का टाइप चुनना लेख पढ़ें.

• ट्रिगर का समय. अगर आपने ट्रिगर का जो समय तय किया है वह बीत चुका है, तो अलार्म तुरंत ट्रिगर हो जाता है.

• अलार्म का इंटरवल. उदाहरण के लिए, दिन में एक बार, हर घंटे या हर पांच मिनट में.

• एक पेंडिंग इंटेंट, जो अलार्म ट्रिगर होने पर फ़ायर होता है. जब एक ही पेंडिंग इंटेंट का इस्तेमाल करने वाला दूसरा अलार्म सेट किया जाता है, तो वह ओरिजनल अलार्म की जगह ले लेता है.

PendingIntent() को रद्द करने के लिए, FLAG_NO_CREATE को PendingIntent.getService() में पास करें, ताकि इंटेंट का इंस्टेंस (अगर मौजूद हो) मिल सके. इसके बाद, उस इंटेंट को AlarmManager.cancel() में पास करें

val alarmManager =
    context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager
val pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE)
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent)
}

AlarmManager alarmManager =
    (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
PendingIntent pendingIntent =
    PendingIntent.getService(context, requestId, intent,
                                PendingIntent.FLAG_NO_CREATE);
if (pendingIntent != null && alarmManager != null) {
  alarmManager.cancel(pendingIntent);
}

अलार्म का टाइप चुनें

बार-बार बजने वाले अलार्म का इस्तेमाल करते समय, सबसे पहले यह तय करना ज़रूरी है कि वह किस तरह का होना चाहिए.

अलार्म के लिए, आम तौर पर दो तरह की घड़ियां होती हैं: "बीता हुआ रीयल टाइम" और "रीयल टाइम क्लॉक" (आरटीसी). बीता हुआ रीयल टाइम, "सिस्टम के चालू होने के बाद से बीता समय" को रेफ़रंस के तौर पर इस्तेमाल करता है. वहीं, रीयल टाइम क्लॉक, यूटीसी (वॉल क्लॉक) समय का इस्तेमाल करता है. इसका मतलब है कि बीते हुए रीयल टाइम का इस्तेमाल, समय बीतने के आधार पर अलार्म सेट करने के लिए किया जा सकता है. उदाहरण के लिए, हर 30 सेकंड में बजने वाला अलार्म. ऐसा इसलिए, क्योंकि इस पर टाइम ज़ोन या स्थान-भाषा का असर नहीं पड़ता. रीयल टाइम क्लॉक टाइप, उन अलार्म के लिए बेहतर है जो मौजूदा स्थान-भाषा पर निर्भर करते हैं.

दोनों तरह के अलार्म में "वेकअप" वर्शन होता है. इससे डिवाइस के सीपीयू को चालू करने के लिए कहा जाता है, भले ही स्क्रीन बंद हो. इससे यह पक्का होता है कि अलार्म, शेड्यूल किए गए समय पर बजेगा. यह तब काम आता है, जब आपका ऐप्लिकेशन समय पर निर्भर करता हो. उदाहरण के लिए, अगर किसी खास काम को करने के लिए एक सीमित समय है. अगर अलार्म टाइप के वेकअप वर्शन का इस्तेमाल नहीं किया जाता है, तो डिवाइस के चालू होने पर, बार-बार बजने वाले सभी अलार्म बजेंगे.

अगर आपको अलार्म को किसी खास समयावधि (उदाहरण के लिए, हर आधे घंटे) पर ट्रिगर करना है, तो बीता हुआ रीयल टाइम टाइप में से कोई एक चुनें. आम तौर पर, यह बेहतर विकल्प है.

अगर आपको दिन के किसी खास समय पर अलार्म ट्रिगर करना है, तो घड़ी पर आधारित रीयल टाइम क्लॉक टाइप में से कोई एक चुनें. हालांकि, ध्यान दें कि इस तरीके के कुछ नुकसान भी हो सकते हैं. ऐसा हो सकता है कि ऐप्लिकेशन, अन्य स्थान-भाषाओं में सही तरीके से अनुवाद न करे. साथ ही, अगर उपयोगकर्ता डिवाइस के समय की सेटिंग बदलता है, तो आपके ऐप्लिकेशन में अनचाहा व्यवहार हो सकता है. रीयल टाइम क्लॉक अलार्म टाइप का इस्तेमाल करने से भी, ऊपर बताए गए तरीके से स्केल नहीं किया जा सकता. हमारा सुझाव है कि अगर हो सके, तो "बीता हुआ असल समय" अलार्म का इस्तेमाल करें.

यहां टाइप की सूची दी गई है:

• ELAPSED_REALTIME: डिवाइस के चालू होने के बाद से बीते समय के आधार पर, पेंडिंग इंटेंट को ट्रिगर करता है. हालांकि, यह डिवाइस को चालू नहीं करता. बीते हुए समय में वह समय भी शामिल होता है जब डिवाइस स्लीप मोड में था.

• ELAPSED_REALTIME_WAKEUP: डिवाइस के चालू होने के बाद, तय की गई अवधि बीत जाने पर, यह डिवाइस को चालू करता है और पेंडिंग इंटेंट को ट्रिगर करता है.

• RTC: यह तय समय पर पेंडिंग इंटेंट को ट्रिगर करता है, लेकिन डिवाइस को चालू नहीं करता.

• RTC_WAKEUP: यह तय समय पर पेंडिंग इंटेंट को ट्रिगर करने के लिए, डिवाइस को चालू करता है.

बीते हुए रीयल टाइम अलार्म के उदाहरण

यहां ELAPSED_REALTIME_WAKEUP का इस्तेमाल करने के कुछ उदाहरण दिए गए हैं

डिवाइस को चालू करें, ताकि 30 मिनट में अलार्म बजे और उसके बाद हर 30 मिनट में अलार्म बजे:

// Hopefully your alarm will have a lower frequency than this!
alarmMgr?.setInexactRepeating(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR,
        alarmIntent
)

// Hopefully your alarm will have a lower frequency than this!
alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR,
        AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);

एक मिनट में एक बार (दोहराया नहीं जाने वाला) अलार्म बजाने के लिए, डिवाइस को चालू करें:

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

alarmMgr?.set(
        AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() + 60 * 1000,
        alarmIntent
)

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP,
        SystemClock.elapsedRealtime() +
        60 * 1000, alarmIntent);

रीयल टाइम क्लॉक अलार्म के उदाहरण

यहां RTC_WAKEUP का इस्तेमाल करने के कुछ उदाहरण दिए गए हैं.

डिवाइस को चालू करें, ताकि दोपहर करीब 2:00 बजे अलार्म बजे. साथ ही, हर दिन इसी समय पर अलार्म को दोहराएं:

// Set the alarm to start at approximately 2:00 p.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 14)
}

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr?.setInexactRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        AlarmManager.INTERVAL_DAY,
        alarmIntent
)

// Set the alarm to start at approximately 2:00 p.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 14);

// With setInexactRepeating(), you have to use one of the AlarmManager interval
// constants--in this case, AlarmManager.INTERVAL_DAY.
alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        AlarmManager.INTERVAL_DAY, alarmIntent);

डिवाइस को चालू करें, ताकि ठीक सुबह 8:30 बजे अलार्म बजे. इसके बाद, हर 20 मिनट पर अलार्म बजे:

private var alarmMgr: AlarmManager? = null
private lateinit var alarmIntent: PendingIntent
...
alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager
alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent ->
    PendingIntent.getBroadcast(context, 0, intent, 0)
}

// Set the alarm to start at 8:30 a.m.
val calendar: Calendar = Calendar.getInstance().apply {
    timeInMillis = System.currentTimeMillis()
    set(Calendar.HOUR_OF_DAY, 8)
    set(Calendar.MINUTE, 30)
}

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr?.setRepeating(
        AlarmManager.RTC_WAKEUP,
        calendar.timeInMillis,
        1000 * 60 * 20,
        alarmIntent
)

private AlarmManager alarmMgr;
private PendingIntent alarmIntent;
...
alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context, AlarmReceiver.class);
alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0);

// Set the alarm to start at 8:30 a.m.
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(System.currentTimeMillis());
calendar.set(Calendar.HOUR_OF_DAY, 8);
calendar.set(Calendar.MINUTE, 30);

// setRepeating() lets you specify a precise custom interval--in this case,
// 20 minutes.
alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(),
        1000 * 60 * 20, alarmIntent);

तय करें कि आपको अलार्म कितने सटीक समय पर चाहिए

जैसा कि पहले बताया गया है, अलार्म सेट करने का पहला चरण अक्सर अलार्म का टाइप चुनना होता है. एक और अंतर यह है कि आपको अलार्म कितना सटीक चाहिए. ज़्यादातर ऐप्लिकेशन के लिए, setInexactRepeating() सही विकल्प है. इस तरीके का इस्तेमाल करने पर, Android कई बार दोहराए जाने वाले अलार्म को सिंक करता है और उन्हें एक ही समय पर ट्रिगर करता है. इससे बैटरी कम खर्च होती है.

अगर हो सके, तो एग्ज़ैक्ट अलार्म का इस्तेमाल करने से बचें. हालांकि, कुछ ऐप्लिकेशन के लिए समय की पाबंदी होती है. ऐसे ऐप्लिकेशन के लिए, setRepeating() को कॉल करके एग्ज़ैक्ट अलार्म सेट किया जा सकता है.

setInexactRepeating() में, कस्टम इंटरवल को उस तरह से तय नहीं किया जा सकता जिस तरह से setRepeating() में किया जा सकता है. आपको इंटरवल के किसी एक कॉन्सटेंट का इस्तेमाल करना होगा. जैसे, INTERVAL_FIFTEEN_MINUTES, INTERVAL_DAY वगैरह. पूरी सूची देखने के लिए, AlarmManager पर जाएं.

अलार्म रद्द करना

अपने ऐप्लिकेशन के हिसाब से, अलार्म रद्द करने की सुविधा शामिल की जा सकती है. किसी अलार्म को रद्द करने के लिए, Alarm Manager पर cancel() को कॉल करें. साथ ही, वह PendingIntent पास करें जिसे अब आपको ट्रिगर नहीं करना है. उदाहरण के लिए:

// If the alarm has been set, cancel it.
alarmMgr?.cancel(alarmIntent)

// If the alarm has been set, cancel it.
if (alarmMgr!= null) {
    alarmMgr.cancel(alarmIntent);
}

डिवाइस के रीस्टार्ट होने पर अलार्म शुरू करना

डिफ़ॉल्ट रूप से, डिवाइस के बंद होने पर सभी अलार्म रद्द हो जाते हैं. ऐसा होने से रोकने के लिए, अपने ऐप्लिकेशन को इस तरह से डिज़ाइन किया जा सकता है कि अगर उपयोगकर्ता डिवाइस को रीबूट करता है, तो बार-बार बजने वाला अलार्म अपने-आप रीस्टार्ट हो जाए. इससे यह पक्का होता है कि AlarmManager अपना काम करता रहेगा. इसके लिए, उपयोगकर्ता को अलार्म को मैन्युअल तरीके से रीस्टार्ट करने की ज़रूरत नहीं होगी.

इसका तरीका यहां बताया गया है:

1. अपने ऐप्लिकेशन के मेनिफ़ेस्ट में RECEIVE_BOOT_COMPLETED अनुमति सेट करें. इससे आपके ऐप्लिकेशन को वह ACTION_BOOT_COMPLETED मिलता है जो सिस्टम के बूट होने के बाद ब्रॉडकास्ट होता है. हालांकि, ऐसा सिर्फ़ तब होता है, जब उपयोगकर्ता ने ऐप्लिकेशन को पहले ही कम से कम एक बार लॉन्च कर लिया हो:

   <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>

2. ब्रॉडकास्ट पाने के लिए, BroadcastReceiver लागू करें:

   Kotlin

   class SampleBootReceiver : BroadcastReceiver() {
   
       override fun onReceive(context: Context, intent: Intent) {
           if (intent.action == "android.intent.action.BOOT_COMPLETED") {
               // Set the alarm here.
           }
       }
   }

   Java

   public class SampleBootReceiver extends BroadcastReceiver {
   
       @Override
       public void onReceive(Context context, Intent intent) {
           if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) {
               // Set the alarm here.
           }
       }
   }

3. रिसीवर को अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में जोड़ें. इसके लिए, ऐसे इंटेंट फ़िल्टर का इस्तेमाल करें जो ACTION_BOOT_COMPLETED कार्रवाई को फ़िल्टर करता हो:

   <receiver android:name=".SampleBootReceiver"
           android:enabled="false">
       <intent-filter>
           <action android:name="android.intent.action.BOOT_COMPLETED"></action>
       </intent-filter>
   </receiver>

   ध्यान दें कि मेनिफ़ेस्ट में, बूट रिसीवर को android:enabled="false" पर सेट किया गया है. इसका मतलब है कि रिसीवर को तब तक कॉल नहीं किया जाएगा, जब तक ऐप्लिकेशन साफ़ तौर पर इसे चालू नहीं करता. इससे बूट रिसीवर को बेवजह कॉल किए जाने से रोका जा सकता है. रिसीवर को चालू किया जा सकता है. उदाहरण के लिए, अगर उपयोगकर्ता अलार्म सेट करता है, तो इस तरह से रिसीवर को चालू किया जा सकता है:

   Kotlin

   val receiver = ComponentName(context, SampleBootReceiver::class.java)
   
   context.packageManager.setComponentEnabledSetting(
           receiver,
           PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
           PackageManager.DONT_KILL_APP
   )

   Java

   ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
   PackageManager pm = context.getPackageManager();
   
   pm.setComponentEnabledSetting(receiver,
           PackageManager.COMPONENT_ENABLED_STATE_ENABLED,
           PackageManager.DONT_KILL_APP);

   इस तरह से रिसीवर को चालू करने के बाद, यह चालू रहेगा. भले ही, उपयोगकर्ता डिवाइस को रीबूट कर दे. दूसरे शब्दों में, प्रोग्राम के हिसाब से रिसीवर को चालू करने पर, मेनिफ़ेस्ट सेटिंग बदल जाती है. ऐसा डिवाइस को फिर से चालू करने पर भी होता है. रिसीवर तब तक चालू रहेगा, जब तक आपका ऐप्लिकेशन उसे बंद नहीं कर देता. रिसीवर को बंद किया जा सकता है. उदाहरण के लिए, अगर उपयोगकर्ता अलार्म रद्द करता है, तो ऐसा इस तरह किया जा सकता है:

   Kotlin

   val receiver = ComponentName(context, SampleBootReceiver::class.java)
   
   context.packageManager.setComponentEnabledSetting(
           receiver,
           PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
           PackageManager.DONT_KILL_APP
   )

   Java

   ComponentName receiver = new ComponentName(context, SampleBootReceiver.class);
   PackageManager pm = context.getPackageManager();
   
   pm.setComponentEnabledSetting(receiver,
           PackageManager.COMPONENT_ENABLED_STATE_DISABLED,
           PackageManager.DONT_KILL_APP);

डिवाइस के बैटरी बचाने वाले मोड में होने पर अलार्म ट्रिगर करना

Android 6.0 (एपीआई लेवल 23) पर चलने वाले डिवाइसों में, बैटरी बचाएं मोड काम करता है. इससे डिवाइस की बैटरी लाइफ़ बढ़ाने में मदद मिलती है. डिवाइस के बैटरी बचाएं मोड में होने पर, अलार्म नहीं बजते शेड्यूल किए गए अलार्म तब तक नहीं बजते, जब तक डिवाइस बैटरी बचाएं मोड से बाहर नहीं आ जाता. अगर आपको डिवाइस के इस्तेमाल में न होने पर भी काम पूरा करना है, तो आपके पास कई विकल्प उपलब्ध हैं:

• एग्ज़ैक्ट अलार्म सेट करें.

• WorkManager API का इस्तेमाल करें. इसे बैकग्राउंड में काम करने के लिए बनाया गया है. सिस्टम को यह निर्देश दिया जा सकता है कि वह आपके काम को तेज़ी से पूरा करे, ताकि काम जल्द से जल्द खत्म हो सके. ज़्यादा जानकारी के लिए, WorkManager की मदद से टास्क शेड्यूल करना लेख पढ़ें

सबसे सही तरीके

बार-बार बजने वाले अलार्म को डिज़ाइन करते समय, आपके हर विकल्प का असर इस बात पर पड़ सकता है कि आपका ऐप्लिकेशन, सिस्टम के संसाधनों का इस्तेमाल (या गलत इस्तेमाल) कैसे करता है. उदाहरण के लिए, किसी ऐसे लोकप्रिय ऐप्लिकेशन के बारे में सोचें जो सर्वर के साथ सिंक होता है. अगर सिंक करने की प्रोसेस, घड़ी के समय पर आधारित है और ऐप्लिकेशन का हर इंस्टेंस रात 11:00 बजे सिंक होता है, तो सर्वर पर लोड की वजह से इंतज़ार का समय बढ़ सकता है या "सेवा में रुकावट" भी आ सकती है. अलार्म का इस्तेमाल करने के लिए, ये सबसे सही तरीके अपनाएं:

• बार-बार बजने वाले अलार्म की वजह से ट्रिगर होने वाले नेटवर्क के अनुरोधों में, रैंडमनेस (जिटर) जोड़ें:

  • अलार्म ट्रिगर होने पर, स्थानीय तौर पर कोई काम करना. "लोकल वर्क" का मतलब है, ऐसा कोई भी काम जिसके लिए सर्वर से डेटा की ज़रूरत नहीं होती या जो सर्वर पर नहीं होता.

  • साथ ही, नेटवर्क के अनुरोधों वाले अलार्म को किसी भी समय ट्रिगर होने के लिए शेड्यूल करें.

• अलार्म की फ़्रीक्वेंसी कम से कम रखें.

• डिवाइस को बेवजह चालू न करें. यह व्यवहार, अलार्म के टाइप से तय होता है. इसके बारे में, अलार्म का टाइप चुनें में बताया गया है.

• अलार्म के ट्रिगर होने का समय ज़रूरत से ज़्यादा सटीक न बनाएं.

  setRepeating() के बजाय, setInexactRepeating() का इस्तेमाल करें. setInexactRepeating() का इस्तेमाल करने पर, Android कई ऐप्लिकेशन से बार-बार बजने वाले अलार्म को सिंक करता है और उन्हें एक ही समय पर ट्रिगर करता है. इससे सिस्टम को डिवाइस को चालू करने की ज़रूरत कम पड़ती है. इस वजह से, बैटरी कम खर्च होती है. Android 4.4 (एपीआई लेवल 19) के बाद से, बार-बार बजने वाले सभी अलार्म, तय समय पर न बजने वाले अलार्म होते हैं. ध्यान दें कि setInexactRepeating(), setRepeating() से बेहतर है. हालांकि, अगर किसी ऐप्लिकेशन का हर इंस्टेंस एक ही समय पर सर्वर को हिट करता है, तो सर्वर पर अब भी लोड बढ़ सकता है. इसलिए, नेटवर्क के अनुरोधों के लिए, अपने अलार्म में कुछ रैंडमनेस जोड़ें, जैसा कि पहले बताया गया है.

• अगर हो सके, तो अलार्म को घड़ी के समय के हिसाब से सेट न करें.

  ट्रिगर होने के सटीक समय पर आधारित बार-बार बजने वाले अलार्म, सही तरीके से काम नहीं करते. अगर हो सके, तो ELAPSED_REALTIME का इस्तेमाल करें. अलार्म के अलग-अलग टाइप के बारे में ज़्यादा जानकारी, यहां दी गई है.