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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 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 पर सेटिंग में उपयोगकर्ताओं को सूचना देने के बाद, बैकअप को क्लाइंट-साइड सीक्रेट के साथ एन्क्रिप्ट करता है सेटअप विज़र्ड पर क्लिक करें.

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

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>
</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() से मिली डायरेक्ट्री में मौजूद फ़ाइलों को हमेशा बाहर रखा जाता है. भले ही, आप उन्हें शामिल करने की कोशिश करें.

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

ज़्यादा जानकारी के लिए, Extend बैकअपAgent देखें.