Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

ऑटो बैकअप से उपयोगकर्ता के डेटा का बैक अप लें

ऐप्लिकेशन के लिए ऑटो बैकअप की सुविधा, उपयोगकर्ता के डेटा का बैकअप अपने-आप लेती है. यह सुविधा, Android 6.0 (एपीआई लेवल 23) या इसके बाद के वर्शन पर काम करने वाले ऐप्लिकेशन के लिए उपलब्ध है. Android, ऐप्लिकेशन के डेटा को उपयोगकर्ता के Google Drive पर अपलोड करके सुरक्षित रखता है. यहां यह डेटा, उपयोगकर्ता के Google खाते के क्रेडेंशियल से सुरक्षित रहता है. Android 9 या इसके बाद के वर्शन वाले डिवाइसों पर, बैकअप को पूरी तरह सुरक्षित किया जाता है. इसके लिए, डिवाइस के पिन, पैटर्न या पासवर्ड का इस्तेमाल किया जाता है. हर ऐप्लिकेशन, अपने हर उपयोगकर्ता के लिए ज़्यादा से ज़्यादा 25 एमबी बैकअप डेटा तय कर सकता है. बैकअप डेटा को सेव करने के लिए, कोई शुल्क नहीं लिया जाता. आपका ऐप्लिकेशन, बैकअप लेने की प्रोसेस को पसंद के मुताबिक बना सकता है या बैकअप लेने की सुविधा बंद करके ऑप्ट आउट कर सकता है.

Android पर बैकअप लेने के विकल्पों की खास जानकारी पाने और यह जानने के लिए कि किस डेटा का बैकअप लेना और उसे वापस पाना है, डेटा के बैकअप की खास जानकारी देखें.

ऐसी फ़ाइलें जिनका बैक अप लिया गया है

डिफ़ॉल्ट रूप से, ऑटो बैकअप की सुविधा में उन ज़्यादातर डायरेक्ट्री की फ़ाइलें शामिल होती हैं जिन्हें सिस्टम ने आपके ऐप्लिकेशन को असाइन किया है:

शेयर की गई प्राथमिकताओं वाली फ़ाइलें
ऐप्लिकेशन के इंटरनल स्टोरेज में सेव की गई फ़ाइलें, जिन्हें getFilesDir() या getDir(String, int) से ऐक्सेस किया जाता है
getDatabasePath(String) से मिली डायरेक्ट्री में मौजूद फ़ाइलें. इनमें SQLiteOpenHelper क्लास से बनाई गई फ़ाइलें भी शामिल हैं
getExternalFilesDir(String) से मिली डायरेक्ट्री में, बाहरी स्टोरेज पर मौजूद फ़ाइलें

ऑटो बैकअप की सुविधा, getCacheDir(), getCodeCacheDir(), और getNoBackupFilesDir() से मिलने वाली डायरेक्ट्री में मौजूद फ़ाइलों को शामिल नहीं करती. इन जगहों पर सेव की गई फ़ाइलों की ज़रूरत सिर्फ़ कुछ समय के लिए होती है. इसलिए, इन्हें बैकअप लेने की प्रोसेस से जान-बूझकर बाहर रखा जाता है.

अपने ऐप्लिकेशन को इस तरह कॉन्फ़िगर किया जा सकता है कि उसमें कुछ खास फ़ाइलें शामिल की जा सकें और कुछ को बाहर रखा जा सके. ज़्यादा जानकारी के लिए, फ़ाइलें शामिल करना और बाहर रखना सेक्शन देखें.

ध्यान दें: Android, कॉम्पोनेंट के कॉन्फ़िगरेशन को उपयोगकर्ता के डेटा के तौर पर नहीं मानता. अगर आपका ऐप्लिकेशन, रन होने के दौरान अपने मेनिफ़ेस्ट में कुछ कॉम्पोनेंट को चालू या बंद करता है, तो ऑटो बैकअप की सुविधा, कॉन्फ़िगरेशन को अपने-आप सेव और वापस नहीं लाती. कॉन्फ़िगरेशन की स्थिति को बनाए रखने के लिए, स्थिति को शेयर की गई सेटिंग में सेव करें और रीस्टोर करने पर, शेयर की गई सेटिंग वापस पाएं.

बैकअप की जगह

बैकअप डेटा, उपयोगकर्ता के Google Drive खाते में मौजूद एक निजी फ़ोल्डर में सेव किया जाता है. हर ऐप्लिकेशन के लिए, 25 एमबी तक का डेटा सेव किया जा सकता है. सेव किया गया डेटा, उपयोगकर्ता के निजी Google Drive कोटे में नहीं गिना जाता. सिर्फ़ सबसे हाल ही का बैकअप सेव किया जाता है. बैकअप लेने पर, पिछला बैकअप मिटा दिया जाता है. बैकअप डेटा को उपयोगकर्ता या डिवाइस पर मौजूद अन्य ऐप्लिकेशन नहीं पढ़ सकते.

