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

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

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

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

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

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

सटीक समय के बजाय, कोई दूसरा समय सेट करना

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

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

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

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

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

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

अगर आपका ऐप्लिकेशन 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) और इसके बाद के वर्शन पर, बार-बार बजने वाले सभी अलार्म गलत अलार्म होते हैं.

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

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

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

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

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

किसी 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 बजे अलार्म बजाने के लिए चालू करें और इसे हर दिन एक ही समय पर दोहराएं:

// 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 देखें.

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

आपके ऐप्लिकेशन के आधार पर, हो सकता है कि आप अलार्म को रद्द करने की सुविधा शामिल करना चाहें. अलार्म को रद्द करने के लिए, अलार्म मैनेजर में 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) पर काम करने वाले डिवाइसों पर, Doze मोड काम करता है. इससे डिवाइस की बैटरी लाइफ़ बढ़ती है. डिवाइस के डॉज़ मोड में होने पर, अलार्म नहीं बजते. डिवाइस के डॉज़ मोड से बाहर आने तक, शेड्यूल किए गए सभी अलार्म बजने में देरी होती है. अगर आपको डिवाइस के कुछ समय से इस्तेमाल में न होने के बावजूद, काम पूरा करना है, तो इसके लिए कई विकल्प उपलब्ध हैं:

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

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

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

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

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

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

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

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

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

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

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

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

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