এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 থেকে শুরু করে, এই বালতিটি ডিফল্টরূপে সক্রিয় থাকে। সমস্ত বালতিগুলির মধ্যে সীমাবদ্ধ বালতিটির সর্বনিম্ন অগ্রাধিকার (এবং সর্বোচ্চ সীমাবদ্ধতা) রয়েছে৷ উচ্চ থেকে নিচু পর্যন্ত অগ্রাধিকারের ক্রম অনুসারে বালতিগুলি হল:

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

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

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

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

সিস্টেম আপনার অ্যাপটিকে সীমাবদ্ধ বাকেটে রেখেছে কিনা তা পরীক্ষা করতে, 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 12 কে লক্ষ্য করে, তাহলে এই পরিস্থিতিতে আপনাকে ACTION_CLOSE_SYSTEM_DIALOGS ব্যবহার করতে হবে না। এর কারণ, যদি আপনার অ্যাপটি startActivity() কল করে যখন একটি উইন্ডো নোটিফিকেশন ড্রয়ারের উপরে থাকে, সিস্টেমটি স্বয়ংক্রিয়ভাবে নোটিফিকেশন ড্রয়ার বন্ধ করে দেয়।
আপনার অ্যাপ্লিকেশানটি 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 পতাকা ব্যবহার করে৷

ব্যতিক্রম

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

আপনার অ্যাপের মধ্যে মিথস্ক্রিয়া। আপনার অ্যাপ ওভারলে দেখায়, এবং ওভারলে শুধুমাত্র তখনই দেখা যায় যখন ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট করে।
বিশ্বস্ত জানালা। এই উইন্ডোগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত (কিন্তু সীমাবদ্ধ নয়)
দ্রষ্টব্য: TYPE_APPLICATION_OVERLAY ধরণের উইন্ডোজ বিশ্বস্ত নয় ৷
অদৃশ্য জানালা। উইন্ডোর রুট ভিউ 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 ইন্টারফেসের উপর সীমাবদ্ধতা দেখুন।

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

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

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

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

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

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

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

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

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

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

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

কোটলিন

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

জাভা

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

কোটলিন

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 মাল্টি-উইন্ডো মোড স্ট্যান্ডার্ড আচরণ করে।

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

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

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

কর্মক্ষমতা

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

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

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

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

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

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

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

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

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

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

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

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

এই পরিবর্তনটি আপনার অ্যাপ্লিকেশনটিকে প্রভাবিত করে যদি নিম্নলিখিতগুলির কোনওটি সত্য হয়:

আপনার অ্যাপ্লিকেশন 512-বিট কী আকার ব্যবহার করে। কনক্রিপ্ট এই মূল আকারটিকে সমর্থন করে না। যদি প্রয়োজন হয় তবে বিভিন্ন কী আকার ব্যবহার করতে আপনার অ্যাপ্লিকেশনটির ক্রিপ্টোগ্রাফি যুক্তি আপডেট করুন।
আপনার অ্যাপ্লিকেশনটি KeyGenerator সাথে অবৈধ কী আকার ব্যবহার করে। বাউনস্যাক্টলের তুলনায় KeyGenerator কনক্রিপ্টের বাস্তবায়ন কী প্যারামিটারগুলিতে অতিরিক্ত বৈধতা সম্পাদন করে। উদাহরণস্বরূপ, কনক্রিপ্ট আপনার অ্যাপ্লিকেশনটিকে একটি 64-বিট এইএস কী তৈরি করতে দেয় না কারণ এইএস কেবল 128-, 192-, এবং 256-বিট কীগুলি সমর্থন করে।
বাউন্সক্যাসল অবৈধ আকারের কীগুলি উত্পন্ন করার অনুমতি দেয় তবে পরে যদি এই কীগুলি Cipher ব্যবহার করা হয় তবে ব্যর্থ হয়। কনক্রিপ্ট আগে ব্যর্থ হয়।
আপনি আপনার গ্যালোইস/কাউন্টার মোড (জিসিএম) সাইফারগুলি 12 বাইটের চেয়ে অন্য আকার ব্যবহার করে আরম্ভ করুন। GcmParameterSpec কনক্রিপ্টের বাস্তবায়নের জন্য 12 বাইটের সূচনা প্রয়োজন, যা এনআইএসটি সুপারিশ করে।

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

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

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

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