उपयोगकर्ता, Google Drive के Android ऐप्लिकेशन में उन ऐप्लिकेशन की सूची देख सकते हैं जिनका बैकअप लिया गया है. Android डिवाइस पर, उपयोगकर्ता इस सूची को Drive ऐप्लिकेशन के नेविगेशन पैनल में, सेटिंग > बैकअप लें और रीसेट करें में जाकर देख सकते हैं.

हर डिवाइस-सेटअप-लाइफ़टाइम के बैकअप, अलग-अलग डेटासेट में सेव किए जाते हैं. इसके बारे में यहां दिए गए उदाहरणों में बताया गया है:

अगर उपयोगकर्ता के पास दो डिवाइस हैं, तो हर डिवाइस के लिए एक बैकअप डेटासेट मौजूद होता है.
अगर उपयोगकर्ता किसी डिवाइस को फ़ैक्ट्री रीसेट करता है और फिर उसी खाते से डिवाइस को सेट अप करता है, तो बैकअप को नए डेटासेट में सेव किया जाता है. इस्तेमाल न किए जाने वाले डेटासेट, कुछ समय बाद अपने-आप मिट जाते हैं.

बैकअप का शेड्यूल

बैकअप अपने-आप तब लिया जाता है, जब ये सभी शर्तें पूरी होती हैं:

उपयोगकर्ता ने डिवाइस पर बैकअप लेने की सुविधा चालू की हो. Android 9 में, यह सेटिंग सेटिंग > सिस्टम > बैकअप में होती है.
पिछली बार बैकअप लिए हुए कम से कम 24 घंटे हो गए हों.
डिवाइस कुछ समय से इस्तेमाल में नहीं है.
डिवाइस किसी वाई-फ़ाई नेटवर्क से कनेक्ट हो. हालांकि, ऐसा तब ज़रूरी है, जब डिवाइस इस्तेमाल करने वाले व्यक्ति ने मोबाइल डेटा से बैकअप लेने की सुविधा के लिए ऑप्ट इन न किया हो.

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

ऑटो बैकअप के दौरान, सिस्टम ऐप्लिकेशन को बंद कर देता है, ताकि यह पक्का किया जा सके कि वह फ़ाइल सिस्टम में अब और डेटा सेव न करे. डिफ़ॉल्ट रूप से, बैकअप सिस्टम उन ऐप्लिकेशन को अनदेखा कर देता है जो फ़ोरग्राउंड में चल रहे हैं. इससे उपयोगकर्ता अनुभव खराब नहीं होता. android:backupInForeground एट्रिब्यूट को true पर सेट करके, डिफ़ॉल्ट तरीके को बदला जा सकता है.

जांच को आसान बनाने के लिए, Android में ऐसे टूल शामिल हैं जिनकी मदद से, ऐप्लिकेशन के बैकअप को मैन्युअल तरीके से शुरू किया जा सकता है. ज़्यादा जानकारी के लिए, बैकअप और डेटा वापस पाने की सुविधा की जांच करना लेख पढ़ें.

शेड्यूल को पहले जैसा करना

ऐप्लिकेशन इंस्टॉल होने पर, डेटा वापस लाया जाता है. भले ही, ऐप्लिकेशन को Play Store से इंस्टॉल किया गया हो, डिवाइस सेटअप करने के दौरान (जब सिस्टम पहले से इंस्टॉल किए गए ऐप्लिकेशन इंस्टॉल करता है) या adb इंस्टॉल करके. डेटा वापस पाने की प्रोसेस, APK इंस्टॉल होने के बाद शुरू होती है. हालांकि, यह प्रोसेस तब तक पूरी हो जाती है, जब तक उपयोगकर्ता ऐप्लिकेशन को लॉन्च करने के लिए तैयार होता है.

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

जांच को आसान बनाने के लिए, Android में ऐसे टूल शामिल हैं जिनकी मदद से, ऐप्लिकेशन को मैन्युअल तरीके से रीस्टोर किया जा सकता है. ज़्यादा जानकारी के लिए, बैकअप और रीस्टोर की जांच करना लेख पढ़ें.

बैकअप लेने की सुविधा चालू और बंद करना

Android 6.0 (एपीआई लेवल 23) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, ऑटो बैकअप की सुविधा में अपने-आप शामिल हो जाते हैं. बैकअप लेने की सुविधा को चालू या बंद करने के लिए, अपनी ऐप्लिकेशन मेनिफ़ेस्ट फ़ाइल में बूलियन वैल्यू android:allowBackup सेट करें. डिफ़ॉल्ट वैल्यू true है. हालांकि, हमारा सुझाव है कि आप अपने मेनिफ़ेस्ट में एट्रिब्यूट को साफ़ तौर पर सेट करें. इसके बारे में यहां दिए गए उदाहरण में बताया गया है:

<manifest ... >
    ...
    <application android:allowBackup="true" ... >
        ...
    </application>
</manifest>

बैकअप लेने की सुविधा को बंद करने के लिए, android:allowBackup को false पर सेट करें. ऐसा तब किया जा सकता है, जब आपका ऐप्लिकेशन किसी अन्य तरीके से अपनी स्थिति को फिर से बना सकता हो या आपका ऐप्लिकेशन संवेदनशील जानकारी से जुड़ा हो.

