डिवाइस पर मौजूद मनमुताबिक अनुभव पाने के लिए डेवलपर गाइड

ऑन-डिवाइस पर्सनलाइज़ेशन (ओडीपी) को, ऐप्लिकेशन से असली उपयोगकर्ताओं की जानकारी को सुरक्षित रखने के लिए डिज़ाइन किया गया है. ऐप्लिकेशन, ओडीपी का इस्तेमाल करके, उपयोगकर्ताओं के लिए अपने प्रॉडक्ट और सेवाओं को पसंद के मुताबिक बनाते हैं. हालांकि, वे उपयोगकर्ता के लिए किए गए सटीक बदलावों को नहीं देख पाएंगे. ऐसा तब तक होगा, जब तक ऐप्लिकेशन और उपयोगकर्ता के बीच ओडीपी के बाहर सीधे तौर पर इंटरैक्शन नहीं होते. मशीन लर्निंग मॉडल या आंकड़ों के विश्लेषण वाले ऐप्लिकेशन के लिए, ओडीपी सेवाओं और एल्गोरिदम का एक सेट उपलब्ध कराता है. इससे यह पक्का किया जा सकता है कि डिफ़रेंशियल प्राइवसी के सही तरीकों का इस्तेमाल करके, उन्हें ठीक से गुमनाम किया गया हो. ज़्यादा जानकारी के लिए, डिवाइस पर मनमुताबिक बनाने की सुविधा के बारे में जानकारी देने वाला लेख पढ़ें.

ओडीपी, डेवलपर कोड को IsolatedProcess में चलाता है. इसका नेटवर्क, लोकल डिस्क या डिवाइस पर चल रही अन्य सेवाओं से कोई सीधा ऐक्सेस नहीं होता. हालांकि, इसके पास स्थानीय तौर पर सेव किए गए इन डेटा सोर्स का ऐक्सेस होता है:

• RemoteData - रिमोट, डेवलपर के बैकएंड से डाउनलोड किया गया ऐसा डेटा जिसे बदला नहीं जा सकता. हालांकि, यह सिर्फ़ तब लागू होता है, जब ऐसा करना ज़रूरी हो.
• LocalData - डेवलपर की ओर से स्थानीय तौर पर सेव किया गया, बदलाव किया जा सकने वाला कुंजी-वैल्यू डेटा. यह तब लागू होता है, जब ऐसा करना ज़रूरी हो.
• UserData - प्लैटफ़ॉर्म से मिला उपयोगकर्ता डेटा.

इन फ़ॉर्मैट में आउटपुट दिया जा सकता है:

• स्थायी आउटपुट: इन आउटपुट का इस्तेमाल आने वाले समय में स्थानीय प्रोसेसिंग के लिए किया जा सकता है. इससे आउटपुट दिखते हैं, फ़ेडरेटेड लर्निंग की मदद से मॉडल ट्रेनिंग की जाती है या फ़ेडरेटेड ऐनलिटिक्स की मदद से अलग-अलग डिवाइसों पर आंकड़ों का विश्लेषण किया जाता है.
  • डेवलपर, अनुरोधों के साथ-साथ उनकी प्रोसेसिंग के नतीजों को लोकल REQUESTS टेबल में लिख सकते हैं.
  • डेवलपर, पिछले अनुरोध से जुड़ा अतिरिक्त डेटा EVENTS टेबल में लिख सकते हैं.
• दिखाया गया आउटपुट:
  • डेवलपर, WebView में मौजूद SurfaceView में, ODP से रेंडर किया गया एचटीएमएल वापस भेज सकते हैं. वहां रेंडर किया गया कॉन्टेंट, ऐप्लिकेशन को नहीं दिखेगा.
  • डेवलपर, ODP से मिले इवेंट यूआरएल को एचटीएमएल आउटपुट में एम्बेड कर सकते हैं. इससे, रेंडर किए गए एचटीएमएल के साथ उपयोगकर्ता के इंटरैक्शन की लॉगिंग और प्रोसेसिंग ट्रिगर की जा सकती है. ओडीपी, उन यूआरएल के अनुरोधों को इंटरसेप्ट करता है और डेटा जनरेट करने के लिए कोड को लागू करता है. यह डेटा, EVENTS टेबल में लिखा जाता है.

