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

অ্যান্ড্রয়েড 12 প্ল্যাটফর্মে এমন আচরণের পরিবর্তন রয়েছে যা আপনার অ্যাপকে প্রভাবিত করতে পারে। নিম্নলিখিত আচরণের পরিবর্তনগুলি সমস্ত অ্যাপের ক্ষেত্রে প্রযোজ্য যখন তারা Android 12-এ চলে, targetSdkVersion নির্বিশেষে। আপনার অ্যাপটি পরীক্ষা করা উচিত এবং তারপরে যেখানে প্রযোজ্য সেখানে সঠিকভাবে সমর্থন করার জন্য প্রয়োজন অনুসারে এটি সংশোধন করা উচিত।

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

ব্যবহারকারীর অভিজ্ঞতা

প্রসারিত overscroll প্রভাব

Android 12 এবং উচ্চতর সংস্করণে চলমান ডিভাইসগুলিতে, ওভারস্ক্রোল ইভেন্টগুলির ভিজ্যুয়াল আচরণ পরিবর্তিত হয়।

অ্যান্ড্রয়েড 11 এবং তার নিচের সংস্করণে, একটি ওভারস্ক্রোল ইভেন্ট ভিজ্যুয়াল উপাদানগুলিকে উজ্জ্বল করে তোলে; অ্যান্ড্রয়েড 12 এবং উচ্চতর সংস্করণে, ভিজ্যুয়াল উপাদানগুলি একটি ড্র্যাগ ইভেন্টে প্রসারিত এবং বাউন্স ব্যাক করে এবং তারা একটি ফ্লিং ইভেন্টে ফ্লিং এবং বাউন্স ব্যাক করে।

আরও তথ্যের জন্য, স্ক্রোল অঙ্গভঙ্গি অ্যানিমেট করার নির্দেশিকা দেখুন।

অ্যাপ স্প্ল্যাশ স্ক্রিন

আপনি যদি আগে অ্যান্ড্রয়েড 11 বা তার নিচের সংস্করণে একটি কাস্টম স্প্ল্যাশ স্ক্রিন প্রয়োগ করে থাকেন, তাহলে আপনাকে আপনার অ্যাপটি SplashScreen এপিআই-তে স্থানান্তর করতে হবে যাতে এটি Android 12 থেকে সঠিকভাবে প্রদর্শিত হয়। লঞ্চ অভিজ্ঞতা।

নির্দেশাবলীর জন্য, আপনার বিদ্যমান স্প্ল্যাশ স্ক্রীন বাস্তবায়নকে Android 12-এ স্থানান্তরিত করুন দেখুন।

উপরন্তু, অ্যান্ড্রয়েড 12 থেকে শুরু করে, সিস্টেমটি সর্বদা নতুন অ্যান্ড্রয়েড সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিনটি সমস্ত অ্যাপের জন্য ঠান্ডা এবং উষ্ণ শুরুতে প্রয়োগ করে। ডিফল্টরূপে, এই সিস্টেম ডিফল্ট স্প্ল্যাশ স্ক্রিনটি আপনার অ্যাপের লঞ্চার আইকন উপাদান এবং আপনার থিমের windowBackground (যদি এটি একটি একক রঙ হয়) ব্যবহার করে তৈরি করা হয়।

আরও বিশদ বিবরণের জন্য, স্প্ল্যাশ স্ক্রিন বিকাশকারী নির্দেশিকা দেখুন।

ওয়েব অভিপ্রায় রেজোলিউশন

অ্যান্ড্রয়েড 12 (এপিআই লেভেল 31) থেকে শুরু করে, একটি সাধারণ ওয়েব অভিপ্রায় আপনার অ্যাপে কোনো কার্যকলাপের সমাধান করে তখনই যদি আপনার অ্যাপটি সেই ওয়েব অভিপ্রায়ে থাকা নির্দিষ্ট ডোমেনের জন্য অনুমোদিত হয়। যদি আপনার অ্যাপটি ডোমেনের জন্য অনুমোদিত না হয়, তবে ওয়েব অভিপ্রায় ব্যবহারকারীর ডিফল্ট ব্রাউজার অ্যাপে সমাধান করে।

অ্যাপগুলি নিম্নলিখিতগুলির মধ্যে একটি করে এই অনুমোদন পেতে পারে:

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

অঙ্গভঙ্গি নেভিগেশন জন্য ইমারসিভ মোড উন্নতি