ध्यान दें: Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, यह तरीका अलग-अलग होता है. कुछ डिवाइस मैन्युफ़ैक्चरर के डिवाइसों पर, android:allowBackup="false" को तय करने से क्लाउड-आधारित बैकअप और डेटा वापस पाने की सुविधा (जैसे कि Google Drive बैकअप) बंद हो जाती है. हालांकि, इससे ऐप्लिकेशन के लिए, एक डिवाइस से दूसरे डिवाइस पर डेटा ट्रांसफ़र करने की सुविधा बंद नहीं होती. ज़्यादा जानकारी के लिए, बैकअप और डेटा वापस पाने की सुविधा में हुए बदलावों के बारे में जानकारी देखें.

फ़ाइलों को शामिल करना और बाहर रखना

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

आपके पास यह कंट्रोल करने का विकल्प होता है कि ट्रांसफ़र के टाइप के आधार पर, बैकअप में कौनसा डेटा शामिल किया जाए. ऑटो बैकअप की सुविधा, Google Drive पर क्लाउड बैकअप लेने और सीधे एक डिवाइस से दूसरे डिवाइस (डी2डी) पर डेटा ट्रांसफ़र करने की सुविधा के साथ काम करती है. कॉन्फ़िगरेशन के तरीके, Android वर्शन और आपके ऐप्लिकेशन के targetSdkVersion के हिसाब से अलग-अलग होते हैं.

Android 11 या इससे पहले के वर्शन वाले डिवाइसों के लिए, Android 11 और इससे पहले के वर्शन पर बैकअप को कंट्रोल करना लेख पढ़ें.
Android 12 या इसके बाद के वर्शन वाले डिवाइसों पर, एपीआई लेवल 31 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, data-extraction-rules फ़ॉर्मैट का इस्तेमाल करते हैं. ज़्यादा जानकारी के लिए, Android 12 या इसके बाद के वर्शन पर बैकअप को कंट्रोल करना लेख पढ़ें.
data-extraction-rules फ़ॉर्मैट में, क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र की सुविधा भी काम करती है. जैसे, iOS पर ट्रांसफ़र करना. यह सुविधा, Android 16 QPR2 से उपलब्ध है. क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र कॉन्फ़िगर करना लेख में ज़्यादा जानें.

Android 11 और इससे पहले के वर्शन पर बैकअप कंट्रोल करना

Android 11 (एपीआई लेवल 30) या इससे पहले के वर्शन वाले डिवाइसों पर, बैकअप ली जाने वाली फ़ाइलों को कंट्रोल करने के लिए, इस सेक्शन में दिया गया तरीका अपनाएं.

अहम जानकारी: अगर आपका ऐप्लिकेशन Android 11 या इससे पहले के वर्शन को टारगेट करता है, तो एक्सएमएल बैकअप के ये नियम, Android 12 या इसके बाद के वर्शन वाले डिवाइसों के लिए भी इस्तेमाल किए जाते हैं. Android 12 या इसके बाद के वर्शन वाले डिवाइसों के लिए, बैकअप और रीस्टोर करने की सुविधा में किए गए बदलावों के बारे में जानने के लिए, यहां दिया गया सेक्शन देखें. इसमें एक्सएमएल बैकअप के नियमों का एक अतिरिक्त सेट भी दिया गया है.

अपनी AndroidManifest.xml फ़ाइल में, <application> एलिमेंट में android:fullBackupContent एट्रिब्यूट जोड़ें. इसके लिए, यहां दिया गया उदाहरण देखें. यह एट्रिब्यूट, बैकअप के नियमों वाली एक्सएमएल फ़ाइल पर ले जाता है.
```
<application ...
    android:fullBackupContent="@xml/backup_rules">
</application>
```
res/xml/ डायरेक्ट्री में @xml/backup_rules नाम की एक एक्सएमएल फ़ाइल बनाएं. इस फ़ाइल में, <include> और <exclude> एलिमेंट के साथ नियम जोड़ें. यहां दिए गए सैंपल में, device.xml को छोड़कर, शेयर की गई सभी प्राथमिकताओं का बैकअप लिया जाता है:
```
<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
  <include domain="sharedpref" path="."/>
  <exclude domain="sharedpref" path="device.xml"/>
</full-backup-content>
```

बैकअप लेने के लिए, डिवाइस की ज़रूरी शर्तें तय करना

अगर आपका ऐप्लिकेशन, डिवाइस पर संवेदनशील जानकारी सेव करता है, तो आपके पास यह तय करने का विकल्प होता है कि किन शर्तों के तहत आपके ऐप्लिकेशन का डेटा, उपयोगकर्ता के बैकअप में शामिल किया जाए. Android 9 (एपीआई लेवल 28) या इसके बाद के वर्शन में, ये शर्तें जोड़ी जा सकती हैं:

clientSideEncryption: उपयोगकर्ता के बैकअप को क्लाइंट-साइड सीक्रेट की मदद से एन्क्रिप्ट (सुरक्षित) किया गया है. एन्क्रिप्ट करने का यह तरीका, Android 9 या इसके बाद के वर्शन वाले डिवाइसों पर चालू होता है. हालांकि, इसके लिए ज़रूरी है कि उपयोगकर्ता ने Android 9 या इसके बाद के वर्शन में बैकअप लेने की सुविधा चालू की हो और अपने डिवाइस के लिए स्क्रीन लॉक सेट किया हो (पिन, पैटर्न या पासवर्ड).
deviceToDeviceTransfer: उपयोगकर्ता अपने बैकअप को किसी ऐसे दूसरे डिवाइस पर ट्रांसफ़र कर रहा है जिसमें एक डिवाइस से दूसरे डिवाइस पर डेटा ट्रांसफ़र करने की सुविधा काम करती है. उदाहरण के लिए, Google Pixel.

अगर आपने डेवलपमेंट के लिए इस्तेमाल किए जाने वाले डिवाइसों को Android 9 पर अपग्रेड किया है, तो आपको अपग्रेड करने के बाद, डेटा बैकअप की सुविधा को बंद करके फिर से चालू करना होगा. ऐसा इसलिए है, क्योंकि Android सिर्फ़ क्लाइंट-साइड सीक्रेट का इस्तेमाल करके बैकअप को एन्क्रिप्ट करता है. ऐसा वह सेटिंग या सेटअप विज़र्ड में उपयोगकर्ताओं को सूचना देने के बाद करता है.

शामिल करने की शर्तें तय करने के लिए, बैकअप नियमों के सेट में मौजूद <include> एलिमेंट में, requireFlags एट्रिब्यूट को चुनी गई वैल्यू पर सेट करें:

backup_rules.xml

<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
    <!-- App data isn't included in user's backup
         unless client-side encryption is enabled. -->
    <include domain="file" path="."
             requireFlags="clientSideEncryption" />
</full-backup-content>

अगर आपका ऐप्लिकेशन की-वैल्यू बैकअप सिस्टम लागू करता है या आपने खुद लागूBackupAgent किया है, तो बैकअप लॉजिक पर भी ये शर्तें लागू की जा सकती हैं. इसके लिए, BackupDataOutput ऑब्जेक्ट के ट्रांसपोर्ट फ़्लैग के सेट और आपके कस्टम बैकअप एजेंट के FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED या FLAG_DEVICE_TO_DEVICE_TRANSFER फ़्लैग के बीच बिटवाइज़ तुलना करनी होगी.

नीचे दिए गए कोड स्निपेट में, इस तरीके के इस्तेमाल का एक उदाहरण दिखाया गया है:

Kotlin

class CustomBackupAgent : BackupAgent() {
    override fun onBackup(
        oldState: ParcelFileDescriptor?,
        data: BackupDataOutput?,
        newState: ParcelFileDescriptor?
    ) {
        if (data != null) {
            if ((data.transportFlags and
                    FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED) != 0) {
                // Client-side backup encryption is enabled.
            }

            if ((data.transportFlags and FLAG_DEVICE_TO_DEVICE_TRANSFER) != 0) {
                // Local device-to-device transfer is enabled.
            }
        }
    }

    // Implementation of onRestore() here.
}

Java

public class CustomBackupAgent extends BackupAgent {
    @Override
    public void onBackup(
        ParcelFileDescriptor oldState,
        BackupDataOutput data,
        ParcelFileDescriptor newState
    ) throws IOException {
        if ((data.getTransportFlags() &
                FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED) != 0) {
            // Client-side backup encryption is enabled.
        }

        if ((data.getTransportFlags() &
                FLAG_DEVICE_TO_DEVICE_TRANSFER) != 0) {
            // Local device-to-device transfer is enabled.
        }
    }

    // Implementation of onRestore() here.
}

Android 12 या इसके बाद के वर्शन पर बैकअप कंट्रोल करना

अगर आपका ऐप्लिकेशन Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन को टारगेट करता है, तो इस सेक्शन में दिया गया तरीका अपनाएं. इससे यह कंट्रोल किया जा सकता है कि Android 12 या इसके बाद के वर्शन वाले डिवाइसों पर, किन फ़ाइलों का बैकअप लिया जाए.

अपनी AndroidManifest.xml फ़ाइल में, <application> एलिमेंट में android:dataExtractionRules एट्रिब्यूट जोड़ें. इसके लिए, यहां दिया गया उदाहरण देखें. यह एट्रिब्यूट, बैकअप के नियमों वाली एक्सएमएल फ़ाइल पर ले जाता है.
```
<application ...
    android:dataExtractionRules="backup_rules.xml">
</application>
```
res/xml/ डायरेक्ट्री में backup_rules.xml नाम की एक एक्सएमएल फ़ाइल बनाएं. इस फ़ाइल में, <include> और <exclude> एलिमेंट के साथ नियम जोड़ें. यहां दिए गए सैंपल में, device.xml को छोड़कर, शेयर की गई सभी प्राथमिकताओं का बैकअप लिया जाता है:
```
<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    <include domain="sharedpref" path="."/>
    <exclude domain="sharedpref" path="device.xml"/>
  </cloud-backup>
</data-extraction-rules>
```