क्लाइंट ऐप्लिकेशन और एसडीके, ओडीपी एपीआई का इस्तेमाल करके SurfaceView में एचटीएमएल कॉन्टेंट दिखाने के लिए, ओडीपी को चालू कर सकते हैं. SurfaceView में रेंडर किया गया कॉन्टेंट, कॉल करने वाले ऐप्लिकेशन को नहीं दिखता. क्लाइंट ऐप्लिकेशन या एसडीके, ओडीपी का इस्तेमाल करके डेवलप करने वाली इकाई से अलग हो सकता है.

ODP सेवा, उस क्लाइंट ऐप्लिकेशन को मैनेज करती है जो अपने यूज़र इंटरफ़ेस (यूआई) में लोगों की दिलचस्पी के हिसाब से कॉन्टेंट दिखाने के लिए, ODP का इस्तेमाल करना चाहता है. यह डेवलपर के दिए गए एंडपॉइंट से कॉन्टेंट डाउनलोड करता है. साथ ही, डाउनलोड किए गए डेटा को प्रोसेस करने के लिए लॉजिक लागू करता है. यह IsolatedProcess और अन्य सेवाओं और ऐप्लिकेशन के बीच होने वाली सभी बातचीत को भी मैनेज करता है.

क्लाइंट ऐप्लिकेशन, OnDevicePersonalizationManager क्लास में मौजूद तरीकों का इस्तेमाल करके, IsolatedProcess में चल रहे डेवलपर के कोड से इंटरैक्ट करते हैं. डेवलपर का कोड, IsolatedProcess में चलता है. यह IsolatedService क्लास को बढ़ाता है और IsolatedWorker इंटरफ़ेस को लागू करता है. IsolatedService को हर अनुरोध के लिए, IsolatedWorker का एक इंस्टेंस बनाना होगा.

इस डायग्राम में, OnDevicePersonalizationManager और IsolatedWorker में मौजूद तरीकों के बीच का संबंध दिखाया गया है.

क्लाइंट ऐप्लिकेशन, IsolatedService नाम के साथ execute तरीके का इस्तेमाल करके, ODP को कॉल करता है. ओडीपी सेवा, कॉल को IsolatedWorker के onExecute तरीके पर फ़ॉरवर्ड करती है. IsolatedWorker, सेव किए जाने वाले रिकॉर्ड और दिखाए जाने वाले कॉन्टेंट को वापस भेजता है. ओडीपी सेवा, परसिस्टेंट आउटपुट को REQUESTS या EVENTS टेबल में लिखती है. साथ ही, क्लाइंट ऐप्लिकेशन को दिखाए गए आउटपुट का ओपेक रेफ़रंस देती है. क्लाइंट ऐप्लिकेशन, इस ओपेक रेफ़रंस का इस्तेमाल आने वाले समय में requestSurfacePackage कॉल में कर सकता है. इससे वह अपने यूज़र इंटरफ़ेस (यूआई) में कोई भी डिसप्ले कॉन्टेंट दिखा सकता है.

परसिस्टेंट आउटपुट