অ্যান্ড্রয়েড 12 এবং উচ্চতর, getPrimaryClipDescription() নিম্নলিখিত বিবরণগুলি সনাক্ত করতে পারে:

স্টাইলাইজড টেক্সট, isStyledText() ব্যবহার করে।
getConfidenceScore() ব্যবহার করে ইউআরএলএসের মতো পাঠ্যের বিভিন্ন শ্রেণিবিন্যাস।

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

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

যদি আপনার অ্যাপ্লিকেশনটি অ্যান্ড্রয়েড 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.
```

ব্যতিক্রম

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

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

অবিশ্বস্ত স্পর্শ ইভেন্টগুলি অবরুদ্ধ

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

ক্ষতিগ্রস্থ অ্যাপ্লিকেশন

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

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

ব্যতিক্রম

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

আপনার অ্যাপ্লিকেশন মধ্যে মিথস্ক্রিয়া। আপনার অ্যাপ্লিকেশনটি ওভারলেটি দেখায় এবং ব্যবহারকারী যখন আপনার অ্যাপ্লিকেশনটির সাথে ইন্টারঅ্যাক্ট করছে তখনই ওভারলে উপস্থিত হয়।
বিশ্বস্ত উইন্ডোজ। এই উইন্ডোতে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে (তবে সীমাবদ্ধ নয়):
দ্রষ্টব্য: টাইপ TYPE_APPLICATION_OVERLAY এর উইন্ডোজগুলি বিশ্বাসযোগ্য নয় ।
অদৃশ্য উইন্ডোজ। উইন্ডোর মূল দৃশ্যটি GONE বা INVISIBLE ।
সম্পূর্ণ স্বচ্ছ উইন্ডো। উইন্ডোটির জন্য alpha সম্পত্তি 0.0।
পর্যাপ্ত ট্রান্সলুসেন্ট সিস্টেম সতর্কতা উইন্ডো। সিস্টেমটি সিস্টেম সতর্কতা উইন্ডোগুলির একটি সেটকে যথেষ্ট পরিমাণে স্বচ্ছ হিসাবে বিবেচনা করে যখন সম্মিলিত অস্বচ্ছতা ছোঁয়াগুলির জন্য সিস্টেমের সর্বাধিক অস্পষ্ট অস্বচ্ছতার চেয়ে কম বা সমান হয়। অ্যান্ড্রয়েড 12 -এ, এই সর্বাধিক অস্বচ্ছতা ডিফল্টরূপে 0.8।

যখন কোনও অবিশ্বস্ত স্পর্শ অবরুদ্ধ থাকে তখন সনাক্ত করুন

যদি কোনও টাচ অ্যাকশন সিস্টেম দ্বারা অবরুদ্ধ থাকে তবে লগক্যাট নিম্নলিখিত বার্তাটি লগ করে:

Untrusted touch due to occlusion by PACKAGE_NAME

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

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

# 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() ওভাররাইড করার পরিবর্তে কাস্টম ব্যাক নেভিগেশন সরবরাহের জন্য অ্যান্ড্রয়েডএক্স ক্রিয়াকলাপ এপিআই ব্যবহার করার পরামর্শ দিই। অ্যান্ড্রয়েডএক্স ক্রিয়াকলাপ এপিআইগুলি সিস্টেম ব্যাক প্রেসকে বাধা দেওয়ার কোনও উপাদান না থাকলে স্বয়ংক্রিয়ভাবে উপযুক্ত সিস্টেমের আচরণের দিকে পিছিয়ে যায়।

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

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

অ্যান্ড্রয়েড 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);

সংযোগ

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

নিম্নলিখিত এপিআইগুলি অ্যান্ড্রয়েড 12 এ যুক্ত করা হয়েছে:

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

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

আরও তথ্যের জন্য, ইন্টারনেট সংযোগের জন্য ওয়াই-ফাই পরামর্শ এপিআই দেখুন।

নন-এসডিকে ইন্টারফেস বিধিনিষেধ আপডেট হয়েছে

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

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

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

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

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

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

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

প্রসারিত ওভারক্রোল প্রভাব

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

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

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

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

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

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

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

আরও তথ্যের জন্য, স্প্ল্যাশ স্ক্রিন বিকাশকারী গাইড দেখুন।

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

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

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

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

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

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

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

#GetRealsize এবং getrealmetrics প্রদর্শন করুন: অবমূল্যায়ন এবং সীমাবদ্ধতা

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

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

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

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

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

উইন্ডোমেট্রিক্স কীভাবে ব্যবহার করবেন তার উদাহরণ

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

কোনও ক্রিয়াকলাপের কোনও ইউআই-সম্পর্কিত কাজের জন্য বিশেষত WindowManager.getCurrentWindowMetrics() বা জেটপ্যাকের WindowMetricsCalculator.computeCurrentWindowMetrics() এর জন্য কোনও ক্রিয়াকলাপের প্রসঙ্গ থেকে WindowMetrics উপর নির্ভর করা উচিত।

যদি আপনার অ্যাপ্লিকেশনটি কোনও MediaProjection তৈরি করে তবে প্রজেকশনটি প্রজেক্টর অ্যাপটি যে প্রদর্শন করছে তা প্রদর্শন পার্টিশনটি ক্যাপচার করার কারণে সীমানাগুলি অবশ্যই সঠিকভাবে আকার দেওয়া উচিত।

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

কোটলিন

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

জাভা

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

যদি অ্যাপটি পুরোপুরি পুনরায় আকার পরিবর্তনযোগ্য না হয় তবে এটি অবশ্যই WindowContext উদাহরণ থেকে জিজ্ঞাসা করতে হবে এবং WindowManager.getMaximumWindowMetrics() বা জেটপ্যাক পদ্ধতি 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();

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

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

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

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

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

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

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

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

অগ্রভাগ পরিষেবা বিজ্ঞপ্তিগুলির জন্য ইউএক্স বিলম্ব

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

কর্মক্ষমতা

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

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

সক্রিয়: অ্যাপটি বর্তমানে ব্যবহৃত হচ্ছে বা খুব সম্প্রতি ব্যবহৃত হয়েছিল।
ওয়ার্কিং সেট: অ্যাপটি নিয়মিত ব্যবহারে রয়েছে।
ঘন ঘন: অ্যাপ্লিকেশন প্রায়শই ব্যবহৃত হয় তবে প্রতিদিন নয়।
বিরল: অ্যাপটি প্রায়শই ব্যবহৃত হয় না।
সীমাবদ্ধ: অ্যাপ্লিকেশন সিস্টেমের সংস্থানগুলির একটি দুর্দান্ত চুক্তি গ্রহণ করে, বা অনাকাঙ্ক্ষিত আচরণ প্রদর্শন করতে পারে।

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

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

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

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

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

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

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

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

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

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

সুনির্দিষ্ট : সুনির্দিষ্ট অবস্থানের তথ্যে অ্যাক্সেস সরবরাহ করে।
আনুমানিক : কেবলমাত্র আনুমানিক অবস্থানের তথ্যে অ্যাক্সেস সরবরাহ করে।

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

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

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

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

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

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

দ্রুত সেটিংস টাইলগুলি 'ক্যামেরা অ্যাক্সেস' এবং 'মাইক অ্যাক্সেস' লেবেলযুক্ত রয়েছে — **চিত্র 2.** মাইক্রোফোন এবং ক্যামেরা দ্রুত সেটিংসে টগল করে।

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

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

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

আপনার অ্যাপ্লিকেশন 512-বিট কী আকার ব্যবহার করে। কনক্রিপ্ট এই মূল আকারটিকে সমর্থন করে না। যদি প্রয়োজন হয় তবে বিভিন্ন কী আকার ব্যবহার করতে আপনার অ্যাপ্লিকেশনটির ক্রিপ্টোগ্রাফি যুক্তি আপডেট করুন।
আপনার অ্যাপ্লিকেশনটি KeyGenerator সাথে অবৈধ কী আকার ব্যবহার করে। বাউনস্যাক্টলের তুলনায় KeyGenerator কনক্রিপ্টের বাস্তবায়ন কী প্যারামিটারগুলিতে অতিরিক্ত বৈধতা সম্পাদন করে। উদাহরণস্বরূপ, কনক্রিপ্ট আপনার অ্যাপ্লিকেশনটিকে একটি 64-বিট এইএস কী তৈরি করতে দেয় না কারণ এইএস কেবল 128-, 192-, এবং 256-বিট কীগুলি সমর্থন করে।
বাউন্সক্যাসল অবৈধ আকারের কীগুলি উত্পন্ন করার অনুমতি দেয় তবে পরে যদি এই কীগুলি Cipher ব্যবহার করা হয় তবে ব্যর্থ হয়। কনক্রিপ্ট আগে ব্যর্থ হয়।
আপনি আপনার গ্যালোইস/কাউন্টার মোড (জিসিএম) সাইফারগুলি 12 বাইটের চেয়ে অন্য আকার ব্যবহার করে আরম্ভ করুন। GcmParameterSpec কনক্রিপ্টের বাস্তবায়নের জন্য 12 বাইটের সূচনা প্রয়োজন, যা এনআইএসটি সুপারিশ করে।

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

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

স্টাইলাইজড টেক্সট, isStyledText() ব্যবহার করে।
getConfidenceScore() ব্যবহার করে ইউআরএলএসের মতো পাঠ্যের বিভিন্ন শ্রেণিবিন্যাস।

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

যদি আপনার অ্যাপ্লিকেশনটি অ্যান্ড্রয়েড 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.
```

