আচরণের পরিবর্তন: Android 16 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপ

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

আপনার অ্যাপ্লিকেশানের targetSdkVersion নির্বিশেষে Android 16-এ চলমান সমস্ত অ্যাপ্লিকেশানকে প্রভাবিত করে এমন আচরণের পরিবর্তনগুলির তালিকাটিও পর্যালোচনা করতে ভুলবেন না।

ব্যবহারকারীর অভিজ্ঞতা এবং সিস্টেম UI

অ্যান্ড্রয়েড 16 (এপিআই লেভেল 36) নিম্নলিখিত পরিবর্তনগুলিকে অন্তর্ভুক্ত করে যা আরও সামঞ্জস্যপূর্ণ, স্বজ্ঞাত ব্যবহারকারীর অভিজ্ঞতা তৈরি করার উদ্দেশ্যে করা হয়েছে৷

এজ টু এজ অপ্ট-আউট চলে যাচ্ছে

অ্যান্ড্রয়েড 15 (API লেভেল 35) টার্গেট করা অ্যাপ্লিকেশানগুলির জন্য এজ-টু-এজ এনফোর্স করেছে , কিন্তু আপনার অ্যাপটি R.attr#windowOptOutEdgeToEdgeEnforcement সেট করে অপ্ট-আউট করতে পারে true Android 16 (API লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য, R.attr#windowOptOutEdgeToEdgeEnforcement অবহেলিত এবং অক্ষম করা হয়েছে এবং আপনার অ্যাপ এজ-টু-এজ যাওয়া অপ্ট-আউট করতে পারে না।

• আপনার অ্যাপ যদি Android 16 (API লেভেল 36) কে টার্গেট করে এবং একটি Android 15 ডিভাইসে চলমান থাকে, R.attr#windowOptOutEdgeToEdgeEnforcement কাজ করতে থাকবে।
• আপনার অ্যাপ যদি Android 16 (API লেভেল 36) কে লক্ষ্য করে এবং একটি Android 16 ডিভাইসে চলমান থাকে, R.attr#windowOptOutEdgeToEdgeEnforcement অক্ষম করা হয়েছে।

অ্যান্ড্রয়েড 16-এ পরীক্ষার জন্য, নিশ্চিত করুন যে আপনার অ্যাপ এজ-টু-এজ সমর্থন করে এবং R.attr#windowOptOutEdgeToEdgeEnforcement এর ব্যবহার সরিয়ে ফেলুন যাতে আপনার অ্যাপটি Android 15 ডিভাইসে এজ-টু-এজ সমর্থন করে। এজ-টু-এজ সমর্থন করতে, রচনা এবং দর্শন নির্দেশিকা দেখুন।

ভবিষ্যদ্বাণীমূলক ফিরে জন্য মাইগ্রেশন বা অপ্ট-আউট প্রয়োজন

Android 16 (API স্তর 36) বা উচ্চতর এবং Android 16 বা উচ্চতর ডিভাইসে চলমান অ্যাপ্লিকেশানগুলির জন্য, পূর্বাভাসমূলক ব্যাক সিস্টেম অ্যানিমেশনগুলি (ব্যাক-টু-হোম, ক্রস-টাস্ক, এবং ক্রস-অ্যাক্টিভিটি) ডিফল্টরূপে সক্রিয় থাকে। উপরন্তু, onBackPressed বলা হয় না এবং KeyEvent.KEYCODE_BACK আর পাঠানো হয় না।

যদি আপনার অ্যাপ ব্যাক ইভেন্টে বাধা দেয় এবং আপনি এখনও পূর্বাভাসমূলক ব্যাক এ মাইগ্রেট না করে থাকেন, তাহলে সমর্থিত ব্যাক নেভিগেশন এপিআই ব্যবহার করতে আপনার অ্যাপ আপডেট করুন , অথবা আপনার অ্যাপের AndroidManifest.xml ফাইলের <application> অ্যাপ্লিকেশন> বা <activity> ট্যাগে android:enableOnBackInvokedCallback অ্যাট্রিবিউটকে false সেট করে সাময়িকভাবে অপ্ট আউট করুন।

মার্জিত ফন্ট API গুলি অবমূল্যায়িত এবং অক্ষম করা হয়েছে৷

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

মূল কার্যকারিতা

Android 16 (API স্তর 36) নিম্নলিখিত পরিবর্তনগুলিকে অন্তর্ভুক্ত করে যা Android সিস্টেমের বিভিন্ন মূল ক্ষমতাগুলিকে সংশোধন বা প্রসারিত করে৷

নির্দিষ্ট হার কাজের সময়সূচী অপ্টিমাইজেশান

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

ডিভাইস ফর্ম ফ্যাক্টর

Android 16 (API লেভেল 36) বড় স্ক্রীন ডিভাইসে প্রদর্শিত হলে অ্যাপগুলির জন্য নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে।

অভিযোজিত বিন্যাস