डेवलपर के onExecute को लागू करने के बाद, ODP सेवा REQUESTS टेबल में रिकॉर्ड सेव करती है. REQUESTS टेबल के हर रिकॉर्ड में, ओडीपी सेवा से जनरेट किया गया कुछ सामान्य डेटा होता है. साथ ही, इसमें Rows की सूची होती है. हर Row में, (key, value) पेयर की सूची होती है. हर वैल्यू एक स्केलर, स्ट्रिंग या ब्लॉब होती है. एग्रीगेशन के बाद, संख्या वाली वैल्यू की रिपोर्ट की जा सकती हैं. साथ ही, लोकल या सेंट्रल डिफ़रेंशियल प्राइवसी लागू करने के बाद, स्ट्रिंग या ब्लॉब डेटा की रिपोर्ट की जा सकती है. डेवलपर, उपयोगकर्ता के इंटरैक्शन से जुड़े इवेंट को EVENTS टेबल में भी लिख सकते हैं. EVENTS टेबल का हर रिकॉर्ड, REQUESTS टेबल की किसी लाइन से जुड़ा होता है. ओडीपी सेवा, हर रिकॉर्ड के साथ कॉल करने वाले ऐप्लिकेशन का टाइमस्टैंप और पैकेज का नाम लॉग करती है. साथ ही, ओडीपी डेवलपर के APK का नाम भी लॉग करती है.

शुरू करने से पहले

ODP का इस्तेमाल करके डेवलपमेंट शुरू करने से पहले, आपको अपना पैकेज मेनिफ़ेस्ट सेट अप करना होगा और डेवलपर मोड चालू करना होगा.

पैकेज मेनिफ़ेस्ट की सेटिंग

ओडीपी का इस्तेमाल करने के लिए, ये ज़रूरी शर्तें पूरी करनी होंगी:

1. AndroidManifest.xml में मौजूद <property> टैग, पैकेज में मौजूद एक्सएमएल रिसॉर्स की ओर इशारा करता है. इस पैकेज में ओडीपी कॉन्फ़िगरेशन की जानकारी होती है.
2. AndroidManifest.xml में मौजूद <service> टैग, IsolatedService को बढ़ाने वाली क्लास की पहचान करता है. इसे यहां दिए गए उदाहरण में दिखाया गया है. <service> टैग में मौजूद सेवा के लिए, exported और isolatedProcess एट्रिब्यूट को true पर सेट किया जाना चाहिए.
3. पहले चरण में बताई गई XML फ़ाइल में मौजूद <service> टैग, दूसरे चरण में बताई गई सेवा की क्लास की पहचान करता है. <service> टैग में, ओडीपी से जुड़ी अन्य सेटिंग भी शामिल होनी चाहिए. ये सेटिंग, टैग में ही शामिल होती हैं. इसके बारे में दूसरे उदाहरण में बताया गया है.

AndroidManifest.xml

<!-- Contents of AndroidManifest.xml -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.odpsample" >
    <application android:label="OdpSample">
        <!-- XML resource that contains other ODP settings. -->
        <property android:name="android.ondevicepersonalization.ON_DEVICE_PERSONALIZATION_CONFIG"
                  android:resource="@xml/OdpSettings"></property>
        <!-- The service that ODP binds to. -->
        <service android:name="com.example.odpsample.SampleService"
                android:exported="true" android:isolatedProcess="true" />
    </application>
</manifest>

एक्सएमएल रिसॉर्स में ओडीपी के लिए खास मेनिफ़ेस्ट

<property> टैग में बताई गई एक्सएमएल रिसॉर्स फ़ाइल में, <service> टैग में सेवा क्लास का एलान भी किया जाना चाहिए. साथ ही, उस यूआरएल एंडपॉइंट के बारे में भी बताया जाना चाहिए जहां से ओडीपी, RemoteData टेबल में डेटा भरने के लिए कॉन्टेंट डाउनलोड करेगा. इस बारे में यहां दिए गए उदाहरण में बताया गया है. अगर फ़ेडरेटेड कंप्यूट की सुविधाओं का इस्तेमाल किया जा रहा है, तो आपको फ़ेडरेटेड कंप्यूट सर्वर यूआरएल एंडपॉइंट भी तय करना होगा. फ़ेडरेटेड कंप्यूट क्लाइंट इसी से कनेक्ट होगा.

