অটো ব্যাক-আপের মাধ্যমে ব্যবহারকারীর ডেটার ব্যাক-আপ নেওয়া

অ্যাপের জন্য অটোমেটিক ব্যাক-আপ ফিচারটি Android 6.0 (API লেভেল 23) বা তার পরবর্তী যেকোনও ভার্সনে টার্গেট করা ও রান করা অ্যাপ থেকে ব্যবহারকারীর ডেটার অটোমেটিক ব্যাক-আপ নেয়। Android ব্যবহারকারীর Google Drive-এ আপলোড করে অ্যাপ ডেটা সংরক্ষণ করে, যেখানে এটি ব্যবহারকারীর Google অ্যাকাউন্ট ক্রেডেনশিয়ালের মাধ্যমে সুরক্ষিত থাকে। Android 9 বা তার পরবর্তী ভার্সন চলছে এমন ডিভাইসে, ডিভাইসের পিন, প্যাটার্ন বা পাসওয়ার্ড ব্যবহার করে ব্যাক-আপ এন্ড-টু-এন্ড এনক্রিপ্ট করা হয়। প্রতিটি অ্যাপ, অ্যাপ ব্যবহারকারী প্রতি সর্বাধিক ২৫ এমবি ব্যাক-আপ ডেটা বরাদ্দ করতে পারে। ব্যাক-আপ ডেটা স্টোর করার জন্য কোনও চার্জ লাগে না। আপনার অ্যাপ ব্যাক-আপ প্রসেস কাস্টমাইজ করতে পারে অথবা ব্যাক-আপ বন্ধ করে অপ্ট-আউট করতে পারে।

Android-এর ব্যাক-আপ বিকল্পের ওভারভিউ এবং কোন ডেটার ব্যাক-আপ নিতে হবে ও ফিরিয়ে আনতে হবে সেই সম্পর্কে নির্দেশিকা পেতে, ডেটা ব্যাক-আপের ওভারভিউ দেখুন।

যেসব ফাইলের ব্যাক-আপ নেওয়া হয়েছে

ডিফল্ট হিসেবে, অটো ব্যাক-আপে বেশিরভাগ ডিরেক্টরির ফাইল অন্তর্ভুক্ত থাকে যা সিস্টেমের মাধ্যমে আপনার অ্যাপে অ্যাসাইন করা হয়:

  • শেয়ার করা পছন্দ সম্পর্কিত ফাইল

  • আপনার অ্যাপের ইন্টার্নাল স্টোরেজে সেভ করা ফাইল এবং getFilesDir() বা getDir(String, int)-এর মাধ্যমে অ্যাক্সেস করা ফাইল

  • getDatabasePath(String)-এর মাধ্যমে রিটার্ন করা ডিরেক্টরির ফাইল, যার মধ্যে SQLiteOpenHelper ক্লাস দিয়ে তৈরি করা ফাইলও অন্তর্ভুক্ত

  • getExternalFilesDir(String)-এর মাধ্যমে ফেরত পাঠানো ডিরেক্টরির এক্সটার্নাল স্টোরেজে থাকা ফাইল

অটো ব্যাক-আপ getCacheDir(), getCodeCacheDir() এবং getNoBackupFilesDir()-এর মাধ্যমে ফেরত পাঠানো ডিরেক্টরির ফাইল বাদ দেয়। এইসব লোকেশনে সেভ করা ফাইলগুলি শুধুমাত্র সাময়িকভাবে প্রয়োজন হয় এবং ব্যাক-আপ অপারেশন থেকে ইচ্ছাকৃতভাবে বাদ দেওয়া হয়।

নির্দিষ্ট ফাইল অন্তর্ভুক্ত বা বাদ দেওয়ার জন্য আপনি অ্যাপ কনফিগার করতে পারবেন। আরও তথ্যের জন্য, ফাইল অন্তর্ভুক্ত করা ও বাদ দেওয়া বিভাগ দেখুন।

ব্যাক-আপ লোকেশন

ব্যাক-আপ ডেটা ব্যবহারকারীর Google Drive অ্যাকাউন্টের একটি ব্যক্তিগত ফোল্ডারে স্টোর করা হয়, প্রতিটি অ্যাপের জন্য ২৫ এমবি পর্যন্ত। সেভ করা ডেটা ব্যবহারকারীর ব্যক্তিগত Google Drive কোটার মধ্যে ধরা হয় না। শুধুমাত্র সবচেয়ে সাম্প্রতিক ব্যাক-আপ স্টোর করা হয়। ব্যাক-আপ নেওয়া হলে, আগের যেকোনও ব্যাক-আপ মুছে যায়। ব্যাক-আপ ডেটা ব্যবহারকারী বা ডিভাইসের অন্যান্য অ্যাপ পড়তে পারে না।