Android অ্যাপগুলি এখন বিভিন্ন ডিভাইসে (যেমন ফোন, ট্যাবলেট, ফোল্ডেবল, ডেস্কটপ, গাড়ি এবং টিভি) এবং বড় স্ক্রিনে (যেমন স্প্লিট স্ক্রিন এবং ডেস্কটপ উইন্ডোজিং) উইন্ডোজিং মোডগুলিতে চলার সাথে, ডেভেলপারদের Android অ্যাপ তৈরি করা উচিত যা ডিভাইসের অভিযোজন নির্বিশেষে যেকোনো স্ক্রীন এবং উইন্ডো আকারের সাথে খাপ খায়। আজকের মাল্টিডিভাইস বিশ্বে সীমাবদ্ধতা এবং পরিবর্তনযোগ্যতার মতো দৃষ্টান্তগুলি খুব সীমাবদ্ধ।

অভিযোজন, পরিবর্তনযোগ্যতা এবং আকৃতির অনুপাতের সীমাবদ্ধতা উপেক্ষা করুন

অ্যান্ড্রয়েড 16 (এপিআই লেভেল 36) টার্গেট করা অ্যাপগুলির জন্য, অ্যান্ড্রয়েড 16-এ সিস্টেম কীভাবে ওরিয়েন্টেশন, রিসাইজবিলিটি এবং অ্যাসপেক্ট রেশিও সীমাবদ্ধতাগুলি পরিচালনা করে তার পরিবর্তনগুলি অন্তর্ভুক্ত করে৷ সবচেয়ে ছোট প্রস্থ >= 600dp সহ ডিসপ্লেতে, বিধিনিষেধ আর প্রযোজ্য নয়। অ্যাসপেক্ট রেশিও বা ব্যবহারকারীর পছন্দের অভিযোজন নির্বিশেষে অ্যাপগুলি সম্পূর্ণ ডিসপ্লে উইন্ডোটি পূরণ করে এবং পিলারবক্সিং ব্যবহার করা হয় না।

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

আপনি অ্যাপের সামঞ্জস্যতা ফ্রেমওয়ার্ক ব্যবহার করে এবং UNIVERSAL_RESIZABLE_BY_DEFAULT কম্প্যাট পতাকা সক্ষম করে এই আচরণটি পরীক্ষা করতে পারেন৷

সাধারণ ব্রেকিং পরিবর্তন

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

ডিভাইস ঘূর্ণন মঞ্জুরি প্রদানের ফলে আরও কার্যকলাপ পুনঃসৃষ্টি হয়, যা সঠিকভাবে সংরক্ষণ না করলে ব্যবহারকারীর অবস্থা হারাতে পারে। সেভ UI স্টেটে কীভাবে সঠিকভাবে UI স্থিতি সংরক্ষণ করবেন তা শিখুন।

বাস্তবায়নের বিবরণ

নিম্নলিখিত ম্যানিফেস্ট অ্যাট্রিবিউট এবং রানটাইম APIগুলি পূর্ণ-স্ক্রীন এবং মাল্টি-উইন্ডো মোডে বড় স্ক্রীন ডিভাইসগুলিতে উপেক্ষা করা হয়:

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

screenOrientation , setRequestedOrientation() , এবং getRequestedOrientation() এর জন্য নিম্নলিখিত মানগুলি উপেক্ষা করা হয়েছে:

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

ডিসপ্লে রিসাইজযোগ্যতা সম্পর্কে, android:resizeableActivity="false" , android:minAspectRatio , এবং android:maxAspectRatio কোনো প্রভাব নেই৷

অ্যান্ড্রয়েড 16 (API স্তর 36) লক্ষ্য করা অ্যাপগুলির জন্য, অ্যাপের অভিযোজন, পরিবর্তনযোগ্যতা এবং আকৃতির অনুপাতের সীমাবদ্ধতাগুলি ডিফল্টভাবে বড় স্ক্রিনে উপেক্ষা করা হয়, কিন্তু সম্পূর্ণরূপে প্রস্তুত নয় এমন প্রতিটি অ্যাপ সাময়িকভাবে অপ্ট আউট করে এই আচরণটিকে ওভাররাইড করতে পারে (যার ফলে সামঞ্জস্য মোডে রাখা আগের আচরণে পরিণত হয়)।

ব্যতিক্রম

নিম্নলিখিত পরিস্থিতিতে Android 16 অভিযোজন, পরিবর্তনযোগ্যতা এবং আকৃতির অনুপাতের সীমাবদ্ধতা প্রযোজ্য নয়:

• গেমস ( android:appCategory পতাকার উপর ভিত্তি করে)
• ব্যবহারকারীরা ডিভাইসের আকৃতির অনুপাত সেটিংসে অ্যাপের ডিফল্ট আচরণে স্পষ্টভাবে নির্বাচন করছেন
• sw600dp এর থেকে ছোট স্ক্রীন

সাময়িকভাবে অপ্ট আউট করুন

একটি নির্দিষ্ট কার্যকলাপ অপ্ট আউট করতে, PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY ম্যানিফেস্ট সম্পত্তি ঘোষণা করুন:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

যদি আপনার অ্যাপের অনেক অংশ Android 16-এর জন্য প্রস্তুত না হয়, তাহলে আপনি অ্যাপ্লিকেশন স্তরে একই সম্পত্তি প্রয়োগ করে সম্পূর্ণরূপে অপ্ট আউট করতে পারেন:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