Android 12 বিদ্যমান আচরণকে একীভূত করে যাতে ব্যবহারকারীদের ইমারসিভ মোডে থাকাকালীন জেসচার নেভিগেশন কমান্ডগুলি সম্পাদন করা সহজ হয়৷ এছাড়াও, Android 12 স্টিকি ইমারসিভ মোডের জন্য পশ্চাদগামী সামঞ্জস্যপূর্ণ আচরণ প্রদান করে।

প্রদর্শন#getRealSize এবং getRealMetrics: অবচয় এবং সীমাবদ্ধতা

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

অ্যান্ড্রয়েড 12-এ আমরা WindowMetrics ব্যবহার করার পরামর্শ দিয়ে যাচ্ছি, এবং এই পদ্ধতিগুলিকে অবমূল্যায়ন করছি:

অ্যাপ্লিকেশনের সীমানা পুনরুদ্ধার করার জন্য ডিসপ্লে API ব্যবহার করে অ্যাপ্লিকেশনগুলির আচরণকে প্রশমিত করতে, অ্যান্ড্রয়েড 12 সম্পূর্ণরূপে পরিবর্তনযোগ্য নয় এমন অ্যাপ্লিকেশনগুলির জন্য API দ্বারা প্রত্যাবর্তিত মানগুলিকে সীমাবদ্ধ করে৷ MediaProjection সাথে এই তথ্য ব্যবহার করে এমন অ্যাপগুলির উপর এর প্রভাব পড়তে পারে।

অ্যাপগুলিকে তাদের উইন্ডোর সীমানা অনুসন্ধান করতে WindowMetrics API ব্যবহার করা উচিত এবং বর্তমান ঘনত্ব অনুসন্ধান করতে Configuration.densityDpi ব্যবহার করা উচিত৷

অ্যান্ড্রয়েডের পুরানো সংস্করণগুলির সাথে বিস্তৃত সামঞ্জস্যের জন্য, আপনি জেটপ্যাক WindowManager লাইব্রেরি ব্যবহার করতে পারেন, যার মধ্যে একটি WindowMetrics ক্লাস রয়েছে যা অ্যান্ড্রয়েড 4.0 (এপিআই স্তর 14) এবং উচ্চতর সমর্থন করে৷

WindowMetrics কিভাবে ব্যবহার করবেন তার উদাহরণ

প্রথমত, নিশ্চিত করুন যে আপনার অ্যাপের কার্যকলাপগুলি সম্পূর্ণরূপে পরিবর্তনযোগ্য ৷

যেকোন UI-সম্পর্কিত কাজের জন্য, বিশেষ করে WindowManager.getCurrentWindowMetrics() বা Jetpack-এর WindowMetricsCalculator.computeCurrentWindowMetrics() -এর জন্য একটি কার্যকলাপের প্রেক্ষাপট থেকে WindowMetrics উপর নির্ভর করা উচিত।

যদি আপনার অ্যাপটি একটি MediaProjection তৈরি করে, তাহলে সীমাগুলি অবশ্যই সঠিকভাবে মাপ করা উচিত কারণ প্রজেকশনটি ডিসপ্লে পার্টিশনটি ক্যাপচার করে যেখানে প্রজেক্টর অ্যাপটি চলছে৷

যদি অ্যাপটি সম্পূর্ণরূপে পরিবর্তনযোগ্য হয়, তবে কার্যকলাপের প্রসঙ্গটি সঠিক সীমানা প্রদান করে:

কোটলিন 

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

জাভা 

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

যদি অ্যাপটি সম্পূর্ণরূপে পরিবর্তনযোগ্য না হয়, তাহলে এটিকে অবশ্যই একটি WindowContext উদাহরণ থেকে জিজ্ঞাসা করতে হবে এবং WindowManager.getMaximumWindowMetrics() বা Jetpack পদ্ধতি WindowMetricsCalculator.computeMaximumWindowMetrics() ব্যবহার করে কার্যকলাপের সীমার WindowMetrics পুনরুদ্ধার করতে হবে।

কোটলিন 

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

জাভা 

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

মাল্টি-উইন্ডো মোডে সমস্ত অ্যাপ

Android 12 মাল্টি-উইন্ডো মোড স্ট্যান্ডার্ড আচরণ করে।

