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

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

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

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

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

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

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

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

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

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

अगर आपका ऐप्लिकेशन 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 का इस्तेमाल करके उसे शेड्यूल करें. डिवाइस के Doze मोड में होने पर भी काम करने के लिए, 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 बजे अलार्म बजाने के लिए चालू करें और इसे हर दिन एक ही समय पर दोहराएं:

// 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 का इस्तेमाल करें. अलग-अलग तरह के अलार्म के बारे में ज़्यादा जानकारी, नीचे दिए गए सेक्शन में दी गई है.