স্বাস্থ্য এবং ফিটনেস

Android 16 (API স্তর 36) স্বাস্থ্য এবং ফিটনেস ডেটা সম্পর্কিত নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

স্বাস্থ্য এবং ফিটনেস অনুমতি

Android 16 (API লেভেল 36) বা তার বেশির অ্যাপ্লিকেশানগুলির জন্য, BODY_SENSORS অনুমতিগুলি android.permissions.health এর অধীনে আরও দানাদার অনুমতি ব্যবহার করে, যা Health Connect ও ব্যবহার করে৷ অ্যান্ড্রয়েড 16 অনুযায়ী, যে কোনো API এর আগে BODY_SENSORS বা BODY_SENSORS_BACKGROUND জন্য সংশ্লিষ্ট android.permissions.health অনুমতি প্রয়োজন। এটি নিম্নলিখিত ডেটা প্রকার, API এবং ফোরগ্রাউন্ড পরিষেবার প্রকারগুলিকে প্রভাবিত করে:

• Wear OS-এ স্বাস্থ্য পরিষেবা থেকে HEART_RATE_BPM
• Android সেন্সর ম্যানেজার থেকে Sensor.TYPE_HEART_RATE
• Wear OS-এ ProtoLayout থেকে heartRateAccuracy এবং heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH যেখানে BODY_SENSORS এর জায়গায় সংশ্লিষ্ট android.permission.health অনুমতি প্রয়োজন

যদি আপনার অ্যাপ এই APIগুলি ব্যবহার করে, তাহলে এটিকে সংশ্লিষ্ট দানাদার অনুমতির অনুরোধ করা উচিত:

• ব্যবহারের সময় হার্ট রেট, SpO2 বা ত্বকের তাপমাত্রা পর্যবেক্ষণের জন্য: android.permissions.health এর অধীনে দানাদার অনুমতির জন্য অনুরোধ করুন, যেমন BODY_SENSORS পরিবর্তে READ_HEART_RATE ।
• ব্যাকগ্রাউন্ড সেন্সর অ্যাক্সেসের জন্য: BODY_SENSORS_BACKGROUND এর পরিবর্তে READ_HEALTH_DATA_IN_BACKGROUND অনুরোধ করুন।

এই অনুমতিগুলি স্বাস্থ্য, ফিটনেস এবং সুস্থতার ডেটার জন্য Android ডেটাস্টোর Health Connect থেকে ডেটা পড়ার অ্যাক্সেস রক্ষা করে সেই অনুমতিগুলির মতোই৷

মোবাইল অ্যাপস

READ_HEART_RATE এবং অন্যান্য দানাদার অনুমতিগুলি ব্যবহার করার জন্য মাইগ্রেট করা মোবাইল অ্যাপগুলিকে অবশ্যই অ্যাপের গোপনীয়তা নীতি প্রদর্শনের জন্য একটি কার্যকলাপ ঘোষণা করতে হবে। এটি স্বাস্থ্য সংযোগের মতো একই প্রয়োজনীয়তা।

সংযোগ

Android 16 (API লেভেল 36) পেরিফেরাল ডিভাইসগুলির সাথে সংযোগ উন্নত করতে ব্লুটুথ স্ট্যাকের নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

বন্ড ক্ষতি এবং এনক্রিপশন পরিবর্তনগুলি পরিচালনা করার জন্য নতুন উদ্দেশ্য

উন্নত বন্ড লস পরিচালনার অংশ হিসাবে, Android 16 বন্ড ক্ষয় এবং এনক্রিপশন পরিবর্তন সম্পর্কে আরও বেশি সচেতনতা সহ অ্যাপগুলি সরবরাহ করার জন্য 2টি নতুন উদ্দেশ্যও প্রবর্তন করেছে।

Android 16 টার্গেট করা অ্যাপগুলি এখন করতে পারে:

• একটি ACTION_KEY_MISSING অভিপ্রায় প্রাপ্ত করুন যখন দূরবর্তী বন্ড ক্ষতি সনাক্ত করা হয়, তাদের আরও তথ্যপূর্ণ ব্যবহারকারীর প্রতিক্রিয়া প্রদান করতে এবং যথাযথ পদক্ষেপ নেওয়ার অনুমতি দেয়৷
• যখনই লিঙ্কের এনক্রিপশন স্থিতি পরিবর্তন হয় তখন একটি ACTION_ENCRYPTION_CHANGE অভিপ্রায় পান৷ এর মধ্যে রয়েছে এনক্রিপশন স্ট্যাটাস পরিবর্তন, এনক্রিপশন অ্যালগরিদম পরিবর্তন এবং এনক্রিপশন কী সাইজ পরিবর্তন। পরে ACTION_ENCRYPTION_CHANGE অভিপ্রায় পাওয়ার পরে যদি লিঙ্কটি সফলভাবে এনক্রিপ্ট করা হয় তবে অ্যাপগুলিকে অবশ্যই বন্ড পুনরুদ্ধার করা বিবেচনা করতে হবে৷

