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

Android 8.0 আচরণ পরিবর্তন

নতুন বৈশিষ্ট্য এবং ক্ষমতার পাশাপাশি, Android 8.0 (API লেভেল 26) বিভিন্ন ধরনের সিস্টেম এবং API আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে। এই দস্তাবেজটি কিছু মূল পরিবর্তনগুলিকে হাইলাইট করে যা আপনার বুঝতে হবে এবং আপনার অ্যাপগুলিতে অ্যাকাউন্ট করা উচিত৷

এই পরিবর্তনগুলির বেশিরভাগই সমস্ত অ্যাপ্লিকেশানকে প্রভাবিত করে, তারা Android এর কোন সংস্করণকে লক্ষ্য করে না কেন। যাইহোক, বেশ কয়েকটি পরিবর্তন শুধুমাত্র Android 8.0 কে লক্ষ্য করে এমন অ্যাপগুলিকে প্রভাবিত করে। স্পষ্টতা সর্বাধিক করার জন্য, এই পৃষ্ঠাটিকে দুটি বিভাগে বিভক্ত করা হয়েছে: সমস্ত অ্যাপ্লিকেশনের জন্য পরিবর্তন এবং Android 8.0 লক্ষ্য করা অ্যাপ্লিকেশনগুলির জন্য পরিবর্তন ৷

সব অ্যাপের জন্য পরিবর্তন

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

পটভূমি সম্পাদন সীমা

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

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

যে অ্যাপগুলি ব্যাকগ্রাউন্ডে চলছে তাদের এখন কতটা অবাধে ব্যাকগ্রাউন্ড পরিষেবাগুলি অ্যাক্সেস করতে পারে তার সীমাবদ্ধতা রয়েছে৷
অ্যাপগুলি বেশিরভাগ অন্তর্নিহিত সম্প্রচারের জন্য নিবন্ধন করতে তাদের ম্যানিফেস্টগুলি ব্যবহার করতে পারে না (অর্থাৎ, অ্যাপে বিশেষভাবে লক্ষ্য করা হয় না এমন সম্প্রচার)।

ডিফল্টরূপে, এই বিধিনিষেধগুলি শুধুমাত্র সেই অ্যাপগুলির জন্য প্রযোজ্য যেগুলি O টার্গেট করে৷ যাইহোক, ব্যবহারকারীরা সেটিংস স্ক্রীন থেকে যে কোনও অ্যাপের জন্য এই বিধিনিষেধগুলি সক্ষম করতে পারেন, এমনকি যদি অ্যাপটি লক্ষ্য না করে থাকে৷

Android 8.0 (API লেভেল 26) নির্দিষ্ট পদ্ধতিতে নিম্নলিখিত পরিবর্তনগুলিও অন্তর্ভুক্ত করে:

startService() পদ্ধতিটি এখন একটি IllegalStateException নিক্ষেপ করে যদি Android 8.0 টার্গেট করে একটি অ্যাপ সেই পদ্ধতিটি এমন পরিস্থিতিতে ব্যবহার করার চেষ্টা করে যখন এটি ব্যাকগ্রাউন্ড পরিষেবাগুলি তৈরি করার অনুমতি নেই৷
নতুন Context.startForegroundService() পদ্ধতি একটি ফোরগ্রাউন্ড পরিষেবা শুরু করে। অ্যাপটি ব্যাকগ্রাউন্ডে থাকা অবস্থায়ও সিস্টেমটি অ্যাপকে Context.startForegroundService() কল করার অনুমতি দেয়। যাইহোক, পরিষেবাটি তৈরি হওয়ার পাঁচ সেকেন্ডের মধ্যে অ্যাপটিকে অবশ্যই পরিষেবাটির startForeground() পদ্ধতিতে কল করতে হবে।

আরও তথ্যের জন্য, ব্যাকগ্রাউন্ড এক্সিকিউশন লিমিটস দেখুন।

অ্যান্ড্রয়েড ব্যাকগ্রাউন্ড লোকেশন সীমা

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

এই পরিবর্তনগুলি নিম্নলিখিত APIগুলিকে প্রভাবিত করে:

ফিউজড লোকেশন প্রোভাইডার (এফএলপি)
জিওফেন্সিং
GNSS পরিমাপ
অবস্থান ব্যবস্থাপক
ওয়াই-ফাই ম্যানেজার

আপনার অ্যাপটি প্রত্যাশিতভাবে চলছে তা নিশ্চিত করতে, নিম্নলিখিত পদক্ষেপগুলি সম্পূর্ণ করুন:

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

এই পরিবর্তনগুলি সম্পর্কে আরও তথ্যের জন্য, পটভূমি অবস্থানের সীমা দেখুন।

অ্যাপ শর্টকাট

Android 8.0 (API লেভেল 26) অ্যাপ শর্টকাটগুলিতে নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে:

com.android.launcher.action.INSTALL_SHORTCUT সম্প্রচারটি আপনার অ্যাপে আর কোনো প্রভাব ফেলবে না, কারণ এটি এখন একটি ব্যক্তিগত, অন্তর্নিহিত সম্প্রচার। পরিবর্তে, আপনার ShortcutManager ক্লাস থেকে requestPinShortcut() পদ্ধতি ব্যবহার করে একটি অ্যাপ শর্টকাট তৈরি করা উচিত।
ACTION_CREATE_SHORTCUT অভিপ্রায় এখন অ্যাপ শর্টকাট তৈরি করতে পারে যা আপনি ShortcutManager ক্লাস ব্যবহার করে পরিচালনা করেন। এই অভিপ্রায় লিগ্যাসি লঞ্চার শর্টকাটগুলিও তৈরি করতে পারে যা ShortcutManager এর সাথে ইন্টারঅ্যাক্ট করে না। পূর্বে, এই উদ্দেশ্য শুধুমাত্র উত্তরাধিকার লঞ্চার শর্টকাট তৈরি করতে পারে।
requestPinShortcut() ব্যবহার করে তৈরি শর্টকাট এবং ACTION_CREATE_SHORTCUT অভিপ্রায় পরিচালনা করে এমন একটি কার্যকলাপে তৈরি শর্টকাটগুলি এখন সম্পূর্ণ অ্যাপ শর্টকাট। ফলস্বরূপ, অ্যাপগুলি এখন ShortcutManager থাকা পদ্ধতিগুলি ব্যবহার করে সেগুলিকে আপডেট করতে পারে।
লিগ্যাসি শর্টকাটগুলি Android এর পূর্ববর্তী সংস্করণগুলি থেকে তাদের কার্যকারিতা ধরে রাখে, তবে আপনাকে অবশ্যই সেগুলিকে আপনার অ্যাপে ম্যানুয়ালি অ্যাপ শর্টকাটে রূপান্তর করতে হবে।

অ্যাপ শর্টকাট পরিবর্তন সম্পর্কে আরও জানতে, পিনিং শর্টকাট এবং উইজেট বৈশিষ্ট্য নির্দেশিকা দেখুন।

স্থানীয় এবং আন্তর্জাতিকীকরণ

অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) একটি ডিফল্ট বিভাগ লোকেল নির্দিষ্ট করতে সক্ষম হওয়ার ধারণাটি চালু করেছে, কিন্তু কিছু এপিআই যুক্তি ছাড়াই জেনেরিক Locale.getDefault() পদ্ধতি ব্যবহার করা অব্যাহত রেখেছে, যখন তাদের পরিবর্তে ডিফল্ট DISPLAY বিভাগ লোকেল ব্যবহার করা উচিত ছিল। Android 8.0 (API স্তর 26) এ, নিম্নলিখিত পদ্ধতিগুলি এখন Locale.getDefault() এর পরিবর্তে Locale.getDefault(Category.DISPLAY) ব্যবহার করে:

Locale.getDisplayScript(Locale) Locale.getDefault() এ ফিরে আসে যখন Locale আর্গুমেন্টের জন্য নির্দিষ্ট displayScript মান উপলব্ধ না হয়।

অতিরিক্ত লোকেল এবং আন্তর্জাতিকীকরণ-সম্পর্কিত পরিবর্তনগুলি নিম্নরূপ:

Currency.getDisplayName(null) কল করা একটি NullPointerException নিক্ষেপ করে, নথিভুক্ত আচরণের সাথে মিলে যায়।
সময় অঞ্চলের নাম পার্সিং পরিবর্তিত হয়েছে৷ পূর্বে, অ্যান্ড্রয়েড ডিভাইসগুলি তারিখের সময় পার্স করার জন্য ব্যবহৃত টাইম জোনের নামগুলি ক্যাশে করার জন্য বুট করার সময় নমুনাকৃত সিস্টেম ঘড়ির মান ব্যবহার করত। ফলস্বরূপ, পার্সিং নেতিবাচকভাবে প্রভাবিত হতে পারে যদি বুট করার সময় সিস্টেম ঘড়ি ভুল হয় বা অন্য, বিরল ক্ষেত্রে।
এখন, সাধারণ ক্ষেত্রে পার্সিং লজিক আইসিইউ এবং বর্তমান সিস্টেম ঘড়ির মান ব্যবহার করে সময় অঞ্চলের নাম পার্স করার সময়। এই পরিবর্তনটি আরও সঠিক ফলাফল প্রদান করে, যা আপনার অ্যাপ SimpleDateFormat এর মত ক্লাস ব্যবহার করার সময় পূর্ববর্তী Android সংস্করণ থেকে ভিন্ন হতে পারে।
Android 8.0 (API লেভেল 26) আইসিইউ-এর সংস্করণ 58-এ আপডেট করে।

সতর্কতা জানালা

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

...তাহলে এই উইন্ডোগুলি সর্বদা সেই উইন্ডোগুলির নীচে উপস্থিত হয় যা TYPE_APPLICATION_OVERLAY উইন্ডো টাইপ ব্যবহার করে৷ যদি কোনো অ্যাপ Android 8.0 (API লেভেল 26) কে লক্ষ্য করে, তাহলে অ্যালার্ট উইন্ডো প্রদর্শন করতে অ্যাপটি TYPE_APPLICATION_OVERLAY উইন্ডো টাইপ ব্যবহার করে।

আরও তথ্যের জন্য, অ্যালার্ট উইন্ডোজ বিভাগের জন্য সাধারণ উইন্ডোর ধরন দেখুন Android 8.0 টার্গেট করা অ্যাপের আচরণ পরিবর্তনের মধ্যে।

ইনপুট এবং নেভিগেশন

ChromeOS-এ অ্যান্ড্রয়েড অ্যাপ্লিকেশানগুলির আবির্ভাবের সাথে এবং ট্যাবলেটের মতো অন্যান্য বৃহৎ ফর্ম ফ্যাক্টরগুলিতে, আমরা Android অ্যাপগুলির মধ্যে কীবোর্ড নেভিগেশন ব্যবহারের পুনরুত্থান দেখতে পাচ্ছি৷ অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) এর মধ্যে, আমরা একটি নেভিগেশন ইনপুট ডিভাইস হিসাবে কীবোর্ড ব্যবহার করে পুনরায় সম্বোধন করেছি, যার ফলে তীর- এবং ট্যাব-ভিত্তিক নেভিগেশনের জন্য আরও নির্ভরযোগ্য, অনুমানযোগ্য মডেল।

বিশেষ করে, আমরা উপাদান ফোকাস আচরণে নিম্নলিখিত পরিবর্তন করেছি:

আপনি যদি একটি View অবজেক্টের জন্য কোনো ফোকাস স্টেট রং নির্ধারণ না করে থাকেন (হয় এটির অগ্রভাগ বা পটভূমিতে আঁকা যায়), ফ্রেমওয়ার্কটি এখন View জন্য একটি ডিফল্ট ফোকাস হাইলাইট রঙ সেট করে। এই ফোকাস হাইলাইট হল একটি রিপল ড্রয়েবল যা কার্যকলাপের থিমের উপর ভিত্তি করে।
আপনি যদি চান না যে কোনো View অবজেক্ট ফোকাস পাওয়ার সময় এই ডিফল্ট হাইলাইটটি ব্যবহার করুক, android:defaultFocusHighlightEnabled অ্যাট্রিবিউটটিকে View ধারণকারী লেআউট XML ফাইলে false তে সেট করুন অথবা আপনার অ্যাপের UI লজিকে setDefaultFocusHighlightEnabled() এ false পাস করুন।
কীবোর্ড ইনপুট কীভাবে UI উপাদান ফোকাসকে প্রভাবিত করে তা পরীক্ষা করতে, আপনি অঙ্কন > লেআউট সীমানা বিকাশকারী বিকল্পটি সক্ষম করতে পারেন। অ্যান্ড্রয়েড 8.0-এ, এই বিকল্পটি বর্তমানে যে উপাদানটিতে ফোকাস রয়েছে তার উপরে একটি "X" আইকন প্রদর্শন করে৷

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

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

ওয়েব ফর্ম অটোফিল

এখন যেহেতু অ্যান্ড্রয়েড অটোফিল ফ্রেমওয়ার্ক অটোফিল কার্যকারিতার জন্য অন্তর্নির্মিত সমর্থন প্রদান করে, WebView অবজেক্ট সম্পর্কিত নিম্নলিখিত পদ্ধতিগুলি Android 8.0 (API স্তর 26) চালিত ডিভাইসগুলিতে ইনস্টল করা অ্যাপগুলির জন্য পরিবর্তিত হয়েছে:

WebSettings

getSaveFormData() পদ্ধতি এখন false রিটার্ন করে। পূর্বে, এই পদ্ধতি পরিবর্তে true ফিরে.
setSaveFormData() কল করার আর কোন প্রভাব নেই।

WebViewDatabase

clearFormData() কল করলে আর কোনো প্রভাব নেই।
hasFormData() পদ্ধতি এখন false রিটার্ন করে। পূর্বে, ফর্মটিতে ডেটা থাকাকালীন এই পদ্ধতিটি true হয়ে উঠত।

Android 8.0 (API লেভেল 26) অ্যাক্সেসযোগ্যতায় নিম্নলিখিত পরিবর্তনগুলি অন্তর্ভুক্ত করে:

অ্যাক্সেসিবিলিটি ফ্রেমওয়ার্ক এখন সমস্ত ডবল-ট্যাপ অঙ্গভঙ্গিকে ACTION_CLICK অ্যাকশনে রূপান্তর করে৷ এই পরিবর্তনটি TalkBack কে অন্যান্য অ্যাক্সেসিবিলিটি পরিষেবার মতো আচরণ করার অনুমতি দেয়৷
যদি আপনার অ্যাপের View অবজেক্টগুলি কাস্টম টাচ হ্যান্ডলিং ব্যবহার করে, আপনার যাচাই করা উচিত যে সেগুলি এখনও টকব্যাকের সাথে কাজ করে৷ আপনার View অবজেক্ট ব্যবহার করে এমন ক্লিক হ্যান্ডলারটি আপনাকে রেজিস্টার করতে হতে পারে। যদি TalkBack এখনও এই View অবজেক্টে সম্পাদিত অঙ্গভঙ্গিগুলিকে চিনতে না পারে, তাহলে performAccessibilityAction() ওভাররাইড করুন।
অ্যাক্সেসিবিলিটি পরিষেবাগুলি এখন আপনার অ্যাপের TextView অবজেক্টের মধ্যে থাকা সমস্ত ClickableSpan দৃষ্টান্ত সম্পর্কে সচেতন৷

আপনার অ্যাপকে কীভাবে আরও অ্যাক্সেসযোগ্য করা যায় সে সম্পর্কে আরও জানতে, অ্যাক্সেসযোগ্যতা দেখুন।

নেটওয়ার্কিং এবং HTTP(S) সংযোগ

Android 8.0 (API লেভেল 26) নেটওয়ার্কিং এবং HTTP(S) সংযোগে নিম্নলিখিত আচরণ পরিবর্তনগুলি অন্তর্ভুক্ত করে:

কোন বডি ছাড়াই OPTIONS অনুরোধের একটি Content-Length: 0 হেডার নেই। পূর্বে তাদের কোন Content-Length শিরোনাম ছিল না।
HttpURLConnection একটি স্ল্যাশ সহ হোস্ট বা কর্তৃপক্ষের নামের পরে একটি স্ল্যাশ যুক্ত করে খালি পাথ ধারণকারী URLগুলিকে স্বাভাবিক করে। উদাহরণস্বরূপ, এটি http://example.com কে http://example.com/ এ রূপান্তর করে।
ProxySelector.setDefault() এর মাধ্যমে একটি কাস্টম প্রক্সি নির্বাচক সেট শুধুমাত্র একটি অনুরোধ করা URL এর ঠিকানা (স্কিম, হোস্ট এবং পোর্ট) লক্ষ্য করে। ফলস্বরূপ, প্রক্সি নির্বাচন শুধুমাত্র সেই মানগুলির উপর ভিত্তি করে হতে পারে। একটি কাস্টম প্রক্সি নির্বাচককে পাস করা একটি URL অনুরোধ করা URL এর পাথ, ক্যোয়ারী প্যারামিটার বা খণ্ডগুলি অন্তর্ভুক্ত করে না৷
URI তে খালি লেবেল থাকতে পারে না।
পূর্বে, প্ল্যাটফর্মটি হোস্টের নামে খালি লেবেল গ্রহণ করার জন্য একটি সমাধান সমর্থন করেছিল, যা ইউআরআই-এর একটি অবৈধ ব্যবহার। এই সমাধানটি পুরানো libcore রিলিজের সাথে সামঞ্জস্যের জন্য ছিল। ভুলভাবে API ব্যবহারকারী বিকাশকারীরা একটি ADB বার্তা দেখতে পাবেন: "URI example..com-এর হোস্টনামে খালি লেবেল রয়েছে। এটি ত্রুটিপূর্ণ এবং ভবিষ্যতে অ্যান্ড্রয়েড রিলিজে গ্রহণ করা হবে না।" অ্যান্ড্রয়েড 8.0 এই সমাধানকে সরিয়ে দেয়; বিকৃত URI-এর জন্য সিস্টেমটি শূন্য প্রদান করে।
HttpsURLConnection-এর Android 8.0 এর বাস্তবায়ন অনিরাপদ TLS/SSL প্রোটোকল সংস্করণ ফলব্যাক করে না।
টানেলিং HTTP(S) সংযোগগুলির পরিচালনা নিম্নরূপ পরিবর্তিত হয়েছে:
- সংযোগের উপর HTTPS সংযোগ টানেলিং করার সময়, একটি মধ্যবর্তী সার্ভারে এই তথ্য পাঠানোর সময় সিস্টেম সঠিকভাবে পোর্ট নম্বর (:443) হোস্ট লাইনে রাখে। পূর্বে, পোর্ট নম্বর শুধুমাত্র CONNECT লাইনে ছিল।
- সিস্টেমটি আর ব্যবহারকারী-এজেন্ট এবং প্রক্সি-অনুমোদন শিরোনামগুলি প্রক্সি সার্ভারে একটি টানেল করা অনুরোধ থেকে পাঠায় না।
  টানেল সেট আপ করার সময় সিস্টেমটি আর একটি টানেলযুক্ত Http(গুলি)URL সংযোগ প্রক্সিতে প্রক্সি-অনুমোদন শিরোনাম পাঠায় না। পরিবর্তে, সিস্টেমটি একটি প্রক্সি-অনুমোদন শিরোনাম তৈরি করে এবং প্রক্সিতে পাঠায় যখন সেই প্রক্সিটি প্রাথমিক অনুরোধের জবাবে HTTP 407 পাঠায়।
  একইভাবে, সিস্টেমটি আর ব্যবহারকারী-এজেন্ট হেডারকে টানেল করা অনুরোধ থেকে প্রক্সি অনুরোধে কপি করে না যা টানেল সেট আপ করে। পরিবর্তে, লাইব্রেরি সেই অনুরোধের জন্য একটি ব্যবহারকারী-এজেন্ট হেডার তৈরি করে।
যদি পূর্বে সম্পাদিত সংযোগ() পদ্ধতি ব্যর্থ হয় তাহলে send(java.net.DatagramPacket) পদ্ধতি একটি SocketException নিক্ষেপ করে।
- অভ্যন্তরীণ ত্রুটি থাকলে DatagramSocket.connect() একটি মুলতুবি সকেট এক্সেপশন সেট করে। Android 8.0-এর আগে, একটি পরবর্তী recv() কল একটি SocketException থ্রো করেছিল যদিও একটি send() কল সফল হত। সামঞ্জস্যের জন্য, উভয় কলই এখন একটি SocketException নিক্ষেপ করে।
InetAddress.isReachable() TCP ইকো প্রোটোকলে ফিরে আসার আগে ICMP চেষ্টা করে।
- কিছু হোস্ট যারা পোর্ট 7 (টিসিপি ইকো) ব্লক করে, যেমন google.com, তারা ICMP ইকো প্রোটোকল গ্রহণ করলে এখন পৌঁছানো যায়।
- সত্যিকার অর্থে পৌঁছানো যায় না এমন হোস্টের জন্য, এই পরিবর্তনের অর্থ হল যে কল রিটার্নের আগে দ্বিগুণ সময় ব্যয় করা হয়েছে।

ব্লুটুথ

Android 8.0 (API স্তর 26) ScanRecord.getBytes() পদ্ধতি পুনরুদ্ধার করা ডেটার দৈর্ঘ্যে নিম্নলিখিত পরিবর্তনগুলি করে:

getBytes() পদ্ধতিটি প্রাপ্ত বাইটের সংখ্যা সম্পর্কে কোন অনুমান করে না। অতএব, অ্যাপগুলিকে ফেরত দেওয়া ন্যূনতম বা সর্বোচ্চ সংখ্যক বাইটের উপর নির্ভর করা উচিত নয়। পরিবর্তে, তাদের ফলস্বরূপ অ্যারের দৈর্ঘ্য মূল্যায়ন করা উচিত।
ব্লুটুথ 5-সামঞ্জস্যপূর্ণ ডিভাইস পূর্ববর্তী সর্বোচ্চ ~60 বাইট অতিক্রম করে ডেটা দৈর্ঘ্য ফেরত দিতে পারে।
যদি একটি দূরবর্তী ডিভাইস একটি স্ক্যান প্রতিক্রিয়া প্রদান না করে, তাহলে 60 বাইটেরও কম ফেরত দেওয়া হতে পারে।

বিরামহীন সংযোগ

অ্যান্ড্রয়েড 8.0 (API লেভেল 26) Wi-Fi সেটিংসে অনেক উন্নতি করে যাতে ব্যবহারকারীর সেরা অভিজ্ঞতা প্রদান করে এমন Wi-Fi নেটওয়ার্ক বেছে নেওয়া সহজ করে। নির্দিষ্ট পরিবর্তন অন্তর্ভুক্ত:

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

নিরাপত্তা

Android 8.0-এ নিম্নলিখিত নিরাপত্তা-সম্পর্কিত পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে:

প্ল্যাটফর্মটি আর SSLv3 সমর্থন করে না।
একটি সার্ভারে একটি HTTPS সংযোগ স্থাপন করার সময় যা ভুলভাবে TLS প্রোটোকল-সংস্করণ নেগোসিয়েশন প্রয়োগ করে, HttpsURLConnection আর আগের TLS প্রোটোকল সংস্করণগুলিতে ফিরে যাওয়ার এবং পুনরায় চেষ্টা করার সমাধানের চেষ্টা করে না।
অ্যান্ড্রয়েড 8.0 (API লেভেল 26) সমস্ত অ্যাপে একটি সিকিউর কম্পিউটিং (SECCMP) ফিল্টার প্রয়োগ করে। অনুমোদিত syscalls তালিকা বায়োনিক মাধ্যমে উন্মুক্ত যারা সীমাবদ্ধ. যদিও পিছনের সামঞ্জস্যের জন্য আরও কয়েকটি সিস্ক্যাল সরবরাহ করা হয়েছে, আমরা তাদের ব্যবহারের বিরুদ্ধে সুপারিশ করি।
আপনার অ্যাপের WebView অবজেক্ট এখন মাল্টিপ্রসেস মোডে চলে। বর্ধিত নিরাপত্তার জন্য ওয়েব বিষয়বস্তু একটি পৃথক, বিচ্ছিন্ন প্রক্রিয়ায় ধারণ করা অ্যাপের প্রক্রিয়া থেকে পরিচালনা করা হয়।
আপনি আর অনুমান করতে পারবেন না যে APKগুলি ডিরেক্টরিগুলিতে থাকে যার নাম -1 বা -2 তে শেষ হয়৷ অ্যাপগুলিকে ডিরেক্টরিটি পেতে sourceDir ব্যবহার করা উচিত, এবং সরাসরি ডিরেক্টরি বিন্যাসের উপর নির্ভর করা উচিত নয়।
নেটিভ লাইব্রেরিগুলির ব্যবহার সম্পর্কিত নিরাপত্তা বর্ধন সম্পর্কে তথ্যের জন্য, নেটিভ লাইব্রেরি দেখুন।

এছাড়াও, Android 8.0 (API স্তর 26) অজানা উত্স থেকে অজানা অ্যাপ ইনস্টল করার সাথে সম্পর্কিত নিম্নলিখিত পরিবর্তনগুলি প্রবর্তন করে:

লিগ্যাসি সেটিং INSTALL_NON_MARKET_APPS এর মান এখন সর্বদা 1। একটি অজানা উৎস প্যাকেজ ইনস্টলার ব্যবহার করে অ্যাপ ইনস্টল করতে পারে কিনা তা নির্ধারণ করতে, আপনার পরিবর্তে canRequestPackageInstalls() এর রিটার্ন মান ব্যবহার করা উচিত।
যদি আপনি setSecureSetting() ব্যবহার করে INSTALL_NON_MARKET_APPS এর মান পরিবর্তন করার চেষ্টা করেন, একটি UnsupportedOperationException নিক্ষেপ করা হয়। ব্যবহারকারীদের অজানা উৎস ব্যবহার করে অজানা অ্যাপ ইনস্টল করা থেকে বিরত রাখতে, আপনার পরিবর্তে DISALLOW_INSTALL_UNKNOWN_SOURCES ব্যবহারকারী সীমাবদ্ধতা প্রয়োগ করা উচিত।
অ্যান্ড্রয়েড 8.0 (API লেভেল 26) চালিত ডিভাইসগুলিতে তৈরি পরিচালিত প্রোফাইলগুলি স্বয়ংক্রিয়ভাবে DISALLOW_INSTALL_UNKNOWN_SOURCES ব্যবহারকারী সীমাবদ্ধতা সক্ষম করে। Android 8.0-এ আপগ্রেড করা ডিভাইসগুলিতে বিদ্যমান পরিচালিত প্রোফাইলগুলির জন্য, DISALLOW_INSTALL_UNKNOWN_SOURCES ব্যবহারকারীর সীমাবদ্ধতা স্বয়ংক্রিয়ভাবে সক্ষম হয় যদি না প্রোফাইলের মালিক INSTALL_NON_MARKET_APPS সেট করে স্পষ্টভাবে এই বিধিনিষেধটি (আপগ্রেড করার আগে) অক্ষম করে থাকেন৷

অজানা অ্যাপ ইনস্টল করার বিষয়ে অতিরিক্ত বিবরণের জন্য, অজানা অ্যাপ ইনস্টল করার অনুমতি নির্দেশিকা দেখুন।

আপনার অ্যাপটিকে আরও সুরক্ষিত করার জন্য অতিরিক্ত নির্দেশিকাগুলির জন্য, Android বিকাশকারীদের জন্য নিরাপত্তা দেখুন৷

গোপনীয়তা

Android 8.0 (API স্তর 26) প্ল্যাটফর্মে নিম্নলিখিত গোপনীয়তা-সম্পর্কিত পরিবর্তনগুলি করে৷