<!-- Contents of res/xml/OdpSettings.xml -->
<on-device-personalization>
   <!-- Name of the service subclass -->
   <service name="com.example.odpsample.SampleService">
     <!-- If this tag is present, ODP will periodically poll this URL and
          download content to populate REMOTE_DATA. Developers that do not need to
          download content from their servers can skip this tag. -->
     <download-settings url="https://example.com/get" />
     <!-- If you want to use federated compute feature to train a model, you
          need to specify this tag. -->
     <federated-compute-settings url="https://fcpserver.example.com/" />
   </service>
</on-device-personalization>

डेवलपर मोड चालू करना

Android Studio के दस्तावेज़ में मौजूद, डेवलपर के लिए सेटिंग और टूल चालू करना सेक्शन में दिए गए निर्देशों का पालन करके, डेवलपर मोड चालू करें.

स्विच करने और फ़्लैग करने की सेटिंग

ODP में स्विच और फ़्लैग का एक सेट होता है. इनका इस्तेमाल कुछ सुविधाओं को कंट्रोल करने के लिए किया जाता है:

• _global_killswitch: यह सभी ओडीपी सुविधाओं के लिए ग्लोबल स्विच है. ओडीपी का इस्तेमाल करने के लिए, इसे false पर सेट करें
• _federated_compute_kill_switch: _यह स्विच, ODP की सभी ट्रेनिंग (फ़ेडरेटेड लर्निंग) सुविधाओं को कंट्रोल करता है. ट्रेनिंग का इस्तेमाल करने के लिए, इसे false पर सेट करें
• _caller_app_allowlist: इससे यह कंट्रोल किया जाता है कि ODP को कॉल करने की अनुमति किसे है. यहां ऐप्लिकेशन (पैकेज का नाम, [ज़रूरी नहीं] सर्टिफ़िकेट) जोड़े जा सकते हैं. सभी को अनुमति देने के लिए, इसे * के तौर पर सेट करें
• _isolated_service_allowlist: इससे यह कंट्रोल किया जाता है कि Isolated Service प्रोसेस में कौनसी सेवाएं चल सकती हैं.

सभी स्विच और फ़्लैग को बिना किसी पाबंदी के ओडीपी का इस्तेमाल करने के लिए कॉन्फ़िगर करने के लिए, यहां दिए गए निर्देशों का पालन करें:

# Set flags and killswitches
adb shell device_config set_sync_disabled_for_tests persistent
adb shell device_config put on_device_personalization global_kill_switch false
adb shell device_config put on_device_personalization federated_compute_kill_switch false
adb shell device_config put on_device_personalization caller_app_allow_list \"*\"
adb shell device_config put on_device_personalization isolated_service_allow_list \"*\"

डिवाइस-साइड एपीआई

ओडीपी के लिए, Android API का रेफ़रंस दस्तावेज़ देखें.

IsolatedService के साथ इंटरैक्शन

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

डेवलपर को IsolatedWorker इंटरफ़ेस के तरीकों को लागू करना होगा. इससे क्लाइंट ऐप्लिकेशन के अनुरोधों को मैनेज किया जा सकेगा. साथ ही, डाउनलोड पूरा होने और रेंडर किए गए एचटीएमएल से ट्रिगर होने वाले इवेंट को मैनेज किया जा सकेगा. इन सभी तरीकों में, डिफ़ॉल्ट रूप से नो-ऑप लागू होते हैं. इसलिए, डेवलपर उन तरीकों को लागू करना छोड़ सकते हैं जिनमें उनकी दिलचस्पी नहीं है.

OnDevicePersonalizationManager क्लास, ऐप्लिकेशन और एसडीके के लिए एक एपीआई उपलब्ध कराती है. इससे वे डेवलपर के लागू किए गए IsolatedService के साथ इंटरैक्ट कर पाते हैं. यह IsolatedService, अलग प्रोसेस में चलता है. यहां इस्तेमाल के कुछ उदाहरण दिए गए हैं:

SurfaceView में दिखाने के लिए एचटीएमएल कॉन्टेंट जनरेट करना