বিভিন্ন OEM বাস্তবায়নের সাথে মানিয়ে নেওয়া

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

আমরা নিম্নলিখিত অ্যাপ আচরণের সুপারিশ করি:

• যদি ACTION_KEY_MISSING অভিপ্রায় সম্প্রচার করা হয়:

  ACL (অ্যাসিনক্রোনাস সংযোগ-কম) লিঙ্কটি সিস্টেম দ্বারা সংযোগ বিচ্ছিন্ন করা হবে, কিন্তু ডিভাইসের জন্য বন্ড তথ্য (যেমন এখানে বর্ণনা করা হয়েছে) ধরে রাখা হবে।

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

  ACTION_KEY_MISSING প্রাপ্তির পরে যদি একটি ডিভাইস সংযোগ বিচ্ছিন্ন হয়ে যায়, আপনার অ্যাপটিকে পুনরায় সংযোগ করার বিষয়ে সতর্ক হওয়া উচিত, কারণ ডিভাইসটি আর সিস্টেমের সাথে বন্ধন নাও থাকতে পারে৷

• যদি ACTION_KEY_MISSING অভিপ্রায় সম্প্রচার না করা হয়:

  ACL লিঙ্কটি সংযুক্ত থাকবে এবং ডিভাইসের বন্ড তথ্য সিস্টেম দ্বারা সরিয়ে দেওয়া হবে, Android 15-এর আচরণের মতো।

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

ব্লুটুথ বন্ড অপসারণের নতুন উপায়

Android 16 টার্গেট করা সমস্ত অ্যাপ এখন CompanionDeviceManager এ একটি পাবলিক API ব্যবহার করে ব্লুটুথ ডিভাইসগুলিকে আনপেয়ার করতে সক্ষম৷ যদি একটি সহচর ডিভাইস একটি CDM অ্যাসোসিয়েশন হিসাবে পরিচালিত হয়, তাহলে অ্যাপটি সংশ্লিষ্ট ডিভাইসে নতুন removeBond(int) API ব্যবহার করে ব্লুটুথ বন্ড অপসারণ ট্রিগার করতে পারে। অ্যাপটি ব্লুটুথ ডিভাইসের সম্প্রচার ইভেন্ট ACTION_BOND_STATE_CHANGED শুনে বন্ডের অবস্থার পরিবর্তনগুলি নিরীক্ষণ করতে পারে।

নিরাপত্তা

Android 16 (API স্তর 36) নিম্নলিখিত নিরাপত্তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

মিডিয়াস্টোর সংস্করণ লকডাউন

অ্যান্ড্রয়েড 16 বা তার বেশির দিকের অ্যাপ্লিকেশানগুলির জন্য, MediaStore#getVersion() এখন প্রতিটি অ্যাপের জন্য অনন্য হবে৷ এটি ফিঙ্গারপ্রিন্টিং কৌশলগুলির অপব্যবহার এবং ব্যবহার রোধ করতে সংস্করণ স্ট্রিং থেকে বৈশিষ্ট্যগুলি সনাক্তকরণকে সরিয়ে দেয়। অ্যাপগুলিকে এই সংস্করণের বিন্যাসের চারপাশে কোনো অনুমান করা উচিত নয়। এই API ব্যবহার করার সময় অ্যাপগুলির ইতিমধ্যেই সংস্করণ পরিবর্তনগুলি পরিচালনা করা উচিত এবং বেশিরভাগ ক্ষেত্রে তাদের বর্তমান আচরণ পরিবর্তন করার প্রয়োজন হবে না, যদি না বিকাশকারী অতিরিক্ত তথ্য অনুমান করার চেষ্টা না করে যা এই API এর উদ্দেশ্যের বাইরে।

নিরাপদ অভিপ্রায়

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

অ্যান্ড্রয়েড 15- এ বৈশিষ্ট্যটি পাঠানোর অ্যাপের উপর দৃষ্টি নিবদ্ধ করে, এখন অ্যান্ড্রয়েড 16-এর সাথে, নিয়ন্ত্রণ গ্রহণকারী অ্যাপে স্থানান্তরিত করে, ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্ট ব্যবহার করে কঠোর অভিপ্রায় রেজোলিউশনে অপ্ট-ইন করার অনুমতি দেয়।

দুটি মূল পরিবর্তন বাস্তবায়িত হচ্ছে:

1. স্পষ্ট অভিপ্রায়গুলি অবশ্যই লক্ষ্য উপাদানের অভিপ্রায় ফিল্টারের সাথে মিলবে: যদি একটি অভিপ্রায় স্পষ্টভাবে একটি উপাদানকে লক্ষ্য করে, তবে এটি সেই উপাদানটির অভিপ্রায় ফিল্টারের সাথে মিলিত হওয়া উচিত।

2. কোনো ক্রিয়া ছাড়া ইন্টেন্ট কোনো ইন্টেন্ট ফিল্টারের সাথে মেলে না: কোনো ইন্টেন্ট ফিল্টারে নির্দিষ্ট কোনো অ্যাকশন নেই এমন ইন্টেন্টের সমাধান করা উচিত নয়।