বড় স্ক্রিনে (sw >= 600dp), প্ল্যাটফর্মটি অ্যাপ কনফিগারেশন নির্বিশেষে মাল্টি-উইন্ডো মোডে সমস্ত অ্যাপ সমর্থন করে। resizeableActivity="false" হলে, ডিসপ্লের মাত্রা মিটমাট করার জন্য অ্যাপটিকে সামঞ্জস্যপূর্ণ মোডে রাখা হয়।

ছোট স্ক্রিনে (sw <600dp), সিস্টেমটি একটি অ্যাক্টিভিটির minWidth এবং minHeight চেক করে তা নির্ধারণ করে যে অ্যাক্টিভিটি মাল্টি-উইন্ডো মোডে চলতে পারে কিনা। resizeableActivity="false" হলে, ন্যূনতম প্রস্থ এবং উচ্চতা নির্বিশেষে অ্যাপটিকে মাল্টি-উইন্ডো মোডে চলতে বাধা দেওয়া হয়।

আরও তথ্যের জন্য, মাল্টি-উইন্ডো সমর্থন দেখুন।

বড় পর্দায় ক্যামেরা প্রিভিউ

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

অ্যান্ড্রয়েড 12-এ, ক্যামেরা অ্যাপ্লিকেশানগুলি যেগুলি একটি নির্দিষ্ট স্ক্রিন অভিযোজনের অনুরোধ করে এবং পুনরায় আকার দেওয়া যায় না ( resizeableActivity="false" ) সেগুলি স্বয়ংক্রিয়ভাবে ইনসেট পোর্ট্রেট মোডে প্রবেশ করে, যা ক্যামেরা প্রিভিউয়ের সঠিক অভিযোজন এবং আকৃতির অনুপাত নিশ্চিত করে৷ ফোল্ডেবল এবং অন্যান্য ডিভাইসে যেগুলিতে ক্যামেরা হার্ডওয়্যার অ্যাবস্ট্রাকশন লেয়ার ( HAL ) রয়েছে, ক্যামেরা সেন্সর ওরিয়েন্টেশনের জন্য ক্ষতিপূরণ দিতে ক্যামেরা আউটপুটে অতিরিক্ত ঘূর্ণন প্রয়োগ করা হয় এবং অ্যাপের ক্যামেরা প্রিভিউয়ের আকৃতির অনুপাতের সাথে মেলে ক্যামেরা আউটপুট ক্রপ করা হয়। ক্রপিং এবং অতিরিক্ত ঘূর্ণন ডিভাইসের অভিযোজন এবং ভাঁজ করা বা খোলা অবস্থায় থাকা নির্বিশেষে ক্যামেরা প্রিভিউটির সঠিক উপস্থাপনা নিশ্চিত করে।

ফোরগ্রাউন্ড পরিষেবা বিজ্ঞপ্তির জন্য UX বিলম্ব

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

কর্মক্ষমতা

সীমাবদ্ধ অ্যাপ স্ট্যান্ডবাই বালতি

Android 11 (API স্তর 30) একটি অ্যাপ স্ট্যান্ডবাই বাকেট হিসাবে সীমাবদ্ধ বালতি চালু করেছে। অ্যান্ড্রয়েড 12 থেকে শুরু করে, এই বালতিটি ডিফল্টরূপে সক্রিয় থাকে। সমস্ত বালতিগুলির মধ্যে সীমাবদ্ধ বালতিটির সর্বনিম্ন অগ্রাধিকার (এবং সর্বোচ্চ সীমাবদ্ধতা) রয়েছে৷ উচ্চ থেকে নিচু পর্যন্ত অগ্রাধিকারের ক্রম অনুসারে বালতিগুলি হল:

  1. সক্রিয়: অ্যাপ বর্তমানে ব্যবহৃত হচ্ছে বা খুব সম্প্রতি ব্যবহৃত হয়েছে।
  2. ওয়ার্কিং সেট: অ্যাপ নিয়মিত ব্যবহার করা হয়।
  3. ঘন ঘন: অ্যাপটি প্রায়ই ব্যবহৃত হয়, কিন্তু প্রতিদিন নয়।
  4. বিরল: অ্যাপটি প্রায়শই ব্যবহার করা হয় না।
  5. সীমাবদ্ধ: অ্যাপ প্রচুর পরিমাণে সিস্টেম রিসোর্স ব্যবহার করে বা অবাঞ্ছিত আচরণ প্রদর্শন করতে পারে।

