2026 में Android पर फोरग्राउंड सर्विस टाइप्स: वह चुनना जो आपके फीचर पर सच में लागू हो

फोरग्राउंड सर्विस शुरू करना पहले एक लाइन और एक नोटिफिकेशन का मामला था। अब नहीं है। किसी भी मौजूदा टारगेट SDK पर हर फोरग्राउंड सर्विस को मैनिफेस्ट में एक टाइप बताना होता है, मैचिंग परमिशन मांगनी होती है, और कुछ मामलों में ऐप शिप होने से पहले Google के सामने अपने होने की वजह भी साबित करनी होती है। इसमें से कुछ भी बेवजह की औपचारिकता नहीं है — हर टाइप एक अलग लाइफटाइम गारंटी लेकर आता है, और गलत टाइप चुनना ही वह तरीका है जिससे टेस्टिंग में ठीक चलने वाला फीचर हफ्तों बाद असली डिवाइस पर चुपचाप मार दिया जाता है। यहां बताया गया है कि असल में कैसे चुनें, Mintly के फोकस टाइमर को जो फैसला लेना पड़ा उसे उदाहरण के तौर पर लेते हुए।

“बस एक फोरग्राउंड सर्विस शुरू कर दो” काम करना क्यों बंद हो गया

पुराना मॉडल उदार था: startForeground() कॉल करें, एक नोटिफिकेशन दिखाएं, और जब तक नोटिफिकेशन दिखता रहे तब तक सिस्टम आपको ज़्यादातर अकेला छोड़ देता था। इसने फोरग्राउंड सर्विसेज़ को दुरुपयोग के लिए चुंबक बना दिया — एक “sync” सर्विस जो कभी सिंक ही नहीं करती, एक “listening” सर्विस जो सिर्फ प्रोसेस को ज़िंदा रखती रहती है। प्लेटफॉर्म का जवाब हर फोरग्राउंड सर्विस को एक घोषित टाइप से जोड़ना रहा है, हर एक की अपनी परमिशन और बिना निगरानी के कितनी देर चल सकती है इसका अपना अनुबंध। अब आप यह नहीं कह सकते “मुझ पर भरोसा करो, यह ज़रूरी है।” आप बताते हैं किस तरह का ज़रूरी, और बाकी सिस्टम लागू करता है।

<service
    android:name=".timer.FocusSessionService"
    android:foregroundServiceType="specialUse"
    android:exported="false">
    <property
        android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
        android:value="active-focus-timer" />
</service>

टाइप की घोषणा छोड़ दें और सर्विस मौजूदा टारगेट SDK पर बस शुरू ही नहीं होगी — startForeground() चेतावनी नहीं देता, वह एक्सेप्शन फेंकता है।

वे टाइप्स जो सच में ज़्यादातर इंडी फीचर्स पर फिट बैठते हैं

चुनी हुई लिस्ट में camera, microphone, location, phoneCall, mediaPlayback, और connectedDevice जैसे मामले आते हैं — हर एक नाम के मुताबिक सख्ती से सीमित, हर एक असली क्षमता से जुड़ी एक परमिशन से सुरक्षित (FOREGROUND_SERVICE_CAMERA को CAMERA चाहिए, और आगे भी ऐसे ही)। अगर आपका फीचर सच में ऑडियो चला रहा है या किसी कनेक्टेड डिवाइस से स्ट्रीम कर रहा है, तो टाइप साफ है और परमिशन शायद वह है जो आपके पास पहले से ही है।

दो टाइप्स जिन्हें ज़्यादा गहराई से समझना ज़रूरी है, वे हैं जो किसी एक सेंसर से मेल नहीं खाते: dataSync और specialUse।

dataSync एक साफ फिनिश लाइन वाले बैकग्राउंड ट्रांसफर के लिए है — बैकअप अपलोड करना, कोई रिमोट अपडेट खींचना। यह टिके रहने की अवस्था नहीं है; Android 15 से, dataSync और mediaProcessing सर्विसेज़ को 24 घंटे की चलती विंडो में लगभग छह घंटे का कुल रनटाइम बजट मिलता है। इसे पार करें और सिस्टम Service.onTimeout() कॉल करता है, ज़बरदस्ती रोकने से पहले काम समेटने के लिए थोड़ी मोहलत देता है। यह उस चीज़ के लिए एक उचित समझौता है जिसके लिए यह टाइप बना है — एक ट्रांसफर जिसे खत्म होना ही है — और उस चीज़ के लिए बुरा फिट है जिसे अनिश्चित काल तक टिके रहना है।

specialUse: वह टाइप जो लिस्ट में न हो उन सबके लिए