ব্যতিক্রম

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

অবিশ্বস্ত স্পর্শ ইভেন্টগুলি অবরুদ্ধ

ক্ষতিগ্রস্থ অ্যাপ্লিকেশন

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

ব্যতিক্রম

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

আপনার অ্যাপ্লিকেশন মধ্যে মিথস্ক্রিয়া। আপনার অ্যাপ্লিকেশনটি ওভারলেটি দেখায় এবং ব্যবহারকারী যখন আপনার অ্যাপ্লিকেশনটির সাথে ইন্টারঅ্যাক্ট করছে তখনই ওভারলে উপস্থিত হয়।
বিশ্বস্ত উইন্ডোজ। এই উইন্ডোতে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে (তবে সীমাবদ্ধ নয়):
দ্রষ্টব্য: টাইপ TYPE_APPLICATION_OVERLAY এর উইন্ডোজগুলি বিশ্বাসযোগ্য নয় ।
অদৃশ্য উইন্ডোজ। উইন্ডোর মূল দৃশ্যটি GONE বা INVISIBLE ।
সম্পূর্ণ স্বচ্ছ উইন্ডো। উইন্ডোটির জন্য alpha সম্পত্তি 0.0।
পর্যাপ্ত ট্রান্সলুসেন্ট সিস্টেম সতর্কতা উইন্ডো। সিস্টেমটি সিস্টেম সতর্কতা উইন্ডোগুলির একটি সেটকে যথেষ্ট পরিমাণে স্বচ্ছ হিসাবে বিবেচনা করে যখন সম্মিলিত অস্বচ্ছতা ছোঁয়াগুলির জন্য সিস্টেমের সর্বাধিক অস্পষ্ট অস্বচ্ছতার চেয়ে কম বা সমান হয়। অ্যান্ড্রয়েড 12 -এ, এই সর্বাধিক অস্বচ্ছতা ডিফল্টরূপে 0.8।