আপনার অ্যাপটিকে সীমাবদ্ধ বালতিতে রাখতে হবে কিনা তা সিদ্ধান্ত নিতে সিস্টেমটি ব্যবহারের ধরণ ছাড়াও আপনার অ্যাপের আচরণ বিবেচনা করে।

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

আপনার অ্যাপ সীমাবদ্ধ বালতিতে আছে কিনা তা পরীক্ষা করুন

সিস্টেম আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রেখেছে কিনা তা পরীক্ষা করতে, getAppStandbyBucket() কল করুন। যদি এই পদ্ধতির রিটার্ন মান STANDBY_BUCKET_RESTRICTED হয়, তাহলে আপনার অ্যাপটি সীমাবদ্ধ বালতিতে রয়েছে।

সীমাবদ্ধ বালতি আচরণ পরীক্ষা করুন

সিস্টেম যখন আপনার অ্যাপটিকে সীমাবদ্ধ বালতিতে রাখে তখন আপনার অ্যাপ কীভাবে আচরণ করে তা পরীক্ষা করতে, আপনি ম্যানুয়ালি আপনার অ্যাপটিকে সেই বালতিতে নিয়ে যেতে পারেন। এটি করতে, একটি টার্মিনাল উইন্ডোতে নিম্নলিখিত কমান্ডটি চালান:

adb shell am set-standby-bucket PACKAGE_NAME restricted

নিরাপত্তা এবং গোপনীয়তা

আনুমানিক অবস্থান

ডায়ালগে দুটি সেটের বিকল্প রয়েছে, একটি উপরে অন্যান্য
চিত্র 1. সিস্টেম অনুমতি ডায়ালগ যা ব্যবহারকারীকে আনুমানিক অবস্থানের তথ্য প্রদান করতে দেয়।

যে ডিভাইসগুলিতে Android 12 বা উচ্চতর সংস্করণ চলে, ব্যবহারকারীরা অনুরোধ করতে পারেন যে আপনার অ্যাপটি শুধুমাত্র আনুমানিক অবস্থানের তথ্য অ্যাক্সেস করতে পারে।

আপনার অ্যাপ যদি ACCESS_FINE_LOCATION রানটাইম অনুমতির জন্য অনুরোধ করে, তাহলে ব্যবহারকারী আপনার অ্যাপে আনুমানিক অবস্থান অ্যাক্সেস করার অনুমতি দেয় এমন ক্ষেত্রে আপনাকে ACCESS_COARSE_LOCATION অনুমতির অনুরোধ করা উচিত। আপনার একটি একক রানটাইম অনুরোধে উভয় অনুমতি অন্তর্ভুক্ত করা উচিত।

সিস্টেম অনুমতি ডায়ালগে ব্যবহারকারীর জন্য নিম্নলিখিত বিকল্পগুলি অন্তর্ভুক্ত রয়েছে, যেমন চিত্র 1 এ দেখানো হয়েছে:

  • সুনির্দিষ্ট : সুনির্দিষ্ট অবস্থানের তথ্য অ্যাক্সেস প্রদান করে।
  • আনুমানিক : শুধুমাত্র আনুমানিক অবস্থান তথ্য অ্যাক্সেস প্রদান করে.

মাইক্রোফোন এবং ক্যামেরা টগল

সমর্থিত ডিভাইসগুলি যেগুলি অ্যান্ড্রয়েড 12 বা উচ্চতর চালায় সেগুলি ব্যবহারকারীদের একটি একক টগল বিকল্প টিপে ডিভাইসের সমস্ত অ্যাপের জন্য ক্যামেরা এবং মাইক্রোফোন অ্যাক্সেস সক্ষম এবং অক্ষম করতে দেয়৷ ব্যবহারকারীরা দ্রুত সেটিংস থেকে টগলযোগ্য বিকল্পগুলি অ্যাক্সেস করতে পারে, যেমন চিত্র 1-এ দেখানো হয়েছে, বা সিস্টেম সেটিংসের গোপনীয়তা স্ক্রীন থেকে।

এই টগলগুলি সম্পর্কে আরও জানুন, এবং কীভাবে পরীক্ষা করবেন যে আপনার অ্যাপটি CAMERA এবং RECORD_AUDIO অনুমতি সংক্রান্ত সর্বোত্তম অনুশীলনগুলি অনুসরণ করে৷

মাইক্রোফোন এবং ক্যামেরা সূচক

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