एक्सएमएल कॉन्फ़िगरेशन सिंटैक्स

कॉन्फ़िगरेशन फ़ाइल के लिए एक्सएमएल सिंटैक्स, Android के उस वर्शन के हिसाब से अलग-अलग होता है जिसे आपका ऐप्लिकेशन टारगेट कर रहा है और जिस पर वह चल रहा है.

Android 11 या इससे पहले का वर्शन

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

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string" />
</full-backup-content>

Android 12 या इसके बाद का वर्शन

अगर आपका ऐप्लिकेशन Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन को टारगेट करता है, तो कॉन्फ़िगरेशन फ़ाइल के लिए यहां दिए गए एक्सएमएल सिंटैक्स का इस्तेमाल करें. यह फ़ाइल, Android 12 या इसके बाद के वर्शन वाले डिवाइसों के लिए बैकअप को कंट्रोल करती है.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
  </device-transfer>
  <cross-platform-transfer platform="ios">
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <platform-specific-params bundleId="string" teamId="string" contentVersion="string"/>
    ...
  </cross-platform-transfer>
</data-extraction-rules>

कॉन्फ़िगरेशन के हर सेक्शन (<cloud-backup>, <device-transfer>, <cross-platform-transfer>) में ऐसे नियम होते हैं जो सिर्फ़ उस तरह के ट्रांसफ़र पर लागू होते हैं. इसकी मदद से, Google Drive के बैकअप से किसी फ़ाइल या डायरेक्ट्री को हटाया जा सकता है. हालांकि, उसे एक डिवाइस से दूसरे डिवाइस (डी2डी) पर या क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र के दौरान ट्रांसफ़र किया जा सकता है. यह सुविधा तब काम आती है, जब आपके पास ऐसी फ़ाइलें हों जो क्लाउड पर बैक अप लेने के लिए बहुत बड़ी हों, लेकिन उन्हें डिवाइसों के बीच आसानी से ट्रांसफ़र किया जा सकता हो.

अगर बैकअप लेने के किसी खास मोड के लिए कोई नियम नहीं है, जैसे कि अगर <device-transfer> सेक्शन मौजूद नहीं है, तो वह मोड सभी कॉन्टेंट के लिए पूरी तरह से चालू हो जाता है. हालांकि, no-backup और cache डायरेक्ट्री के लिए ऐसा नहीं होता. इसके बारे में, जिन फ़ाइलों का बैकअप लिया जाता है सेक्शन में बताया गया है.

आपका ऐप्लिकेशन, <cloud-backup> सेक्शन में disableIfNoEncryptionCapabilities फ़्लैग सेट कर सकता है. इससे यह पक्का किया जा सकता है कि बैकअप सिर्फ़ तब लिया जाए, जब उसे एन्क्रिप्ट (सुरक्षित) किया जा सके. जैसे, जब उपयोगकर्ता के पास लॉक स्क्रीन हो. इस पाबंदी को सेट करने पर, अगर उपयोगकर्ता के डिवाइस पर एन्क्रिप्शन की सुविधा काम नहीं करती है, तो बैकअप को क्लाउड पर भेजने से रोक दिया जाता है. हालांकि, डी2डी ट्रांसफ़र को सर्वर पर नहीं भेजा जाता है. इसलिए, वे उन डिवाइसों पर भी काम करते रहते हैं जिन पर एन्क्रिप्शन की सुविधा काम नहीं करती है.

शामिल करने और बाहर रखने वाले एलिमेंट के लिए सिंटैक्स

<full-backup-content>, <cloud-backup>, और <device-transfer> टैग (डिवाइस के Android वर्शन और आपके ऐप्लिकेशन के targetSDKVersion के आधार पर) के अंदर, <include> और <exclude> एलिमेंट तय किए जा सकते हैं:

<include>

बैकअप लेने के लिए कोई फ़ाइल या फ़ोल्डर तय करता है. डिफ़ॉल्ट रूप से, ऑटो बैकअप की सुविधा में ऐप्लिकेशन की ज़्यादातर फ़ाइलें शामिल होती हैं. अगर आपने <include> एलिमेंट तय किया है, तो सिस्टम डिफ़ॉल्ट रूप से कोई भी फ़ाइल शामिल नहीं करता. साथ ही, सिर्फ़ तय की गई फ़ाइलों का बैकअप लेता है. एक से ज़्यादा फ़ाइलें शामिल करने के लिए, एक से ज़्यादा <include> एलिमेंट का इस्तेमाल करें.

Android 11 और इससे पहले के वर्शन पर, इस एलिमेंट में requireFlags एट्रिब्यूट भी शामिल हो सकता है. इसके बारे में, बैकअप के लिए ज़रूरी शर्तों को तय करने के तरीके वाले सेक्शन में ज़्यादा जानकारी दी गई है.

getCacheDir(), getCodeCacheDir() या getNoBackupFilesDir() से मिली डायरेक्ट्री में मौजूद फ़ाइलें हमेशा बाहर रखी जाती हैं. भले ही, आपने उन्हें शामिल करने की कोशिश की हो.