যখন কোনও অবিশ্বস্ত স্পর্শ অবরুদ্ধ থাকে তখন সনাক্ত করুন

Untrusted touch due to occlusion by PACKAGE_NAME

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

# 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

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

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

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

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

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

কোটলিন

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

সংযোগ

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

নিম্নলিখিত এপিআইগুলি অ্যান্ড্রয়েড 12 এ যুক্ত করা হয়েছে:

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

আরও তথ্যের জন্য, ইন্টারনেট সংযোগের জন্য ওয়াই-ফাই পরামর্শ এপিআই দেখুন।

নন-এসডিকে ইন্টারফেস বিধিনিষেধ আপডেট হয়েছে

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

প্রসারিত ওভারক্রোল প্রভাব

অ্যান্ড্রয়েড 11 এবং লোরে, একটি ওভারক্রোল ইভেন্টের ফলে ভিজ্যুয়াল উপাদানগুলিকে একটি আভা থাকে; on Android 12 and higher, the visual elements stretch and bounce back on a drag event and they fling and bounce back on a fling event.

For more information, see the guide to animating scroll gestures .

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

If you have previously implemented a custom splash screen in Android 11 or lower, you'll need to migrate your app to the SplashScreen API to ensure that it displays correctly starting in Android 12. Not migrating your app will result in a degraded or unintended app launch experience.