এই সূচকগুলি সম্পর্কে আরও জানুন এবং কীভাবে পরীক্ষা করবেন যে আপনার অ্যাপটি CAMERA এবং RECORD_AUDIO অনুমতি সংক্রান্ত সর্বোত্তম অনুশীলনগুলি অনুসরণ করে৷

দ্রুত সেটিংস টাইলস লেবেল 'ক্যামেরা অ্যাক্সেস' এবং 'মাইক অ্যাক্সেস'
চিত্র 2. দ্রুত সেটিংসে মাইক্রোফোন এবং ক্যামেরা টগল।
উপরের-ডান কোণে একটি বৃত্তাকার আয়তক্ষেত্র, যা একটি ক্যামেরা আইকন এবং একটি মাইক্রোফোন আইকন অন্তর্ভুক্ত
চিত্র 3. মাইক্রোফোন এবং ক্যামেরা সূচক, যা সাম্প্রতিক ডেটা অ্যাক্সেস দেখায়।

অনুমতি প্যাকেজ দৃশ্যমানতা

যেসব ডিভাইসে Android 12 বা তার উচ্চতর সংস্করণ চলে, সেসব অ্যাপ যেগুলি Android 11 (API লেভেল 30) বা উচ্চতরকে লক্ষ্য করে এবং যেগুলিকে নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটি কল করে তারা অন্যান্য অ্যাপে অ্যাপের প্যাকেজ দৃশ্যমানতার উপর ভিত্তি করে একটি ফিল্টার করা ফলাফল পায়:

BouncyCastle বাস্তবায়ন সরানো হয়েছে

অ্যান্ড্রয়েড 12 ক্রিপ্টোগ্রাফিক অ্যালগরিদমগুলির অনেকগুলি বাউন্সি ক্যাস্টল বাস্তবায়নকে সরিয়ে দেয় যা পূর্বে বাতিল করা হয়েছিল, সমস্ত AES অ্যালগরিদম সহ। সিস্টেমটি পরিবর্তে এই অ্যালগরিদমগুলির কনস্ক্রিপ্ট বাস্তবায়ন ব্যবহার করে।

এই পরিবর্তনটি আপনার অ্যাপকে প্রভাবিত করে যদি নিচের কোনটি সত্য হয়:

  • আপনার অ্যাপ 512-বিট কী মাপ ব্যবহার করে। কনস্ক্রিপ্ট এই কী আকার সমর্থন করে না। প্রয়োজনে, বিভিন্ন কী আকার ব্যবহার করতে আপনার অ্যাপের ক্রিপ্টোগ্রাফি লজিক আপডেট করুন।

  • আপনার অ্যাপ KeyGenerator সাথে অবৈধ কী আকার ব্যবহার করে। Conscrypt-এর KeyGenerator এর বাস্তবায়ন বাউন্সি ক্যাসলের তুলনায় কী প্যারামিটারে অতিরিক্ত বৈধতা দেয়। উদাহরণস্বরূপ, কনস্ক্রিপ্ট আপনার অ্যাপকে একটি 64-বিট AES কী তৈরি করার অনুমতি দেয় না কারণ AES শুধুমাত্র 128-, 192- এবং 256-বিট কী সমর্থন করে।

    BouncyCastle অবৈধ মাপের কীগুলি তৈরি করার অনুমতি দেয়, কিন্তু পরে ব্যর্থ হয় যদি এই কীগুলি একটি Cipher সাথে ব্যবহার করা হয়। কনস্ক্রিপ্ট আগে ব্যর্থ হয়।

  • আপনি 12 বাইট ছাড়া অন্য একটি আকার ব্যবহার করে আপনার গ্যালোইস/কাউন্টার মোড (GCM) সাইফার শুরু করেন। GcmParameterSpec এর Conscrypt বাস্তবায়নের জন্য 12 বাইটের প্রারম্ভিকতা প্রয়োজন, যা NIST সুপারিশ করে।

ক্লিপবোর্ড অ্যাক্সেস বিজ্ঞপ্তি

অ্যান্ড্রয়েড 12 এবং উচ্চতর সংস্করণে, যখন একটি অ্যাপ প্রথমবারের জন্য একটি ভিন্ন অ্যাপ থেকে ক্লিপ ডেটা অ্যাক্সেস করতে getPrimaryClip() কল করে, একটি টোস্ট বার্তা ব্যবহারকারীকে এই ক্লিপবোর্ড অ্যাক্সেসের বিষয়ে অবহিত করে।

