আচরণের পরিবর্তন: 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 গুলি অবমূল্যায়িত এবং অক্ষম করা হয়েছে৷

অ্যান্ড্রয়েড 15 (API স্তর 35) টার্গেট করা অ্যাপগুলির মধ্যে elegantTextHeight TextView বৈশিষ্ট্যটি ডিফল্টভাবে true হিসাবে সেট করা আছে, কমপ্যাক্ট ফন্টটিকে এমন একটি দিয়ে প্রতিস্থাপন করা যা অনেক বেশি পাঠযোগ্য। আপনি elegantTextHeight অ্যাট্রিবিউটটি false সেট করে এটিকে ওভাররাইড করতে পারেন।

অ্যান্ড্রয়েড 16 elegantTextHeight অ্যাট্রিবিউটকে অবমূল্যায়ন করে, এবং আপনার অ্যাপটি Android 16 কে লক্ষ্য করলে অ্যাট্রিবিউটটি উপেক্ষা করা হবে। এই APIগুলির দ্বারা নিয়ন্ত্রিত "UI ফন্টগুলি" বন্ধ করা হচ্ছে, তাই আরবি, লাও, মায়ানমার, গুজরাটি, মায়ানমার, মালাগুজরাতি, মালায়ানা, মালাগুজরা, মায়ানমার, মালাগুজরা, মায়ানমার, টেক্সট টেক্সট রেন্ডারিং সামঞ্জস্যপূর্ণ এবং ভবিষ্যতের প্রুফ টেক্সট রেন্ডারিং নিশ্চিত করতে আপনার যেকোনো লেআউটকে মানিয়ে নেওয়া উচিত। থাই।

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

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

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

Android 16 টার্গেট করার আগে, যখন scheduleAtFixedRate একটি বৈধ প্রক্রিয়া লাইফসাইকেলের বাইরে থাকার কারণে একটি টাস্ক এক্সিকিউশন মিস করে, অ্যাপটি একটি বৈধ লাইফসাইকেলে ফিরে গেলে সমস্ত মিস করা এক্সিকিউশন অবিলম্বে কার্যকর হয়।

অ্যান্ড্রয়েড 16-কে টার্গেট করার সময়, অ্যাপটি একটি বৈধ জীবনচক্রে ফিরে এলে scheduleAtFixedRate সর্বাধিক একটি মিস করা কার্যকর করা হয়। এই আচরণ পরিবর্তন অ্যাপের কর্মক্ষমতা উন্নত করবে বলে আশা করা হচ্ছে। আপনার অ্যাপ প্রভাবিত হয়েছে কিনা তা পরীক্ষা করতে আপনার অ্যাপে এই আচরণ পরীক্ষা করুন। এছাড়াও আপনি অ্যাপের সামঞ্জস্যতা ফ্রেমওয়ার্ক ব্যবহার করে এবং STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS কম্প্যাট পতাকা সক্ষম করে পরীক্ষা করতে পারেন।

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

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) নিম্নলিখিত নিরাপত্তা পরিবর্তনগুলি অন্তর্ভুক্ত করে৷

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

For apps targeting Android 16 or higher, MediaStore#getVersion() will now be unique to each app. This eliminates identifying properties from the version string to prevent abuse and usage for fingerprinting techniques. Apps shouldn't make any assumptions around the format of this version. Apps should already handle version changes when using this API and in most cases shouldn't need to change their current behavior, unless the developer has attempted to infer additional information that is beyond the intended scope of this API.

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

The Safer Intents feature is a multi-phase security initiative designed to improve the security of Android's intent resolution mechanism. The goal is to protect apps from malicious actions by adding checks during intent processing and filtering intents that don't meet specific criteria.

In Android 15 the feature focused on the sending app, now with Android 16, shifts control to the receiving app, allowing developers to opt-in to strict intent resolution using their app manifest.

Two key changes are being implemented:

1. Explicit Intents Must Match the Target Component's Intent Filter: If an intent explicitly targets a component, it should match that component's intent filter.

2. Intents Without an Action Cannot Match any Intent Filter: Intents that don't have an action specified shouldn't be resolved to any intent filter.

These changes only apply when multiple apps are involved and don't affect intent handling within a single app.

Impact

The opt-in nature means that developers must explicitly enable it in their app manifest for it to take effect. As a result, the feature's impact will be limited to apps whose developers:

• Are aware of the Safer Intents feature and its benefits.
• Actively choose to incorporate stricter intent handling practices into their apps.

This opt-in approach minimizes the risk of breaking existing apps that may rely on the current less-secure intent resolution behavior.

While the initial impact in Android 16 may be limited, the Safer Intents initiative has a roadmap for broader impact in future Android releases. The plan is to eventually make strict intent resolution the default behavior.

The Safer Intents feature has the potential to significantly enhance the security of the Android ecosystem by making it more difficult for malicious apps to exploit vulnerabilities in the intent resolution mechanism.

However, the transition to opt-out and mandatory enforcement must be carefully managed to address potential compatibility issues with existing apps.

Implementation

Developers need to explicitly enable stricter intent matching using the intentMatchingFlags attribute in their app manifest. Here is an example where the feature is opt-in for the entire app, but disabled/opt-out on a receiver:

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

More on the supported flags:

Testing and Debugging

When the enforcement is active, apps should function correctly if the intent caller has properly populated the intent. However, blocked intents will trigger warning log messages like "Intent does not match component's intent filter:" and "Access blocked:" with the tag "PackageManager." This indicates a potential issue that could impact the app and requires attention.

Logcat filter:

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

গোপনীয়তা

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) স্থানীয় নেটওয়ার্ক ঠিকানা হিসাবে শ্রেণীবদ্ধ করা হয়েছে।

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