For instructions, see Migrate your existing splash screen implementation to Android 12 .

Additionally, starting in Android 12, the system always applies the new Android system default splash screen on cold and warm starts for all apps. By default, this system default splash screen is constructed using your app's launcher icon element and the windowBackground of your theme (if it's a single color).

For more details, see the splash screens developer guide .

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

Starting in Android 12 (API level 31), a generic web intent resolves to an activity in your app only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead.

Apps can get this approval by doing one of the following:

Verify the domain using Android App Links .
On apps that target Android 12 or higher, the system changes how it automatically verifies your app's Android App Links. In your app's intent filters , check that you include the BROWSABLE category and support the https scheme.
On Android 12 or higher, you can manually verify your app's Android App Links, to test how this updated logic affects your app.
Request the user to associate your app with the domain in system settings.

If your app invokes web intents, consider adding a prompt or dialog that asks the user to confirm the action.

Immersive mode improvements for gesture navigation

Android 12 consolidates existing behavior to make it easier for users to perform gesture navigation commands while in immersive mode . In addition, Android 12 provides backward compatibility behavior for sticky immersive mode .

Display#getRealSize and getRealMetrics: deprecation and constraints

Android devices are available in many different form factors, such as large screens, tablets, and foldables. To render content appropriately for each device, your app needs to determine the screen or display size. Over time, Android has provided different APIs for retrieving this information. In Android 11, we introduced the WindowMetrics API and deprecated these methods:

In Android 12 we're continuing to recommend using WindowMetrics , and are deprecating these methods:

To mitigate the behavior of applications using Display APIs to retrieve the application's bounds, Android 12 constrains the values returned by the APIs for apps that are not fully resizable. This could have an impact on apps that are using this information with MediaProjection .

Apps should use the WindowMetrics APIs to query the bounds of their window, and Configuration.densityDpi to query the current density.

For broader compatibility with older versions of Android, you can use the Jetpack WindowManager library, which includes a WindowMetrics class that supports Android 4.0 (API level 14) and higher.

Examples of how to use WindowMetrics

First, be sure your app's activities are fully resizable .

An activity should rely upon WindowMetrics from an activity context for any UI-related work, particularly WindowManager.getCurrentWindowMetrics() or Jetpack's WindowMetricsCalculator.computeCurrentWindowMetrics() .

If your app creates a MediaProjection , the bounds must be correctly sized since the projection captures the display partition in which the projector app is running.

If the app is fully resizable, the activity context returns the correct bounds like so:

কোটলিন

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

জাভা

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

If the app is not fully resizable, it must query from a WindowContext instance and retrieve the WindowMetrics of the activity bounds using WindowManager.getMaximumWindowMetrics() or the Jetpack method WindowMetricsCalculator.computeMaximumWindowMetrics() .

কোটলিন

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 makes multi-window mode standard behavior.

On large screens (sw >= 600dp), the platform supports all apps in multi-window mode regardless of app configuration. If resizeableActivity="false" , the app is put into compatibility mode when necessary to accommodate display dimensions.

On small screens (sw < 600dp), the system checks an activity's minWidth and minHeight to determine whether the activity can run in multi-window mode. If resizeableActivity="false" , the app is prevented from running in multi‑window mode regardless of minimum width and height.