প্ল্যাটফর্মটি এখন শনাক্তকারীকে ভিন্নভাবে পরিচালনা করে।
- Android 8.0 (API লেভেল 26) (API লেভেল 26) এর একটি সংস্করণে OTA-এর আগে ইনস্টল করা অ্যাপগুলির জন্য, ANDROID_ID এর মান একই থাকে যদি না আনইনস্টল করা হয় এবং OTA-এর পরে পুনরায় ইনস্টল করা হয়। OTA এর পরে আনইনস্টল জুড়ে মানগুলি সংরক্ষণ করতে, বিকাশকারীরা কী/মান ব্যাকআপ ব্যবহার করে পুরানো এবং নতুন মানগুলিকে সংযুক্ত করতে পারে৷
- Android 8.0 চালিত একটি ডিভাইসে ইনস্টল করা অ্যাপগুলির জন্য, ANDROID_ID এর মান এখন অ্যাপ সাইনিং কী, সেইসাথে ব্যবহারকারী পিছু ব্যাপ্ত। অ্যাপ-সাইনিং কী, ব্যবহারকারী এবং ডিভাইসের প্রতিটি সমন্বয়ের জন্য ANDROID_ID এর মান অনন্য। ফলস্বরূপ, একই ডিভাইসে চলমান বিভিন্ন সাইনিং কী সহ অ্যাপগুলি আর একই অ্যান্ড্রয়েড আইডি দেখতে পায় না (এমনকি একই ব্যবহারকারীর জন্যও)।
- প্যাকেজ আনইনস্টল বা পুনরায় ইনস্টল করার সময় ANDROID_ID এর মান পরিবর্তন হয় না, যতক্ষণ না সাইনিং কী একই থাকে (এবং অ্যাপটি Android 8.0-এর সংস্করণে OTA-এর আগে ইনস্টল করা হয়নি)।
- ANDROID_ID এর মান পরিবর্তন হয় না এমনকি যদি একটি সিস্টেম আপডেট প্যাকেজ সাইনিং কী পরিবর্তন করে।
- Google Play পরিষেবা এবং বিজ্ঞাপন আইডি সহ শিপিং ডিভাইসগুলিতে, আপনাকে অবশ্যই বিজ্ঞাপন আইডি ব্যবহার করতে হবে৷ অ্যাপ্লিকেশানগুলিকে নগদীকরণ করার জন্য একটি সাধারণ, আদর্শ সিস্টেম, বিজ্ঞাপন আইডি হল একটি অনন্য, বিজ্ঞাপনের জন্য ব্যবহারকারী-পুনরায় সেটযোগ্য আইডি৷ এটি Google Play পরিষেবা দ্বারা সরবরাহ করা হয়।
  অন্যান্য ডিভাইস নির্মাতাদের ANDROID_ID প্রদান করা চালিয়ে যেতে হবে।
net.hostname সিস্টেম প্রপার্টি জিজ্ঞাসা করলে একটি শূন্য ফলাফল পাওয়া যায়।

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

যদি কোনো অ্যাপ একটি Thread.UncaughtExceptionHandler ইনস্টল করে যা ডিফল্ট Thread.UncaughtExceptionHandler এর মাধ্যমে কল করে না, যখন ধরা না পড়া ব্যতিক্রম ঘটে তখন সিস্টেম অ্যাপটিকে মেরে ফেলবে না। অ্যান্ড্রয়েড 8.0 (API লেভেল 26) থেকে শুরু করে, সিস্টেম এই পরিস্থিতিতে ব্যতিক্রম স্ট্যাকট্রেস লগ করে; প্ল্যাটফর্মের পূর্ববর্তী সংস্করণগুলিতে, সিস্টেমটি ব্যতিক্রম স্ট্যাকট্রেস লগ ইন করত না।

আমরা সুপারিশ করি যে কাস্টম Thread.UncaughtExceptionHandler বাস্তবায়ন সর্বদা ডিফল্ট হ্যান্ডলারের মাধ্যমে কল করুন; যে অ্যাপগুলি এই সুপারিশ অনুসরণ করে তারা Android 8.0-এর পরিবর্তন দ্বারা প্রভাবিত হয় না৷

findViewById() স্বাক্ষর পরিবর্তন

findViewById() পদ্ধতির সমস্ত উদাহরণ এখন View এর পরিবর্তে <T extends View> T প্রদান করে। এই পরিবর্তনের নিম্নলিখিত প্রভাব রয়েছে:

এর ফলে বিদ্যমান কোডে এখন অস্পষ্ট রিটার্ন টাইপ থাকতে পারে, উদাহরণস্বরূপ যদি someMethod(View) এবং someMethod(TextView) উভয়ই থাকে যা findViewById() এ কলের ফলাফল নেয়।
Java 8 সোর্স ল্যাঙ্গুয়েজ ব্যবহার করার সময়, যখন রিটার্ন টাইপ অনিয়ন্ত্রিত হয় তখন View জন্য একটি স্পষ্ট কাস্ট প্রয়োজন (উদাহরণস্বরূপ, assertNotNull(findViewById(...)).someViewMethod()) ।
অ-ফাইনাল findViewById() পদ্ধতির ওভাররাইড (উদাহরণস্বরূপ, Activity.findViewById() ) তাদের রিটার্ন টাইপ আপডেট করতে হবে।

পরিচিতি প্রদানকারীর ব্যবহারের পরিসংখ্যান পরিবর্তন হয়

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

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

এই আচরণ পরিবর্তন নিম্নলিখিত ক্যোয়ারী পরামিতি প্রভাবিত করে:

সংগ্রহ পরিচালনা

AbstractCollection.removeAll() এবং AbstractCollection.retainAll() এখন সর্বদা একটি NullPointerException নিক্ষেপ করুন; পূর্বে, সংগ্রহটি খালি হলে NullPointerException নিক্ষেপ করা হয়নি। এই পরিবর্তনটি আচরণকে ডকুমেন্টেশনের সাথে সামঞ্জস্যপূর্ণ করে তোলে।

অ্যান্ড্রয়েড এন্টারপ্রাইজ

অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) ডিভাইস পলিসি কন্ট্রোলার (ডিপিসি) সহ এন্টারপ্রাইজ অ্যাপের জন্য কিছু API এবং বৈশিষ্ট্যের আচরণ পরিবর্তন করে । পরিবর্তনগুলি অন্তর্ভুক্ত:

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

অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) এ এন্টারপ্রাইজের সমস্ত পরিবর্তন দেখতে এবং তারা কীভাবে আপনার অ্যাপকে প্রভাবিত করতে পারে তা জানতে, এন্টারপ্রাইজে Android পড়ুন।

Android 8.0 কে লক্ষ্য করে অ্যাপস

এই আচরণ পরিবর্তনগুলি শুধুমাত্র Android 8.0 (API স্তর 26) বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলিতে প্রযোজ্য৷ যে অ্যাপগুলি Android 8.0-এর বিপরীতে কম্পাইল করে বা Android 8.0 বা উচ্চতর তে targetSdkVersion সেট করে তাদের অবশ্যই এই আচরণগুলিকে সঠিকভাবে সমর্থন করার জন্য তাদের অ্যাপগুলিকে সংশোধন করতে হবে, যেখানে অ্যাপের ক্ষেত্রে প্রযোজ্য।

সতর্কতা জানালা

যে অ্যাপগুলি SYSTEM_ALERT_WINDOW অনুমতি ব্যবহার করে সেগুলি আর অন্যান্য অ্যাপ এবং সিস্টেম উইন্ডোর উপরে সতর্কতা উইন্ডো প্রদর্শন করতে নিম্নলিখিত উইন্ডো প্রকারগুলি ব্যবহার করতে পারবে না:

পরিবর্তে, অ্যাপগুলিকে অবশ্যই TYPE_APPLICATION_OVERLAY নামে একটি নতুন উইন্ডো টাইপ ব্যবহার করতে হবে।

আপনার অ্যাপের জন্য সতর্কতা উইন্ডো প্রদর্শন করতে TYPE_APPLICATION_OVERLAY উইন্ডো টাইপ ব্যবহার করার সময়, নতুন উইন্ডো টাইপের নিম্নলিখিত বৈশিষ্ট্যগুলি মনে রাখবেন:

একটি অ্যাপ্লিকেশানের সতর্কতা উইন্ডোগুলি সর্বদা গুরুত্বপূর্ণ সিস্টেম উইন্ডোগুলির অধীনে প্রদর্শিত হয়, যেমন স্ট্যাটাস বার এবং IMEs৷
সিস্টেমটি স্ক্রীন উপস্থাপনা উন্নত করতে TYPE_APPLICATION_OVERLAY উইন্ডো টাইপ ব্যবহার করে এমন উইন্ডোগুলি সরাতে বা পুনরায় আকার দিতে পারে৷
বিজ্ঞপ্তি শেড খোলার মাধ্যমে, ব্যবহারকারীরা TYPE_APPLICATION_OVERLAY উইন্ডো টাইপ ব্যবহার করে দেখানো সতর্কতা উইন্ডোগুলি প্রদর্শন করা থেকে একটি অ্যাপকে ব্লক করতে সেটিংস অ্যাক্সেস করতে পারে।

বিষয়বস্তু পরিবর্তন বিজ্ঞপ্তি

Android 8.0 (API স্তর 26) কীভাবে ContentResolver.notifyChange() এবং registerContentObserver(Uri, boolean, ContentObserver) অ্যানড্রয়েড 8.0-কে টার্গেট করে এমন অ্যাপের আচরণ পরিবর্তন করে।

এই APIগুলির এখন প্রয়োজন যে সমস্ত Uris-এ কর্তৃপক্ষের জন্য একটি বৈধ ContentProvider সংজ্ঞায়িত করা হয়েছে৷ প্রাসঙ্গিক অনুমতি সহ একটি বৈধ ContentProvider সংজ্ঞায়িত করা আপনার অ্যাপকে ক্ষতিকারক অ্যাপের সামগ্রীর পরিবর্তনের বিরুদ্ধে রক্ষা করতে সাহায্য করবে এবং ক্ষতিকারক অ্যাপগুলিতে সম্ভাব্য ব্যক্তিগত ডেটা ফাঁস হতে বাধা দেবে।

ফোকাস দেখুন

ক্লিকযোগ্য View অবজেক্টগুলিও এখন ডিফল্টরূপে ফোকাসযোগ্য। আপনি যদি একটি View অবজেক্টকে ক্লিক করার যোগ্য কিন্তু ফোকাসযোগ্য না করতে চান, তাহলে View সহ লেআউট XML ফাইলে android:focusable অ্যাট্রিবিউটটিকে false এ সেট করুন অথবা আপনার অ্যাপের UI লজিকে setFocusable() এ false পাস করুন।

ব্রাউজার সনাক্তকরণে ব্যবহারকারী-এজেন্ট ম্যাচিং

Android 8.0 (API লেভেল 26) এবং উচ্চতর বিল্ড আইডেন্টিফায়ার স্ট্রিং OPR অন্তর্ভুক্ত। কিছু প্যাটার্ন মিলের কারণে ব্রাউজার-ডিটেকশন লজিক অপেরা নয় এমন ব্রাউজারকে অপেরা হিসেবে ভুল শনাক্ত করতে পারে। এই ধরনের একটি প্যাটার্ন মিলের একটি উদাহরণ হতে পারে:

if(p.match(/OPR/)){k="Opera";c=p.match(/OPR\/(\d+.\d+)/);n=new Ext.Version(c[1])}

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

নিরাপত্তা

নিম্নলিখিত পরিবর্তনগুলি Android 8.0 (API স্তর 26) এর নিরাপত্তাকে প্রভাবিত করে:

যদি আপনার অ্যাপের নেটওয়ার্ক সিকিউরিটি কনফিগারেশন ক্লিয়ারটেক্সট ট্র্যাফিক সমর্থন করা থেকে অপ্ট আউট করে , তাহলে আপনার অ্যাপের WebView অবজেক্ট HTTP-এর মাধ্যমে ওয়েবসাইট অ্যাক্সেস করতে পারবে না। প্রতিটি WebView বস্তুর পরিবর্তে HTTPS ব্যবহার করতে হবে।
অজানা উত্সগুলিকে অনুমতি দিন সিস্টেম সেটিংটি সরানো হয়েছে; এর জায়গায়, অজানা অ্যাপ ইনস্টল করার অনুমতি অজানা উত্স থেকে অজানা অ্যাপ ইনস্টল পরিচালনা করে। এই নতুন অনুমতি সম্পর্কে আরও জানতে, অজানা অ্যাপ ইনস্টল অনুমতি নির্দেশিকা দেখুন।

অ্যাকাউন্ট অ্যাক্সেস এবং আবিষ্কারযোগ্যতা

অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26), অ্যাপগুলি আর ব্যবহারকারীর অ্যাকাউন্টগুলিতে অ্যাক্সেস পেতে পারে না যদি না প্রমাণীকরণকারী অ্যাকাউন্টগুলির মালিক না হয় বা ব্যবহারকারী সেই অ্যাক্সেস মঞ্জুর করে। GET_ACCOUNTS অনুমতি আর যথেষ্ট নয়৷ একটি অ্যাকাউন্টে অ্যাক্সেস মঞ্জুর করার জন্য, অ্যাপগুলির হয় AccountManager.newChooseAccountIntent() অথবা একটি প্রমাণীকরণকারী-নির্দিষ্ট পদ্ধতি ব্যবহার করা উচিত। অ্যাকাউন্টগুলিতে অ্যাক্সেস পাওয়ার পরে, একটি অ্যাপ সেগুলি অ্যাক্সেস করতে AccountManager.getAccounts() এ কল করতে পারে।

Android 8.0 LOGIN_ACCOUNTS_CHANGED_ACTION বর্জন করে। রানটাইম চলাকালীন অ্যাকাউন্ট সম্পর্কে আপডেট পেতে অ্যাপগুলির পরিবর্তে addOnAccountsUpdatedListener() ব্যবহার করা উচিত।

নতুন API এবং অ্যাকাউন্ট অ্যাক্সেস এবং আবিষ্কারযোগ্যতার জন্য যোগ করা পদ্ধতি সম্পর্কে তথ্যের জন্য, এই নথির নতুন APIs বিভাগে অ্যাকাউন্ট অ্যাক্সেস এবং আবিষ্কারযোগ্যতা দেখুন।

গোপনীয়তা

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

সিস্টেম বৈশিষ্ট্য net.dns1 , net.dns2 , net.dns3 , এবং net.dns4 আর উপলব্ধ নেই, একটি পরিবর্তন যা প্ল্যাটফর্মে গোপনীয়তা উন্নত করে৷
DNS সার্ভারের মতো নেটওয়ার্কিং তথ্য পেতে, ACCESS_NETWORK_STATE অনুমতি সহ অ্যাপগুলি একটি NetworkRequest বা NetworkCallback অবজেক্ট নিবন্ধন করতে পারে। এই ক্লাসগুলি Android 5.0 (API স্তর 21) এবং উচ্চতর সংস্করণে উপলব্ধ।
Build.SERIAL বাতিল করা হয়েছে। যে অ্যাপগুলির হার্ডওয়্যার সিরিয়াল নম্বর জানা দরকার তাদের পরিবর্তে নতুন Build.getSerial() পদ্ধতি ব্যবহার করা উচিত, যার জন্য READ_PHONE_STATE অনুমতি প্রয়োজন৷
LauncherApps API আর কাজের প্রোফাইল অ্যাপগুলিকে প্রাথমিক প্রোফাইল সম্পর্কে তথ্য পেতে অনুমতি দেয় না। যখন একজন ব্যবহারকারী একটি কাজের প্রোফাইলে থাকে, তখন LauncherApps API এমনভাবে আচরণ করে যেন একই প্রোফাইল গ্রুপের মধ্যে অন্য প্রোফাইলে কোনো অ্যাপ ইনস্টল করা নেই। আগের মতো, সম্পর্কহীন প্রোফাইল অ্যাক্সেস করার প্রচেষ্টা নিরাপত্তা ব্যতিক্রম ঘটায়।