ব্যবহারকারীরা Google Drive Android অ্যাপে ব্যাক-আপ নেওয়া অ্যাপের তালিকা দেখতে পাবেন। Android-চালিত ডিভাইসে, ব্যবহারকারীরা Drive অ্যাপের নেভিগেশন ড্রয়ারে সেটিংস > ব্যাক-আপ ও রিসেট বিকল্পের অধীনে এই তালিকা দেখতে পাবেন।

প্রতিটি ডিভাইস-সেট-আপ-লাইফটাইম থেকে ব্যাক-আপ আলাদা ডেটাসেটে স্টোর করা হয়, যেমন নিম্নলিখিত উদাহরণে বর্ণনা করা হয়েছে:

  • ব্যবহারকারীর দুটি ডিভাইস থাকলে, প্রতিটি ডিভাইসের জন্য ব্যাক-আপ ডেটাসেট থাকে।

  • ব্যবহারকারী যদি কোনও ডিভাইস ফ্যাক্টরি রিসেট করেন এবং তারপরে একই অ্যাকাউন্ট দিয়ে ডিভাইস সেট-আপ করেন, তাহলে ব্যাক-আপ নতুন ডেটাসেটে স্টোর করা হয়। কিছু সময় ধরে কোনও অ্যাক্টিভিটি না থাকলে, পুরনো ডেটাসেট অটোমেটিক মুছে যায়।

ব্যাক-আপ শিডিউল

নিম্নলিখিত সব শর্ত পূরণ হলে অটোমেটিক ব্যাক-আপ নেওয়া হয়:

  • ব্যবহারকারী ডিভাইসে ব্যাক-আপ চালু করেছেন। Android 9-এ, এই সেটিং সেটিংস > সিস্টেম > ব্যাক-আপ বিকল্পে রয়েছে।
  • শেষ ব্যাক-আপ নেওয়ার পর থেকে অন্তত ২৪ ঘণ্টা কেটে গেছে।
  • ডিভাইসটি আইডেল অবস্থায় আছে।
  • ডিভাইসটি ওয়াই-ফাই নেটওয়ার্কের সাথে কানেক্ট করা আছে (যদি ডিভাইস ব্যবহারকারী মোবাইল-ডেটা ব্যাক-আপের বিকল্প বেছে না নেন)।

সাধারণত, এই শর্তগুলি প্রায় প্রতি রাতেই পূরণ হয়, তবে কোনও ডিভাইস কখনও ব্যাক-আপ নাও নিতে পারে (যেমন, এটি কখনও নেটওয়ার্কে কানেক্ট না হলে)। নেটওয়ার্ক ব্যান্ডউইথ সংরক্ষণ করতে, অ্যাপ ডেটা পরিবর্তন হলে তবেই আপলোড করা হয়।

অটোমেটিক ব্যাক-আপ নেওয়ার সময়, সিস্টেম অ্যাপটি বন্ধ করে দেয় যাতে এটি আর ফাইল সিস্টেমে লিখতে না পারে। ডিফল্ট হিসেবে, ব্যাক-আপ সিস্টেম সেইসব অ্যাপকে উপেক্ষা করে যেগুলি ব্যবহারকারীর অভিজ্ঞতা খারাপ হওয়া এড়াতে ফোরগ্রাউন্ডে চলছে। আপনি android:backupInForeground অ্যাট্রিবিউট true-তে সেট করে ডিফল্ট অ্যাকশন ওভাররাইড করতে পারবেন।

টেস্টিং সহজ করতে, Android-এ এমন টুল অন্তর্ভুক্ত থাকে যা আপনাকে ম্যানুয়ালি অ্যাপের ব্যাক-আপ শুরু করতে দেয়। আরও তথ্যের জন্য, ব্যাক-আপ ও রিস্টোর টেস্ট করুন দেখুন।

শিডিউল ফিরিয়ে আনুন

