इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

ऐप्लिकेशन के लिए ऑटो बैकअप की सुविधा, उपयोगकर्ता के डेटा का बैक अप अपने-आप लेती है. यह सुविधा, उन ऐप्लिकेशन के डेटा का बैक अप लेती है जो Android 6.0 (एपीआई लेवल 23) या इसके बाद के वर्शन पर काम करते हैं और जिनका टारगेट 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 ऐप्लिकेशन में उन ऐप्लिकेशन की सूची देख सकते हैं जिनका बैक अप Google Drive में लिया गया है. Android पर काम करने वाले डिवाइस पर, उपयोगकर्ता यह सूची सेटिंग > बैकअप लें और रीसेट करें में Drive ऐप्लिकेशन के नेविगेशन पैनल में देख सकते हैं.

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

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

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

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

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

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

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

जांच को आसान बनाने के लिए, 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 पर बैकअप लेने की सुविधा) बंद हो जाती है. हालांकि, इससे ऐप्लिकेशन के लिए, एक डिवाइस से दूसरे डिवाइस पर डेटा ट्रांसफ़र करने की सुविधा बंद नहीं होती. ज़्यादा जानकारी के लिए, बैकअप लेने और उसे वापस लाने की सुविधा में हुए बदलाव के बारे में जानकारी देखें.

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

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

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

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>
</data-extraction-rules>

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

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

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

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

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

<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

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

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

BackupAgent लागू करना

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

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

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

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

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

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

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