OnDevicePersonalizationManager#execute की मदद से, दिखाने के लिए कॉन्टेंट जनरेट करने के लिए, कॉल करने वाला ऐप्लिकेशन, बाद के requestSurfacePackage कॉल में मिले SurfacePackageToken ऑब्जेक्ट का इस्तेमाल कर सकता है. इससे, SurfaceView में नतीजे रेंडर करने का अनुरोध किया जा सकता है.

अगर अनुरोध पूरा हो जाता है, तो रिसीवर को SurfacePackage के साथ कॉल किया जाता है. यह SurfacePackage, ओडीपी सेवा से रेंडर किए गए व्यू के लिए होता है. क्लाइंट ऐप्लिकेशन को अपनी व्यू हैरारकी में मौजूद SurfaceView में SurfacePackage को डालना होगा.

जब कोई ऐप्लिकेशन, पहले किए गए OnDevicePersonalizationManager#execute कॉल से मिले SurfacePackageToken के साथ requestSurfacePackage कॉल करता है, तब ओडीपी सेवा, IsolatedWorker#onRender को कॉल करती है. इससे, फ़ेंस किए गए फ़्रेम में रेंडर किए जाने वाले एचटीएमएल स्निपेट को फ़ेच किया जा सकता है. इस फ़ेज़ के दौरान, डेवलपर के पास LocalData या UserData का ऐक्सेस नहीं होता. इससे डेवलपर को जनरेट किए गए एचटीएमएल में, ऐसेट फ़ेच करने वाले यूआरएल में संभावित रूप से संवेदनशील UserData एम्बेड करने से रोका जाता है. डेवलपर, जनरेट किए गए एचटीएमएल में शामिल करने के लिए, ट्रैकिंग यूआरएल जनरेट करने के लिए IsolatedService#getEventUrlProvider का इस्तेमाल कर सकते हैं. एचटीएमएल रेंडर होने पर, ओडीपी सेवा इन यूआरएल के अनुरोधों को इंटरसेप्ट करेगी और IsolatedWorker#onEvent को कॉल करेगी. onRender() को लागू करते समय, getRemoteData() को शुरू किया जा सकता है.

एचटीएमएल कॉन्टेंट में इवेंट ट्रैक करना

EventUrlProvider क्लास, इवेंट ट्रैकिंग यूआरएल जनरेट करने के लिए एपीआई उपलब्ध कराती है. डेवलपर इन्हें अपने एचटीएमएल आउटपुट में शामिल कर सकते हैं. एचटीएमएल रेंडर होने पर, ODP, इवेंट यूआरएल के पेलोड के साथ IsolatedWorker#onEvent को चालू करेगा.

ODP सेवा, रेंडर किए गए एचटीएमएल में, ODP से जनरेट किए गए इवेंट यूआरएल के अनुरोधों को इंटरसेप्ट करती है. साथ ही, IsolatedWorker#onEvent को कॉल करती है और EventLogRecord को EVENTS टेबल में लॉग करती है.

हमेशा के लिए नतीजे लिखना

OnDevicePersonalizationManager#execute की मदद से, सेवा के पास डेटा को परसिस्टेंट स्टोरेज (REQUESTS और EVENTS टेबल) में लिखने का विकल्प होता है. यहां दी गई टेबल में, इन टेबल में लिखी जा सकने वाली एंट्री दी गई हैं:

• RequestLogRecord टेबल में जोड़ने के लिए RequestLogRecord.REQUESTS
• EventLogRecord ऑब्जेक्ट की सूची, जिसे EVENTS टेबल में जोड़ा जाना है. इनमें से हर ऑब्जेक्ट में, पहले से लिखे गए RequestLogRecord का पॉइंटर होता है.

डिवाइस पर सेव किए गए नतीजों का इस्तेमाल, फ़ेडरेटेड लर्निंग की मदद से मॉडल को ट्रेनिंग देने के लिए किया जा सकता है.

डिवाइस पर ट्रेनिंग से जुड़े टास्क मैनेज करना