Play Store থেকে, ডিভাইস সেট-আপ করার সময় (যখন সিস্টেম আগে ইনস্টল করা অ্যাপ ইনস্টল করে) অথবা adb ইনস্টল রান করার মাধ্যমে, যখনই অ্যাপ ইনস্টল করা হয়, তখনই ডেটা ফিরিয়ে আনা হয়। APK ইনস্টল করার পরে রিস্টোর অপারেশন হয় তবে ব্যবহারকারী অ্যাপ লঞ্চ করার আগে।

প্রাথমিক ডিভাইস সেট-আপ উইজার্ড চলাকালীন, ব্যবহারকারীকে উপলভ্য ব্যাক-আপ ডেটাসেটের একটি তালিকা দেখানো হয় এবং জিজ্ঞাসা করা হয় যে কোন ডেটাসেট থেকে ডেটা রিস্টোর করতে হবে। যে ব্যাক-আপ ডেটাসেট বেছে নেওয়া হয় সেটি ডিভাইসের জন্য পূর্বপুরুষ ডেটাসেট হয়ে যায়। ডিভাইসটি তার নিজস্ব ব্যাকআপ বা পূর্বপুরুষের ডেটাসেট থেকে রিস্টোর করতে পারে। দুটি সোর্স থেকেই ব্যাক-আপ উপলভ্য থাকলে, ডিভাইসটি নিজের ব্যাক-আপকে অগ্রাধিকার দেয়। ব্যবহারকারী ডিভাইস সেট-আপ উইজার্ডের মাধ্যমে না গেলে, ডিভাইসটি শুধুমাত্র তার নিজস্ব ব্যাক-আপ থেকে রিস্টোর করতে পারবে।

টেস্টিং সহজ করতে, Android-এ এমন টুল অন্তর্ভুক্ত থাকে যা আপনাকে ম্যানুয়ালি অ্যাপের ডেটা রিস্টোর করার প্রক্রিয়া শুরু করতে দেয়। আরও তথ্যের জন্য, ব্যাক-আপ ও রিস্টোর টেস্ট করুন দেখুন।

ব্যাক-আপ চালু ও বন্ধ করা

Android 6.0 (API লেভেল 23) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করে এমন অ্যাপ অটোমেটিক ব্যাক-আপে অটোমেটিক অংশগ্রহণ করে। আপনার অ্যাপ ম্যানিফেস্ট ফাইলে, ব্যাক-আপ চালু বা বন্ধ করতে বুলিয়ান ভ্যালু android:allowBackup সেট করুন। ডিফল্ট ভ্যালু হল true, তবে আমরা সাজেস্ট করি যে আপনার ম্যানিফেস্টে অ্যাট্রিবিউট স্পষ্টভাবে সেট করুন, যেমন নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

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

android:allowBackup-কে false-এ সেট করে আপনি ব্যাক-আপ বন্ধ করতে পারবেন। আপনার অ্যাপ যদি অন্য কোনও উপায়ে নিজের অবস্থা আবার তৈরি করতে পারে অথবা আপনার অ্যাপ যদি সংবেদনশীল তথ্য নিয়ে কাজ করে, তাহলে আপনি এটি করতে চাইতে পারেন।

ফাইল অন্তর্ভুক্ত করা ও বাদ দেওয়া

ডিফল্ট হিসেবে, সিস্টেম প্রায় সব অ্যাপ ডেটার ব্যাক-আপ নেয়। আরও তথ্যের জন্য, ব্যাক-আপ নেওয়া হয় এমন ফাইল সংক্রান্ত বিভাগ দেখুন।

ট্রান্সফারের ধরনের উপর ভিত্তি করে ব্যাক-আপে কোন ডেটা অন্তর্ভুক্ত করা হবে তা আপনি কন্ট্রোল করতে পারবেন। অটোমেটিক ব্যাক-আপের মাধ্যমে Google Drive-এ ক্লাউড ব্যাক-আপ এবং সরাসরি ডিভাইস-টু-ডিভাইস (D2D) ট্রান্সফার করা যায়। Android ভার্সন এবং আপনার অ্যাপের targetSdkVersion-এর উপর ভিত্তি করে কনফিগারেশন পদ্ধতি আলাদা হয়।

Android 11 ও তার আগের যেকোনও ভার্সনে ব্যাক-আপ নিয়ন্ত্রণ করা