25 मिनट का फोकस टाइमर न तो डेटा सिंक है, न मीडिया प्लेबैक है, न किसी सेंसर से जुड़ा है। यह ठीक वही खाली जगह है जिसे भरने के लिए specialUse मौजूद है — एक फोरग्राउंड सर्विस जो वाकई समय-सीमित है और यूज़र द्वारा शुरू की गई है, लेकिन नामित श्रेणियों में से किसी से मेल नहीं खाती। दिक्कत यह है कि आप बस इसे घोषित करके आगे नहीं बढ़ सकते: मैनिफेस्ट का <property> टैग एक सबटाइप स्ट्रिंग मांगता है जो बताए कि सर्विस क्या करती है, और Google Play का ऐप रिव्यू उस स्ट्रिंग को पढ़ता है। किसी ऐसी चीज़ के लिए specialUse घोषित करें जो असल में छुपा हुआ डेटा-सिंक या ज़िंदा रखने वाला हैक हो, तो ठीक इसी तरह की गड़बड़ी लॉन्च के बाद नहीं, रिव्यू के दौरान पकड़ी जाती है।

Mintly के लिए, सबटाइप active-focus-timer है, और Play Console का फोरग्राउंड सर्विस डिक्लेरेशन फॉर्म भी यही बात सीधी भाषा में कहता है: एक चल रहा सेशन जो यूज़र ने शुरू किया और सक्रिय रूप से देख रहा है, जो एक तय समय पर खत्म होता है। यह जायज ठहराने में आसान मामला है क्योंकि यह सच है। सर्विस क्या करती है इसका एक ईमानदार, एक-लाइन विवरण लिखना, ऐसे टाइप की तलाश में समय गंवाने से बेहतर है जो रिव्यू की बारीक नज़र से बच जाए।

shortService: सेशन के लिए नहीं, छोटे झटके के लिए बना

जानने लायक दूसरा टाइप shortService है, जो उस फोरग्राउंड सर्विस के लिए है जिसे कुछ खत्म करने के लिए बस कुछ मिनट चाहिए — एक बड़ा एक्सपोर्ट लिखना, एक बार की सफाई चलाना — इतने कम समय के लिए कि यूज़र WorkManager के एक्सपिडाइटेड जॉब के कोल्ड स्टार्ट को बर्दाश्त करने के मूड में भी न हों। इसके साथ लगभग तीन मिनट की सख्त रनटाइम सीमा आती है; सिस्टम उससे आगे मोलभाव नहीं करता, और यह टाइप ठीक इसलिए मौजूद है ताकि छोटी अवधि का काम ज़रूरत से ज़्यादा मोहलत पाने के लिए dataSync या specialUse का दुरुपयोग करना बंद कर दे। अगर आपका टास्क अनुमानित रूप से तीन मिनट से कम में खत्म हो जाता है, तो इस्तेमाल करने लायक ईमानदार टाइप यही है। अगर यह कभी-कभी लंबा खिंच जाता है, तो यह गलत है, और यह आपको प्रोडक्शन में पता चलेगा, टेस्टिंग में नहीं।

गलत टाइप चुनना एक प्रोडक्शन बग है, कोई लिंट चेतावनी नहीं

जो टाइप आप घोषित करते हैं वह ऐसा मेटाडेटा नहीं है जिसे Android आपके अनिश्चित होने पर विनम्रता से नज़रअंदाज़ कर दे। दिन में आठ घंटे चलने वाली किसी चीज़ के लिए dataSync घोषित करें, तो वह बीच रन में टाइमआउट हो जाती है — एक ऐसी स्थिति जिसे आपके ऐप को सही तरीके से पहचानना और उससे उबरना होता है, वरना यूज़र को बिना किसी वजह के बस अटका हुआ फीचर दिखता है। ईमानदार सबटाइप के बिना specialUse घोषित करें और Play का रिव्यू सीधे अपडेट को रिजेक्ट कर सकता है, जो शुरुआत में सही टाइप चुनने में लगने वाले दस मिनट से कहीं ज़्यादा बुरी लॉन्च देरी है।

फैसला दो सवालों पर आ टिकता है: क्या यह सर्विस camera या mediaPlayback जैसी किसी असली क्षमता से मेल खाती है? अगर नहीं, तो क्या काम स्वाभाविक रूप से मिनटों में सीमित है (shortService), साफ अंत वाले घंटों में (dataSync), या खुला-अंत लेकिन यूज़र द्वारा शुरू किया गया और सक्रिय रूप से देखा जा रहा है (specialUse, ईमानदारी से घोषित)? मैनिफेस्ट एंट्री लिखने से पहले इनका जवाब दें, क्रैश रिपोर्ट सामने आने के बाद नहीं। टाइप सिस्टम एक बार सीखने में झंझट भरा है, उसके बाद यह प्लेटफॉर्म के बारे में बस एक तथ्य है — ठीक उसी तरह जैसे Android 16 के Live Updates, Mintly की टाइमर सर्विस के ऊपर बैठते हैं, न कि उसके फोरग्राउंड सर्विस टाइप को शुरुआत में सही चुनने की ज़रूरत की जगह लेते हुए।