2026 में Android पर Health Connect: लोकल-फर्स्ट को छोड़े बिना डेटा पढ़ना और लिखना

Health Connect वह ऑन-डिवाइस स्टोर है जिससे Android अब हेल्थ और फ़िटनेस ऐप्स से यह उम्मीद रखता है कि वे अपना अलग सायलो बनाए रखने के बजाय इसी से पढ़ें और इसी में लिखें। एक लोकल-फर्स्ट ऐप के लिए यह एक ईमानदार सवाल खड़ा करता है: क्या यह डेटा पब्लिश करने की जगह है, पढ़ने की जगह है, या दोनों — और क्या इनमें से किसी एक को भी हाँ कहने से आपका सोर्स ऑफ़ ट्रुथ चुपचाप उस डिवाइस से बाहर खिसक जाता है जिस पर रखने का आपने वादा किया था। यहाँ बताया गया है कि यह API असल में आपसे क्या माँगता है, और मैं इसके इर्द-गिर्द जो लकीर खींचता हूँ।

Health Connect क्या है, और क्या नहीं है

Health Connect एक सिस्टम-लेवल डेटास्टोर है, कोई क्लाउड सर्विस नहीं। रिकॉर्ड्स — स्टेप्स, हाइड्रेशन, वज़न, स्लीप सेशन — एक लोकल डेटाबेस में रहते हैं जिसकी एक्सेस Android मध्यस्थता करता है, और जिस भी ऐप को यूज़र मंज़ूरी दे, वह इसके ज़रिए पढ़ या लिख सकता है। यही इसका आकर्षण है: एक हाइड्रेशन ऐप और एक फ़िटनेस ऐप अलग-अलग, अधूरी गिनती रखने के बजाय एक हाइड्रेशन टोटल शेयर कर सकते हैं। यही इसका जोखिम भी है। जिस पल आपका ऐप वहाँ लिखता है, उस डेटा को वह हर दूसरा ऐप भी देख सकता है जिसे यूज़र ने रीड एक्सेस दिया है। Health Connect को छूते ही लोकल-फर्स्ट का मतलब खत्म नहीं हो जाता, लेकिन इसका मतलब कुछ संकुचित ज़रूर हो जाता है: डेटा अब भी डिवाइस से बाहर कभी नहीं जाता, लेकिन अब यह सिर्फ़ आपको ही नहीं दिखता।

जिन फ़ोन में Health Connect ऐप पहले से इंस्टॉल नहीं होता, वहाँ क्लाइंट लाइब्रेरी पहली बार रिक्वेस्ट करने पर Play से इंस्टॉल का प्रॉम्प्ट दिखाती है। इस फ़ेल्योर पथ के लिए बजट रखें — एक बिल्कुल नई डिवाइस या कोई छांटा हुआ ROM API को अनुपलब्ध छोड़ सकता है, और आपकी परमिशन रिक्वेस्ट को एक असली फ़ॉलबैक चाहिए, क्रैश नहीं।

2026 का परमिशन मॉडल

हेल्थ परमिशन ActivityCompat.requestPermissions के मायने वाली रनटाइम परमिशन नहीं हैं — वे एक समर्पित रैशनेल स्क्रीन से होकर गुज़रती हैं जो Health Connect ऐप की अपनी है, आपके ऐप के डायलॉग की नहीं। आप मैनिफ़ेस्ट में इरादा घोषित करते हैं, फिर एक कॉन्ट्रैक्ट लॉन्च करते हैं:

val requestPermissions = registerForActivityResult(
    PermissionController.createRequestPermissionResultContract()
) { granted ->
    if (HealthPermission.getWritePermission(HydrationRecord::class) in granted) {
        // proceed
    }
}

requestPermissions.launch(
    setOf(
        HealthPermission.getWritePermission(HydrationRecord::class),
        HealthPermission.getReadPermission(HydrationRecord::class),
    )
)

नतीजे वाला सेट सिर्फ़ यह बताता है कि क्या मंज़ूर हुआ, कभी नहीं बताता कि कुछ क्यों नामंज़ूर हुआ — न कोई “हमेशा के लिए नामंज़ूर” फ़्लैग, न कोई रैशनेल जिसे आप जाँच सकें। अगर जिस परमिशन की आपको उम्मीद थी वह लौटे हुए सेट में नहीं है, तो सही कदम यह है कि हर रीड या राइट से पहले PermissionController.getGrantedPermissions() चेक करें और ग्रेसफ़ुली डिग्रेड करें, न कि यह मान लें कि कल की मंज़ूरी आज भी बरकरार है। यूज़र्स कभी भी, आपके ऐप के लाइफ़साइकल से बिल्कुल बाहर, सिस्टम सेटिंग्स से Health Connect परमिशन वापस ले सकते हैं, और आपकी अगली API कॉल ऐसे फ़ेल होगी जैसे वह कभी मंज़ूर ही नहीं हुई थी।

एक रिकॉर्ड लिखना और पढ़ना

एक HydrationRecord एक ऐसी वैल्यू है जिसका एक टाइम रेंज और एक वॉल्यूम होता है, जो लिखने वाले ऐप के अपने मेटाडेटा से जुड़ी होती है:

val record = HydrationRecord(
    startTime = Instant.now(),
    startZoneOffset = ZoneOffset.systemDefault().rules.getOffset(Instant.now()),
    endTime = Instant.now(),
    endZoneOffset = ZoneOffset.systemDefault().rules.getOffset(Instant.now()),
    volume = Volume.milliliters(250.0),
)

healthConnectClient.insertRecords(listOf(record))

वापस पढ़ना एक टाइम-रेंज क्वेरी है, पूरी टेबल का स्कैन नहीं — आपसे एक विंडो माँगने की उम्मीद की जाती है, “सब कुछ” नहीं:

val response = healthConnectClient.readRecords(
    ReadRecordsRequest(
        recordType = HydrationRecord::class,
        timeRangeFilter = TimeRangeFilter.between(
            startOfToday, Instant.now()
        ),
    )
)

हर रिकॉर्ड के साथ एक metadata.dataOrigin होता है, ताकि आप अपने खुद के राइट्स को किसी फ़िटनेस ट्रैकर या किसी दूसरे ऐप के राइट्स से अलग बता सकें — यह उस पल काम आता है जब आप एक से ज़्यादा सोर्स से “आज का टोटल” जोड़ रहे हों और डबल-काउंट नहीं करना चाहते।

बैकग्राउंड रीड्स को एक अलग परमिशन चाहिए

आपका ऐप फ़ोरग्राउंड में न होने पर Health Connect डेटा पढ़ने के लिए हर रिकॉर्ड की अपनी परमिशन के ऊपर PERMISSION_READ_HEALTH_DATA_IN_BACKGROUND चाहिए, और Android इसे इतना संवेदनशील मानता है कि इसे रैशनेल स्क्रीन में अपनी अलग लाइन मिलती है। अगर आपका यूज़ केस “ऐप खुलने पर एक बार सिंक करना” है, तो इसे छोड़ दें — इसे सिर्फ़ किसी असली बैकग्राउंड जॉब के लिए रिक्वेस्ट करें, जैसे कोई विजेट या कोई डेली रोलअप नोटिफ़िकेशन जिसे यूज़र के ऐप खोलने से पहले ही अपना नंबर गिनना पड़े। जब ज़रूरत न हो तब भी इसे रिक्वेस्ट करना तकनीकी तौर पर फ़ेल नहीं होता; यह बस आपकी परमिशन स्क्रीन को उस फ़ीचर के जायज़ ठहरा सकने से कहीं ज़्यादा लंबा और चिंताजनक बना देता है — और यही वह चीज़ है जो पूरी मंज़ूरी ही गँवा सकती है।

मैं इसे वैकल्पिक, अतिरिक्त डेटा क्यों मानता हूँ

Hydrame जैसे किसी ऐप के लिए, Health Connect एक वजह से लुभावना है: जो यूज़र कहीं और भी वर्कआउट लॉग करता है, उसे दो आपस में न मिलने वाली संख्याओं की बजाय एक सच्चा हाइड्रेशन नंबर मिल जाता है। लेकिन यह ग़लत वजह से भी लुभावना है — “Health Connect पर सिंक करना” चुपचाप “Health Connect अब सोर्स ऑफ़ ट्रुथ है” में बदल जाना आसान है, और उस पल ऐप का अपना लोकल डेटाबेस एक ऐसे कैश में बदल जाता है जो बहक सकता है, और यह वादा कि कुछ भी डिवाइस से बाहर नहीं जाता, हर बार जब किसी और ऐप को रीड एक्सेस मिलता है, थोड़ा और धुंधला हो जाता है। जो वर्शन मैं असल में शिप करूँगा वह Health Connect को उसी लोकल रिकॉर्ड का एक तरफ़ा पब्लिश मानता है, कभी ऐसा रीड पथ नहीं जिस पर ऐप के काम करने की निर्भरता हो — Health Connect ऐप को पूरी तरह अनइंस्टॉल कर दें, तो मुख्य अनुभव को इसका पता तक नहीं चलना चाहिए।

चेकलिस्ट

Health Connect को जोड़ने से पहले: उपलब्धता चेक करें और ऐप के गायब होने की स्थिति हैंडल करें, सिर्फ़ उन्हीं विशिष्ट रिकॉर्ड परमिशन को रिक्वेस्ट करें जिनका आप इस्तेमाल करते हैं, हर एक्सेस से पहले तीन स्क्रीन पुरानी किसी हाँ को कैश रखने के बजाय मंज़ूर परमिशन दोबारा चेक करें, बैकग्राउंड रीड्स को असली बैकग्राउंड काम तक सीमित रखें, और पहले से तय कर लें कि आप Health Connect पर पब्लिश कर रहे हैं या उस पर निर्भर हैं — क्योंकि यह API आपको खुशी-खुशी दोनों करने देगा, और इनमें से सिर्फ़ एक ही एक लोकल-फर्स्ट ऐप को इस बारे में ईमानदार रखता है कि उसका डेटा असल में कहाँ रहता है।