এই পরিবর্তনগুলি শুধুমাত্র তখনই প্রযোজ্য হয় যখন একাধিক অ্যাপ জড়িত থাকে এবং একটি একক অ্যাপের মধ্যে অভিপ্রায় পরিচালনাকে প্রভাবিত করে না।

প্রভাব

অপ্ট-ইন প্রকৃতির মানে হল যে এটি কার্যকর করার জন্য বিকাশকারীদের অবশ্যই তাদের অ্যাপ ম্যানিফেস্টে স্পষ্টভাবে এটি সক্ষম করতে হবে। ফলস্বরূপ, বৈশিষ্ট্যটির প্রভাব সীমাবদ্ধ থাকবে সেই অ্যাপগুলির মধ্যে যার বিকাশকারীরা:

• নিরাপদ অভিপ্রায় বৈশিষ্ট্য এবং এর সুবিধা সম্পর্কে সচেতন।
• সক্রিয়ভাবে তাদের অ্যাপ্লিকেশানগুলিতে কঠোর অভিপ্রায় পরিচালনার অনুশীলনগুলি অন্তর্ভুক্ত করতে বেছে নিন।

এই অপ্ট-ইন পদ্ধতিটি বিদ্যমান অ্যাপগুলিকে ভাঙ্গার ঝুঁকি কমিয়ে দেয় যা বর্তমান কম-সুরক্ষিত অভিপ্রায় রেজোলিউশন আচরণের উপর নির্ভর করতে পারে।

যদিও অ্যান্ড্রয়েড 16-এ প্রাথমিক প্রভাব সীমিত হতে পারে, নিরাপদ অভিপ্রায় উদ্যোগের ভবিষ্যতের অ্যান্ড্রয়েড রিলিজে ব্যাপক প্রভাবের জন্য একটি রোডম্যাপ রয়েছে। পরিকল্পনাটি শেষ পর্যন্ত কঠোর অভিপ্রায় সমাধানকে ডিফল্ট আচরণ করা।

Safer Intents বৈশিষ্ট্যটি দূষিত অ্যাপগুলির জন্য অভিপ্রায় রেজোলিউশন পদ্ধতিতে দুর্বলতাগুলিকে কাজে লাগাতে আরও কঠিন করে Android ইকোসিস্টেমের নিরাপত্তা উল্লেখযোগ্যভাবে উন্নত করার সম্ভাবনা রয়েছে৷

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

বাস্তবায়ন

ডেভেলপারদের তাদের অ্যাপ ম্যানিফেস্টে intentMatchingFlags অ্যাট্রিবিউট ব্যবহার করে স্পষ্টভাবে কঠোর অভিপ্রায় ম্যাচিং সক্ষম করতে হবে। এখানে একটি উদাহরণ রয়েছে যেখানে বৈশিষ্ট্যটি সম্পূর্ণ অ্যাপের জন্য অপ্ট-ইন করা হয়েছে, কিন্তু একটি রিসিভারে অক্ষম/অপ্ট-আউট করা হয়েছে:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

সমর্থিত পতাকা সম্পর্কে আরও:

পরীক্ষা এবং ডিবাগিং

যখন এনফোর্সমেন্ট সক্রিয় থাকে, তখন অ্যাপগুলি সঠিকভাবে কাজ করবে যদি অভিপ্রায় কলকারীর অভিপ্রায়টি সঠিকভাবে পূরণ করা থাকে। যাইহোক, অবরুদ্ধ অভিপ্রায়গুলি "PackageManager." ট্যাগ সহ " "Intent does not match component's intent filter:" এবং "Access blocked:" মতো সতর্কীকরণ লগ বার্তাগুলিকে ট্রিগার করবে৷ এটি একটি সম্ভাব্য সমস্যা নির্দেশ করে যা অ্যাপটিকে প্রভাবিত করতে পারে এবং মনোযোগের প্রয়োজন।

লগক্যাট ফিল্টার:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

GPU syscall ফিল্টারিং

মালি জিপিইউ পৃষ্ঠকে শক্ত করার জন্য, মালি জিপিইউ আইওসিটিএলগুলিকে অবমূল্যায়ন করা হয়েছে বা শুধুমাত্র জিপিইউ ডেভেলপমেন্টের উদ্দেশ্যে তৈরি করা হয়েছে প্রোডাকশন বিল্ডে ব্লক করা হয়েছে। অতিরিক্তভাবে, GPU প্রোফাইলিংয়ের জন্য ব্যবহৃত IOCTLগুলি শেল প্রক্রিয়া বা ডিবাগযোগ্য অ্যাপ্লিকেশনগুলিতে সীমাবদ্ধ করা হয়েছে। প্ল্যাটফর্ম-স্তরের নীতির আরও বিস্তারিত জানার জন্য SAC আপডেট পড়ুন।

মালি জিপিইউ (পিক্সেল 6-9) ব্যবহার করে পিক্সেল ডিভাইসে এই পরিবর্তনটি ঘটে। আর্ম তাদের IOCTL-এর অফিসিয়াল শ্রেণীকরণ তাদের r54p2 রিলিজের Documentation/ioctl-categories.rst এ প্রদান করেছে। এই তালিকাটি ভবিষ্যতের ড্রাইভার রিলিজে বজায় রাখা অব্যাহত থাকবে।

