AlarmManager
के हिसाब से
क्लास) से आपकी परफ़ॉर्मेंस को
समयसीमा के आधार पर तय किए गए ऑपरेशन.
उदाहरण के लिए, लंबे समय तक चलने वाली कार्रवाई शुरू करने के लिए, अलार्म का इस्तेमाल किया जा सकता है. उदाहरण के लिए,
यानी मौसम के पूर्वानुमान को डाउनलोड करने के लिए, दिन में एक बार सेवा शुरू करना.
अलार्म में ये विशेषताएं होती हैं:
इनकी मदद से, सेट किए गए समय और/या इंटरवल पर इंटेंट ट्रिगर किए जा सकते हैं.
इन्हें ब्रॉडकास्ट रिसीवर के साथ शेड्यूल करके इस्तेमाल किया जा सकता है नौकरी या अन्य कार्रवाइयां करने के लिए, WorkRequests कार्रवाइयां.
वे आपके ऐप्लिकेशन के बाहर काम करते हैं, इसलिए आप उन्हें ट्रिगर करने के लिए इस्तेमाल कर सकते हैं इवेंट या कार्रवाइयां, भले ही आपका ऐप्लिकेशन न चल रहा हो. भले ही, डिवाइस वह सो रहा है.
इनकी मदद से, अपने ऐप्लिकेशन के संसाधन से जुड़ी ज़रूरतों को कम किया जा सकता है. शेड्यूल किया जा सकता है टाइमर या लगातार चलने वाली सेवाओं के बिना काम करना.
सटीक समय पर पहुंचने वाला अलार्म सेट करें
जब कोई ऐप्लिकेशन एग्ज़ैक्ट अलार्म सेट करता है, तो सिस्टम कुछ समय पर अलार्म भेजता है आने वाले समय में. सटीक समय वाले अलार्म, अलार्म सेट करने के समय की कुछ गारंटी देते हैं बैटरी की बचत करने वाली पाबंदियों, जैसे कि डोज़.
डेवलपर, एपीआई की यहां दी गई गारंटी का इस्तेमाल करके, सटीक समय पर अलार्म डिलीवर नहीं किया जा सकता.
किसी खास समय के बाद अलार्म डिलीवर करें
अगर आपके ऐप्लिकेशन ने 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
. इस दौरान काम करने के लिए
डिवाइस बैटरी में है, तो इसका इस्तेमाल करके सटीक अलार्म बनाएं
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
- उपयोगकर्ता ने अनुमति दी है
- इस्तेमाल के ज़्यादा उदाहरण
- ऐप्लिकेशन को यह पुष्टि करनी चाहिए कि अनुमति रद्द नहीं की गई है
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
ब्रॉडकास्ट. आपके ऐप्लिकेशन में ब्रॉडकास्ट लागू करना चाहिए
पाने वाला है, जो
फ़ॉलो किया जा रहा है:
- यह पुष्टि करता है कि आपके ऐप्लिकेशन के पास अब भी खास ऐप्लिकेशन का ऐक्सेस है. ऐसा करने के लिए, कॉल करें
canScheduleExactAlarms()
. यह जांच आपके ऐप्लिकेशन को उन मामलों से बचाती है जहां उपयोगकर्ता आपके ऐप्लिकेशन को अनुमति देता है अनुमति है, तो वह लगभग तुरंत बाद उसे रद्द कर देती है. - यह आपके ऐप्लिकेशन की मौजूदा स्थिति के हिसाब से, सटीक समय वाले उन अलार्म को फिर से शेड्यूल करता है जिनकी ज़रूरत होती है.
यह लॉजिक, आपके ऐप्लिकेशन को
ACTION_BOOT_COMPLETED
ब्रॉडकास्ट.
उपयोगकर्ताओं से SCHEDULE_EXACT_ALARM
की अनुमति देने के लिए कहें
अगर ज़रूरी हो, तो आप उपयोगकर्ताओं को अलार्म और सिस्टम की रिमाइंडर स्क्रीन सेटिंग, जैसा कि इमेज 1 में दिखाया गया है. इसके लिए, नीचे दिया गया तरीका अपनाएं:
- अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) में, उपयोगकर्ता को यह बताएं कि आपके ऐप्लिकेशन के लिए, इवेंट को सटीक शेड्यूल करने की ज़रूरत क्यों है अलार्म.
- कोई ऐसा इंटेंट शुरू करें जिसमें
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); }
अलार्म का कोई टाइप चुनें
दोहराए जाने वाले अलार्म का इस्तेमाल करते समय, सबसे पहले इस बात पर ध्यान देना चाहिए कि वह अलार्म किस तरह का है होना चाहिए.
अलार्म के लिए सामान्य तौर पर दो तरह के अलार्म सेट किए जाते हैं: "रीयल टाइम बीत चुका है" और "रीयल टाइम घड़ी" (आरटीसी). बीत चुका रीयल टाइम, "सिस्टम बूट होने के बाद से समय" का इस्तेमाल करता है इस रूप में संदर्भ देता है, और रियल टाइम घड़ी UTC (वॉल घड़ी) समय का उपयोग करती है. इसका मतलब है कि बीत चुका रीयल टाइम, समय के बीतने के साथ अलार्म सेट करने के लिए सबसे सही होता है (इसके लिए उदाहरण के लिए, हर 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:00 बजे डिवाइस को चालू करके अलार्म बजाएं, और उसी समय पर दिन में एक बार दोहराएं:
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 बजे पर सिंक होता है और ऐप के हर इंस्टेंस पर सर्वर की वजह से, इंतज़ार का समय ज़्यादा हो सकता है या "सेवा में रुकावट." अलार्म का इस्तेमाल करने के लिए इन सबसे सही तरीकों को अपनाएं:
ऐसे किसी भी नेटवर्क अनुरोध में रैंडमनेस (झटका) जोड़ें बार-बार होने वाले अलार्म की वजह से ट्रिगर हो सकता है:
अलार्म ट्रिगर होने पर कोई भी स्थानीय काम करें. "स्थानीय काम" इसका मतलब ऐसे किसी भी सर्वर पर हिट नहीं होता या सर्वर से डेटा की ज़रूरत नहीं होती.
उसी समय, उस अलार्म को शेड्यूल करें जिसमें नेटवर्क अनुरोध शामिल हों कभी-कभी आग लग जाती है.
अलार्म की फ़्रीक्वेंसी को कम से कम पर सेट करें.
डिवाइस को बेवजह न जगाएं (यह व्यवहार अलार्म का टाइप, जैसा कि अलार्म का टाइप चुनें) में बताया गया है.
अपने अलार्म के ट्रिगर होने के समय को सामान्य से ज़्यादा सटीक न बनाएं.
इस्तेमाल की जाने वाली चीज़ें
setInexactRepeating()
के बजायsetRepeating()
. जब आपsetInexactRepeating()
का इस्तेमाल करते/करती हैं, Android, कई ऐप्लिकेशन से बार-बार ट्रिगर हुए अलार्म को सिंक करता है और आग लग जाती है एक साथ आ सकते हैं. इससे सिस्टम को उस संख्या को कम करने की ज़रूरत पड़ती है इससे बैटरी का खर्च कम होता है. Android 4.4 तक (एपीआई लेवल 19), बार-बार दोहराए जाने वाले सभी अलार्म एग्ज़ैक्ट अलार्म के तौर पर सेट होंगे. नोट जोड़ें उस समयsetInexactRepeating()
पिछले महीने के मुकाबलेsetRepeating()
, अगर किसी ऐप्लिकेशन का हर इंस्टेंस सर्वर पर हिट करता है, तो यह अब भी सर्वर को नुकसान पहुंचा सकता है करीब एक ही समय पर. इसलिए, नेटवर्क अनुरोधों के लिए आपके अलार्म के बारे में बताएँगे.अगर हो सके, तो अलार्म को घड़ी के समय पर न रखें.
ट्रिगर होने के सटीक समय पर आधारित बार-बार आने वाले अलार्म सही तरीके से मेज़र नहीं करते. इस्तेमाल की जाने वाली चीज़ें
ELAPSED_REALTIME
अगर तो आप ऐसा कर सकते हैं. अलग अलार्म नीचे दिए गए सेक्शन में, टाइप के बारे में ज़्यादा जानकारी दी गई है.