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

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

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

बैक अप ली गई फ़ाइलें

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

• शेयर की गई प्राथमिकताएं फ़ाइलें

• ऐप्लिकेशन के इंटरनल स्टोरेज में सेव की गई फ़ाइलें, जिन्हें getFilesDir() या getDir(String, int) ऐक्सेस करता है

• getDatabasePath(String) से मिली डायरेक्ट्री में मौजूद फ़ाइलें. इनमें SQLiteOpenHelper क्लास से बनाई गई फ़ाइलें भी शामिल हैं

• getExternalFilesDir(String) से मिले डायरेक्ट्री में मौजूद बाहरी स्टोरेज की फ़ाइलें

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

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

बैकअप की जगह

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

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

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

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

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

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

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

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

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

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

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

शेड्यूल वापस लाना

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

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

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

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

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

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

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

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

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

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

1. अपनी AndroidManifest.xml फ़ाइल में, <application> एलिमेंट में android:fullBackupContent एट्रिब्यूट जोड़ें. इसका उदाहरण यहां दिया गया है. यह एट्रिब्यूट, ऐसी एक्सएमएल फ़ाइल की ओर ले जाता है जिसमें बैकअप के नियम शामिल होते हैं.

   <application ...
    android:fullBackupContent="@xml/backup_rules">
   </application>

2. @xml/backup_rules डायरेक्ट्री में res/xml/ नाम की एक्सएमएल फ़ाइल बनाएं. इस फ़ाइल में, <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 फ़्लैग के बीच बिटवाइज़ तुलना करें.

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

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.
}

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 या उसके बाद के वर्शन पर चलने वाले डिवाइसों पर कौनसी फ़ाइलों का बैक अप लिया जाए.

1. अपनी AndroidManifest.xml फ़ाइल में, <application> एलिमेंट में android:dataExtractionRules एट्रिब्यूट जोड़ें. इसका उदाहरण यहां दिया गया है. यह एट्रिब्यूट, ऐसी एक्सएमएल फ़ाइल की ओर ले जाता है जिसमें बैकअप के नियम शामिल होते हैं.

   <application ...
    android:dataExtractionRules="backup_rules.xml">
   </application>

2. backup_rules.xml डायरेक्ट्री में res/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 के बैकअप से हटाया जा सकता है. हालांकि, डिवाइस-टू-डिवाइस (D2D) ट्रांसफ़र या क्रॉस-प्लैटफ़ॉर्म ट्रांसफ़र के दौरान इसे ट्रांसफ़र किया जा सकता है. यह सुविधा तब काम आती है, जब आपके पास ऐसी फ़ाइलें हों जिनका साइज़ इतना बड़ा हो कि उन्हें क्लाउड पर बैक अप न लिया जा सके. हालांकि, उन्हें एक डिवाइस से दूसरे डिवाइस पर आसानी से ट्रांसफ़र किया जा सकता हो.

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

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

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

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

<include>

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

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

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

<exclude>

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

• ऐसी फ़ाइलें जिनमें डिवाइस के हिसाब से आइडेंटिफ़ायर होते हैं. इन्हें सर्वर जारी करता है या डिवाइस पर जनरेट किया जाता है. उदाहरण के लिए, जब भी कोई उपयोगकर्ता किसी नए डिवाइस पर आपका ऐप्लिकेशन इंस्टॉल करता है, तो Firebase Cloud Messaging (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 डिवाइसों के अलावा अन्य डिवाइसों पर डेटा ट्रांसफ़र करने के लिए, ऑटो बैकअप की सुविधा को कॉन्फ़िगर किया जा सकता है. इसके लिए, <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 पर फ़ाइलें ट्रांसफ़र करते समय, Android domain और path में तय किए गए <include> नियम, किसी डायरेक्ट्री स्ट्रक्चर के साथ मैप होते हैं. यहां दी गई टेबल में, Android domain के आधार पर, ट्रांसफ़र किए गए डेटा के डेस्टिनेशन रूट के हिसाब से iOS पर डेस्टिनेशन पाथ दिखाए गए हैं:

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

BackupAgent को लागू करना

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

• आपको बैकअप इवेंट की सूचना चाहिए. जैसे, onRestoreFinished() और onQuotaExceeded(). ये कॉलबैक तरीके, ऐप्लिकेशन के बंद होने पर भी काम करते हैं.

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

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

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

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

// 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()
}

// 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();
}