অনুমতি

অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) এর আগে, যদি কোনও অ্যাপ রানটাইমে অনুমতির অনুরোধ করে এবং অনুমতি দেওয়া হয়, তবে সিস্টেমটি একই অনুমতি গোষ্ঠীর অন্তর্গত বাকি অনুমতিগুলিও অ্যাপটিকে ভুলভাবে মঞ্জুর করে এবং যেগুলি নিবন্ধিত ছিল প্রকাশ

Android 8.0 কে লক্ষ্য করে এমন অ্যাপগুলির জন্য, এই আচরণটি সংশোধন করা হয়েছে৷ অ্যাপটিকে শুধুমাত্র সেই অনুমতিই দেওয়া হয় যা এটি স্পষ্টভাবে অনুরোধ করেছে। যাইহোক, একবার ব্যবহারকারী অ্যাপটিকে অনুমতি দিলে, সেই অনুমতি গোষ্ঠীতে অনুমতির জন্য পরবর্তী সমস্ত অনুরোধ স্বয়ংক্রিয়ভাবে মঞ্জুর হয়ে যায়।

উদাহরণস্বরূপ, ধরুন একটি অ্যাপ তার ম্যানিফেস্টে READ_EXTERNAL_STORAGE এবং WRITE_EXTERNAL_STORAGE উভয়কেই তালিকাভুক্ত করে৷ অ্যাপটি READ_EXTERNAL_STORAGE অনুরোধ করে এবং ব্যবহারকারী এটি মঞ্জুর করে৷ যদি অ্যাপটি API স্তর 25 বা তার নিচের দিকে লক্ষ্য করে, তবে সিস্টেমটি একই সময়ে WRITE_EXTERNAL_STORAGE মঞ্জুর করে, কারণ এটি একই STORAGE অনুমতি গোষ্ঠীর অন্তর্গত এবং ম্যানিফেস্টে নিবন্ধিতও রয়েছে৷ যদি অ্যাপটি Android 8.0 (API স্তর 26) কে লক্ষ্য করে, তবে সিস্টেমটি সেই সময়ে শুধুমাত্র READ_EXTERNAL_STORAGE মঞ্জুর করে; যাইহোক, যদি অ্যাপটি পরবর্তীতে WRITE_EXTERNAL_STORAGE অনুরোধ করে, তাহলে সিস্টেম অবিলম্বে ব্যবহারকারীকে প্রম্পট না করেই সেই বিশেষাধিকার প্রদান করে।

মিডিয়া

ফ্রেমওয়ার্ক নিজেই স্বয়ংক্রিয় অডিও ডাকিং করতে পারে। এই ক্ষেত্রে, যখন অন্য একটি অ্যাপ্লিকেশন AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK এর সাথে ফোকাস করার অনুরোধ করে, তখন যে অ্যাপ্লিকেশনটিতে ফোকাস রয়েছে সেটি তার ভলিউম কমিয়ে দেয় কিন্তু সাধারণত onAudioFocusChange() কলব্যাক পায় না এবং অডিও ফোকাস হারাবে না। নতুন এপিআইগুলি এমন অ্যাপ্লিকেশনগুলির জন্য এই আচরণটিকে ওভাররাইড করতে উপলব্ধ রয়েছে যেগুলিকে ডাকার পরিবর্তে বিরতি দিতে হবে৷
যখন ব্যবহারকারী একটি ফোন কল নেয়, সক্রিয় মিডিয়া স্ট্রীম কলের সময়কালের জন্য নিঃশব্দ করে।
সমস্ত অডিও-সম্পর্কিত API-এর অডিও প্লেব্যাক ব্যবহারের ক্ষেত্রে বর্ণনা করতে অডিও স্ট্রিম প্রকারের পরিবর্তে AudioAttributes ব্যবহার করা উচিত। শুধুমাত্র ভলিউম নিয়ন্ত্রণের জন্য অডিও স্ট্রিম প্রকারগুলি ব্যবহার করা চালিয়ে যান। স্ট্রিম প্রকারের অন্যান্য ব্যবহারগুলি এখনও কাজ করে (উদাহরণস্বরূপ, AudioTrack কনস্ট্রাক্টরের কাছে streamType আর্গুমেন্ট), কিন্তু সিস্টেম এটিকে একটি ত্রুটি হিসাবে লগ করে।
একটি AudioTrack ব্যবহার করার সময়, যদি অ্যাপ্লিকেশনটি যথেষ্ট বড় অডিও বাফারের জন্য অনুরোধ করে, ফ্রেমওয়ার্কটি উপলব্ধ থাকলে গভীর বাফার আউটপুট ব্যবহার করার চেষ্টা করবে।
অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) মিডিয়া বোতাম ইভেন্টগুলির পরিচালনা আলাদা:
1. একটি UI কার্যকলাপে মিডিয়া বোতাম পরিচালনার পরিবর্তন হয়নি: মিডিয়া বোতাম ইভেন্টগুলি পরিচালনা করার ক্ষেত্রে অগ্রভাগের কার্যকলাপগুলি এখনও অগ্রাধিকার পায়৷
2. যদি ফোরগ্রাউন্ড অ্যাক্টিভিটি মিডিয়া বোতাম ইভেন্টটি পরিচালনা না করে, সিস্টেমটি ইভেন্টটিকে সেই অ্যাপে রুট করে যেটি সম্প্রতি স্থানীয়ভাবে অডিও চালানো হয়েছে। কোন অ্যাপ মিডিয়া বোতাম ইভেন্টগুলি গ্রহণ করে তা নির্ধারণ করার সময় একটি মিডিয়া সেশনের সক্রিয় স্থিতি, পতাকা এবং প্লেব্যাক অবস্থা বিবেচনা করা হয় না।
3. যদি অ্যাপটির মিডিয়া সেশন প্রকাশ করা হয়, সিস্টেমটি মিডিয়া বোতাম ইভেন্টটিকে অ্যাপের MediaButtonReceiver এ পাঠায় যদি এটিতে একটি থাকে।
4. অন্য প্রতিটি ক্ষেত্রে, সিস্টেম মিডিয়া বোতাম ইভেন্ট বাতিল করে।

নেটিভ লাইব্রেরি

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

আরও তথ্যের জন্য, লিখনযোগ্য এবং এক্সিকিউটেবল সেগমেন্ট দেখুন।

লিঙ্কার পরিবর্তনগুলি এপিআই স্তরের সাথে সংযুক্ত থাকে যা একটি অ্যাপ লক্ষ্য করে। লক্ষ্যযুক্ত API স্তরে লিঙ্কার পরিবর্তন হলে, অ্যাপটি লাইব্রেরি লোড করতে পারবে না। আপনি যদি API স্তরের থেকে কম একটি API স্তর লক্ষ্য করেন যেখানে লিঙ্কার পরিবর্তন ঘটে, logcat একটি সতর্কতা দেখায়।

সংগ্রহ পরিচালনা

Android 8.0 (API লেভেল 26), Collections.sort() List.sort() এর উপরে প্রয়োগ করা হয়েছে। বিপরীতটি অ্যান্ড্রয়েড 7.x (API স্তর 24 এবং 25) এ সত্য ছিল: List.sort() এর ডিফল্ট বাস্তবায়ন Collections.sort() নামে পরিচিত।