Android 11 (API লেভেল 30) বা তার আগের ভার্সন রান করছে এমন ডিভাইসে কোন কোন ফাইলের ব্যাক-আপ নেওয়া হবে তা নিয়ন্ত্রণ করতে এই বিভাগে উল্লেখ করা ধাপগুলি অনুসরণ করুন।

  1. আপনার AndroidManifest.xml ফাইলে, <application> এলিমেন্টে android:fullBackupContent অ্যাট্রিবিউট যোগ করুন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে। এই অ্যাট্রিবিউট এমন একটি XML ফাইলকে নির্দেশ করে যেটিতে ব্যাক-আপ সংক্রান্ত নিয়ম আছে।

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

  2. res/xml/ ডিরেক্টরিতে @xml/backup_rules নামের একটি 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 (API লেভেল 28) বা তার পরবর্তী ভার্সনে নিম্নলিখিত শর্ত যোগ করতে পারবেন:

আপনি যদি নিজের ডেভেলপমেন্ট ডিভাইস 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.
}

জাভা

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 (API লেভেল 31) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, Android 12 বা তার পরবর্তী যেকোনও ভার্সনে চলা ডিভাইসে কোন ফাইল ব্যাক-আপ নেওয়া হবে তা নিয়ন্ত্রণ করতে এই বিভাগের ধাপগুলি অনুসরণ করুন।

  1. আপনার AndroidManifest.xml ফাইলে, <application> এলিমেন্টে android:dataExtractionRules অ্যাট্রিবিউট যোগ করুন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে। এই অ্যাট্রিবিউটটি একটি XML ফাইলকে নির্দেশ করে যেটিতে ব্যাকআপ নিয়ম রয়েছে।

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

  2. res/xml/ ডিরেক্টরিতে backup_rules.xml নামের একটি 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>

XML কনফিগারেশন সিনট্যাক্স

আপনার অ্যাপ Android-এর যে ভার্সনকে টার্গেট করছে এবং যে ভার্সনে চলছে তার উপর নির্ভর করে কনফিগারেশন ফাইলের XML সিনট্যাক্স আলাদা হয়।

Android 11 বা এর আগের যেকোনও ভার্সন

Android 11 বা তার আগের ভার্সনে চলা ডিভাইসের জন্য ব্যাক-আপ নিয়ন্ত্রণ করে এমন কনফিগারেশন ফাইলের জন্য নিম্নলিখিত XML সিনট্যাক্স ব্যবহার করুন।

<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 (API লেভেল 31) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করলে, কনফিগারেশন ফাইলের জন্য নিম্নলিখিত XML সিনট্যাক্স ব্যবহার করুন যা 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 ডিরেক্টরি ছাড়া সব কন্টেন্টের জন্য সম্পূর্ণরূপে চালু করা হয়, যেমনটি ব্যাক-আপ নেওয়া ফাইল বিভাগে বর্ণনা করা হয়েছে।

আপনার অ্যাপ, <cloud-backup> বিভাগে disableIfNoEncryptionCapabilities ফ্ল্যাগ সেট করতে পারে যাতে ব্যাক-আপ শুধুমাত্র তখনই হয় যখন এটি এনক্রিপ্ট করা যায়, যেমন ব্যবহারকারীর লক স্ক্রিন থাকলে। এই সীমাবদ্ধতা সেট করলে, ব্যবহারকারীর ডিভাইস এনক্রিপশন সাপোর্ট না করলে ক্লাউডে ব্যাক-আপ পাঠানো বন্ধ হয়ে যায়, তবে D2D ট্রান্সফার সার্ভারে পাঠানো হয় না বলে, এনক্রিপশন সাপোর্ট করে না এমন ডিভাইসেও সেগুলি কাজ করতে থাকে।

অন্তর্ভুক্ত করা ও বাদ দেওয়ার এলিমেন্টের সিনট্যাক্স

<full-backup-content>, <cloud-backup> এবং <device-transfer> ট্যাগের (ডিভাইসের Android ভার্সন এবং আপনার অ্যাপের targetSDKVersion-এর উপর নির্ভর করে) মধ্যে আপনি <include> এবং <exclude> এলিমেন্ট নির্ধারণ করতে পারবেন:

<include>

ব্যাক-আপ নেওয়ার জন্য কোনও ফাইল বা ফোল্ডার নির্দিষ্ট করে। ডিফল্ট হিসেবে, অটো ব্যাক-আপে প্রায় সব অ্যাপ ফাইল অন্তর্ভুক্ত থাকে। আপনি <include> এলিমেন্ট উল্লেখ করলে, সিস্টেম আর ডিফল্ট হিসেবে কোনও ফাইল অন্তর্ভুক্ত করে না এবং শুধুমাত্র উল্লেখ করা ফাইল ব্যাক-আপ নেয়। একাধিক ফাইল অন্তর্ভুক্ত করতে, একাধিক <include> এলিমেন্ট ব্যবহার করুন।

Android 11 ও তার আগের ভার্সনে, এই এলিমেন্টে requireFlags অ্যাট্রিবিউটও থাকতে পারে, যা ব্যাক-আপের জন্য শর্তসাপেক্ষ প্রয়োজনীয়তা কীভাবে নির্ধারণ করতে হয় সেই সংক্রান্ত বিভাগে আরও বিস্তারিতভাবে আলোচনা করা হয়েছে।

getCacheDir(), getCodeCacheDir() বা getNoBackupFilesDir()-এর মাধ্যমে ফেরত পাঠানো ডিরেক্টরির ফাইলগুলি আপনি অন্তর্ভুক্ত করার চেষ্টা করলেও সেগুলি সবসময় বাদ দেওয়া হয়।

<exclude>

ব্যাক-আপ নেওয়ার সময় বাদ দেওয়ার জন্য কোনও ফাইল বা ফোল্ডার নির্দিষ্ট করে। এখানে কিছু ফাইল দেওয়া হল যেগুলি সাধারণত ব্যাক-আপ থেকে বাদ দেওয়া হয়:

  • এমন ফাইল যাতে ডিভাইস-নির্দিষ্ট শনাক্তকারী থাকে, যা সার্ভার দ্বারা ইস্যু করা হয় অথবা ডিভাইসে তৈরি করা হয়। যেমন, কোনও ব্যবহারকারী নতুন ডিভাইসে আপনার অ্যাপ ইনস্টল করলে, প্রতিবার Firebase Cloud Messaging (FCM)-কে রেজিস্ট্রেশন টোকেন জেনারেট করতে হয়। পুরনো রেজিস্ট্রেশন টোকেন রিস্টোর করা হলে, অ্যাপটি অপ্রত্যাশিতভাবে আচরণ করতে পারে।

  • অ্যাপ ডিবাগিং সম্পর্কিত ফাইল।

  • বড় ফাইল যার কারণে অ্যাপ ২৫ এমবি ব্যাকআপ কোটা অতিক্রম করে।

প্রতিটি <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 (API লেভেল 36.1) থেকে শুরু করে, আপনি Android নয় এমন ডিভাইসে ডেটা ট্রান্সফার করার জন্য অটো ব্যাক-আপ কনফিগার করতে পারবেন। এটি করতে, Android 12 বা তার পরবর্তী ভার্সনের সিনট্যাক্সে দেখানো অনুযায়ী, আপনার <data-extraction-rules> কনফিগারেশনের মধ্যে <cross-platform-transfer> এলিমেন্ট যোগ করুন। আপনাকে অবশ্যই প্রয়োজনীয় platform অ্যাট্রিবিউট ব্যবহার করে টার্গেট প্ল্যাটফর্ম নির্দিষ্ট করতে হবে। শুধুমাত্র ios ভ্যালু কাজ করে।

এই বিভাগের মধ্যে, আপনি স্ট্যান্ডার্ড <include> এবং <exclude> এলিমেন্ট ব্যবহার করতে পারেন, যেমন এলিমেন্ট অন্তর্ভুক্ত এবং বাদ দেওয়ার সিনট্যাক্স-এ বর্ণনা করা হয়েছে, কোন ডেটা ট্রান্সফার করতে হবে তা নির্দিষ্ট করার জন্য।

এছাড়াও, টার্গেট প্ল্যাটফর্মে সংশ্লিষ্ট অ্যাপের সাথে আপনার অ্যাপ ম্যাচ করতে সিস্টেমকে সাহায্য করার জন্য আপনাকে অবশ্যই <platform-specific-params> এলিমেন্ট অন্তর্ভুক্ত করতে হবে। এই এলিমেন্টে নিম্নলিখিত প্রয়োজনীয় অ্যাট্রিবিউট আছে:

  • bundleId: অন্য প্ল্যাটফর্মে অ্যাপের বান্ডিল আইডি (যেমন, আপনার iOS অ্যাপের বান্ডিল আইডি)।
  • teamId: অন্য প্ল্যাটফর্মে অ্যাপের টিম আইডি (যেমন, আপনার iOS অ্যাপের টিম আইডি)।
  • contentVersion: আপনার সংজ্ঞায়িত করা একটি ভার্সন স্ট্রিং, যা এক্সপোর্ট করা ডেটা ফর্ম্যাটের সাথে যুক্ত।

bundleId এবং teamId অ্যাট্রিবিউট ডেটা ইন্টিগ্রিটি এবং অ্যাপ-টু-অ্যাপ ম্যাচিং যাচাই করতে ব্যবহার করা হয়। তারা গ্যারান্টি দেয় যে এক্সপোর্ট করার সময় ডেটা শুধুমাত্র অন্য প্ল্যাটফর্মের নির্দিষ্ট অ্যাপে ট্রান্সফার করা হয় এবং ইমপোর্ট করার সময় এই Android অ্যাপ শুধুমাত্র সেই নির্দিষ্ট অ্যাপ থেকে ডেটা ইমপোর্ট করে।

XML নিয়মের বাইরে ডেটা ট্রান্সফর্মেশন ও ট্রান্সফার প্রসেসের উপর আরও সূক্ষ্ম নিয়ন্ত্রণ পেতে, আপনি কাস্টম BackupAgent প্রয়োগ করতে এবং ক্রস-প্ল্যাটফর্ম ট্রান্সফার API ব্যবহার করতে পারবেন।

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()। অ্যাপ না চললেও এই কলব্যাক পদ্ধতিগুলি কার্যকর করা হয়।

  • আপনি XML নিয়মের মাধ্যমে ব্যাক-আপ নিতে চান এমন ফাইলের সেট সহজে প্রকাশ করতে পারবেন না। এইসব বিরল ক্ষেত্রে, আপনি BackupAgent প্রয়োগ করতে পারেন যা onFullBackup(FullBackupDataOutput) ওভাররাইড করে আপনার প্রয়োজনীয় ডেটা স্টোর করে। সিস্টেমের ডিফল্ট ইমপ্লিমেন্টেশন বজায় রাখতে, super.onFullBackup() সহ সুপারক্লাসে সংশ্লিষ্ট মেথড কল করুন।

আপনি BackupAgent প্রয়োগ করলে, ডিফল্ট হিসেবে সিস্টেম আশা করে যে আপনার অ্যাপ কী-ভ্যালু ব্যাক-আপ ও রিস্টোর করবে। পরিবর্তে ফাইল-ভিত্তিক অটো ব্যাক-আপ ব্যবহার করতে, আপনার অ্যাপের ম্যানিফেস্টে android:fullBackupOnly অ্যাট্রিবিউটটি true-এ সেট করুন।

অটোমেটিক ব্যাক-আপ ও রিস্টোর করার সময়, সিস্টেম অ্যাপটিকে সীমাবদ্ধ মোডে চালু করে যাতে অ্যাপটি এমন ফাইল অ্যাক্সেস করতে না পারে যার ফলে সমস্যা হতে পারে এবং অ্যাপটি যাতে তার BackupAgent-এ কলব্যাক পদ্ধতি কার্যকর করতে পারে। এই সীমাবদ্ধ মোডে, অ্যাপের মূল অ্যাক্টিভিটি অটোমেটিক চালু হয় না, এর কন্টেন্ট প্রোভাইডার শুরু হয় না এবং অ্যাপের ম্যানিফেস্টে ঘোষিত কোনও সাব-ক্লাসের পরিবর্তে বেস-ক্লাস Application ইনস্ট্যান্টিয়েট হয়।

আপনার BackupAgent-কে অবশ্যই অ্যাবস্ট্রাক্ট পদ্ধতি onBackup() এবং onRestore() প্রয়োগ করতে হবে, যা কী-ভ্যালু ব্যাক-আপের জন্য ব্যবহার করা হয়। আপনি কী-ভ্যালু ব্যাক-আপ পারফর্ম করতে না চাইলে, এইসব পদ্ধতির ইমপ্লিমেন্টেশন ফাঁকা রাখতে পারেন।

আরও তথ্যের জন্য, BackupAgent এক্সটেন্ড করুন দেখুন।

BackupAgent-এ ক্রস-প্ল্যাটফর্ম ট্রান্সফার ম্যানেজ করুন

Android 16 QPR2 (API লেভেল ৩৬.১) থেকে শুরু করে, ক্রস-প্ল্যাটফর্ম ডেটা ট্রান্সফার আরও ভালোভাবে করার জন্য BackupAgent-এ বেশ কিছু নতুন API উপলভ্য আছে।

নতুন ট্রান্সপোর্ট ফ্ল্যাগ:

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

জাভা

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