এই পরিবর্তনটি সমর্থিত গ্রাফিক্স এপিআইগুলিকে প্রভাবিত করে না (ভুলকান এবং ওপেনজিএল সহ), এবং বিকাশকারী বা বিদ্যমান অ্যাপ্লিকেশনগুলিকে প্রভাবিত করবে বলে আশা করা যায় না। GPU প্রোফাইলিং টুল যেমন স্ট্রীমলাইন পারফরম্যান্স অ্যানালাইজার এবং Android GPU ইন্সপেক্টর প্রভাবিত হবে না।

টেস্টিং

আপনি যদি নিচের মত একটি SELinux অস্বীকার দেখতে পান, তাহলে সম্ভবত আপনার আবেদন এই পরিবর্তন দ্বারা প্রভাবিত হয়েছে:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

আপনার অ্যাপ্লিকেশনের যদি ব্লক করা IOCTL ব্যবহার করার প্রয়োজন হয়, তাহলে অনুগ্রহ করে একটি বাগ ফাইল করুন এবং এটি android-partner-security@google.com-এ বরাদ্দ করুন।

FAQ

1. এই নীতি পরিবর্তন কি সমস্ত OEM-এর ক্ষেত্রে প্রযোজ্য? এই পরিবর্তনটি অপ্ট-ইন করা হবে, তবে যেকোন OEM যারা এই শক্ত করার পদ্ধতি ব্যবহার করতে চান তাদের জন্য উপলব্ধ। পরিবর্তন বাস্তবায়নের নির্দেশাবলী বাস্তবায়ন ডকুমেন্টেশনে পাওয়া যাবে।

2. এটি কার্যকর করার জন্য OEM কোডবেসে পরিবর্তন করা কি বাধ্যতামূলক, নাকি এটি ডিফল্টরূপে একটি নতুন AOSP রিলিজের সাথে আসে? প্ল্যাটফর্ম-স্তরের পরিবর্তন ডিফল্টরূপে একটি নতুন AOSP রিলিজের সাথে আসবে। বিক্রেতারা তাদের কোডবেসে এই পরিবর্তনটি অপ্ট-ইন করতে পারে যদি তারা এটি প্রয়োগ করতে চায়৷

3. IOCTL তালিকা আপ টু ডেট রাখার জন্য SoCs কি দায়ী? উদাহরণস্বরূপ, যদি আমার ডিভাইস একটি ARM Mali GPU ব্যবহার করে, তাহলে আমাকে কি কোনো পরিবর্তনের জন্য ARM-এর সাথে যোগাযোগ করতে হবে? ড্রাইভার রিলিজের পরে পৃথক SoC গুলিকে ডিভাইস প্রতি তাদের IOCTL তালিকা আপডেট করতে হবে। উদাহরণ স্বরূপ, ARM তাদের প্রকাশিত IOCTL তালিকা ড্রাইভার আপডেটের পর আপডেট করবে। যাইহোক, OEM-দের নিশ্চিত করা উচিত যে তারা তাদের SEPpolicy-তে আপডেটগুলি অন্তর্ভুক্ত করেছে এবং প্রয়োজন অনুযায়ী তালিকায় যেকোনও নির্বাচিত কাস্টম IOCTL যোগ করেছে।

4. এই পরিবর্তনটি কি সমস্ত Pixel-এর ইন-মার্কেট ডিভাইসে স্বয়ংক্রিয়ভাবে প্রযোজ্য হয়, নাকি এই পরিবর্তনটি প্রয়োগ করার জন্য কিছু টগল করার জন্য ব্যবহারকারীর অ্যাকশন প্রয়োজন? এই পরিবর্তনটি মালি GPU (Pixel 6-9) ব্যবহার করে সমস্ত Pixel ইন-মার্কেট ডিভাইসগুলিতে প্রযোজ্য। এই পরিবর্তনটি প্রয়োগ করার জন্য কোন ব্যবহারকারীর পদক্ষেপের প্রয়োজন নেই।

5. এই নীতির ব্যবহার কার্নেল ড্রাইভারের কর্মক্ষমতা প্রভাবিত করবে? GFXBench ব্যবহার করে মালি GPU-তে এই নীতি পরীক্ষা করা হয়েছে, এবং GPU কর্মক্ষমতাতে কোনো পরিমাপযোগ্য পরিবর্তন লক্ষ্য করা যায়নি।

6. IOCTL তালিকার জন্য কি বর্তমান ইউজারস্পেস এবং কার্নেল ড্রাইভার সংস্করণের সাথে সারিবদ্ধ করা প্রয়োজন? হ্যাঁ, অনুমোদিত আইওসিটিএল-এর তালিকা অবশ্যই ইউজারস্পেস এবং কার্নেল ড্রাইভার উভয় দ্বারা সমর্থিত IOCTL-এর সাথে সিঙ্ক্রোনাইজ করা উচিত। ইউজার স্পেস বা কার্নেল ড্রাইভারের IOCTL আপডেট করা হলে, SEPpolicy IOCTL তালিকা মেলে আপডেট করতে হবে।