सलाह: उपयोगकर्ता के क्रेडेंशियल और पुष्टि करने वाले टोकन का बैक अप लेने के लिए, उन्हें शेयर की गई सेटिंग या किसी फ़ाइल में सेव न करें. क्रेडेंशियल सेव करने और मैनेज करने के लिए, Block Store API का इस्तेमाल करें. इससे यह पक्का होता है कि वे सुरक्षित तरीके से सेव किए गए हैं. साथ ही, ऐप्लिकेशन के अन्य डेटा के साथ उनका बैकअप लिया जा सकता है और उन्हें वापस लाया जा सकता है.

<exclude>

बैकअप के दौरान, किसी फ़ाइल या फ़ोल्डर को शामिल न करने के लिए तय करता है. यहां कुछ ऐसी फ़ाइलों के बारे में बताया गया है जिन्हें आम तौर पर बैकअप में शामिल नहीं किया जाता:

ऐसी फ़ाइलें जिनमें डिवाइस के हिसाब से आइडेंटिफ़ायर होते हैं. ये आइडेंटिफ़ायर, सर्वर से जारी किए जाते हैं या डिवाइस पर जनरेट किए जाते हैं. उदाहरण के लिए, जब भी कोई उपयोगकर्ता किसी नए डिवाइस पर आपका ऐप्लिकेशन इंस्टॉल करता है, तो Firebase क्लाउड से मैसेज (FCM) को हर बार एक रजिस्ट्रेशन टोकन जनरेट करना पड़ता है. अगर पुराना रजिस्ट्रेशन टोकन वापस लाया जाता है, तो हो सकता है कि ऐप्लिकेशन उम्मीद के मुताबिक काम न करे.
ऐप्लिकेशन को डीबग करने से जुड़ी फ़ाइलें.
ऐसी बड़ी फ़ाइलें जिनकी वजह से ऐप्लिकेशन का बैकअप कोटा 25 एमबी से ज़्यादा हो जाता है.

हर <include> और <exclude> एलिमेंट में ये दो एट्रिब्यूट शामिल होने चाहिए:

domain

इससे संसाधन की जगह की जानकारी मिलती है. इस एट्रिब्यूट के लिए मान्य वैल्यू में ये शामिल हैं:

root: फ़ाइल सिस्टम की वह डायरेक्ट्री जहां इस ऐप्लिकेशन की सभी निजी फ़ाइलें सेव की जाती हैं.
file: getFilesDir() से मिली डायरेक्ट्री.
database: getDatabasePath() से मिली डायरेक्ट्री. SQLiteOpenHelper से बनाए गए डेटाबेस यहां सेव किए जाते हैं.
sharedpref: वह डायरेक्ट्री जहां SharedPreferences सेव किए जाते हैं.
external: getExternalFilesDir() से मिली डायरेक्ट्री.
device_root: यह root की तरह है, लेकिन डिवाइस-प्रोटेक्टेड स्टोरेज के लिए है.
device_file: यह file की तरह है, लेकिन डिवाइस-प्रोटेक्टेड स्टोरेज के लिए है.
device_database: यह database की तरह है, लेकिन डिवाइस-प्रोटेक्टेड स्टोरेज के लिए है.
device_sharedpref: यह sharedpref की तरह है, लेकिन डिवाइस-प्रोटेक्टेड स्टोरेज के लिए है.

path

बैकअप में शामिल करने या उससे बाहर रखने के लिए, किसी फ़ाइल या फ़ोल्डर के बारे में बताता है. इन बातों का ध्यान रखें:

इस एट्रिब्यूट में वाइल्डकार्ड या रेगुलर एक्सप्रेशन सिंटैक्स का इस्तेमाल नहीं किया जा सकता.
./ का इस्तेमाल करके, मौजूदा डायरेक्ट्री को रेफ़रंस के तौर पर इस्तेमाल किया जा सकता है. हालांकि, सुरक्षा की वजहों से पैरंट डायरेक्ट्री को रेफ़रंस के तौर पर इस्तेमाल नहीं किया जा सकता. जैसे, .. का इस्तेमाल करके.
अगर कोई डायरेक्ट्री तय की जाती है, तो नियम उस डायरेक्ट्री और बार-बार होने वाली सबडायरेक्ट्री की सभी फ़ाइलों पर लागू होता है.

क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र को कॉन्फ़िगर करना

Android 16 QPR2 (एपीआई लेवल 36.1) से, ऑटो बैकअप की सुविधा को कॉन्फ़िगर किया जा सकता है. इससे, Android डिवाइसों से गैर-Android डिवाइसों पर और गैर-Android डिवाइसों से Android डिवाइसों पर डेटा ट्रांसफ़र किया जा सकता है. इसके लिए, अपने <data-extraction-rules> कॉन्फ़िगरेशन में <cross-platform-transfer> एलिमेंट जोड़ें. इसके बारे में Android 12 या इसके बाद के वर्शन के सिंटैक्स में बताया गया है. आपको ज़रूरी platform एट्रिब्यूट का इस्तेमाल करके, टारगेट प्लैटफ़ॉर्म की जानकारी देनी होगी. वैल्यू के तौर पर सिर्फ़ ios का इस्तेमाल किया जा सकता है.