এই পরিবর্তন Collections.sort() অপ্টিমাইজ করা List.sort() বাস্তবায়নের সুবিধা নিতে দেয়, কিন্তু নিম্নলিখিত সীমাবদ্ধতা রয়েছে:

List.sort() এর বাস্তবায়ন অবশ্যই Collections.sort() কল করবে না, কারণ এটি করার ফলে অসীম পুনরাবৃত্তির কারণে স্ট্যাক ওভারফ্লো হবে। পরিবর্তে, আপনি যদি আপনার List বাস্তবায়নে ডিফল্ট আচরণ চান, তাহলে আপনার ওভাররাইডিং sort() এড়ানো উচিত।
যদি কোনো অভিভাবক শ্রেণি অনুপযুক্তভাবে sort() প্রয়োগ করে, তাহলে List.toArray() , Arrays.sort() , এবং ListIterator.set() এর উপরে নির্মিত একটি বাস্তবায়নের সাথে List.sort() ওভাররাইড করা সাধারণত ভালো। যেমন:
```
@Override
public void sort(Comparator<? super E> c) {
  Object[] elements = toArray();
  Arrays.sort(elements, c);
  ListIterator<E> iterator = (ListIterator<Object>) listIterator();
  for (Object element : elements) {
    iterator.next();
    iterator.set((E) element);
  }
}
```
বেশিরভাগ ক্ষেত্রে, আপনি List.sort() একটি বাস্তবায়নের মাধ্যমে ওভাররাইড করতে পারেন যা API স্তরের উপর নির্ভর করে বিভিন্ন ডিফল্ট বাস্তবায়নে প্রতিনিধিত্ব করে। যেমন:
```
@Override
public void sort(Comparator<? super E> comparator) {
  if (Build.VERSION.SDK_INT <= 25) {
    Collections.sort(this);
  } else {
    super.sort(comparator);
  }
}
```
আপনি যদি পরবর্তীটি করছেন শুধুমাত্র কারণ আপনি একটি sort() পদ্ধতি সমস্ত API স্তরে উপলব্ধ করতে চান, তাহলে এটিকে একটি অনন্য নাম দেওয়ার কথা বিবেচনা করুন, যেমন sortCompat() , overriding sort() এর পরিবর্তে।
Collections.sort() এখন তালিকা বাস্তবায়নে একটি কাঠামোগত পরিবর্তন হিসাবে গণনা করা হয় যা sort() কল করে। উদাহরণ স্বরূপ, Android 8.0 (API লেভেল 26) এর পূর্বের প্ল্যাটফর্মের সংস্করণগুলিতে, একটি ArrayList উপর পুনরাবৃত্তি করা এবং পুনরাবৃত্তের মাধ্যমে এটিতে sort() কল করা একটি ConcurrentModificationException নিক্ষেপ করত যদি List.sort() কল করে বাছাই করা হয়। . Collections.sort() একটি ব্যতিক্রম নিক্ষেপ করেনি।
এই পরিবর্তনটি প্ল্যাটফর্মের আচরণকে আরও সামঞ্জস্যপূর্ণ করে তোলে: যে কোনও পদ্ধতির ফলে এখন একটি ConcurrentModificationException হয়।

ক্লাস-লোডিং আচরণ

অ্যান্ড্রয়েড 8.0 (এপিআই লেভেল 26) নতুন ক্লাস লোড করার সময় ক্লাস লোডাররা রানটাইমের অনুমান ভঙ্গ করে না তা নিশ্চিত করতে পরীক্ষা করে। ক্লাসটি জাভা ( forName() থেকে), ডালভিক বাইটকোড বা JNI থেকে রেফারেন্স করা হয়েছে কিনা এই পরীক্ষাগুলি করা হয়। প্ল্যাটফর্মটি জাভা থেকে loadClass() পদ্ধতিতে সরাসরি কলগুলিকে বাধা দেয় না বা এই ধরনের কলগুলির ফলাফলগুলি পরীক্ষা করে না। এই আচরণটি ভাল আচরণ করা ক্লাস লোডারদের কার্যকারিতাকে প্রভাবিত করবে না।

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

প্ল্যাটফর্মটিও পরীক্ষা করে যে অনুরোধ করা ক্লাসের বর্ণনাকারী বৈধ। এই চেকটি জেএনআই কল ক্যাচ করে যা পরোক্ষভাবে ক্লাস লোড করে যেমন GetFieldID() , সেই ক্লাসগুলিতে অবৈধ বর্ণনাকারী পাস করে৷ উদাহরণস্বরূপ, স্বাক্ষর java/lang/String সহ একটি ক্ষেত্র পাওয়া যায় না কারণ সেই স্বাক্ষরটি অবৈধ; এটি Ljava/lang/String; .

এটি একটি JNI কল থেকে FindClass() যেখানে java/lang/String একটি বৈধ সম্পূর্ণ-যোগ্য নাম।

Android 8.0 (API লেভেল 26) একাধিক ক্লাস লোডার একই ডেক্সফাইল অবজেক্ট ব্যবহার করে ক্লাস সংজ্ঞায়িত করার চেষ্টা করা সমর্থন করে না। এটি করার একটি প্রচেষ্টার ফলে অ্যান্ড্রয়েড রানটাইম "একাধিক ক্লাস লোডারের সাথে ডেক্স ফাইল <filename> নিবন্ধন করার চেষ্টা" বার্তার সাথে একটি InternalError ত্রুটি ছুঁড়ে দেয়।

DexFile API এখন অবহেলিত হয়েছে, এবং এর পরিবর্তে PathClassLoader বা BaseDexClassLoader সহ প্ল্যাটফর্ম ক্লাসলোডারগুলির একটি ব্যবহার করার জন্য আপনাকে জোরালোভাবে উত্সাহিত করা হচ্ছে৷

দ্রষ্টব্য: আপনি একাধিক ক্লাস লোডার তৈরি করতে পারেন যা ফাইল সিস্টেম থেকে একই APK বা JAR ফাইল কন্টেইনারকে উল্লেখ করে। সাধারণত এটি করার ফলে বেশি মেমরি ওভারহেড হয় না: যদি কনটেইনারে DEX ফাইলগুলি সংকুচিত করার পরিবর্তে সংরক্ষণ করা হয়, তাহলে প্ল্যাটফর্ম সরাসরি তাদের বের করার পরিবর্তে তাদের উপর একটি mmap অপারেশন করতে পারে। তবে, যদি প্ল্যাটফর্মটি অবশ্যই ধারক থেকে ডেক্স ফাইলটি বের করতে পারে তবে এই ফ্যাশনে একটি ডেক্স ফাইল উল্লেখ করা প্রচুর মেমরি গ্রাস করতে পারে।

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

সাবধানতা: অ্যান্ড্রয়েড 8.0 (এপিআই স্তর 26) এর চেয়ে কম প্ল্যাটফর্মের সংস্করণগুলিতে, এই অনুমানগুলি ভাঙার ফলে একই শ্রেণীর একাধিকবার সংজ্ঞায়িত হতে পারে, শ্রেণীর বিভ্রান্তির কারণে হিপ দুর্নীতি এবং অন্যান্য অনাকাঙ্ক্ষিত প্রভাবগুলি হতে পারে।