फ़ेडरेटेड कंप्यूट ट्रेनिंग का काम शुरू होने पर, ODP सेवा IsolatedWorker#onTrainingExample को कॉल करती है. ऐसा तब होता है, जब उसे ODP का इस्तेमाल करने वाले डेवलपर से ट्रेनिंग के उदाहरण चाहिए होते हैं. onTrainingExample() को लागू करते समय, getRemoteData(), getLocalData(), getUserData(), और getLogReader() को चालू किया जा सकता है.

फ़ेडरेटेड कंप्यूट जॉब शेड्यूल करने या रद्द करने के लिए, FederatedComputeScheduler क्लास का इस्तेमाल किया जा सकता है. यह क्लास, सभी ओडीपी IsolatedService के लिए एपीआई उपलब्ध कराती है. फ़ेडरेटेड कंप्यूट के हर जॉब की पहचान, उसके पॉपुलेशन के नाम से की जा सकती है.

फ़ेडरेटेड कंप्यूट का नया जॉब शेड्यूल करने से पहले:

• इस पॉपुलेशन के नाम से, फ़ेडरेटेड कंप्यूट सर्वर पर पहले से ही एक टास्क बनाया जाना चाहिए.
• फ़ेडरेटेड कंप्यूट सर्वर यूआरएल एंडपॉइंट को पैकेज मेनिफ़ेस्ट सेटिंग में federated-compute-settings टैग के साथ पहले से ही तय किया जाना चाहिए.

लगातार दिखने वाले आउटपुट के साथ इंटरैक्शन

यहां दिए गए सेक्शन में, ओडीपी में परसिस्टेंट आउटपुट के साथ इंटरैक्ट करने का तरीका बताया गया है.

स्थानीय टेबल को पढ़ता है

LogReader क्लास, REQUESTS और EVENTS टेबल को पढ़ने के लिए एपीआई उपलब्ध कराती है. इन टेबल में वह डेटा शामिल होता है जिसे IsolatedService ने onExecute() या onEvent() कॉल के दौरान लिखा था. इन टेबल में मौजूद डेटा का इस्तेमाल, फ़ेडरेटेड लर्निंग की मदद से मॉडल को ट्रेनिंग देने या फ़ेडरेटेड ऐनलिटिक्स की मदद से अलग-अलग डिवाइसों पर आंकड़ों का विश्लेषण करने के लिए किया जा सकता है.

डाउनलोड किए गए कॉन्टेंट के साथ इंटरैक्शन

नीचे दिए गए सेक्शन में, ओडीपी में डाउनलोड किए गए कॉन्टेंट के साथ इंटरैक्ट करने का तरीका बताया गया है.

सर्वर से कॉन्टेंट डाउनलोड करना

ओडीपी सेवा, IsolatedService के पैकेज मेनिफ़ेस्ट में बताए गए यूआरएल से समय-समय पर कॉन्टेंट डाउनलोड करती है. डाउनलोड पूरा होने के बाद, यह onDownloadCompleted को कॉल करती है. डाउनलोड की गई फ़ाइल, की-वैल्यू पेयर वाली JSON फ़ाइल होती है.

ओडीपी का इस्तेमाल करने वाले डेवलपर यह चुन सकते हैं कि डाउनलोड किए गए कॉन्टेंट के किस सबसेट को RemoteData टेबल में जोड़ा जाना चाहिए और किसे हटाया जाना चाहिए. डेवलपर, डाउनलोड किए गए कॉन्टेंट में बदलाव नहीं कर सकते. इससे यह पक्का होता है कि RemoteData टेबल में उपयोगकर्ता का कोई डेटा शामिल नहीं है. इसके अलावा, डेवलपर अपनी पसंद के हिसाब से LocalData टेबल में डेटा भर सकते हैं. उदाहरण के लिए, वे पहले से कैलकुलेट किए गए कुछ नतीजों को कैश मेमोरी में सेव कर सकते हैं.

डाउनलोड करने के अनुरोध का फ़ॉर्मैट

ओडीपी, डेवलपर के पैकेज मेनिफ़ेस्ट में बताए गए यूआरएल एंडपॉइंट को समय-समय पर पोल करता है. इससे वह RemoteData टेबल में कॉन्टेंट भर पाता है.