টোস্ট বার্তার ভিতরের পাঠ্যটিতে নিম্নলিখিত বিন্যাস রয়েছে: APP pasted from your clipboard.

ক্লিপ বিবরণে পাঠ্য সম্পর্কে তথ্য

Android 12 এবং উচ্চতর সংস্করণে, getPrimaryClipDescription() নিম্নলিখিত বিবরণ সনাক্ত করতে পারে:

  • স্টাইলাইজড টেক্সট, isStyledText() ব্যবহার করে।
  • getConfidenceScore() ব্যবহার করে টেক্সটের বিভিন্ন শ্রেণীবিভাগ, যেমন URLs।

অ্যাপ সিস্টেম ডায়ালগ বন্ধ করতে পারে না

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

  • যদি আপনার অ্যাপটি Android 12 বা উচ্চতরকে লক্ষ্য করে, তাহলে একটি SecurityException ঘটে।

  • যদি আপনার অ্যাপটি অ্যান্ড্রয়েড 11 (এপিআই লেভেল 30) বা তার নিচের দিকে লক্ষ্য করে, উদ্দেশ্যটি কার্যকর হয় না এবং নিম্নলিখিত বার্তাটি লগক্যাটে উপস্থিত হয়:

    E ActivityTaskManager Permission Denial: \
android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
dropping broadcast.

ব্যতিক্রম

নিম্নলিখিত ক্ষেত্রে, একটি অ্যাপ এখনও Android 12 বা উচ্চতর সিস্টেম ডায়ালগ বন্ধ করতে পারে:

  • আপনার অ্যাপটি একটি ইন্সট্রুমেন্টেশন পরীক্ষা চালাচ্ছে।

  • আপনার অ্যাপ্লিকেশানটি Android 11 বা তার নিচের সংস্করণগুলিকে লক্ষ্য করে এবং বিজ্ঞপ্তি ড্রয়ারের উপরে একটি উইন্ডো দেখাচ্ছে৷

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

  • আপনার অ্যাপ্লিকেশানটি Android 11 বা তার চেয়ে কম সংস্করণকে লক্ষ্য করে এবং একটি সক্রিয় অ্যাক্সেসিবিলিটি পরিষেবা রয়েছে৷ যদি আপনার অ্যাপটি Android 12 কে টার্গেট করে এবং বিজ্ঞপ্তি বার বন্ধ করতে চায়, তাহলে পরিবর্তে GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE অ্যাক্সেসিবিলিটি অ্যাকশন ব্যবহার করুন।

অবিশ্বস্ত স্পর্শ ইভেন্ট ব্লক করা হয়

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

প্রভাবিত অ্যাপস

এই পরিবর্তনটি সেই অ্যাপগুলিকে প্রভাবিত করে যেগুলি তাদের উইন্ডোগুলির মধ্য দিয়ে স্পর্শ করতে দেয়, উদাহরণস্বরূপ FLAG_NOT_TOUCHABLE পতাকা ব্যবহার করে৷ বেশ কয়েকটি উদাহরণের মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে তবে সীমাবদ্ধ নয়:

  • ওভারলেগুলির জন্য SYSTEM_ALERT_WINDOW অনুমতি প্রয়োজন, যেমন উইন্ডোগুলি যেগুলি TYPE_APPLICATION_OVERLAY ব্যবহার করে এবং FLAG_NOT_TOUCHABLE পতাকা ব্যবহার করে৷
  • কার্যকলাপ উইন্ডো যেগুলি FLAG_NOT_TOUCHABLE পতাকা ব্যবহার করে৷

ব্যতিক্রম

নিম্নলিখিত ক্ষেত্রে, "পাস-থ্রু" স্পর্শ অনুমোদিত:

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

  • বিশ্বস্ত জানালা। এই উইন্ডোগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত (কিন্তু সীমাবদ্ধ নয়)

  • অদৃশ্য জানালা। উইন্ডোর রুট ভিউ GONE বা INVISIBLE ।

  • সম্পূর্ণ স্বচ্ছ জানালা। উইন্ডোটির জন্য alpha বৈশিষ্ট্য হল 0.0।

  • পর্যাপ্ত স্বচ্ছ সিস্টেম সতর্কতা জানালা। যখন সম্মিলিত অস্বচ্ছতা স্পর্শের জন্য সিস্টেমের সর্বাধিক অস্পষ্ট অস্বচ্ছতার চেয়ে কম বা সমান হয় তখন সিস্টেমটি সিস্টেম সতর্কতা উইন্ডোগুলির একটি সেটকে যথেষ্ট স্বচ্ছ বলে মনে করে। অ্যান্ড্রয়েড 12-এ, এই সর্বোচ্চ অপাসিটি ডিফল্টরূপে 0.8।

যখন একটি অবিশ্বস্ত স্পর্শ ব্লক করা হয় সনাক্ত করুন

যদি একটি স্পর্শ ক্রিয়া সিস্টেম দ্বারা অবরুদ্ধ করা হয়, Logcat নিম্নলিখিত বার্তাটি লগ করে:

Untrusted touch due to occlusion by PACKAGE_NAME

পরিবর্তন পরীক্ষা করুন

অ্যান্ড্রয়েড 12 বা উচ্চতর সংস্করণে চালিত ডিভাইসগুলিতে অবিশ্বস্ত স্পর্শগুলি ডিফল্টরূপে অবরুদ্ধ থাকে। অবিশ্বস্ত স্পর্শের অনুমতি দিতে, একটি টার্মিনাল উইন্ডোতে নিম্নলিখিত ADB কমান্ডটি চালান:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

আচরণটিকে ডিফল্টে ফিরিয়ে আনতে (অবিশ্বস্ত স্পর্শগুলি ব্লক করা হয়েছে), নিম্নলিখিত কমান্ডটি চালান:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

কার্যকলাপ জীবনচক্র

ব্যাক প্রেসে রুট লঞ্চার কার্যক্রম আর শেষ হয় না

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

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

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

এছাড়াও মনে রাখবেন, সাধারণভাবে, আমরা onBackPressed() ওভাররাইড করার পরিবর্তে কাস্টম ব্যাক নেভিগেশন প্রদানের জন্য AndroidX কার্যকলাপ API ব্যবহার করার পরামর্শ দিই। অ্যান্ড্রয়েডএক্স অ্যাক্টিভিটি এপিআই স্বয়ংক্রিয়ভাবে উপযুক্ত সিস্টেম আচরণে পিছিয়ে দেয় যদি সিস্টেম ব্যাক প্রেসে বাধা দেওয়ার মতো কোনো উপাদান না থাকে।

গ্রাফিক্স এবং ইমেজ

উন্নত রিফ্রেশ হার সুইচিং

অ্যান্ড্রয়েড 12-এ, setFrameRate() ব্যবহার করে রিফ্রেশ রেট পরিবর্তন ঘটতে পারে তা নির্বিশেষে ডিসপ্লে নতুন রিফ্রেশ হারে নির্বিঘ্ন রূপান্তর সমর্থন করে কিনা; একটি বিরামবিহীন রূপান্তর হল এমন যেটিতে কোনো দৃশ্যগত বাধা নেই, যেমন একটি বা দুই সেকেন্ডের জন্য একটি কালো পর্দা। পূর্বে, যদি ডিসপ্লে একটি নিরবচ্ছিন্ন পরিবর্তন সমর্থন না করে, setFrameRate() কল করার পরে এটি সাধারণত একই রিফ্রেশ হার ব্যবহার করা চালিয়ে যাবে। getAlternativeRefreshRates() কল করে নতুন রিফ্রেশে রূপান্তরটি সম্ভবত বিরামহীন হবে কিনা তা আপনি আগেই নির্ধারণ করতে পারেন। সাধারণত, রিফ্রেশ রেট স্যুইচ সম্পূর্ণ হওয়ার পরে কলব্যাক onDisplayChanged() বলা হয়, কিন্তু কিছু বহিরাগত-সংযুক্ত ডিসপ্লের জন্য, এটি একটি নন-সিমলেস ট্রানজিশনের সময় বলা হয়।

আপনি কীভাবে এটি বাস্তবায়ন করতে পারেন তার একটি উদাহরণ এখানে রয়েছে:

কোটলিন 

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

জাভা 

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

সংযোগ

পাসপয়েন্ট আপডেট

নিম্নলিখিত APIগুলি Android 12 এ যোগ করা হয়েছে:

  • isPasspointTermsAndConditionsSupported() : শর্তাবলী হল একটি পাসপয়েন্ট বৈশিষ্ট্য যা নেটওয়ার্ক স্থাপনাগুলিকে একটি নিরাপদ পাসপয়েন্ট নেটওয়ার্কের সাথে ওপেন নেটওয়ার্ক ব্যবহার করে এমন নিরাপদ ক্যাপটিভ পোর্টালগুলি প্রতিস্থাপন করতে দেয়। শর্তাবলী গ্রহণ করার প্রয়োজন হলে ব্যবহারকারীর কাছে একটি বিজ্ঞপ্তি প্রদর্শিত হয়। শর্তাবলী দ্বারা গেট করা পাসপয়েন্ট নেটওয়ার্কের পরামর্শ দেয় এমন অ্যাপগুলিকে ডিভাইসটি সক্ষমতা সমর্থন করে কিনা তা নিশ্চিত করতে প্রথমে এই API কল করতে হবে। ডিভাইসটি সক্ষমতা সমর্থন না করলে, এটি এই নেটওয়ার্কের সাথে সংযোগ করতে সক্ষম হবে না এবং একটি বিকল্প বা উত্তরাধিকারী নেটওয়ার্কের পরামর্শ দেওয়া আবশ্যক৷

  • isDecoratedIdentitySupported() : একটি উপসর্গ সজ্জা সহ নেটওয়ার্কগুলিতে প্রমাণীকরণ করার সময়, সজ্জিত পরিচয় উপসর্গ নেটওয়ার্ক অপারেটরদের নেটওয়ার্ক অ্যাক্সেস আইডেন্টিফায়ার (NAI) আপডেট করার অনুমতি দেয় একটি AAA নেটওয়ার্কের ভিতরে একাধিক প্রক্সির মাধ্যমে সুস্পষ্ট রাউটিং করতে (এ বিষয়ে আরও জানতে RFC 7542 দেখুন) .

    Android 12 PPS-MO এক্সটেনশনের জন্য WBA স্পেসিফিকেশনের সাথে সামঞ্জস্য করতে এই বৈশিষ্ট্যটি প্রয়োগ করে। যে অ্যাপগুলি পাসপয়েন্ট নেটওয়ার্কগুলির পরামর্শ দেয় যেগুলির জন্য একটি সজ্জিত পরিচয়ের প্রয়োজন হয় সেগুলিকে ডিভাইসটি সক্ষমতা সমর্থন করে তা নিশ্চিত করতে প্রথমে এই APIটি কল করতে হবে৷ ডিভাইসটি সক্ষমতা সমর্থন না করলে, পরিচয়টি সজ্জিত হবে না এবং নেটওয়ার্কে প্রমাণীকরণ ব্যর্থ হতে পারে।

একটি পাসপয়েন্ট পরামর্শ তৈরি করতে, অ্যাপগুলিকে অবশ্যই PasspointConfiguration , Credential এবং HomeSp ক্লাসগুলি ব্যবহার করতে হবে৷ এই ক্লাসগুলি পাসপয়েন্ট প্রোফাইল বর্ণনা করে, যা Wi-Fi অ্যালায়েন্স পাসপয়েন্ট স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছে।

আরও তথ্যের জন্য, ইন্টারনেট সংযোগের জন্য Wi-Fi সাজেশন API দেখুন।

নন-SDK ইন্টারফেস সীমাবদ্ধতা আপডেট করা হয়েছে

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

যদি আপনার অ্যাপটি Android 12 কে টার্গেট না করে, তবে এই পরিবর্তনগুলির মধ্যে কিছু আপনাকে অবিলম্বে প্রভাবিত করতে পারে না। যাইহোক, যদিও আপনি বর্তমানে কিছু নন-SDK ইন্টারফেস ব্যবহার করতে পারেন ( আপনার অ্যাপের টার্গেট API লেভেলের উপর নির্ভর করে ), যেকোন নন-SDK পদ্ধতি বা ক্ষেত্র ব্যবহার করলে সবসময় আপনার অ্যাপ ভাঙার উচ্চ ঝুঁকি থাকে।

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

অ্যান্ড্রয়েডের এই প্রকাশের পরিবর্তনগুলি সম্পর্কে আরও জানতে, Android 12-এ নন-SDK ইন্টারফেস সীমাবদ্ধতার আপডেটগুলি দেখুন। সাধারণত নন-SDK ইন্টারফেস সম্পর্কে আরও জানতে, নন-SDK ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।