इस सेक्शन में, स्टैंडर्ड <include> और <exclude> एलिमेंट का इस्तेमाल किया जा सकता है. इनके बारे में, शामिल करने और बाहर रखने वाले एलिमेंट के लिए सिंटैक्स में बताया गया है. इससे यह तय किया जा सकता है कि कौनसा डेटा ट्रांसफ़र करना है.

इसके अलावा, आपको <platform-specific-params> एलिमेंट को शामिल करना होगा. इससे सिस्टम को आपके ऐप्लिकेशन को टारगेट प्लैटफ़ॉर्म पर मौजूद उससे मिलते-जुलते ऐप्लिकेशन से मैच करने में मदद मिलती है. इस एलिमेंट के लिए, ये एट्रिब्यूट ज़रूरी हैं:

bundleId: दूसरे प्लैटफ़ॉर्म पर मौजूद ऐप्लिकेशन का बंडल आईडी (उदाहरण के लिए, आपके iOS ऐप्लिकेशन का बंडल आईडी).
teamId: दूसरे प्लैटफ़ॉर्म पर मौजूद ऐप्लिकेशन का टीम आईडी (उदाहरण के लिए, आपके iOS ऐप्लिकेशन का टीम आईडी).
contentVersion: एक्सपोर्ट किए जा रहे डेटा फ़ॉर्मैट से जुड़ी वर्शन स्ट्रिंग, जिसे आपने तय किया है.

bundleId और teamId एट्रिब्यूट का इस्तेमाल, डेटा की सुरक्षा की पुष्टि करने और ऐप्लिकेशन-टू-ऐप्लिकेशन मैचिंग के लिए किया जाता है. ये फ़ील्ड यह पक्का करते हैं कि एक्सपोर्ट के दौरान, डेटा सिर्फ़ दूसरे प्लैटफ़ॉर्म पर मौजूद तय किए गए ऐप्लिकेशन पर ट्रांसफ़र किया जाए. साथ ही, यह Android ऐप्लिकेशन, इंपोर्ट के दौरान सिर्फ़ उस ऐप्लिकेशन से डेटा इंपोर्ट करे.

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

iOS डिवाइसों के बीच फ़ाइल ट्रांसफ़र करने के लिए, फ़ाइल मैपिंग

iOS पर फ़ाइलें ट्रांसफ़र करते समय, <include> नियमों में बताए गए Android domain और path, किसी खास डायरेक्ट्री स्ट्रक्चर से मैप होते हैं. यहां दी गई टेबल में, Android domain के आधार पर, iOS पर डेस्टिनेशन पाथ दिखाए गए हैं. ये पाथ, ट्रांसफ़र डेस्टिनेशन रूट के हिसाब से दिखाए गए हैं:

Android `domain`	iOS पर पाथ (ट्रांसफ़र रूट के हिसाब से)
`root`	`app/`
`file`	`app/files/`
`database`	`app/databases/`
`sharedpref`	`app/shared_prefs/`
`external`	`external/files/`
`device_root`	`device/app/`
`device_file`	`device/app/files/`
`device_database`	`device/app/databases/`
`device_sharedpref`	`device/app/shared_prefs/`

उदाहरण के लिए, <include domain="file" path="my_settings.txt"/> के साथ शामिल की गई फ़ाइल, iOS पर app/files/my_settings.txt में उपलब्ध होगी. यह फ़ाइल, ट्रांसफ़र डेस्टिनेशन रूट के हिसाब से उपलब्ध होगी.

BackupAgent लागू करना

ऑटो बैकअप की सुविधा लागू करने वाले ऐप्लिकेशन को BackupAgent लागू करने की ज़रूरत नहीं होती. हालांकि, आपके पास कस्टम BackupAgent लागू करने का विकल्प है. आम तौर पर, ऐसा करने की दो वजहें होती हैं:

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

अगर आपने BackupAgent लागू किया है, तो डिफ़ॉल्ट रूप से सिस्टम को उम्मीद होती है कि आपका ऐप्लिकेशन की-वैल्यू बैकअप और रीस्टोर की सुविधा का इस्तेमाल करेगा. इसके बजाय, फ़ाइल पर आधारित ऑटो बैकअप की सुविधा का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन के मेनिफ़ेस्ट में android:fullBackupOnly एट्रिब्यूट को true पर सेट करें.

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

चेतावनी: गड़बड़ियों से बचने के लिए, पक्का करें कि आपके ऐप्लिकेशन के जो हिस्से पाबंदी वाले मोड में काम करते हैं (ज़्यादातर BackupAgent) वे उसी ऐप्लिकेशन में कॉन्टेंट देने वाले ऐप्लिकेशन को ऐक्सेस न करें या Application ऑब्जेक्ट को कास्ट करने की कोशिश न करें. अगर इन पैटर्न से बचना मुमकिन नहीं है, तो की-वैल्यू बैकअप लागू करें या बैकअप लेने की सुविधा को पूरी तरह से बंद कर दें.