एंडपॉइंट से, JSON फ़ॉर्मैट में रिस्पॉन्स मिलने की उम्मीद की जाती है. इसके बारे में बाद में बताया गया है. JSON रिस्पॉन्स में एक syncToken होना चाहिए. इससे भेजे जा रहे डेटा के वर्शन की पहचान होती है. साथ ही, इसमें की-वैल्यू पेयर की एक ऐसी सूची भी होनी चाहिए जिसे भरा जाना है. syncToken की वैल्यू, सेकंड में टाइमस्टैंप होनी चाहिए. साथ ही, इसे यूटीसी के घंटे की सीमा के हिसाब से तय किया जाना चाहिए. डाउनलोड करने के अनुरोध के तहत, ODP, पहले पूरा किए गए डाउनलोड का syncToken और डिवाइस के देश की जानकारी देता है. यह जानकारी, डाउनलोड यूआरएल में syncToken और country पैरामीटर के तौर पर दी जाती है. सर्वर, इंक्रीमेंटल डाउनलोड लागू करने के लिए, पिछले syncToken का इस्तेमाल कर सकता है.

फ़ाइल फ़ॉर्मैट डाउनलोड करें

डाउनलोड की गई फ़ाइल, JSON फ़ाइल होती है. इसका स्ट्रक्चर यहां दिया गया है. JSON फ़ाइल में syncToken होना चाहिए, ताकि डाउनलोड किए जा रहे डेटा के वर्शन की पहचान की जा सके. syncToken, यूटीसी टाइमस्टैंप होना चाहिए. साथ ही, इसे घंटे की सीमा पर सेट किया जाना चाहिए. इसके अलावा, यह पिछले डाउनलोड के syncToken से ज़्यादा होना चाहिए. अगर syncToken, दोनों ज़रूरी शर्तों को पूरा नहीं करता है, तो डाउनलोड किए गए कॉन्टेंट को बिना प्रोसेस किए ही खारिज कर दिया जाता है.

कॉन्टेंट फ़ील्ड, (कुंजी, डेटा, एन्कोडिंग) टपल की सूची होती है. key, UTF-8 स्ट्रिंग होनी चाहिए. encoding फ़ील्ड एक वैकल्पिक पैरामीटर है. इससे यह तय होता है कि data फ़ील्ड को कैसे एन्कोड किया गया है. इसे "utf8" या "base64" पर सेट किया जा सकता है. डिफ़ॉल्ट रूप से, इसे "utf8" माना जाता है. onDownloadCompleted(). को कॉल करने से पहले, key फ़ील्ड को String ऑब्जेक्ट में बदल दिया जाता है और data फ़ील्ड को बाइट ऐरे में बदल दिया जाता है

{
  // syncToken must be a UTC timestamp clamped to an hour boundary, and must be
  // greater than the syncToken of the previously completed download.
  "syncToken": <timeStampInSecRoundedToUtcHour>,
  "contents": [
    // List of { key, data } pairs.
    { "key": "key1",
      "data": "data1"
    },
    { "key": "key2",
      "data": "data2",
      "encoding": "base64"
    },
    // ...
  ]
}

सर्वर-साइड एपीआई

इस सेक्शन में, फ़ेडरेटेड कंप्यूट सर्वर एपीआई के साथ इंटरैक्ट करने का तरीका बताया गया है.

Federated Compute Server API

क्लाइंट-साइड पर फ़ेडरेटेड कंप्यूट जॉब शेड्यूल करने के लिए, आपको एक ऐसे टास्क की ज़रूरत होगी जिसका पॉपुलेशन नेम, रिमोट फ़ेडरेटेड कंप्यूट सर्वर पर बनाया गया हो. इस सेक्शन में, हम फ़ेडरेटेड कंप्यूट सर्वर पर ऐसा टास्क बनाने का तरीका बताते हैं.

