AlarmManager क्लास पर आधारित अलार्म की मदद से, ऐप्लिकेशन के लाइफ़टाइम के बाहर, समय के हिसाब से कार्रवाइयां की जा सकती हैं.
उदाहरण के लिए, लंबे समय तक चलने वाले किसी ऑपरेशन को शुरू करने के लिए, अलार्म का इस्तेमाल किया जा सकता है. जैसे, मौसम का पूर्वानुमान डाउनलोड करने के लिए, दिन में एक बार कोई सेवा शुरू करना.
अलार्म में ये विशेषताएं होती हैं:
इनकी मदद से, सेट किए गए समय और/या इंटरवल पर इंटेंट ट्रिगर किए जा सकते हैं.
इन्हें ब्रॉडकास्ट रिसीवर के साथ इस्तेमाल करके, जॉब या WorkRequests शेड्यूल किए जा सकते हैं. इससे, अन्य ऑपरेशन भी किए जा सकते हैं.
ये आपके ऐप्लिकेशन के बाहर काम करते हैं. इसलिए, इनका इस्तेमाल करके इवेंट या कार्रवाइयां ट्रिगर की जा सकती हैं. भले ही, आपका ऐप्लिकेशन न चल रहा हो और डिवाइस स्लीप मोड में हो.
इनकी मदद से, अपने ऐप्लिकेशन के संसाधन से जुड़ी ज़रूरतों को कम किया जा सकता है. टाइमर या लगातार चलने वाली सेवाओं पर भरोसा किए बिना, ऑपरेशन शेड्यूल किए जा सकते हैं.
सटीक समय पर पहुंचने वाला अलार्म सेट करें
जब कोई ऐप्लिकेशन गलत समय पर अलार्म सेट करता है, तो सिस्टम आने वाले समय में किसी समय पर अलार्म बजाता है. सटीक समय पर अलार्म न बजने की सुविधा, अलार्म डिलीवरी के समय के बारे में कुछ गारंटी देती है. साथ ही, बैटरी बचाने वाली पाबंदियों का भी पालन करती है, जैसे कि Doze.
डेवलपर, अलार्म डिलीवरी के समय को अपनी पसंद के मुताबिक बनाने के लिए, एपीआई की इन गारंटी का फ़ायदा ले सकते हैं.
किसी खास समय के बाद अलार्म बजाना
अगर आपका ऐप्लिकेशन set(),
setInexactRepeating() या setAndAllowWhileIdle() को कॉल करता है, तो अलार्म दिए गए ट्रिगर समय से पहले कभी नहीं बंद होगा.
Android 12 (एपीआई लेवल 31) और उसके बाद वाले वर्शन पर, सिस्टम, दिए गए ट्रिगर समय के एक घंटे के अंदर अलार्म को शुरू करता है. हालांकि, अगर बैटरी सेवर या डोज़ जैसी बैटरी बचाने से जुड़ी कोई पाबंदी लागू है.
किसी समयावधि के दौरान अलार्म भेजना
अगर आपका ऐप्लिकेशन setWindow() को कॉल करता है, तो अलार्म, ट्रिगर करने के लिए तय किए गए समय से पहले कभी नहीं बजता. जब तक बैटरी की बचत करने से जुड़ी कोई पाबंदी लागू न हो, तब तक अलार्म दिए गए समय अवधि में डिलीवर किया जाता है.
अगर आपका ऐप्लिकेशन Android 12 या इसके बाद के वर्शन को टारगेट करता है, तो सिस्टम, तय समय के हिसाब से सटीक अलार्म बजाने में कम से कम 10 मिनट की देरी कर सकता है. इस वजह से, 600000 में windowLengthMillis पैरामीटर की वैल्यू को 600000 पर काट दिया जाता है.
करीब-करीब नियमित अंतराल पर बार-बार होने वाला अलार्म बजे
अगर आपका ऐप्लिकेशन setInexactRepeating() को कॉल करता है, तो सिस्टम कई अलार्म चालू करता है:
- पहला अलार्म, तय समयावधि के अंदर बजता है. यह अलार्म, ट्रिगर करने के लिए तय किए गए समय से शुरू होता है.
- आम तौर पर, तय समयसीमा खत्म होने के बाद अगले अलार्म बजते हैं. अलार्म के दो बार लगातार बजने के बीच का समय अलग-अलग हो सकता है.
एग्ज़ैक्ट अलार्म सेट करना
सिस्टम, आने वाले समय में किसी खास समय पर एग्ज़ैक्ट अलार्म चालू करता है.
ज़्यादातर ऐप्लिकेशन, असटीक अलार्म का इस्तेमाल करके टास्क और इवेंट शेड्यूल कर सकते हैं. इससे, इस्तेमाल के कई सामान्य उदाहरण पूरे किए जा सकते हैं. अगर आपके ऐप्लिकेशन का मुख्य फ़ंक्शन, बिल्कुल सही समय पर बजने वाले अलार्म पर निर्भर करता है, तो एग्ज़ैक्ट अलार्म का इस्तेमाल किया जा सकता है. जैसे, अलार्म क्लॉक ऐप्लिकेशन या कैलेंडर ऐप्लिकेशन के लिए.
इस्तेमाल के ऐसे केस जिनके लिए सटीक समय वाले अलार्म की ज़रूरत नहीं हो सकती
यहां ऐसे सामान्य वर्कफ़्लो की सूची दी गई है जिनके लिए शायद एग्ज़ैक्ट अलार्म की ज़रूरत न हो:
- अपने ऐप्लिकेशन के लाइफ़टाइम के दौरान, टाइमिंग ऑपरेशन शेड्यूल करना
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
- अपने-आप दिया गया
- उपयोगकर्ता इसे रद्द नहीं कर सकता
- 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 ब्रॉडकास्ट भेजता है. आपके ऐप्लिकेशन को ब्रॉडकास्ट रिसीवर लागू करना चाहिए, जो ये काम करता है:
- यह पुष्टि करता है कि आपके ऐप्लिकेशन के पास अब भी ऐप्लिकेशन का खास ऐक्सेस है. ऐसा करने के लिए,
canScheduleExactAlarms()को कॉल करें. इस जांच से आपके ऐप्लिकेशन को उस स्थिति से बचाया जा सकता है जहां उपयोगकर्ता आपके ऐप्लिकेशन को अनुमति देता है और फिर तुरंत उसे रद्द कर देता है. - आपके ऐप्लिकेशन की मौजूदा स्थिति के आधार पर, एग्ज़ैक्ट अलार्म को फिर से शेड्यूल करता है.
यह लॉजिक उसी तरह का होना चाहिए जो आपका ऐप्लिकेशन,
ACTION_BOOT_COMPLETEDब्रॉडकास्ट मिलने पर करता है.
उपयोगकर्ताओं से SCHEDULE_EXACT_ALARM की अनुमति देने के लिए कहें
अगर ज़रूरी हो, तो उपयोगकर्ताओं को सिस्टम सेटिंग में अलार्म और रिमाइंडर स्क्रीन पर भेजा जा सकता है, जैसा कि पहली इमेज में दिखाया गया है. ऐसा करने के लिए, यह तरीका अपनाएं:
- अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में, उपयोगकर्ता को बताएं कि आपके ऐप्लिकेशन में सटीक अलार्म शेड्यूल करने की ज़रूरत क्यों है.
- ऐसा इंटेंट ट्रिगर करें जिसमें
ACTION_REQUEST_SCHEDULE_EXACT_ALARMइंटेंट ऐक्शन शामिल हो.
बार-बार बजने वाला अलार्म सेट करना
बार-बार होने वाले अलार्म की मदद से, सिस्टम आपके ऐप्लिकेशन को बार-बार होने वाले शेड्यूल की सूचना दे पाता है.
खराब तरीके से डिज़ाइन किए गए अलार्म की वजह से बैटरी तेज़ी से खर्च हो सकती है और सर्वर पर बहुत ज़्यादा लोड पड़ सकता है. इस वजह से, Android 4.4 (एपीआई लेवल 19) और उसके बाद वाले वर्शन पर, बार-बार दोहराए जाने वाले सभी अलार्म एग्ज़ैक्ट अलार्म के तौर पर दिखते हैं.
बार-बार बजने वाले अलार्म की ये विशेषताएं होती हैं:
अलार्म का टाइप. ज़्यादा जानकारी के लिए, अलार्म का टाइप चुनना लेख पढ़ें.
ट्रिगर का समय. अगर आपने ट्रिगर का जो समय बताया है वह बीत चुका है, तो अलार्म तुरंत ट्रिगर हो जाता है.
अलार्म का इंटरवल. उदाहरण के लिए, दिन में एक बार, हर घंटे या हर 5 मिनट में.
ऐसा पेंडिंग इंटेंट जो अलार्म ट्रिगर होने पर चालू होता है. अगर आपने एक ही पेंडिंग इंटेंट का इस्तेमाल करके दूसरा अलार्म सेट किया है, तो वह मूल अलार्म की जगह ले लेता है.
किसी 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 अपना काम करता रहेगा. इसके लिए, उपयोगकर्ता को अलार्म को मैन्युअल तरीके से रीस्टार्ट करने की ज़रूरत नहीं पड़ेगी.
इसका तरीका यहां बताया गया है:
अपने ऐप्लिकेशन के मेनिफ़ेस्ट में
RECEIVE_BOOT_COMPLETEDअनुमति सेट करें. इससे आपके ऐप्लिकेशन को सिस्टम के चालू होने के बाद, ब्रॉडकास्ट होने वालाACTION_BOOT_COMPLETEDऐक्सेस मिल जाता है (यह सिर्फ़ तब काम करता है, जब उपयोगकर्ता ने ऐप्लिकेशन को कम से कम एक बार पहले ही लॉन्च कर दिया हो):<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>ब्रॉडकास्ट पाने के लिए,
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. } } }
ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में, फ़ाइल पाने वाले व्यक्ति के लिए ऐसे इंटेंट फ़िल्टर का इस्तेमाल करें जो
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का इस्तेमाल करें. अलग-अलग तरह के अलार्म के बारे में ज़्यादा जानकारी, नीचे दिए गए सेक्शन में दी गई है.