आपके BackupAgent को ऐब्स्ट्रैक्ट तरीके onBackup() और onRestore() लागू करने होंगे. इनका इस्तेमाल, की-वैल्यू बैकअप के लिए किया जाता है. अगर आपको की-वैल्यू बैकअप नहीं लेना है, तो उन तरीकों को लागू करने की प्रोसेस को खाली छोड़ा जा सकता है.

ज़्यादा जानकारी के लिए, BackupAgent को एक्सटेंड करना लेख पढ़ें.

BackupAgent में क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र को मैनेज करना

Android 16 QPR2 (एपीआई लेवल 36.1) से, BackupAgent में कई नए एपीआई उपलब्ध हैं. इनसे क्रॉस-प्लैटफ़ॉर्म डेटा ट्रांसफ़र को बेहतर तरीके से मैनेज किया जा सकता है.

परिवहन के लिए नया फ़्लैग:

FLAG_CROSS_PLATFORM_TRANSFER_IOS: यह फ़्लैग, आपके BackupAgent को दिए गए transportFlags में जोड़ा जाता है.
- onFullBackup में, यह फ़्लैग तब सेट किया जाता है, जब मौजूदा बैकअप ऑपरेशन, iOS डिवाइस पर डेटा एक्सपोर्ट करने का हिस्सा हो.
- नए onRestoreFile ओवरलोड में, यह फ़्लैग तब सेट होता है, जब डेटा को किसी iOS डिवाइस से इंपोर्ट किया जा रहा हो.

onRestoreFile का नया तरीका:

onRestoreFile का एक नया ओवरलोड पेश किया गया है, जो एक FullRestoreDataInput पैरामीटर लेता है. यह ऑब्जेक्ट, डेटा वापस लाने की प्रोसेस के बारे में ज़्यादा जानकारी देता है:

FullRestoreDataInput.getTransportFlags(): यह मौजूदा रीस्टोर ऑपरेशन के लिए, ट्रांसपोर्ट फ़्लैग दिखाता है. इसमें FLAG_CROSS_PLATFORM_TRANSFER_IOS शामिल हो सकता है.
FullRestoreDataInput.getContentVersion(): यह फ़ंक्शन, क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र के दौरान, दूसरे प्लैटफ़ॉर्म पर सोर्स ऐप्लिकेशन से मिली कॉन्टेंट वर्शन स्ट्रिंग दिखाता है. अगर सोर्स से यह वैल्यू नहीं मिलती है, तो यह एक खाली स्ट्रिंग होती है.

साइज़ का अनुमान लगाने का नया तरीका:

onEstimateFullBackupBytes(): इस तरीके से, उस डेटा के साइज़ का अनुमान लगाया जा सकता है जिसका बैकअप आपके ऐप्लिकेशन को लेना है. अगर आपका ऐप्लिकेशन बैकअप के दौरान डेटा में काफ़ी बदलाव करता है या बड़ी मात्रा में डेटा मैनेज करता है, तो इसे लागू करने का सुझाव दिया जाता है. इससे डिफ़ॉल्ट सिस्टम ड्राई रन से बचकर, परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. जिन ऐप्लिकेशन का बैकअप छोटा और आसान होता है उनके लिए आम तौर पर इस तरीके की ज़रूरत नहीं होती.

इस्तेमाल का उदाहरण:

Kotlin

// In your custom BackupAgent class

override fun onFullBackup(out: FullBackupDataOutput) {
    // Check if this is a cross-platform export to iOS
    if ((out.transportFlags and FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        Log.d(TAG, "onFullBackup for iOS transfer")
        // Your custom export logic here
        // Call fullBackupFile() for files to include
    }
}

override fun onRestoreFile(input: FullRestoreDataInput) {
    if ((input.transportFlags and FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        val sourceContentVersion = input.contentVersion
        Log.d(TAG, "onRestoreFile from iOS, content version: $sourceContentVersion")
        // Your custom import logic here, using input.data, input.destination, etc.
    }
}

// Optional: Provide an estimate of the backup size
override fun onEstimateFullBackupBytes(): Long {
    return calculateEstimatedBackupSize()
}

Java

// In your custom BackupAgent class

@Override
public void onFullBackup(FullBackupDataOutput out) throws IOException {
    // Check if this is a cross-platform export to iOS
    if ((out.getTransportFlags() & FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        Log.d(TAG, "onFullBackup for iOS transfer");
        // Your custom export logic here
        // Call fullBackupFile() for files to include
    }
}

@Override
public void onRestoreFile(FullRestoreDataInput input) {
    if ((input.getTransportFlags() & FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        String sourceContentVersion = input.getContentVersion();
        Log.d(TAG, "onRestoreFile from iOS, content version: " + sourceContentVersion);
        // Your custom import logic here, using input.getData(), input.getDestination(), etc.
    }
}

// Optional: Provide an estimate of the backup size
@Override
public long onEstimateFullBackupBytes() {
    return calculateEstimatedBackupSize();
}