ओडीपी डेवलपर को Task Builder के लिए नया टास्क बनाते समय, फ़ाइलों के दो सेट देने चाहिए:

1. tff.learning.models.save_functional_model एपीआई कॉल करके, सेव किया गया tff.learning.models.FunctionalModel मॉडल. आपको हमारी GitHub रिपॉज़िटरी में एक सैंपल मिल सकता है.
2. fcp_server_config.json फ़ाइल, जिसमें नीतियां, फ़ेडरेटेड लर्निंग सेटअप, और डिफ़रेंशियल निजता सेटअप शामिल होता है. यहां fcp_server_config.json का एक उदाहरण दिया गया है:

{
  # Task execution mode.
  mode: TRAINING_AND_EVAL
  # Identifies the set of client devices that participate.
  population_name: "mnist_cnn_task"
  policies {
    # Policy for sampling on-device examples. It is checked every
    # time a device is attempting to start a new training.
    min_separation_policy {
      # The minimum separation required between two successful
      # consective task executions. If a client successfully contributes
      # to a task at index `x`, the earliest they can contribute again
      # is at index `(x + minimum_separation)`. This is required by
      # DP.
      minimum_separation: 1
    }
    data_availability_policy {
      # The minimum number of examples on a device to be considered
      # eligible for training.
      min_example_count: 1
    }
    # Policy for releasing training results to developers adopting ODP.
    model_release_policy {
      # The maximum number of training rounds.
      num_max_training_rounds: 512
    }
  }

  # Federated learning setups. They are applied inside Task Builder.
  federated_learning {
    # Use federated averaging to build federated learning process.
    # Options you can choose:
      # * FED_AVG: Federated Averaging algorithm
      #            (https://arxiv.org/abs/2003.00295)
      # * FED_SGD: Federated SGD algorithm
      #            (https://arxiv.org/abs/1602.05629)
    type: FED_AVG
    learning_process {
      # Optimizer used at client side training. Options you can choose:
      # * ADAM
      # * SGD
      client_optimizer: SGD
      # Learning rate used at client side training.
      client_learning_rate: 0.02
      # Optimizer used at server side training. Options you can choose:
      # * ADAM
      # * SGD
      server_optimizer: SGD
      # Learning rate used at server side training.
      server_learning_rate: 1.0
      runtime_config {
        # Number of participating devices for each round of training.
      report_goal: 2
      }
      metrics {
        name: "sparse_categorical_accuracy"
      }
    }
    evaluation {
      # A checkpoint selector controls how checkpoints are chosen for
      # evaluation. One evaluation task typically runs per training
      # task, and on each round of execution, the eval task
      # randomly picks one checkpoint from the past 24 hours that has
      # been selected for evaluation by these rules.
      # Every_k_round and every_k_hour are definitions of quantization
      # buckets which each checkpoint is placed in for selection.
      checkpoint_selector: "every_1_round"
      # The percentage of a populate that should delicate to this
      # evaluation task.
      evaluation_traffic: 0.2
      # Number of participating devices for each round of evaluation.
      report_goal: 2
    }
  }

  # Differential Privacy setups. They are enforced inside the Task
  # Builder.
  differential_privacy {
    # * fixed_gaussian: DP-SGD with fixed clipping norm described in
    #                   "Learning Differentially Private Recurrent
    #                   Language Models"
    #                   (https://arxiv.org/abs/1710.06963).
    type: FIXED_GAUSSIAN
    #   The value of the clipping norm.
    clip_norm: 0.1
    # Noise multiplier for the Gaussian noise.
    noise_multiplier: 0.1
  }
}

हमारी GitHub रिपॉज़िटरी में, आपको ज़्यादा सैंपल मिल सकते हैं.

इन दोनों इनपुट को तैयार करने के बाद, आर्टफ़ैक्ट बनाने और नए टास्क जनरेट करने के लिए, टास्क बिल्डर को शुरू करें. ज़्यादा जानकारी हमारी GitHub रिपॉज़िटरी में उपलब्ध है.