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

अलार्म (AlarmManager के हिसाब से क्लास) से आपकी परफ़ॉर्मेंस को समयसीमा के आधार पर तय किए गए ऑपरेशन. उदाहरण के लिए, लंबे समय तक चलने वाली कार्रवाई शुरू करने के लिए, अलार्म का इस्तेमाल किया जा सकता है. उदाहरण के लिए, यानी मौसम के पूर्वानुमान को डाउनलोड करने के लिए, दिन में एक बार सेवा शुरू करना.

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

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

  • इन्हें ब्रॉडकास्ट रिसीवर के साथ इस्तेमाल करके, जॉब या 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()

आने वाले समय में किसी सटीक समय पर अलार्म चालू करें. क्योंकि ये अलार्म यह सिस्टम, डिलीवरी के समय में कभी बदलाव नहीं करता. कॉन्टेंट बनाने सिस्टम इन अलार्म की पहचान सबसे अहम अलार्म के तौर पर करता है और कम पावर वाले अलार्म के तौर पर सेट करता है मोड का सुझाव दें.

सिस्टम के संसाधन की खपत

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

यह सुझाव दिया जाता है कि जब भी ऐसा हो, तो आप एग्ज़ैक्ट अलार्म बनाएं किया जा सकता है. लंबे समय तक काम करने के लिए, इसका इस्तेमाल करके इसे शेड्यूल करें WorkManager या आपके अलार्म के समय से JobScheduler BroadcastReceiver. डिवाइस के 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

SCHEDULE_EXACT_ALARM

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

SCHEDULE_EXACT_ALARM की अनुमति, नए इंस्टॉल के लिए पहले से नहीं दी गई थी Android 13 (एपीआई लेवल 33) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन. अगर कोई उपयोगकर्ता ऐप्लिकेशन ट्रांसफ़र करता है 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 की अनुमति मांगना

इस विकल्प को &#39;अलार्म और रिमाइंडर सेट करने की अनुमति दें&#39; कहा जाता है
पहली इमेज. "अलार्म और रिमाइंडर" ऐप्लिकेशन के लिए खास ऐक्सेस पेज पर जाएं, जहां उपयोगकर्ता आपके ऐप्लिकेशन को अलार्म.

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

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

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

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

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

बार-बार होने वाले अलार्म में ये चीज़ें होती हैं:

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

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

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

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

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

Kotlin

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)
}

Java

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 मिनट में अलार्म फ़ायर करने के लिए डिवाइस को जगाएं उसके बाद:

Kotlin

// 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
)

Java

// 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);

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

Kotlin

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
)

Java

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

Kotlin

// 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
)

Java

// 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 मिनट में अलार्म बजने के लिए डिवाइस को जगाएं उसके बाद:

Kotlin

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
)

Java

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 को पास करें जिसे आपको अब बजाना नहीं है. उदाहरण के लिए:

Kotlin

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

Java

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