7. এআরএম আইওসিটিএলগুলিকে 'সীমাবদ্ধ' / 'ইন্সট্রুমেন্টেশন' হিসাবে শ্রেণীবদ্ধ করেছে, তবে আমরা সেগুলির কিছুকে উৎপাদন ব্যবহারের ক্ষেত্রে ব্যবহার করতে চাই এবং/অথবা অন্যকে অস্বীকার করতে চাই। স্বতন্ত্র OEMs/SoCs তাদের ইউজারস্পেস মালি লাইব্রেরির কনফিগারেশনের উপর ভিত্তি করে তারা যে IOCTLগুলি ব্যবহার করে তা কীভাবে শ্রেণীবদ্ধ করা যায় সে বিষয়ে সিদ্ধান্ত নেওয়ার জন্য দায়ী৷ এআরএম-এর তালিকা এগুলি সম্পর্কে সিদ্ধান্ত নিতে সাহায্য করতে ব্যবহার করা যেতে পারে, তবে প্রতিটি OEM/SoC-এর ব্যবহার-কেস আলাদা হতে পারে।

গোপনীয়তা

Android 16 (API স্তর 36) নিম্নলিখিত গোপনীয়তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

স্থানীয় নেটওয়ার্ক অনুমতি

LAN-এ থাকা ডিভাইসগুলি INTERNET অনুমতি আছে এমন যেকোনো অ্যাপ দ্বারা অ্যাক্সেস করা যেতে পারে। এটি স্থানীয় ডিভাইসগুলির সাথে অ্যাপগুলিকে সংযোগ করা সহজ করে তোলে তবে এটির গোপনীয়তার প্রভাবও রয়েছে যেমন ব্যবহারকারীর আঙ্গুলের ছাপ তৈরি করা এবং অবস্থানের জন্য একটি প্রক্সি হওয়া।

স্থানীয় নেটওয়ার্ক সুরক্ষা প্রকল্পের লক্ষ্য একটি নতুন রানটাইম অনুমতির পিছনে স্থানীয় নেটওয়ার্কে অ্যাক্সেস গেট করে ব্যবহারকারীর গোপনীয়তা রক্ষা করা।

মুক্তির পরিকল্পনা

এই পরিবর্তন দুটি রিলিজের মধ্যে স্থাপন করা হবে, যথাক্রমে 25Q2 এবং TBD । এটি অপরিহার্য যে বিকাশকারীরা 25Q2 এর জন্য এই নির্দেশিকা অনুসরণ করুন এবং প্রতিক্রিয়া শেয়ার করুন কারণ এই সুরক্ষাগুলি পরবর্তী Android রিলিজে প্রয়োগ করা হবে ৷ অধিকন্তু, তাদের নিম্নলিখিত নির্দেশিকা ব্যবহার করে অন্তর্নিহিত স্থানীয় নেটওয়ার্ক অ্যাক্সেসের উপর নির্ভর করে এমন পরিস্থিতি আপডেট করতে হবে এবং ব্যবহারকারীর প্রত্যাখ্যান এবং নতুন অনুমতি প্রত্যাহার করার জন্য প্রস্তুত করতে হবে।

প্রভাব

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

অ্যাপগুলি প্রভাবিত হবে যদি তারা ব্যবহার করে ব্যবহারকারীর স্থানীয় নেটওয়ার্ক অ্যাক্সেস করে:

• স্থানীয় নেটওয়ার্ক ঠিকানাগুলিতে কাঁচা সকেটের সরাসরি বা লাইব্রেরি ব্যবহার (যেমন mDNS বা SSDP পরিষেবা আবিষ্কার প্রোটোকল)
• ফ্রেমওয়ার্ক লেভেল ক্লাসের ব্যবহার যা স্থানীয় নেটওয়ার্ক অ্যাক্সেস করে (যেমন NsdManager)

একটি স্থানীয় নেটওয়ার্ক ঠিকানায় এবং সেখান থেকে ট্রাফিকের জন্য স্থানীয় নেটওয়ার্ক অ্যাক্সেসের অনুমতি প্রয়োজন৷ নিম্নলিখিত সারণী কিছু সাধারণ ক্ষেত্রে তালিকাভুক্ত করে:

এই নিষেধাজ্ঞাগুলি নেটওয়ার্কিং স্ট্যাকের গভীরে প্রয়োগ করা হয়, এবং এইভাবে তারা সমস্ত নেটওয়ার্কিং API- এ প্রযোজ্য। এর মধ্যে রয়েছে নেটিভ বা পরিচালিত কোডে তৈরি সকেট, Cronet এবং OkHttp-এর মতো নেটওয়ার্কিং লাইব্রেরি এবং এর উপরে প্রয়োগ করা যেকোনো API। স্থানীয় নেটওয়ার্কে (যেমন একটি .local প্রত্যয় সহ) পরিষেবাগুলি সমাধান করার চেষ্টা করার জন্য স্থানীয় নেটওয়ার্ক অনুমতির প্রয়োজন হবে৷

উপরের নিয়মের ব্যতিক্রম:

• যদি একটি ডিভাইসের DNS সার্ভার একটি স্থানীয় নেটওয়ার্কে থাকে, তাহলে এটিতে বা সেখান থেকে (53 পোর্টে) ট্রাফিকের জন্য স্থানীয় নেটওয়ার্ক অ্যাক্সেসের অনুমতির প্রয়োজন হয় না।
• আউটপুট সুইচার ব্যবহার করে তাদের অ্যাপ-মধ্যস্থ পিকার হিসাবে অ্যাপ্লিকেশনগুলির স্থানীয় নেটওয়ার্ক অনুমতির প্রয়োজন হবে না (2025Q4 এ আরও নির্দেশিকা আসবে)।

বিকাশকারী নির্দেশিকা (অপ্ট-ইন)

স্থানীয় নেটওয়ার্ক সীমাবদ্ধতা নির্বাচন করতে, নিম্নলিখিতগুলি করুন:

1. 25Q2 বিটা 3 বা তার পরের বিল্ডে ডিভাইসটিকে ফ্ল্যাশ করুন।
2. পরীক্ষা করার জন্য অ্যাপটি ইনস্টল করুন।

3. অ্যাডবি-তে অ্যাপকম্প্যাট পতাকা টগল করুন:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. ডিভাইসটি রিবুট করুন

এখন স্থানীয় নেটওয়ার্কে আপনার অ্যাপের অ্যাক্সেস সীমিত করা হয়েছে এবং স্থানীয় নেটওয়ার্ক অ্যাক্সেস করার যেকোনো প্রচেষ্টা সকেট ত্রুটির দিকে পরিচালিত করবে। আপনি যদি এমন API ব্যবহার করেন যা আপনার অ্যাপ প্রক্রিয়ার বাইরে স্থানীয় নেটওয়ার্ক ক্রিয়াকলাপ সম্পাদন করে (যেমন: NsdManager), সেগুলি অপ্ট-ইন পর্বের সময় প্রভাবিত হবে না।

অ্যাক্সেস পুনরুদ্ধার করতে, আপনাকে অবশ্যই NEARBY_WIFI_DEVICES এ আপনার অ্যাপের অনুমতি দিতে হবে।

1. অ্যাপটি তার ম্যানিফেস্টে NEARBY_WIFI_DEVICES অনুমতি ঘোষণা করেছে তা নিশ্চিত করুন।
2. সেটিংস > অ্যাপস > [অ্যাপ্লিকেশনের নাম] > অনুমতি > কাছাকাছি ডিভাইস > অনুমতিতে যান।

এখন স্থানীয় নেটওয়ার্কে আপনার অ্যাপ্লিকেশানের অ্যাক্সেস পুনরুদ্ধার করা উচিত এবং আপনার সমস্ত দৃশ্যকল্পগুলি অ্যাপটি বেছে নেওয়ার আগে যেভাবে কাজ করেছিল সেভাবে কাজ করা উচিত।

একবার স্থানীয় নেটওয়ার্ক সুরক্ষার জন্য প্রয়োগ শুরু হলে, অ্যাপ নেটওয়ার্ক ট্র্যাফিক কীভাবে প্রভাবিত হবে তা এখানে।

অ্যাপ-কম্প্যাট পতাকা টগল-অফ করতে নিম্নলিখিত কমান্ডটি ব্যবহার করুন

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

ত্রুটি

এই বিধিনিষেধগুলি থেকে উদ্ভূত ত্রুটিগুলি কলিং সকেটে ফেরত দেওয়া হবে যখনই এটি একটি স্থানীয় নেটওয়ার্ক ঠিকানায় পাঠান বা পাঠান ভেরিয়েন্ট আহ্বান করে।

উদাহরণ ত্রুটি:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

স্থানীয় নেটওয়ার্ক সংজ্ঞা

এই প্রকল্পে একটি স্থানীয় নেটওয়ার্ক একটি IP নেটওয়ার্ককে বোঝায় যা একটি সম্প্রচার-সক্ষম নেটওয়ার্ক ইন্টারফেস ব্যবহার করে, যেমন Wi-Fi বা ইথারনেট, কিন্তু সেলুলার (WWAN) বা VPN সংযোগগুলি বাদ দেয়৷

নিম্নলিখিতগুলিকে স্থানীয় নেটওয়ার্ক হিসাবে বিবেচনা করা হয়:

IPv4:

• 169.254.0.0/16 // লিঙ্ক স্থানীয়
• 100.64.0.0/10 // CGNAT
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• লিঙ্ক-স্থানীয়
• সরাসরি-সংযুক্ত রুট
• থ্রেডের মত স্টাব নেটওয়ার্ক
• একাধিক-সাবনেট (TBD)

উপরন্তু, উভয় মাল্টিকাস্ট ঠিকানা (224.0.0.0/4, ff00::/8) এবং IPv4 সম্প্রচার ঠিকানা (255.255.255.255) স্থানীয় নেটওয়ার্ক ঠিকানা হিসাবে শ্রেণীবদ্ধ করা হয়েছে।

অ্যাপ-মালিকানাধীন ফটো

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