For more information, see Multi-window support .

Camera preview on large screens

Camera apps generally assume a fixed relationship between the orientation of the device and the aspect ratio of the camera preview. But large screen form factors, such as foldable devices, and display modes such as multi-window and multi-display, challenge that assumption.

On Android 12, camera apps that request a specific screen orientation and are not resizable ( resizeableActivity="false" ) automatically enter inset portrait mode, which ensures the proper orientation and aspect ratio of the camera preview. On foldables and other devices that have a camera hardware abstraction layer ( HAL ), additional rotation is applied to the camera output to compensate for camera sensor orientation, and the camera output is cropped to match the aspect ratio of the app's camera preview. The cropping and extra rotation ensure proper presentation of the camera preview regardless of device orientation and folded or unfolded state of the device.

UX delay for foreground service notifications

To provide a streamlined experience for short-running foreground services , devices that run Android 12 or higher can delay the display of foreground service notifications by 10 seconds, with a few exceptions . This change gives short-lived tasks a chance to complete before their notifications appear.

কর্মক্ষমতা

Restricted App Standby Bucket

Android 11 (API level 30) introduced the restricted bucket as an App Standby Bucket. Starting in Android 12, this bucket is active by default. The restricted bucket has the lowest priority (and the highest restrictions) of all the buckets. The buckets in order of priority from high to low are:

Active: App is currently being used or was very recently used.
Working set: App is in regular use.
Frequent: App is often used, but not every day.
Rare: App is not frequently used.
Restricted: App consumes a great deal of system resources, or may exhibit undesirable behavior.

The system considers your app's behavior, in addition to usage patterns, to decide whether to place your app in the restricted bucket.

Your app is less likely to be placed in the restricted bucket if your app uses system resources more responsibly. Also, the system places your app in a less restrictive bucket if the user interacts directly with your app.

Check whether your app is in the restricted bucket

To check whether the system has placed your app in the restricted bucket, call getAppStandbyBucket() . If the return value of this method is STANDBY_BUCKET_RESTRICTED , then your app is in the restricted bucket.

Test the restricted bucket behavior

To test how your app behaves when the system places your app into the restricted bucket, you can manually move your app to that bucket. To do so, run the following command in a terminal window:

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

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

The dialog has two sets of options, one above the
other — **Figure 1.** System permissions dialog that allows the user to grant approximate location information.

On devices that run Android 12 or higher, users can request that your app have access to only approximate location information.

If your app requests the ACCESS_FINE_LOCATION runtime permission, you should also request the ACCESS_COARSE_LOCATION permission to handle the case where the user grants approximate location access to your app. You should include both permissions in a single runtime request .

The system permissions dialog includes the following options for the user, as shown in figure 1:

Precise : Provides access to precise location information.
Approximate : Provides access only to approximate location information.

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

Supported devices that run Android 12 or higher allow users to enable and disable camera and microphone access for all apps on the device, by pressing a single toggle option. Users can access the toggleable options from Quick Settings , as shown in figure 1, or from the Privacy screen in system settings.

Learn more about these toggles , and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

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

On devices that run Android 12 or higher, when an app accesses the microphone or camera, an icon appears in the status bar.

Learn more about these indicators and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

Quick settings tiles are labeled 'Camera access' and
'Mic access' — **Figure 2.** Microphone and camera toggles in Quick Settings.

A rounded rectangle in the upper-right corner, which
includes a camera icon and a microphone icon — **Figure 3.** Microphone and camera indicators, which show recent data access.

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

On devices that run Android 12 or higher, apps that target Android 11 (API level 30) or higher and that call one of following methods receive a filtered set of results, based on the app's package visibility into other apps:

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

Android 12 removes many BouncyCastle implementations of cryptographic algorithms that were previously deprecated, including all AES algorithms. The system instead uses the Conscrypt implementations of these algorithms.

This change affects your app if any of the following are true:

Your app uses 512-bit key sizes. Conscrypt doesn't support this key size. If necessary, update your app's cryptography logic to use different key sizes.
Your app uses invalid key sizes with KeyGenerator . Conscrypt's implementation of KeyGenerator performs additional validation on key parameters, compared to BouncyCastle. For example, Conscrypt doesn't allow your app to generate a 64-bit AES key because AES only supports 128-, 192-, and 256-bit keys.
BouncyCastle allows keys of invalid sizes to be generated, but later fails if these keys are used with a Cipher . Conscrypt fails earlier.
You initialize your Galois/Counter Mode (GCM) ciphers using a size other than 12 bytes. Conscrypt's implementation of GcmParameterSpec requires an initialization of 12 bytes, which NIST recommends.

Clipboard access notifications

On Android 12 and higher, when an app calls getPrimaryClip() to access clip data from a different app for the first time, a toast message notifies the user of this clipboard access.

The text inside the toast message contains the following format: APP pasted from your clipboard.

Information about text in clip description

On Android 12 and higher, getPrimaryClipDescription() can detect the following details:

Stylized text, using isStyledText() .
Different classifications of text, such as URLs, using getConfidenceScore() .

Apps can't close system dialogs

To improve user control when interacting with apps and the system, the ACTION_CLOSE_SYSTEM_DIALOGS intent action is deprecated as of Android 12. Except for a few special cases , when your app tries to invoke an intent that contains this action, the system does one of the following based on your app's target SDK version:

If your app targets Android 12 or higher, a SecurityException occurs.

If your app targets Android 11 (API level 30) or lower, the intent doesn't execute, and the following message appears in Logcat :

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

ব্যতিক্রম

In the following cases, an app can still close system dialogs on Android 12 or higher:

Your app is running an instrumentation test .
Your app targets Android 11 or lower and is showing a window that is on top of the notification drawer .
Note: If your app targets Android 12, you don't need to use ACTION_CLOSE_SYSTEM_DIALOGS in this situation. That's because, if your app calls startActivity() while a window is on top of the notification drawer, the system closes the notification drawer automatically.
Your app targets Android 11 or lower. In addition, the user has interacted with a notification, possibly using the notification's action buttons , and your app is processing a service or broadcast receiver in response to that user action.
Your app targets Android 11 or lower and has an active accessibility service . If your app targets Android 12 and wants to close the notification bar, use the GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE accessibility action instead.

Untrusted touch events are blocked

To preserve system security and a good user experience, Android 12 prevents apps from consuming touch events where an overlay obscures the app in an unsafe way. In other words, the system blocks touches that pass through certain windows, with a few exceptions .

Affected apps

This change affects apps that choose to let touches pass through their windows, for example by using the FLAG_NOT_TOUCHABLE flag. Several examples include, but aren't limited to, the following:

Overlays that require the SYSTEM_ALERT_WINDOW permission, such as windows that use TYPE_APPLICATION_OVERLAY , and use the FLAG_NOT_TOUCHABLE flag.
Activity windows that use the FLAG_NOT_TOUCHABLE flag.

ব্যতিক্রম

In the following cases, "pass-through" touches are allowed:

Interactions within your app. Your app shows the overlay, and the overlay appears only when the user is interacting with your app.
Trusted windows. These windows include (but aren't limited to) the following:
Note: Windows of type TYPE_APPLICATION_OVERLAY aren't trusted.
Invisible windows. The window's root view is GONE or INVISIBLE .
Completely transparent windows. The alpha property is 0.0 for the window.
Sufficiently translucent system alert windows. The system considers a set of system alert windows to be sufficiently translucent when the combined opacity is less than or equal to the system's maximum obscuring opacity for touches. In Android 12, this maximum opacity is 0.8 by default.

Detect when an untrusted touch is blocked

If a touch action is blocked by the system, Logcat logs the following message:

Untrusted touch due to occlusion by PACKAGE_NAME

Test the change

Untrusted touches are blocked by default on devices that run Android 12 or higher. To allow untrusted touches, run the following ADB command in a terminal window:

# 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

To revert the behavior to the default (untrusted touches are blocked), run the following command:

# 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

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

Root launcher activities are no longer finished on Back press

Android 12 changes the default handling of the system Back press on launcher activities that are at the root of their tasks. In previous versions, the system would finish these activities on Back press. In Android 12, the system now moves the activity and its task to the background instead of finishing the activity. The new behavior matches the current behavior when navigating out of an app using the Home button or gesture.

For most apps, this change means that users who use Back to navigate out of your app are able to more quickly resume your app from a warm state , instead of having to completely restart the app from a cold state .

We recommend testing your apps with this change. If your app currently overrides onBackPressed() to handle Back navigation and finish the Activity , update your implementation to call through to super.onBackPressed() instead of finishing. Calling super.onBackPressed() moves the activity and its task to the background when appropriate and provides a more consistent navigation experience for users across apps.

Also note that, in general, we recommend using the AndroidX Activity APIs for providing custom back navigation , rather than overriding onBackPressed() . The AndroidX Activity APIs automatically defer to the appropriate system behavior if there are no components intercepting the system Back press.

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

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

In Android 12, refresh rate changes using setFrameRate() can happen regardless of whether the display supports a seamless transition to the new refresh rate; a seamless transition is one that doesn't have any visual interruptions, such as a black screen for a second or two. Previously, if the display did not support a seamless transition, it would typically continue using the same refresh rate after setFrameRate() is called. You can determine in advance whether the transition to the new refresh will likely be seamless by calling getAlternativeRefreshRates() . Generally, the callback onDisplayChanged() is called after the refresh rate switch completes, but for some externally-connected displays, it is called during a non-seamless transition.

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

কোটলিন

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

সংযোগ

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

The following APIs are added in Android 12:

isPasspointTermsAndConditionsSupported() : শর্তাবলী হল একটি পাসপয়েন্ট বৈশিষ্ট্য যা নেটওয়ার্ক স্থাপনাগুলিকে একটি নিরাপদ পাসপয়েন্ট নেটওয়ার্কের সাথে ওপেন নেটওয়ার্ক ব্যবহার করে এমন নিরাপদ ক্যাপটিভ পোর্টালগুলি প্রতিস্থাপন করতে দেয়। শর্তাবলী গ্রহণ করার প্রয়োজন হলে ব্যবহারকারীর কাছে একটি বিজ্ঞপ্তি প্রদর্শিত হয়। শর্তাবলী দ্বারা গেট করা পাসপয়েন্ট নেটওয়ার্কের পরামর্শ দেয় এমন অ্যাপগুলিকে ডিভাইসটি সক্ষমতা সমর্থন করে কিনা তা নিশ্চিত করতে প্রথমে এই API কল করতে হবে। ডিভাইসটি সক্ষমতা সমর্থন না করলে, এটি এই নেটওয়ার্কের সাথে সংযোগ করতে সক্ষম হবে না এবং একটি বিকল্প বা উত্তরাধিকারী নেটওয়ার্কের পরামর্শ দেওয়া আবশ্যক৷
isDecoratedIdentitySupported() : When authenticating to networks with a prefix decoration, the decorated identity prefix allows network operators to update the Network Access Identifier (NAI) to perform explicit routing through multiple proxies inside of an AAA network (see RFC 7542 for more on this) .
Android 12 implements this feature to conform with the WBA specification for PPS-MO extensions . Apps that suggest Passpoint networks that require a decorated identity must call this API first to make sure that the device supports the capability. ডিভাইসটি সক্ষমতা সমর্থন না করলে, পরিচয়টি সজ্জিত হবে না এবং নেটওয়ার্কে প্রমাণীকরণ ব্যর্থ হতে পারে।

To create a Passpoint suggestion, apps must use the PasspointConfiguration , Credential , and HomeSp classes. এই ক্লাসগুলি পাসপয়েন্ট প্রোফাইল বর্ণনা করে, যা Wi-Fi অ্যালায়েন্স পাসপয়েন্ট স্পেসিফিকেশনে সংজ্ঞায়িত করা হয়েছে।

For more information, see Wi-Fi suggestion API for internet connectivity .

Updated non-SDK interface restrictions

Android 12 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 12, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces ( depending on your app's target API level ), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API .

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 12 . To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces .