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

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

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

যে পরিবর্তনগুলি শুধুমাত্র API স্তর 28 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপ্লিকেশানগুলিকে প্রভাবিত করে, আচরণের পরিবর্তনগুলি দেখুন: API স্তর 28+ লক্ষ্য করে এমন অ্যাপ ৷

শক্তি ব্যবস্থাপনা

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

বিস্তারিত জানার জন্য, পাওয়ার ম্যানেজমেন্ট দেখুন।

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

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

এই পরিবর্তনগুলি লক্ষ্য SDK সংস্করণ নির্বিশেষে Android 9 এ চলমান সমস্ত অ্যাপকে প্রভাবিত করে৷

পটভূমিতে সেন্সরগুলিতে সীমিত অ্যাক্সেস

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

আপনার অ্যাপ মাইক্রোফোন বা ক্যামেরা অ্যাক্সেস করতে পারে না।
যে সেন্সরগুলি অবিচ্ছিন্ন রিপোর্টিং মোড ব্যবহার করে, যেমন অ্যাক্সিলোমিটার এবং জাইরোস্কোপ, ইভেন্টগুলি গ্রহণ করে না৷
অন-চেঞ্জ বা এক-শট রিপোর্টিং মোড ব্যবহার করে এমন সেন্সরগুলি ইভেন্টগুলি গ্রহণ করে না।

আপনার অ্যাপটিকে যদি Android 9 চালিত ডিভাইসগুলিতে সেন্সর ইভেন্ট সনাক্ত করতে হয়, তাহলে একটি ফোরগ্রাউন্ড পরিষেবা ব্যবহার করুন৷

কল লগগুলিতে সীমাবদ্ধ অ্যাক্সেস

Android 9 CALL_LOG অনুমতি গোষ্ঠীর পরিচয় দেয় এবং READ_CALL_LOG , WRITE_CALL_LOG , এবং PROCESS_OUTGOING_CALLS অনুমতিগুলিকে এই গোষ্ঠীতে স্থানান্তর করে৷ Android এর পূর্ববর্তী সংস্করণগুলিতে, এই অনুমতিগুলি PHONE অনুমতি গোষ্ঠীতে অবস্থিত ছিল৷

এই CALL_LOG অনুমতি গোষ্ঠী ব্যবহারকারীদের এমন অ্যাপগুলিতে আরও ভাল নিয়ন্ত্রণ এবং দৃশ্যমানতা দেয় যেগুলির ফোন কল সম্পর্কে সংবেদনশীল তথ্য, যেমন ফোন কল রেকর্ড পড়া এবং ফোন নম্বর সনাক্তকরণে অ্যাক্সেস প্রয়োজন৷

যদি আপনার অ্যাপের কল লগগুলিতে অ্যাক্সেসের প্রয়োজন হয় বা বহির্গামী কলগুলি প্রক্রিয়া করার প্রয়োজন হয় তবে আপনাকে অবশ্যই CALL_LOG অনুমতি গোষ্ঠী থেকে এই অনুমতিগুলির জন্য স্পষ্টভাবে অনুরোধ করতে হবে৷ অন্যথায়, একটি SecurityException ঘটে।

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

যদি আপনার অ্যাপ ইতিমধ্যেই রানটাইম অনুমতির সর্বোত্তম অনুশীলনগুলি অনুসরণ করে থাকে তবে এটি অনুমতি গোষ্ঠীর পরিবর্তন পরিচালনা করতে পারে৷

ফোন নম্বরগুলিতে সীমাবদ্ধ অ্যাক্সেস

অ্যান্ড্রয়েড 9 এ চলমান অ্যাপগুলি প্রথমে READ_CALL_LOG অনুমতি না নিয়ে ফোন নম্বর বা ফোনের অবস্থা পড়তে পারে না, আপনার অ্যাপের ব্যবহারের ক্ষেত্রে প্রয়োজনীয় অন্যান্য অনুমতিগুলি ছাড়াও৷

ইনকামিং এবং আউটগোয়িং কলগুলির সাথে যুক্ত ফোন নম্বরগুলি ফোন স্টেট ব্রডকাস্টে দৃশ্যমান, যেমন ইনকামিং এবং আউটগোয়িং কলগুলির জন্য এবং PhoneStateListener ক্লাস থেকে অ্যাক্সেসযোগ্য৷ READ_CALL_LOG অনুমতি ব্যতীত, যাইহোক, PHONE_STATE_CHANGED সম্প্রচারে এবং PhoneStateListener এর মাধ্যমে দেওয়া ফোন নম্বর ক্ষেত্রটি খালি।

ফোনের অবস্থা থেকে ফোন নম্বর পড়তে, আপনার ব্যবহারের ক্ষেত্রের উপর ভিত্তি করে প্রয়োজনীয় অনুমতির অনুরোধ করতে আপনার অ্যাপ আপডেট করুন:

PHONE_STATE ইন্টেন্ট অ্যাকশন থেকে নম্বরগুলি পড়ার জন্য, আপনার READ_CALL_LOG অনুমতি এবং READ_PHONE_STATE অনুমতি উভয়ই প্রয়োজন৷
onCallStateChanged() থেকে নম্বরগুলি পড়তে, আপনার শুধুমাত্র READ_CALL_LOG অনুমতি প্রয়োজন৷ আপনার READ_PHONE_STATE অনুমতির প্রয়োজন নেই৷

Wi-Fi অবস্থান এবং সংযোগ তথ্যে সীমাবদ্ধ অ্যাক্সেস

অ্যান্ড্রয়েড 9-এ, ওয়াই-ফাই স্ক্যান করার জন্য একটি অ্যাপের অনুমতির প্রয়োজনীয়তা আগের সংস্করণগুলির তুলনায় আরও কঠোর। বিস্তারিত জানার জন্য, Wi-Fi স্ক্যানিং সীমাবদ্ধতা দেখুন।

অনুরূপ বিধিনিষেধ getConnectionInfo() পদ্ধতিতেও প্রযোজ্য, যা বর্তমান Wi-Fi সংযোগ বর্ণনা করে একটি WifiInfo বস্তু প্রদান করে। কলিং অ্যাপের নিম্নলিখিত অনুমতি থাকলে আপনি শুধুমাত্র SSID এবং BSSID মানগুলি পুনরুদ্ধার করতে এই বস্তুর পদ্ধতিগুলি ব্যবহার করতে পারেন:

ACCESS_FINE_LOCATION বা ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE

SSID বা BSSID পুনরুদ্ধার করার জন্য ডিভাইসে অবস্থান পরিষেবাগুলি সক্ষম করা প্রয়োজন ( সেটিংস > অবস্থানের অধীনে)।

Wi-Fi পরিষেবা পদ্ধতি থেকে তথ্য সরানো হয়েছে৷

Android 9-এ, নিম্নলিখিত ইভেন্ট এবং সম্প্রচারগুলি ব্যবহারকারীর অবস্থান বা ব্যক্তিগতভাবে শনাক্তযোগ্য ডেটা সম্পর্কে তথ্য পায় না:

WifiManager থেকে getScanResults() এবং getConnectionInfo() পদ্ধতি।
WifiP2pManager থেকে discoverServices() এবং addServiceRequest() পদ্ধতি।
NETWORK_STATE_CHANGED_ACTION সম্প্রচার।

Wi-Fi থেকে সম্প্রচারিত NETWORK_STATE_CHANGED_ACTION সিস্টেমে আর SSID (আগে EXTRA_SSID), BSSID (আগে EXTRA_BSSID), বা সংযোগ তথ্য (আগে EXTRA_NETWORK_INFO) থাকে না। আপনার অ্যাপের এই তথ্যের প্রয়োজন হলে, পরিবর্তে getConnectionInfo() কল করুন।

টেলিফোনি তথ্য এখন ডিভাইস অবস্থান সেটিং উপর নির্ভর করে

যদি ব্যবহারকারী Android 9 চালিত একটি ডিভাইসে ডিভাইসের অবস্থান অক্ষম করে থাকে, তাহলে নিম্নলিখিত পদ্ধতিগুলি ফলাফল প্রদান করে না:

নন-SDK ইন্টারফেস ব্যবহারের উপর বিধিনিষেধ

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

নন-SDK ইন্টারফেসে বিধিনিষেধ আরো গুরুত্বপূর্ণ তথ্য ধারণ করে। আপনার অ্যাপটি সঠিকভাবে কাজ করছে কিনা তা নিশ্চিত করতে আপনার এটি পর্যালোচনা করা উচিত।

নিরাপত্তা আচরণ পরিবর্তন

ডিভাইসের নিরাপত্তা পরিবর্তন

অ্যান্ড্রয়েড 9 বিভিন্ন ক্ষমতা যুক্ত করে যা আপনার অ্যাপের নিরাপত্তাকে উন্নত করে, আপনার অ্যাপের যে সংস্করণটি লক্ষ্য করা হোক না কেন।

TLS বাস্তবায়ন পরিবর্তন

সিস্টেমের TLS বাস্তবায়ন অ্যান্ড্রয়েড 9-এ বেশ কিছু পরিবর্তন করেছে:

SSLSocket এর একটি উদাহরণ তৈরি হওয়ার সময় সংযোগ করতে ব্যর্থ হলে, সিস্টেমটি NullPointerException এর পরিবর্তে একটি IOException নিক্ষেপ করে।
SSLEngine ক্লাস পরিচ্ছন্নভাবে যে কোনো close_notify সতর্কতাগুলি পরিচালনা করে।

একটি Android অ্যাপে সুরক্ষিত ওয়েব অনুরোধ করার বিষয়ে আরও জানতে, একটি HTTPS উদাহরণ দেখুন।

কঠোর SECOMP ফিল্টার

Android 9 অ্যাপগুলিতে উপলব্ধ সিস্টেম কলগুলিকে আরও সীমাবদ্ধ করে। এই আচরণটি SECOMP ফিল্টারের একটি এক্সটেনশন যা Android 8.0 (API স্তর 26) অন্তর্ভুক্ত করে ।

ক্রিপ্টোগ্রাফিক পরিবর্তন

অ্যান্ড্রয়েড 9 ক্রিপ্টোগ্রাফিক অ্যালগরিদম বাস্তবায়ন এবং পরিচালনায় বেশ কয়েকটি পরিবর্তন প্রবর্তন করে।

পরামিতি এবং অ্যালগরিদমের কনস্ক্রিপ্ট বাস্তবায়ন

অ্যান্ড্রয়েড 9 কনস্ক্রিপ্টে অ্যালগরিদম প্যারামিটারের অতিরিক্ত বাস্তবায়ন প্রদান করে। এই পরামিতিগুলির মধ্যে রয়েছে: AES, DESEDE, OAEP এবং EC। এই পরামিতিগুলির বাউন্সি ক্যাসেল সংস্করণ এবং অনেক অ্যালগরিদম Android 9-এর হিসাবে বাতিল করা হয়েছে।

যদি আপনার অ্যাপটি Android 8.1 (API লেভেল 27) বা তার নিচের দিকে লক্ষ্য করে, তাহলে এই অবহেলিত অ্যালগরিদমগুলির একটির বাউন্সি ক্যাসল বাস্তবায়নের অনুরোধ করার সময় আপনি একটি সতর্কতা পাবেন। আপনি যদি Android 9 টার্গেট করেন, তবে, এই অনুরোধগুলির প্রতিটিতে একটি NoSuchAlgorithmException থ্রো করা হয়।

অন্যান্য পরিবর্তন

অ্যান্ড্রয়েড 9 ক্রিপ্টোগ্রাফি সম্পর্কিত অন্যান্য বেশ কয়েকটি পরিবর্তন প্রবর্তন করে:

PBE কী ব্যবহার করার সময়, যদি বাউন্সি ক্যাসল একটি ইনিশিয়ালাইজেশন ভেক্টর (IV) আশা করে এবং আপনার অ্যাপ একটি সরবরাহ না করে, আপনি একটি সতর্কতা পাবেন।
ARC4 সাইফারের কনস্ক্রিপ্ট বাস্তবায়ন আপনাকে ARC4/ECB/NoPadding অথবা ARC4/NONE/NoPadding উল্লেখ করতে দেয়।
ক্রিপ্টো জাভা ক্রিপ্টোগ্রাফি আর্কিটেকচার (JCA) প্রদানকারীকে সরানো হয়েছে। ফলস্বরূপ, যদি আপনার অ্যাপ SecureRandom.getInstance("SHA1PRNG", "Crypto") কল করে, তাহলে একটি NoSuchProviderException ঘটে।
যদি আপনার অ্যাপ কী কাঠামোর চেয়ে বড় বাফার থেকে RSA কীগুলিকে পার্স করে, তাহলে একটি ব্যতিক্রম আর ঘটবে না।

অ্যান্ড্রয়েডের ক্রিপ্টোগ্রাফিক ক্ষমতা ব্যবহার সম্পর্কে আরও জানতে, ক্রিপ্টোগ্রাফি দেখুন।

অ্যান্ড্রয়েড সুরক্ষিত এনক্রিপ্ট করা ফাইল আর সমর্থিত নয়

অ্যান্ড্রয়েড 9 সম্পূর্ণরূপে অ্যান্ড্রয়েড সুরক্ষিত এনক্রিপ্টেড ফাইল (ASECs) এর জন্য সমর্থন সরিয়ে দেয়।

অ্যান্ড্রয়েড 2.2 (এপিআই লেভেল 8) এ, অ্যান্ড্রয়েড অ্যাপ-অন-এসডি-কার্ড কার্যকারিতা সমর্থন করার জন্য ASEC চালু করেছে। অ্যান্ড্রয়েড 6.0 (এপিআই লেভেল 23) এ, প্ল্যাটফর্মটি একটি গ্রহণযোগ্য স্টোরেজ ডিভাইস প্রযুক্তি চালু করেছে যা ডেভেলপাররা ASEC-এর জায়গায় ব্যবহার করতে পারে।

আইসিইউ লাইব্রেরিতে আপডেট

Android 9 ICU লাইব্রেরির সংস্করণ 60 ব্যবহার করে। Android 8.0 (API লেভেল 26) এবং Android 8.1 (API লেভেল 27) ICU 58 ব্যবহার করে।

ICU android.icu package নীচে সর্বজনীন API প্রদান করতে ব্যবহৃত হয় এবং আন্তর্জাতিকীকরণ সমর্থনের জন্য অ্যান্ড্রয়েড প্ল্যাটফর্মে অভ্যন্তরীণভাবে ব্যবহৃত হয়। উদাহরণস্বরূপ, এটি java.util , java.text , এবং android.text.format এ Android ক্লাস বাস্তবায়ন করতে ব্যবহৃত হয়।

ICU 60-এর আপডেটে অনেক ছোট কিন্তু দরকারী পরিবর্তন রয়েছে, যার মধ্যে রয়েছে ইমোজি 5.0 ডেটা সমর্থন এবং উন্নত তারিখ/সময় ফর্ম্যাটগুলি, যেমনটি ICU 59 এবং ICU 60 রিলিজ নোটগুলিতে নথিভুক্ত করা হয়েছে।

এই আপডেটে উল্লেখযোগ্য পরিবর্তন:

প্ল্যাটফর্ম যেভাবে সময় অঞ্চল পরিচালনা করে তা পরিবর্তিত হয়েছে।
- প্ল্যাটফর্মটি GMT এবং UTC ভালভাবে পরিচালনা করে; UTC আর GMT এর প্রতিশব্দ নয়।
  ICU এখন GMT এবং UTC এর জন্য অনুবাদ করা অঞ্চলের নাম প্রদান করে। এই পরিবর্তনটি "GMT", "Etc/GMT", "UTC", "Etc/UTC", এবং "Zulu" এর মতো জোনের জন্য android.icu ফর্ম্যাটিং এবং পার্সিং আচরণকে প্রভাবিত করে।
- java.text.SimpleDateFormat এখন UTC/GMT এর জন্য প্রদর্শন নাম প্রদান করতে ICU ব্যবহার করে, যার অর্থ:
  - zzzz ফরম্যাটিং অনেক লোকেলের জন্য একটি দীর্ঘ স্থানীয় স্ট্রিং তৈরি করে। পূর্বে, এটি UTC এর জন্য "UTC" এবং GMT এর জন্য "GMT+00:00" এর মত স্ট্রিং তৈরি করত।
  - পার্সিং zzzz "ইউনিভার্সাল কোঅর্ডিনেটেড টাইম" এবং "গ্রিনউইচ মিন টাইম" এর মতো স্ট্রিংকে স্বীকৃতি দেয়।
  - অ্যাপগুলি সামঞ্জস্যতার সমস্যার সম্মুখীন হতে পারে যদি তারা ধরে নেয় যে "UTC" বা "GMT+00:00" সব ভাষায় zzzz এর জন্য আউটপুট।
- java.text.DateFormatSymbols.getZoneStrings() এর আচরণ পরিবর্তিত হয়েছে:
  - SimpleDateFormat এর মতো, UTC এবং GMT-এর এখন দীর্ঘ নাম রয়েছে। UTC জোনের জন্য টাইম জোনের নামের DST ভেরিয়েন্ট, যেমন "UTC", "Etc/UTC", এবং "Zulu", GMT+00:00 হয়ে যায়, যা কোন নাম পাওয়া না গেলে আদর্শ ফলব্যাক হয়, এর পরিবর্তে হার্ড কোডেড স্ট্রিং UTC ।
  - কিছু জোন আইডি সঠিকভাবে অন্যান্য জোনের প্রতিশব্দ হিসাবে স্বীকৃত হয়, যাতে অ্যান্ড্রয়েড প্রাচীন জোন আইডিগুলির জন্য স্ট্রিং খুঁজে পায়, যেমন Eire , যা আগে সমাধান করা যায়নি।
- এশিয়া/হ্যানয় আর স্বীকৃত অঞ্চল নয়। এই কারণে java.util.TimeZones.getAvailableIds() এই মানটি ফেরত দেয় না এবং java.util.TimeZone.getTimeZone() এটি চিনতে পারে না। এই আচরণটি বিদ্যমান android.icu আচরণের সাথে সামঞ্জস্যপূর্ণ।
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) পদ্ধতিটি বৈধ মুদ্রার পাঠ্য পার্স করার সময়ও একটি ParseException ফেলতে পারে। PLURALCURRENCYSTYLE স্টাইল মুদ্রা পাঠ্যের জন্য Android 7.0 (API স্তর 24) থেকে উপলব্ধ NumberFormat.parseCurrency ব্যবহার করে এই সমস্যাটি এড়িয়ে চলুন।

অ্যান্ড্রয়েড টেস্ট পরিবর্তন

অ্যান্ড্রয়েড 9 অ্যান্ড্রয়েড টেস্ট ফ্রেমওয়ার্কের লাইব্রেরি এবং ক্লাস কাঠামোতে বেশ কিছু পরিবর্তন এনেছে। এই পরিবর্তনগুলি বিকাশকারীদের ফ্রেমওয়ার্ক-সমর্থিত, পাবলিক API ব্যবহার করতে সহায়তা করে, তবে পরিবর্তনগুলি তৃতীয় পক্ষের লাইব্রেরি বা কাস্টম লজিক ব্যবহার করে পরীক্ষা তৈরি এবং চালানোর ক্ষেত্রে আরও নমনীয়তার অনুমতি দেয়।

লাইব্রেরিগুলি ফ্রেমওয়ার্ক থেকে সরানো হয়েছে

Android 9 JUnit-ভিত্তিক ক্লাসগুলিকে তিনটি লাইব্রেরিতে পুনর্গঠিত করে: android.test.base , android.test.runner এবং android.test.mock । এই পরিবর্তনটি আপনাকে JUnit এর একটি সংস্করণের বিরুদ্ধে পরীক্ষা চালানোর অনুমতি দেয় যা আপনার প্রকল্পের নির্ভরতাগুলির সাথে সবচেয়ে ভাল কাজ করে। JUnit-এর এই সংস্করণটি android.jar প্রদান করে তার থেকে ভিন্ন হতে পারে।

এই লাইব্রেরিতে JUnit-ভিত্তিক ক্লাসগুলি কীভাবে সংগঠিত হয়, সেইসাথে কীভাবে আপনার অ্যাপের প্রজেক্ট লেখার এবং পরীক্ষা চালানোর জন্য প্রস্তুত করা যায় সে সম্পর্কে আরও জানতে, Android টেস্টের জন্য সেট আপ প্রজেক্ট দেখুন।

টেস্ট স্যুট বিল্ড পরিবর্তন

TestSuiteBuilder ক্লাসের addRequirements() পদ্ধতিটি সরানো হয়েছে, এবং TestSuiteBuilder ক্লাসটি নিজেই বাতিল করা হয়েছে। addRequirements() পদ্ধতির জন্য ডেভেলপারদের আর্গুমেন্ট সরবরাহ করার প্রয়োজন ছিল যার প্রকারগুলি লুকানো APIs, যা APIকে অবৈধ করে তোলে।

জাভা ইউটিএফ ডিকোডার

UTF-8 অ্যান্ড্রয়েডের ডিফল্ট অক্ষর সেট। একটি UTF-8 বাইট ক্রম একটি String কনস্ট্রাক্টর দ্বারা ডিকোড করা যেতে পারে, যেমন String(byte[] bytes) ।

অ্যান্ড্রয়েড 9-এ UTF-8 ডিকোডার পূর্ববর্তী সংস্করণগুলির তুলনায় আরও কঠোরভাবে ইউনিকোড মান অনুসরণ করে। পরিবর্তনগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

UTF-8-এর অ-সংক্ষিপ্ত রূপ, যেমন <C0, AF> ,কে অসুস্থ বলে ধরা হয়।
UTF-8-এর সারোগেট ফর্ম, যেমন U+D800 .. U+DFFF ,কে অসুস্থ বলে ধরা হয়।
সর্বাধিক সাবপার্ট একটি একক U+FFFD দ্বারা প্রতিস্থাপিত হয়। উদাহরণস্বরূপ, বাইট সিকোয়েন্সে " 41 C0 AF 41 F4 80 80 41 ," সর্বাধিক সাবপার্টগুলি হল " C0 ," " AF ," এবং " F4 80 80 " " F4 80 80 " হতে পারে " F4 80 80 80 " এর প্রাথমিক অনুসৃতি, কিন্তু " C0 " কোনো সুগঠিত কোড ইউনিট ক্রম-এর প্রাথমিক পরবর্তি হতে পারে না। সুতরাং, আউটপুট হওয়া উচিত " A\ufffd\ufffdA\ufffdA ।"
একটি পরিবর্তিত UTF-8 / CESU-8 সিকোয়েন্সকে Android 9 বা উচ্চতর ডিকোড করতে, DataInputStream.readUTF() পদ্ধতি বা NewStringUTF() JNI পদ্ধতি ব্যবহার করুন৷

একটি শংসাপত্র ব্যবহার করে হোস্টনাম যাচাইকরণ

RFC 2818 একটি শংসাপত্রের বিপরীতে একটি ডোমেন নামের সাথে মিল করার দুটি পদ্ধতি বর্ণনা করে- subjectAltName ( SAN ) এক্সটেনশনের মধ্যে উপলব্ধ নামগুলি ব্যবহার করে, অথবা একটি SAN এক্সটেনশনের অনুপস্থিতিতে, commonName ( CN ) এ ফিরে আসা৷

যাইহোক, CN এ ফলব্যাক RFC 2818-এ অবচয় করা হয়েছিল। এই কারণে, Android আর CN ব্যবহারে পিছিয়ে নেই। একটি হোস্টনাম যাচাই করতে, সার্ভারকে অবশ্যই একটি মিলিত SAN সহ একটি শংসাপত্র উপস্থাপন করতে হবে৷ হোস্টনামের সাথে মেলে এমন একটি SAN ধারণ করে না এমন শংসাপত্রগুলি আর বিশ্বস্ত নয়৷

নেটওয়ার্ক ঠিকানা লুকআপ নেটওয়ার্ক লঙ্ঘনের কারণ হতে পারে

নেটওয়ার্ক ঠিকানা লুকআপের জন্য নাম রেজোলিউশন প্রয়োজন নেটওয়ার্ক I/O জড়িত হতে পারে এবং তাই ব্লকিং অপারেশন হিসাবে বিবেচিত হয়। প্রধান থ্রেডে ক্রিয়াকলাপগুলিকে অবরুদ্ধ করার ফলে বিরতি বা জ্যাঙ্ক হতে পারে।

StrictMode ক্লাস একটি ডেভেলপমেন্ট টুল যা ডেভেলপারদের তাদের কোডে সমস্যা সনাক্ত করতে সাহায্য করে।

Android 9 এবং উচ্চতর সংস্করণে, StrictMode নেটওয়ার্ক ঠিকানা লুকআপের কারণে সৃষ্ট নেটওয়ার্ক লঙ্ঘন শনাক্ত করে যার নাম রেজোলিউশন প্রয়োজন।

StrictMode সক্ষম করে আপনার অ্যাপস পাঠানো উচিত নয়। আপনি যদি তা করেন, তাহলে নেটওয়ার্ক লঙ্ঘন সনাক্ত করে এমন একটি নীতি পেতে detectNetwork() বা detectAll() পদ্ধতি ব্যবহার করার সময় আপনার অ্যাপগুলি ব্যতিক্রমগুলি অনুভব করতে পারে, যেমন NetworkOnMainThreadException ।

একটি সংখ্যাসূচক আইপি ঠিকানা সমাধান করা একটি ব্লকিং অপারেশন হিসাবে বিবেচিত হয় না৷ সাংখ্যিক আইপি ঠিকানার রেজোলিউশন Android 9 এর আগের সংস্করণগুলির মতোই কাজ করে।

সকেট ট্যাগিং

অ্যান্ড্রয়েড 9-এর চেয়ে কম প্ল্যাটফর্ম সংস্করণে, যদি setThreadStatsTag() পদ্ধতি ব্যবহার করে একটি সকেট ট্যাগ করা হয়, তাহলে সকেটটি যখন একটি ParcelFileDescriptor কন্টেইনার সহ বাইন্ডার আইপিসি ব্যবহার করে অন্য প্রক্রিয়ায় পাঠানো হয় তখন সেটিকে ট্যাগমুক্ত করা হয়।

অ্যান্ড্রয়েড 9 এবং উচ্চতর, সকেট ট্যাগটি রাখা হয় যখন এটি বাইন্ডার আইপিসি ব্যবহার করে অন্য প্রক্রিয়ায় পাঠানো হয়। এই পরিবর্তন নেটওয়ার্ক ট্রাফিক পরিসংখ্যানকে প্রভাবিত করতে পারে, উদাহরণস্বরূপ, যখন queryDetailsForUidTag() পদ্ধতি ব্যবহার করা হয়।

আপনি যদি পূর্ববর্তী সংস্করণগুলির আচরণ বজায় রাখতে চান, যা অন্য একটি প্রক্রিয়ায় পাঠানো একটি সকেটকে আনট্যাগ করে, আপনি সকেটটি পাঠানোর আগে untagSocket() কল করতে পারেন।

সকেটে উপলব্ধ বাইটের পরিমাণ রিপোর্ট করা হয়েছে

available() পদ্ধতিটি 0 প্রদান করে যখন এটি shutdownInput() পদ্ধতি চালু করার পরে কল করা হয়।

VPN-এর জন্য আরও বিস্তারিত নেটওয়ার্ক ক্ষমতা রিপোর্টিং

অ্যান্ড্রয়েড 8.1 (API স্তর 27) এবং নিম্নতর, NetworkCapabilities শ্রেণী শুধুমাত্র VPN-এর জন্য তথ্যের একটি সীমিত সেট রিপোর্ট করেছে, যেমন TRANSPORT_VPN , কিন্তু NET_CAPABILITY_NOT_VPN বাদ দিয়ে। এই সীমিত তথ্যটি একটি VPN ব্যবহার করার ফলে অ্যাপের ব্যবহারকারীকে চার্জ করা হবে কিনা তা নির্ধারণ করা কঠিন করে তুলেছে। উদাহরণস্বরূপ, NET_CAPABILITY_NOT_METERED চেক করলে অন্তর্নিহিত নেটওয়ার্কগুলি মিটার করা হয়েছে কিনা তা নির্ধারণ করবে না৷

Android 9 এবং পরবর্তীতে, যখন একটি VPN setUnderlyingNetworks() পদ্ধতিতে কল করে, তখন অ্যান্ড্রয়েড সিস্টেম যেকোন অন্তর্নিহিত নেটওয়ার্কগুলির পরিবহন এবং ক্ষমতাগুলিকে একত্রিত করে এবং ফলাফলটিকে VPN নেটওয়ার্কের কার্যকরী নেটওয়ার্ক ক্ষমতা হিসাবে প্রদান করে৷

Android 9 এবং উচ্চতর সংস্করণে, যে অ্যাপগুলি ইতিমধ্যে NET_CAPABILITY_NOT_METERED চেক করে তারা VPN এবং অন্তর্নিহিত নেটওয়ার্কগুলির নেটওয়ার্ক ক্ষমতাগুলি গ্রহণ করে৷

xt_qtaguid ফোল্ডারে থাকা ফাইলগুলি আর অ্যাপগুলিতে উপলব্ধ নেই৷

Android 9 থেকে শুরু করে, অ্যাপগুলিকে /proc/net/xt_qtaguid ফোল্ডারে ফাইলগুলিতে সরাসরি পড়ার অ্যাক্সেসের অনুমতি দেওয়া হয় না। কারণ হল কিছু ডিভাইসের সাথে সামঞ্জস্য নিশ্চিত করা যাতে এই ফাইলগুলি একেবারেই নেই।

সার্বজনিক API যেগুলি এই ফাইলগুলির উপর নির্ভর করে, TrafficStats এবং NetworkStatsManager , উদ্দেশ্য অনুযায়ী কাজ করতে থাকে। যাইহোক, অসমর্থিত cutils ফাংশন, যেমন qtaguid_tagSocket() , বিভিন্ন ডিভাইসে প্রত্যাশিতভাবে কাজ নাও করতে পারে।

FLAG_ACTIVITY_NEW_TASK প্রয়োজনীয়তা এখন প্রয়োগ করা হয়েছে৷

অ্যান্ড্রয়েড 9 এর সাথে, আপনি ফ্ল্যাগ ফ্ল্যাগ FLAG_ACTIVITY_NEW_TASK পাস না করা পর্যন্ত আপনি একটি অ-অ্যাক্টিভিটি প্রসঙ্গ থেকে একটি কার্যকলাপ শুরু করতে পারবেন না। আপনি যদি এই পতাকাটি পাস না করে একটি কার্যকলাপ শুরু করার চেষ্টা করেন, কার্যকলাপটি শুরু হয় না এবং সিস্টেম লগটিতে একটি বার্তা প্রিন্ট করে।

পর্দা ঘূর্ণন পরিবর্তন

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

যখন ডিভাইসটি ঘূর্ণন লক মোডে থাকে, ব্যবহারকারীরা তাদের স্ক্রীনটিকে উপরের, দৃশ্যমান কার্যকলাপ দ্বারা সমর্থিত যেকোনো ঘূর্ণনে লক করতে পারে। একটি ক্রিয়াকলাপ অনুমান করা উচিত নয় যে এটি সর্বদা প্রতিকৃতিতে রেন্ডার করা হবে৷ যদি শীর্ষ ক্রিয়াকলাপগুলি স্বয়ংক্রিয়-ঘূর্ণন মোডে একাধিক ঘূর্ণনে রেন্ডার করা যায়, তবে একই বিকল্পগুলি রোটেশন লক মোডে উপলব্ধ হওয়া উচিত, কিছু ব্যতিক্রম ক্রিয়াকলাপের screenOrientation সেটিং এর উপর ভিত্তি করে (নীচের টেবিলটি দেখুন)।

যে ক্রিয়াকলাপগুলি একটি নির্দিষ্ট ওরিয়েন্টেশনের জন্য অনুরোধ করে (উদাহরণস্বরূপ, screenOrientation=landscape ) ব্যবহারকারীর লক পছন্দকে উপেক্ষা করে এবং Android 8.0 এর মতোই আচরণ করে৷

স্ক্রীন ওরিয়েন্টেশন পছন্দটি Android ম্যানিফেস্টে কার্যকলাপ স্তরে বা setRequestedOrientation() এর সাথে প্রোগ্রাম্যাটিকভাবে সেট করা যেতে পারে।

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

ব্যবহারকারী যখন একটি ঘূর্ণন পরামর্শ গ্রহণ করে তখন ঘূর্ণন পছন্দ প্রস্তাবনায় পরিবর্তিত হয়।
যখন ব্যবহারকারী একটি জোরপূর্বক পোর্ট্রেট অ্যাপে (লক স্ক্রীন বা লঞ্চার সহ) স্যুইচ করে তখন ঘূর্ণন পছন্দটি প্রতিকৃতিতে পরিবর্তিত হয়৷

নিম্নোক্ত সারণীটি সাধারণ পর্দার অভিযোজনের জন্য ঘূর্ণন আচরণের সংক্ষিপ্ত বিবরণ দেয়:

স্ক্রিন ওরিয়েন্টেশন	আচরণ
অনির্দিষ্ট, ব্যবহারকারী	স্বয়ংক্রিয়-ঘোরান এবং ঘূর্ণন লক-এ কার্যকলাপ প্রতিকৃতি বা ল্যান্ডস্কেপে (এবং বিপরীত) রেন্ডার করা যেতে পারে। পোর্ট্রেট এবং ল্যান্ডস্কেপ লেআউট উভয়ই সমর্থন করার প্রত্যাশা করুন।
ব্যবহারকারীর ল্যান্ডস্কেপ	অটো-রোটেট এবং রোটেশন লক-এ অ্যাক্টিভিটি ল্যান্ডস্কেপ বা রিভার্স ল্যান্ডস্কেপে রেন্ডার করা যেতে পারে। শুধুমাত্র ল্যান্ডস্কেপ লেআউট সমর্থন আশা.
ব্যবহারকারীর প্রতিকৃতি	স্বয়ংক্রিয়-ঘূর্ণন এবং ঘূর্ণন লক-এ কার্যকলাপ পোর্ট্রেট বা বিপরীত প্রতিকৃতিতে রেন্ডার করা যেতে পারে। শুধুমাত্র প্রতিকৃতি লেআউট সমর্থন আশা.
সম্পূর্ণ ব্যবহারকারী	স্বয়ংক্রিয়-ঘোরান এবং ঘূর্ণন লক-এ কার্যকলাপ প্রতিকৃতি বা ল্যান্ডস্কেপে (এবং বিপরীত) রেন্ডার করা যেতে পারে। পোর্ট্রেট এবং ল্যান্ডস্কেপ লেআউট উভয়ই সমর্থন করার প্রত্যাশা করুন। ঘূর্ণন লক ব্যবহারকারীদের বিপরীত প্রতিকৃতিতে লক করার বিকল্প দেওয়া হবে, প্রায়শই 180º।
সেন্সর, ফুল সেন্সর, সেন্সর পোর্ট্রেট, সেন্সর ল্যান্ডস্কেপ	ঘূর্ণন লক মোড পছন্দ উপেক্ষা করা হয় এবং স্বয়ংক্রিয় ঘূর্ণন সক্রিয় হিসাবে বিবেচনা করা হয়। খুব সতর্ক UX বিবেচনার সাথে শুধুমাত্র ব্যতিক্রমী পরিস্থিতিতে এটি ব্যবহার করুন।

Apache HTTP ক্লায়েন্ট অবচয় অ-মানক ClassLoader সহ অ্যাপগুলিকে প্রভাবিত করে৷

Android 6.0 এর সাথে, আমরা Apache HTTP ক্লায়েন্টের জন্য সমর্থন সরিয়ে দিয়েছি । এই পরিবর্তনটি Android 9 বা উচ্চতরকে লক্ষ্য করে না এমন বেশিরভাগ অ্যাপের উপর কোন প্রভাব ফেলবে না। যাইহোক, পরিবর্তনটি এমন কিছু অ্যাপকে প্রভাবিত করতে পারে যেগুলি একটি নন-স্ট্যান্ডার্ড ClassLoader কাঠামো ব্যবহার করে, এমনকি যদি অ্যাপগুলি Android 9 বা উচ্চতরকে লক্ষ্য না করে।

একটি অ্যাপ প্রভাবিত হতে পারে যদি এটি একটি অ-মানক ClassLoader ব্যবহার করে যা স্পষ্টভাবে ClassLoader সিস্টেমে অর্পণ করে। org.apache.http.* এ ক্লাস খোঁজার সময় এই অ্যাপগুলির পরিবর্তে ClassLoader অ্যাপে অর্পণ করতে হবে। যদি তারা ClassLoader সিস্টেমে অর্পণ করে, তবে অ্যাপগুলি NoClassDefFoundError সহ Android 9 বা উচ্চতর সংস্করণে ব্যর্থ হবে, কারণ সেই ক্লাসগুলি ClassLoader সিস্টেমে আর পরিচিত নয়৷ ভবিষ্যতে অনুরূপ সমস্যা প্রতিরোধ করার জন্য, অ্যাপগুলিকে ClassLoader সরাসরি সিস্টেম অ্যাক্সেস করার পরিবর্তে ClassLoader অ্যাপের মাধ্যমে ক্লাস লোড করা উচিত।

গণনা করা ক্যামেরা

Android 9 ডিভাইসে চলমান অ্যাপগুলি getCameraIdList() কল করে প্রতিটি উপলব্ধ ক্যামেরা আবিষ্কার করতে পারে৷ একটি অ্যাপের অনুমান করা উচিত নয় যে ডিভাইসটিতে শুধুমাত্র একটি একক ব্যাক ক্যামেরা বা শুধুমাত্র একটি একক ফ্রন্ট ক্যামেরা রয়েছে৷

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

শক্তি ব্যবস্থাপনা

বিস্তারিত জানার জন্য, পাওয়ার ম্যানেজমেন্ট দেখুন।

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

পটভূমিতে সেন্সরগুলিতে সীমিত অ্যাক্সেস

আপনার অ্যাপ মাইক্রোফোন বা ক্যামেরা অ্যাক্সেস করতে পারে না।
যে সেন্সরগুলি অবিচ্ছিন্ন রিপোর্টিং মোড ব্যবহার করে, যেমন অ্যাক্সিলোমিটার এবং জাইরোস্কোপ, ইভেন্টগুলি গ্রহণ করে না৷
অন-চেঞ্জ বা এক-শট রিপোর্টিং মোড ব্যবহার করে এমন সেন্সরগুলি ইভেন্টগুলি গ্রহণ করে না।

কল লগগুলিতে সীমাবদ্ধ অ্যাক্সেস

ফোন নম্বরগুলিতে সীমাবদ্ধ অ্যাক্সেস

PHONE_STATE ইন্টেন্ট অ্যাকশন থেকে নম্বরগুলি পড়ার জন্য, আপনার READ_CALL_LOG অনুমতি এবং READ_PHONE_STATE অনুমতি উভয়ই প্রয়োজন৷
onCallStateChanged() থেকে নম্বরগুলি পড়তে, আপনার শুধুমাত্র READ_CALL_LOG অনুমতি প্রয়োজন৷ আপনার READ_PHONE_STATE অনুমতির প্রয়োজন নেই৷

Wi-Fi অবস্থান এবং সংযোগ তথ্যে সীমাবদ্ধ অ্যাক্সেস

ACCESS_FINE_LOCATION বা ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE

Wi-Fi পরিষেবা পদ্ধতি থেকে তথ্য সরানো হয়েছে৷

WifiManager থেকে getScanResults() এবং getConnectionInfo() পদ্ধতি।
WifiP2pManager থেকে discoverServices() এবং addServiceRequest() পদ্ধতি।
NETWORK_STATE_CHANGED_ACTION সম্প্রচার।

টেলিফোনি তথ্য এখন ডিভাইস অবস্থান সেটিং উপর নির্ভর করে

নন-SDK ইন্টারফেস ব্যবহারের উপর বিধিনিষেধ

নিরাপত্তা আচরণ পরিবর্তন

ডিভাইসের নিরাপত্তা পরিবর্তন

TLS বাস্তবায়ন পরিবর্তন

সিস্টেমের TLS বাস্তবায়ন অ্যান্ড্রয়েড 9-এ বেশ কিছু পরিবর্তন করেছে:

SSLSocket এর একটি উদাহরণ তৈরি হওয়ার সময় সংযোগ করতে ব্যর্থ হলে, সিস্টেমটি NullPointerException এর পরিবর্তে একটি IOException নিক্ষেপ করে।
SSLEngine ক্লাস পরিচ্ছন্নভাবে যে কোনো close_notify সতর্কতাগুলি পরিচালনা করে।

কঠোর SECOMP ফিল্টার

ক্রিপ্টোগ্রাফিক পরিবর্তন

পরামিতি এবং অ্যালগরিদমের কনস্ক্রিপ্ট বাস্তবায়ন

অন্যান্য পরিবর্তন

PBE কী ব্যবহার করার সময়, যদি বাউন্সি ক্যাসল একটি ইনিশিয়ালাইজেশন ভেক্টর (IV) আশা করে এবং আপনার অ্যাপ একটি সরবরাহ না করে, আপনি একটি সতর্কতা পাবেন।
ARC4 সাইফারের কনস্ক্রিপ্ট বাস্তবায়ন আপনাকে ARC4/ECB/NoPadding অথবা ARC4/NONE/NoPadding উল্লেখ করতে দেয়।
ক্রিপ্টো জাভা ক্রিপ্টোগ্রাফি আর্কিটেকচার (JCA) প্রদানকারীকে সরানো হয়েছে। ফলস্বরূপ, যদি আপনার অ্যাপ SecureRandom.getInstance("SHA1PRNG", "Crypto") কল করে, তাহলে একটি NoSuchProviderException ঘটে।
যদি আপনার অ্যাপ কী কাঠামোর চেয়ে বড় বাফার থেকে RSA কীগুলিকে পার্স করে, তাহলে একটি ব্যতিক্রম আর ঘটবে না।

অ্যান্ড্রয়েড সুরক্ষিত এনক্রিপ্ট করা ফাইল আর সমর্থিত নয়

আইসিইউ লাইব্রেরিতে আপডেট

এই আপডেটে উল্লেখযোগ্য পরিবর্তন:

প্ল্যাটফর্ম যেভাবে সময় অঞ্চল পরিচালনা করে তা পরিবর্তিত হয়েছে।
- প্ল্যাটফর্মটি GMT এবং UTC ভালভাবে পরিচালনা করে; ইউটিসি আর জিএমটি -র প্রতিশব্দ নয়।
  আইসিইউ এখন জিএমটি এবং ইউটিসির জন্য অনুবাদ জোনের নাম সরবরাহ করে। এই পরিবর্তনটি "জিএমটি", "ইত্যাদি/জিএমটি", "ইউটিসি", "ইত্যাদি/ইউটিসি", এবং "জুলু" এর মতো অঞ্চলগুলির জন্য android.icu ফর্ম্যাটিং এবং পার্সিং আচরণকে প্রভাবিত করে।
- java.text.SimpleDateFormat এখন ইউটিসি /জিএমটি -র জন্য প্রদর্শনের নাম সরবরাহ করতে আইসিইউ ব্যবহার করে, যার অর্থ:
  - ফর্ম্যাটিং zzzz অনেক লোকালগুলির জন্য একটি দীর্ঘ স্থানীয়করণ স্ট্রিং উত্পন্ন করে। পূর্বে, এটি ইউটিসির জন্য "ইউটিসি" এবং জিএমটি -র জন্য "GMT+00: 00" এর মতো স্ট্রিং তৈরি করেছিল।
  - zzzz পার্সিং "ইউনিভার্সাল সমন্বিত সময়" এবং "গ্রিনউইচ মিন টাইম" এর মতো স্ট্রিংগুলি স্বীকৃতি দেয়।
  - অ্যাপ্লিকেশনগুলি সামঞ্জস্যতার সমস্যার মুখোমুখি হতে পারে যদি তারা ধরে নেয় যে "ইউটিসি" বা "জিএমটি+00: 00" সমস্ত ভাষায় zzzz আউটপুট।
- java.text.DateFormatSymbols.getZoneStrings() এর আচরণ পরিবর্তন হয়েছে:
  - SimpleDateFormat মতো, ইউটিসি এবং জিএমটি এখন দীর্ঘ নাম রয়েছে। ইউটিসি জোনের জন্য টাইম জোনের নামগুলির ডিএসটি রূপগুলি যেমন "ইউটিসি", "ইত্যাদি/ইউটিসি", এবং "জুলু", জিএমটি+00: 00 হয়ে যায়, এটি যখন স্ট্যান্ডার্ড ফ্যালব্যাক হয় যখন কোনও নাম পাওয়া যায় না, বরং কোনও নাম পাওয়া যায় না, বরং কোনও নাম নেই, বরং কোনও নাম নেই, হার্ড-কোডেড স্ট্রিং UTC ।
  - কিছু জোন আইডিগুলি অন্যান্য অঞ্চলগুলির প্রতিশব্দ হিসাবে সঠিকভাবে স্বীকৃত, যাতে অ্যান্ড্রয়েডটি প্রত্নতাত্ত্বিক জোন আইডিগুলির জন্য যেমন স্ট্রিংগুলি খুঁজে পায়, যেমন Eire , যা পূর্বে সমাধান করা যায়নি।
- এশিয়া/হ্যানয় আর স্বীকৃত অঞ্চল নয়। এই কারণে java.util.TimeZones.getAvailableIds() এই মানটি ফেরত দেয় না, এবং java.util.TimeZone.getTimeZone() এটি স্বীকৃতি দেয় না। এই আচরণটি বিদ্যমান android.icu আচরণের সাথে সামঞ্জস্যপূর্ণ।
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) পদ্ধতি বৈধ মুদ্রার পাঠ্যকে পার্স করার পরেও ParseException নিক্ষেপ করতে পারে। PLURALCURRENCYSTYLE স্টাইল -স্টাইল মুদ্রা পাঠ্যের জন্য অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) থেকে উপলভ্য NumberFormat.parseCurrency ব্যবহার করে এই সমস্যাটি এড়িয়ে চলুন।

অ্যান্ড্রয়েড পরীক্ষা পরিবর্তন

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

কাঠামো থেকে গ্রন্থাগার সরানো হয়েছে

অ্যান্ড্রয়েড 9 জুনিত-ভিত্তিক ক্লাসগুলিকে তিনটি লাইব্রেরিতে পুনর্গঠন করে: android.test.base , android.test.runner , এবং android.test.mock । এই পরিবর্তনটি আপনাকে জুনিতের একটি সংস্করণের বিরুদ্ধে পরীক্ষা চালানোর অনুমতি দেয় যা আপনার প্রকল্পের নির্ভরতার সাথে সবচেয়ে ভাল কাজ করে। জুনিতের এই সংস্করণটি android.jar সরবরাহের চেয়ে আলাদা হতে পারে।

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

পরীক্ষা স্যুট বিল্ড পরিবর্তন

TestSuiteBuilder শ্রেণিতে addRequirements() পদ্ধতিটি সরানো হয়েছে, এবং TestSuiteBuilder শ্রেণি নিজেই অবমূল্যায়ন করা হয়েছে। addRequirements() পদ্ধতিতে বিকাশকারীদের এমন যুক্তি সরবরাহ করার প্রয়োজন ছিল যার প্রকারগুলি লুকানো এপিআই রয়েছে, এপিআইকে অবৈধ করে তোলে।

জাভা ইউটিএফ ডিকোডার

ইউটিএফ -8 হ'ল অ্যান্ড্রয়েডের ডিফল্ট চরসেট। একটি ইউটিএফ -8 বাইট সিকোয়েন্সটি String কনস্ট্রাক্টর দ্বারা ডিকোড করা যেতে পারে, যেমন String(byte[] bytes) ।

অ্যান্ড্রয়েড 9 এর ইউটিএফ -8 ডিকোডার পূর্ববর্তী সংস্করণগুলির তুলনায় ইউনিকোড মানগুলি আরও কঠোরভাবে অনুসরণ করে। পরিবর্তনগুলির মধ্যে নিম্নলিখিতগুলি অন্তর্ভুক্ত রয়েছে:

<C0, AF> এর মতো ইউটিএফ -8 এর অ-অস্টেস্ট ফর্মটিকে অসুস্থ-গঠিত হিসাবে বিবেচনা করা হয়।
ইউটিএফ -8 এর সারোগেট ফর্ম, যেমন U+D800 .. U+DFFF , এটি খারাপ-গঠিত হিসাবে বিবেচিত হয়।
সর্বাধিক সাবপার্টটি একক U+FFFD দ্বারা প্রতিস্থাপিত হয়। উদাহরণস্বরূপ, বাইট সিকোয়েন্সে " 41 C0 AF 41 F4 80 80 41 ," সর্বাধিক উপ -বিভাগগুলি " C0 ," " AF ," এবং " F4 80 80 "। " F4 80 80 " " F4 80 80 80 " এর প্রাথমিক অনুপাত হতে পারে তবে " C0 " কোনও ভাল-গঠিত কোড ইউনিট অনুক্রমের প্রাথমিক অনুপাত হতে পারে না। সুতরাং, আউটপুটটি " A\ufffd\ufffdA\ufffdA হওয়া উচিত।"
অ্যান্ড্রয়েড 9 বা উচ্চতর একটি পরিবর্তিত ইউটিএফ -8 / সিইএসইউ -8 সিকোয়েন্সটি ডিকোড করার জন্য, DataInputStream.readUTF() পদ্ধতি বা NewStringUTF() জেএনআই পদ্ধতিটি ব্যবহার করুন।

একটি শংসাপত্র ব্যবহার করে হোস্টনাম যাচাইকরণ

আরএফসি 2818 একটি শংসাপত্রের বিপরীতে একটি ডোমেন নামের সাথে মেলে দুটি পদ্ধতি বর্ণনা করে - subjectAltName ( SAN ) এক্সটেনশনের মধ্যে উপলব্ধ নামগুলি ব্যবহার করে বা SAN এক্সটেনশনের অনুপস্থিতিতে, commonName ( CN ) ফিরে পড়ে।

তবে, CN -তে ফ্যালব্যাকটি আরএফসি 2818 এ অবমূল্যায়ন করা হয়েছিল। এই কারণে অ্যান্ড্রয়েড আর CN ব্যবহার করতে ফিরে আসে না। একটি হোস্টনাম যাচাই করতে, সার্ভারকে অবশ্যই একটি ম্যাচিং SAN সহ একটি শংসাপত্র উপস্থাপন করতে হবে। SAN সাথে মেলে এমন শংসাপত্রগুলিতে যে শংসাপত্রগুলি নেই তা আর বিশ্বাসযোগ্য নয়।

নেটওয়ার্ক অ্যাড্রেস লুকআপগুলি নেটওয়ার্ক লঙ্ঘনের কারণ হতে পারে

নেটওয়ার্ক অ্যাড্রেস লুকআপগুলি যা নাম রেজোলিউশনের প্রয়োজন তা নেটওয়ার্ক I/O এর সাথে জড়িত থাকতে পারে এবং তাই ব্লকিং অপারেশন হিসাবে বিবেচিত হয়। মূল থ্রেডে অপারেশনগুলি ব্লক করা বিরতি বা জ্যাঙ্কের কারণ হতে পারে।

StrictMode ক্লাস একটি উন্নয়ন সরঞ্জাম যা বিকাশকারীদের তাদের কোডের সমস্যাগুলি সনাক্ত করতে সহায়তা করে।

অ্যান্ড্রয়েড 9 এবং উচ্চতর ক্ষেত্রে, StrictMode নেটওয়ার্ক ঠিকানা অনুসন্ধানের দ্বারা সৃষ্ট নেটওয়ার্ক লঙ্ঘনগুলি সনাক্ত করে যার নাম রেজোলিউশন প্রয়োজন।

আপনার অ্যাপ্লিকেশনগুলি StrictMode সক্ষম করে পাঠানো উচিত নয়। যদি আপনি এটি করেন তবে আপনার অ্যাপ্লিকেশনগুলি ব্যতিক্রমগুলি যেমন NetworkOnMainThreadException detectNetwork() বা detectAll() পদ্ধতিগুলি ব্যবহার করার সময় নেটওয়ার্ক লঙ্ঘন সনাক্ত করে এমন একটি নীতি পেতে ব্যতিক্রমগুলি অনুভব করতে পারে।

একটি সংখ্যাসূচক আইপি ঠিকানা সমাধান করা একটি ব্লকিং অপারেশন হিসাবে বিবেচিত হয় না। সংখ্যার আইপি ঠিকানা রেজোলিউশন অ্যান্ড্রয়েড 9 এর আগে সংস্করণগুলির মতো একই কাজ করে।

সকেট ট্যাগিং

অ্যান্ড্রয়েড 9 এর চেয়ে কম প্ল্যাটফর্ম সংস্করণগুলিতে, যদি কোনও সকেট setThreadStatsTag() পদ্ধতি ব্যবহার করে ট্যাগ করা হয়, সকেটটি যখন কোনও ParcelFileDescriptor ধারক সহ বাইন্ডার আইপিসি ব্যবহার করে অন্য কোনও প্রক্রিয়াতে প্রেরণ করা হয় তখন সকেটটি অবরুদ্ধ করা হয়।

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

আপনি যদি পূর্ববর্তী সংস্করণগুলির আচরণটি ধরে রাখতে চান, যা অন্য কোনও প্রক্রিয়াতে প্রেরণ করা একটি সকেটটি আনট্যাগ করে, আপনি সকেট প্রেরণের আগে untagSocket() কল করতে পারেন।

সকেটে উপলব্ধ বাইটের পরিমাণ রিপোর্ট

available() পদ্ধতিটি 0 ফেরত দেয় যখন এটি shutdownInput() পদ্ধতিটি অনুরোধ করার পরে ডাকা হয়।

ভিপিএনগুলির জন্য আরও বিশদ নেটওয়ার্ক ক্ষমতা রিপোর্টিং

অ্যান্ড্রয়েড 8.1 (এপিআই স্তর 27) এবং লোয়ারগুলিতে, NetworkCapabilities ক্লাসটি কেবল ভিপিএনগুলির জন্য যেমন TRANSPORT_VPN , তবে NET_CAPABILITY_NOT_VPN বাদ দিয়ে একটি সীমিত তথ্যের প্রতিবেদন করেছে। এই সীমিত তথ্যটি কোনও ভিপিএন ব্যবহারের ফলে অ্যাপের ব্যবহারকারীর কাছে চার্জের ফলস্বরূপ তা নির্ধারণ করা কঠিন করে তুলেছে। উদাহরণস্বরূপ, NET_CAPABILITY_NOT_METERED পরীক্ষা করা অন্তর্নিহিত নেটওয়ার্কগুলি মিটার করা হয়েছিল কি না তা নির্ধারণ করে না।

অ্যান্ড্রয়েড 9 এবং উচ্চতর ক্ষেত্রে, যখন কোনও ভিপিএন setUnderlyingNetworks() পদ্ধতিতে কল করে, অ্যান্ড্রয়েড সিস্টেমটি কোনও অন্তর্নিহিত নেটওয়ার্কগুলির পরিবহন এবং ক্ষমতাগুলিকে একীভূত করে এবং ভিপিএন নেটওয়ার্কের কার্যকর নেটওয়ার্ক ক্ষমতা হিসাবে ফলাফলটি ফেরত দেয়।

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

Xt_qtaguid ফোল্ডারে ফাইলগুলি অ্যাপসগুলিতে আর উপলব্ধ নেই

অ্যান্ড্রয়েড 9 দিয়ে শুরু করে, অ্যাপ্লিকেশনগুলিকে /proc/net/xt_qtaguid ফোল্ডারে ফাইলগুলিতে সরাসরি পড়ার অ্যাক্সেসের অনুমতি নেই। কারণটি হ'ল এমন কিছু ডিভাইসের সাথে ধারাবাহিকতা নিশ্চিত করা যাতে এই ফাইলগুলি মোটেও নেই।

এই ফাইলগুলি, TrafficStats এবং NetworkStatsManager উপর নির্ভর করে এমন পাবলিক এপিআইগুলি উদ্দেশ্য অনুসারে কাজ চালিয়ে যায়। যাইহোক, অসমর্থিত কাটিলস ফাংশনগুলি যেমন qtaguid_tagSocket() , বিভিন্ন ডিভাইসে প্রত্যাশার মতো কাজ করতে পারে না - বা মোটেও - বা মোটেও কাজ করতে পারে।

FLAG_ACTIVITY_NEW_TASK প্রয়োজনীয়তা এখন প্রয়োগ করা হয়েছে

অ্যান্ড্রয়েড 9 এর সাথে, আপনি যদি কোনও অ-অ্যাক্টিভিটি প্রসঙ্গ থেকে কোনও ক্রিয়াকলাপ শুরু করতে পারবেন না যদি না আপনি অভিপ্রায় FLAG_ACTIVITY_NEW_TASK না পাস করেন। আপনি যদি এই পতাকাটি পাস না করে কোনও ক্রিয়াকলাপ শুরু করার চেষ্টা করেন তবে ক্রিয়াকলাপটি শুরু হয় না এবং সিস্টেমটি লগকে একটি বার্তা মুদ্রণ করে।

স্ক্রিন ঘূর্ণন পরিবর্তন

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

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

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

স্ক্রিন ওরিয়েন্টেশন পছন্দটি অ্যান্ড্রয়েড ম্যানিফেস্টে ক্রিয়াকলাপ স্তরে সেট করা যেতে পারে, বা সেট্রেকটেডোরিয়েন্টেশন () এর সাথে প্রোগ্রামিকভাবে প্রোগ্রামগতভাবে সেট করা যেতে পারে।

ঘূর্ণন লক মোডটি ব্যবহারকারী ঘূর্ণন পছন্দ সেট করে কাজ করে যা উইন্ডো ম্যানেজার ক্রিয়াকলাপের ঘূর্ণন পরিচালনা করার সময় ব্যবহার করে। নিম্নলিখিত ক্ষেত্রে ব্যবহারকারীর ঘূর্ণন পছন্দ পরিবর্তন করা যেতে পারে। নোট করুন যে ডিভাইসের প্রাকৃতিক ঘূর্ণায়মানটিতে ফিরে আসার পক্ষপাত রয়েছে, যা সাধারণত ফোন ফর্ম ফ্যাক্টর ডিভাইসের জন্য প্রতিকৃতি:

যখন ব্যবহারকারী কোনও ঘূর্ণন পরামর্শ গ্রহণ করে তখন ঘূর্ণন পছন্দটি পরামর্শের পরিবর্তিত হয়।
যখন ব্যবহারকারী কোনও জোর করে প্রতিকৃতি অ্যাপ্লিকেশনটিতে স্যুইচ করে (লক স্ক্রিন বা লঞ্চ সহ) ঘূর্ণন পছন্দটি প্রতিকৃতিতে পরিবর্তিত হয়।

নিম্নলিখিত টেবিলটি সাধারণ স্ক্রিন ওরিয়েন্টেশনগুলির জন্য ঘূর্ণন আচরণের সংক্ষিপ্তসার করে:

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

অ্যাপাচি এইচটিটিপি ক্লায়েন্টের অবমূল্যায়ন অ-মানক ক্লাসলোডার সহ অ্যাপ্লিকেশনগুলিকে প্রভাবিত করে

অ্যান্ড্রয়েড 6.0 এর সাহায্যে আমরা অ্যাপাচি এইচটিটিপি ক্লায়েন্টের জন্য সমর্থন সরিয়ে ফেলেছি । এই পরিবর্তনটি অ্যান্ড্রয়েড 9 বা তার বেশি টার্গেট করে না এমন বেশিরভাগ অ্যাপগুলিতে এই পরিবর্তনটির কোনও প্রভাব নেই। তবে, পরিবর্তনগুলি এমন কিছু অ্যাপ্লিকেশনগুলিকে প্রভাবিত করতে পারে যা একটি নন -স্ট্যান্ডার্ড ClassLoader কাঠামো ব্যবহার করে, এমনকি যদি অ্যাপ্লিকেশনগুলি অ্যান্ড্রয়েড 9 বা তার বেশি লক্ষ্য না করে।

কোনও অ্যাপ্লিকেশন প্রভাবিত হতে পারে যদি এটি কোনও অ-মানক ClassLoader ব্যবহার করে যা স্পষ্টভাবে সিস্টেম ClassLoader অর্পণ করে। org.apache.http.* এ ক্লাসগুলি সন্ধান করার সময় এই অ্যাপ্লিকেশনগুলির পরিবর্তে অ্যাপ ClassLoader অর্পণ করা দরকার। যদি তারা সিস্টেম ClassLoader অর্পণ করে তবে অ্যাপ্লিকেশনগুলি অ্যান্ড্রয়েড 9 বা উচ্চতর একটি NoClassDefFoundError দিয়ে ব্যর্থ হবে, কারণ সেই ক্লাসগুলি আর সিস্টেম ClassLoader কাছে পরিচিত নয়। ভবিষ্যতে অনুরূপ সমস্যাগুলি রোধ করতে, অ্যাপ্লিকেশনগুলি সরাসরি সিস্টেম ClassLoader অ্যাক্সেসের চেয়ে অ্যাপ্লিকেশন ClassLoader মাধ্যমে সাধারণ লোড ক্লাসে থাকা উচিত।

গণনা ক্যামেরা

অ্যান্ড্রয়েড 9 ডিভাইসে চলমান অ্যাপ্লিকেশনগুলি getCameraIdList() কল করে প্রতিটি উপলভ্য ক্যামেরা আবিষ্কার করতে পারে। একটি অ্যাপ্লিকেশন ধরে নেওয়া উচিত নয় যে ডিভাইসে কেবল একটি একক ব্যাক ক্যামেরা বা কেবল একটি একক ফ্রন্ট ক্যামেরা রয়েছে।

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

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

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

শক্তি ব্যবস্থাপনা

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

বিশদ জন্য, পাওয়ার ম্যানেজমেন্ট দেখুন।

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

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

এই পরিবর্তনগুলি টার্গেট এসডিকে সংস্করণ নির্বিশেষে অ্যান্ড্রয়েড 9 এ চলমান সমস্ত অ্যাপ্লিকেশনগুলিকে প্রভাবিত করে।

পটভূমিতে সেন্সরগুলিতে সীমিত অ্যাক্সেস

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

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

যদি আপনার অ্যাপ্লিকেশনটিকে অ্যান্ড্রয়েড 9 চলমান ডিভাইসগুলিতে সেন্সর ইভেন্টগুলি সনাক্ত করতে হয় তবে একটি অগ্রভাগ পরিষেবা ব্যবহার করুন।

কল লগগুলিতে সীমাবদ্ধ অ্যাক্সেস

অ্যান্ড্রয়েড 9 CALL_LOG অনুমতি গোষ্ঠীর পরিচয় করিয়ে দেয় এবং এই গ্রুপে READ_CALL_LOG , WRITE_CALL_LOG এবং PROCESS_OUTGOING_CALLS অনুমতিগুলি সরিয়ে দেয়। অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, এই অনুমতিগুলি PHONE অনুমতি গ্রুপে অবস্থিত।

এই CALL_LOG অনুমতি গোষ্ঠী ব্যবহারকারীদের এমন অ্যাপ্লিকেশনগুলিতে আরও ভাল নিয়ন্ত্রণ এবং দৃশ্যমানতা দেয় যা ফোন কল সম্পর্কে সংবেদনশীল তথ্যের অ্যাক্সেসের প্রয়োজন যেমন ফোন কল রেকর্ডগুলি পড়া এবং ফোন নম্বরগুলি সনাক্তকরণ।

যদি আপনার অ্যাপ্লিকেশনটিতে কল লগগুলিতে অ্যাক্সেসের প্রয়োজন হয় বা বহির্গামী কলগুলি প্রক্রিয়া করার প্রয়োজন হয় তবে আপনাকে অবশ্যই CALL_LOG অনুমতি গোষ্ঠী থেকে এই অনুমতিগুলি স্পষ্টভাবে অনুরোধ করতে হবে। অন্যথায়, একটি SecurityException ঘটে।

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

যদি আপনার অ্যাপ্লিকেশনটি ইতিমধ্যে রানটাইম অনুমতিগুলি সর্বোত্তম অনুশীলনগুলি অনুসরণ করে থাকে তবে এটি অনুমতি গোষ্ঠীর পরিবর্তন পরিচালনা করতে পারে।

ফোন নম্বরগুলিতে সীমাবদ্ধ অ্যাক্সেস

অ্যান্ড্রয়েড 9 এ চলমান অ্যাপ্লিকেশনগুলি আপনার অ্যাপের ব্যবহারের ক্ষেত্রে প্রয়োজনীয় অন্যান্য অনুমতি ছাড়াও প্রথমে READ_CALL_LOG অনুমতি অর্জন না করে ফোন নম্বর বা ফোনের রাজ্য পড়তে পারে না।

আগত এবং বহির্গামী কলগুলির সাথে যুক্ত ফোন নম্বরগুলি ফোন স্টেট সম্প্রচারে দৃশ্যমান, যেমন আগত এবং বহির্গামী কলগুলির জন্য এবং PhoneStateListener ক্লাস থেকে অ্যাক্সেসযোগ্য। READ_CALL_LOG অনুমতি ব্যতীত, PHONE_STATE_CHANGED সম্প্রচারে এবং PhoneStateListener মাধ্যমে সরবরাহ করা ফোন নম্বর ক্ষেত্রটি খালি।

ফোন স্টেট থেকে ফোন নম্বরগুলি পড়তে, আপনার ব্যবহারের ক্ষেত্রে প্রয়োজনীয় অনুমতিগুলির জন্য অনুরোধ করতে আপনার অ্যাপ্লিকেশন আপডেট করুন:

PHONE_STATE অভিপ্রায় ক্রিয়া থেকে নম্বরগুলি পড়তে আপনার READ_CALL_LOG অনুমতি এবং READ_PHONE_STATE অনুমতি উভয়ই প্রয়োজন।
onCallStateChanged() থেকে নম্বরগুলি পড়তে আপনার কেবল READ_CALL_LOG অনুমতি প্রয়োজন। আপনার READ_PHONE_STATE অনুমতি দরকার নেই।

Wi-Fi অবস্থান এবং সংযোগের তথ্যে সীমাবদ্ধ অ্যাক্সেস

অ্যান্ড্রয়েড 9-এ, কোনও অ্যাপ্লিকেশনটির জন্য ওয়াই-ফাই স্ক্যানগুলি সম্পাদনের অনুমতি প্রয়োজনীয়তা পূর্ববর্তী সংস্করণগুলির চেয়ে বেশি কঠোর। বিশদগুলির জন্য, ওয়াই-ফাই স্ক্যানিং সীমাবদ্ধতাগুলি দেখুন।

অনুরূপ বিধিনিষেধগুলি getConnectionInfo() পদ্ধতিতেও প্রযোজ্য, যা বর্তমান ওয়াই-ফাই সংযোগের বর্ণনা দিয়ে একটি WifiInfo অবজেক্টকে প্রদান করে। কলিং অ্যাপটিতে নিম্নলিখিত অনুমতিগুলি থাকলে আপনি কেবল এসএসআইডি এবং বিএসএসআইডি মানগুলি পুনরুদ্ধার করতে এই অবজেক্টের পদ্ধতিগুলি ব্যবহার করতে পারেন:

অ্যাক্সেস_ফাইন_লোকেশন বা অ্যাক্সেস_কোয়ারস_লোকেশন
ACCESS_WIFI_STATE

এসএসআইডি বা বিএসএসআইডি পুনরুদ্ধার করার জন্য ডিভাইসে ( সেটিংস> অবস্থানের অধীনে) সক্ষম করার জন্য অবস্থান পরিষেবাগুলিরও প্রয়োজন।

ওয়াই-ফাই পরিষেবা পদ্ধতি থেকে তথ্য সরানো হয়েছে

অ্যান্ড্রয়েড 9 -এ, নিম্নলিখিত ইভেন্টগুলি এবং সম্প্রচারগুলি ব্যবহারকারীর অবস্থান বা ব্যক্তিগতভাবে সনাক্তযোগ্য ডেটা সম্পর্কে তথ্য গ্রহণ করে না:

WifiManager থেকে getScanResults() এবং getConnectionInfo() পদ্ধতি।
WifiP2pManager থেকে discoverServices() এবং addServiceRequest() পদ্ধতিগুলি।
NETWORK_STATE_CHANGED_ACTION সম্প্রচার।

Wi-Fi থেকে সম্প্রচারিত NETWORK_STATE_CHANGED_ACTION সিস্টেমটিতে আর এসএসআইডি (পূর্বে অতিরিক্ত_এসএসআইডি), বিএসএসআইডি (পূর্বে অতিরিক্ত_বিএসআইডি), বা সংযোগের তথ্য (পূর্বে অতিরিক্ত_নেটওয়ার্ক_ইনফো) নেই। যদি আপনার অ্যাপ্লিকেশনটির এই তথ্যের প্রয়োজন হয় তবে পরিবর্তে getConnectionInfo() কল করুন।

টেলিফোনের তথ্য এখন ডিভাইসের অবস্থান সেটিংয়ের উপর নির্ভর করে

যদি ব্যবহারকারী অ্যান্ড্রয়েড 9 চলমান কোনও ডিভাইসে ডিভাইসের অবস্থান অক্ষম করে থাকেন তবে নিম্নলিখিত পদ্ধতিগুলি ফলাফল সরবরাহ করে না:

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

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

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

সুরক্ষা আচরণ পরিবর্তন

ডিভাইস সুরক্ষা পরিবর্তন

অ্যান্ড্রয়েড 9 আপনার অ্যাপ্লিকেশনটির লক্ষ্যগুলি কোন সংস্করণ নির্বিশেষে আপনার অ্যাপ্লিকেশনটির সুরক্ষা উন্নত করে এমন বেশ কয়েকটি ক্ষমতা যুক্ত করে।

টিএলএস বাস্তবায়ন পরিবর্তন

সিস্টেমের টিএলএস বাস্তবায়ন অ্যান্ড্রয়েড 9 এ বেশ কয়েকটি পরিবর্তন হয়েছে:

যদি SSLSocket একটি উদাহরণ এটি তৈরি হওয়ার সময় সংযোগ করতে ব্যর্থ হয় তবে সিস্টেমটি NullPointerException পরিবর্তে একটি IOException নিক্ষেপ করে।
SSLEngine শ্রেণি পরিষ্কারভাবে যে কোনও close_notify সতর্কতাগুলি পরিচালনা করে।

অ্যান্ড্রয়েড অ্যাপ্লিকেশনটিতে সুরক্ষিত ওয়েব অনুরোধগুলি তৈরি করার বিষয়ে আরও জানতে, একটি এইচটিটিপিএস উদাহরণ দেখুন।

কঠোর সেককম্প ফিল্টার

অ্যান্ড্রয়েড 9 আরও অ্যাপ্লিকেশনগুলিতে উপলব্ধ সিস্টেম কলগুলিকে সীমাবদ্ধ করে। এই আচরণটি অ্যান্ড্রয়েড 8.0 (এপিআই স্তর 26) অন্তর্ভুক্ত সেককম্প ফিল্টারটির একটি এক্সটেনশন।

ক্রিপ্টোগ্রাফিক পরিবর্তন

অ্যান্ড্রয়েড 9 ক্রিপ্টোগ্রাফিক অ্যালগরিদমগুলি বাস্তবায়ন এবং পরিচালনা করার ক্ষেত্রে বেশ কয়েকটি পরিবর্তন প্রবর্তন করে।

পরামিতি এবং অ্যালগরিদমগুলির বিবর্তন বাস্তবায়ন

অ্যান্ড্রয়েড 9 কনক্রিপ্টে অ্যালগরিদম পরামিতিগুলির অতিরিক্ত প্রয়োগ সরবরাহ করে। এই পরামিতিগুলির মধ্যে রয়েছে: এইএস, ডেসেড, ওএইপি এবং ইসি। এই পরামিতিগুলির বাউন্সি ক্যাসেল সংস্করণগুলি এবং অনেকগুলি অ্যালগরিদম অ্যান্ড্রয়েড 9 হিসাবে অবমূল্যায়ন করা হয়েছে।

যদি আপনার অ্যাপ্লিকেশনটি অ্যান্ড্রয়েড 8.1 (এপিআই স্তর 27) বা তার চেয়ে কম লক্ষ্য করে তবে আপনি এই অবচয় ক্যাসেল বাস্তবায়নের জন্য অনুরোধ করার সময় একটি সতর্কতা পাবেন। আপনি যদি অ্যান্ড্রয়েড 9 কে টার্গেট করেন তবে এই অনুরোধগুলি প্রতিটি একটি NoSuchAlgorithmException নিক্ষেপ করে।

অন্যান্য পরিবর্তন

অ্যান্ড্রয়েড 9 ক্রিপ্টোগ্রাফি সম্পর্কিত আরও কয়েকটি পরিবর্তন প্রবর্তন করেছে:

পিবিই কীগুলি ব্যবহার করার সময়, যদি বাউন্সি ক্যাসেল একটি ইনিশিয়ালাইজেশন ভেক্টর (iv) প্রত্যাশা করে এবং আপনার অ্যাপ্লিকেশনটি একটি সরবরাহ করে না, আপনি একটি সতর্কতা পাবেন।
এআরসি 4 সাইফারের বিবিধ বাস্তবায়ন আপনাকে আর্ক 4/ইসিবি/নোপ্যাডিং বা এআরসি 4/কোনওটি/নোপ্যাডিং নির্দিষ্ট করতে দেয়।
ক্রিপ্টো জাভা ক্রিপ্টোগ্রাফি আর্কিটেকচার (জেসিএ) সরবরাহকারী সরানো হয়েছে। ফলস্বরূপ, যদি আপনার অ্যাপ্লিকেশনটি SecureRandom.getInstance("SHA1PRNG", "Crypto") কল করে তবে একটি NoSuchProviderException ঘটে।
যদি আপনার অ্যাপ্লিকেশনটি কী কাঠামোর চেয়ে বড় বাফার থেকে আরএসএ কীগুলি পার্স করে তবে একটি ব্যতিক্রম আর ঘটে না।

অ্যান্ড্রয়েড সিকিউর এনক্রিপ্ট করা ফাইলগুলি আর সমর্থিত নয়

অ্যান্ড্রয়েড 9 সম্পূর্ণরূপে অ্যান্ড্রয়েড সিকিউর এনক্রিপ্ট করা ফাইলগুলির জন্য সমর্থন সরিয়ে দেয় (এএসইসিএস)।

অ্যান্ড্রয়েড ২.২ (এপিআই স্তর 8) এ, অ্যান্ড্রয়েড অ্যাপস-অন-এসডি-কার্ড কার্যকারিতা সমর্থন করার জন্য ASECs প্রবর্তন করেছে। অ্যান্ড্রয়েড 6.0 (এপিআই স্তর 23) এ, প্ল্যাটফর্মটি একটি গ্রহণযোগ্য স্টোরেজ ডিভাইস প্রযুক্তি চালু করেছে যা বিকাশকারীরা এএসইসি -র জায়গায় ব্যবহার করতে পারে।

আইসিইউ লাইব্রেরিগুলিতে আপডেট

অ্যান্ড্রয়েড 9 আইসিইউ লাইব্রেরির সংস্করণ 60 ব্যবহার করে। অ্যান্ড্রয়েড 8.0 (এপিআই স্তর 26) এবং অ্যান্ড্রয়েড 8.1 (এপিআই স্তর 27) আইসিইউ 58 ব্যবহার করুন।

আইসিইউ android.icu package নীচে সর্বজনীন এপিআই সরবরাহ করতে ব্যবহৃত হয় এবং আন্তর্জাতিকীকরণ সহায়তার জন্য অ্যান্ড্রয়েড প্ল্যাটফর্মে অভ্যন্তরীণভাবে ব্যবহৃত হয়। উদাহরণস্বরূপ, এটি java.util , java.text , এবং android.text.format এ অ্যান্ড্রয়েড ক্লাসগুলি প্রয়োগ করতে ব্যবহৃত হয়।

আইসিইউ 60 এ আপডেটে ইমোজি 59 এবং আইসিইউ 60 রিলিজ নোটগুলিতে নথিভুক্ত হিসাবে ইমোজি 5.0 ডেটা সমর্থন এবং উন্নত তারিখ/সময় ফর্ম্যাট সহ অনেকগুলি ছোট তবে দরকারী পরিবর্তন রয়েছে।

এই আপডেটে উল্লেখযোগ্য পরিবর্তন:

প্ল্যাটফর্মটি সময় অঞ্চলগুলি যেভাবে পরিচালনা করে তা পরিবর্তিত হয়েছে।
- প্ল্যাটফর্মটি জিএমটি এবং ইউটিসি আরও ভাল পরিচালনা করে; ইউটিসি আর জিএমটি -র প্রতিশব্দ নয়।
  আইসিইউ এখন জিএমটি এবং ইউটিসির জন্য অনুবাদ জোনের নাম সরবরাহ করে। এই পরিবর্তনটি "জিএমটি", "ইত্যাদি/জিএমটি", "ইউটিসি", "ইত্যাদি/ইউটিসি", এবং "জুলু" এর মতো অঞ্চলগুলির জন্য android.icu ফর্ম্যাটিং এবং পার্সিং আচরণকে প্রভাবিত করে।
- java.text.SimpleDateFormat এখন ইউটিসি /জিএমটি -র জন্য প্রদর্শনের নাম সরবরাহ করতে আইসিইউ ব্যবহার করে, যার অর্থ:
  - ফর্ম্যাটিং zzzz অনেক লোকালগুলির জন্য একটি দীর্ঘ স্থানীয়করণ স্ট্রিং উত্পন্ন করে। পূর্বে, এটি ইউটিসির জন্য "ইউটিসি" এবং জিএমটি -র জন্য "GMT+00: 00" এর মতো স্ট্রিং তৈরি করেছিল।
  - zzzz পার্সিং "ইউনিভার্সাল সমন্বিত সময়" এবং "গ্রিনউইচ মিন টাইম" এর মতো স্ট্রিংগুলি স্বীকৃতি দেয়।
  - অ্যাপ্লিকেশনগুলি সামঞ্জস্যতার সমস্যার মুখোমুখি হতে পারে যদি তারা ধরে নেয় যে "ইউটিসি" বা "জিএমটি+00: 00" সমস্ত ভাষায় zzzz আউটপুট।
- java.text.DateFormatSymbols.getZoneStrings() এর আচরণ পরিবর্তন হয়েছে:
  - SimpleDateFormat মতো, ইউটিসি এবং জিএমটি এখন দীর্ঘ নাম রয়েছে। ইউটিসি জোনের জন্য টাইম জোনের নামগুলির ডিএসটি রূপগুলি যেমন "ইউটিসি", "ইত্যাদি/ইউটিসি", এবং "জুলু", জিএমটি+00: 00 হয়ে যায়, এটি যখন স্ট্যান্ডার্ড ফ্যালব্যাক হয় যখন কোনও নাম পাওয়া যায় না, বরং কোনও নাম পাওয়া যায় না, বরং কোনও নাম নেই, বরং কোনও নাম নেই, হার্ড-কোডেড স্ট্রিং UTC ।
  - কিছু জোন আইডিগুলি অন্যান্য অঞ্চলগুলির প্রতিশব্দ হিসাবে সঠিকভাবে স্বীকৃত, যাতে অ্যান্ড্রয়েডটি প্রত্নতাত্ত্বিক জোন আইডিগুলির জন্য যেমন স্ট্রিংগুলি খুঁজে পায়, যেমন Eire , যা পূর্বে সমাধান করা যায়নি।
- এশিয়া/হ্যানয় আর স্বীকৃত অঞ্চল নয়। এই কারণে java.util.TimeZones.getAvailableIds() এই মানটি ফেরত দেয় না, এবং java.util.TimeZone.getTimeZone() এটি স্বীকৃতি দেয় না। এই আচরণটি বিদ্যমান android.icu আচরণের সাথে সামঞ্জস্যপূর্ণ।
android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) পদ্ধতি বৈধ মুদ্রার পাঠ্যকে পার্স করার পরেও ParseException নিক্ষেপ করতে পারে। PLURALCURRENCYSTYLE স্টাইল -স্টাইল মুদ্রা পাঠ্যের জন্য অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) থেকে উপলভ্য NumberFormat.parseCurrency ব্যবহার করে এই সমস্যাটি এড়িয়ে চলুন।

অ্যান্ড্রয়েড পরীক্ষা পরিবর্তন

কাঠামো থেকে গ্রন্থাগার সরানো হয়েছে

পরীক্ষা স্যুট বিল্ড পরিবর্তন

জাভা ইউটিএফ ডিকোডার

<C0, AF> এর মতো ইউটিএফ -8 এর অ-অস্টেস্ট ফর্মটিকে অসুস্থ-গঠিত হিসাবে বিবেচনা করা হয়।
ইউটিএফ -8 এর সারোগেট ফর্ম, যেমন U+D800 .. U+DFFF , এটি খারাপ-গঠিত হিসাবে বিবেচিত হয়।
সর্বাধিক সাবপার্টটি একক U+FFFD দ্বারা প্রতিস্থাপিত হয়। উদাহরণস্বরূপ, বাইট সিকোয়েন্সে " 41 C0 AF 41 F4 80 80 41 ," সর্বাধিক উপ -বিভাগগুলি " C0 ," " AF ," এবং " F4 80 80 "। " F4 80 80 " " F4 80 80 80 " এর প্রাথমিক অনুপাত হতে পারে তবে " C0 " কোনও ভাল-গঠিত কোড ইউনিট অনুক্রমের প্রাথমিক অনুপাত হতে পারে না। সুতরাং, আউটপুটটি " A\ufffd\ufffdA\ufffdA হওয়া উচিত।"
অ্যান্ড্রয়েড 9 বা উচ্চতর একটি পরিবর্তিত ইউটিএফ -8 / সিইএসইউ -8 সিকোয়েন্সটি ডিকোড করার জন্য, DataInputStream.readUTF() পদ্ধতি বা NewStringUTF() জেএনআই পদ্ধতিটি ব্যবহার করুন।

একটি শংসাপত্র ব্যবহার করে হোস্টনাম যাচাইকরণ

নেটওয়ার্ক অ্যাড্রেস লুকআপগুলি নেটওয়ার্ক লঙ্ঘনের কারণ হতে পারে

সকেট ট্যাগিং

সকেটে উপলব্ধ বাইটের পরিমাণ রিপোর্ট

available() পদ্ধতিটি 0 ফেরত দেয় যখন এটি shutdownInput() পদ্ধতিটি অনুরোধ করার পরে ডাকা হয়।

ভিপিএনগুলির জন্য আরও বিশদ নেটওয়ার্ক ক্ষমতা রিপোর্টিং

Xt_qtaguid ফোল্ডারে ফাইলগুলি অ্যাপসগুলিতে আর উপলব্ধ নেই

FLAG_ACTIVITY_NEW_TASK প্রয়োজনীয়তা এখন প্রয়োগ করা হয়েছে

স্ক্রিন ঘূর্ণন পরিবর্তন

When the user accepts a rotation suggestion the rotation preference changes to the suggestion.
When the user switches to a forced portrait app (including the lock screen or the launcher) the rotation preference changes to portrait.

The following table summarizes rotation behavior for the common screen orientations:

স্ক্রিন ওরিয়েন্টেশন	আচরণ
unspecified, user	In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts.
userLandscape	In auto-rotate and rotation lock the Activity can be rendered in either landscape or reverse landscape. Expect to support only landscape layouts.
userPortrait	In auto-rotate and rotation lock the Activity can be rendered in either portrait or reverse portrait. Expect to support only portrait layouts.
fullUser	In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts. Rotation lock users will be given the option to lock to reverse portrait, often 180º.
sensor, fullSensor, sensorPortrait, sensorLandscape	The rotation lock mode preference is ignored and is treated as if auto-rotate is active. Only use this in exceptional circumstances with very careful UX consideration.

Apache HTTP client deprecation affects apps with non-standard ClassLoader

With Android 6.0, we removed support for the Apache HTTP client . This change has no effect on the great majority of apps that do not target Android 9 or higher. However, the change can affect certain apps that use a nonstandard ClassLoader structure, even if the apps do not target Android 9 or higher.

An app can be affected if it uses a non-standard ClassLoader that explicitly delegates to the system ClassLoader . These apps need to delegate to the app ClassLoader instead when looking for classes in org.apache.http.* . If they delegate to the system ClassLoader , the apps will fail on Android 9 or higher with a NoClassDefFoundError , because those classes are no longer known to the system ClassLoader . To prevent similar problems in the future, apps should in general load classes through the app ClassLoader rather than accessing the system ClassLoader directly.

Enumerating cameras

Apps running on Android 9 devices can discover every available camera by calling getCameraIdList() . An app should not assume that the device has only a single back camera or only a single front camera.

For example, if your app has a button to switch between the front and back cameras, there may be more than one front or back camera to choose from. You should walk the camera list, examine each camera's characteristics, and decide which cameras to expose to the user.

Android 9 (API level 28) introduces a number of changes to the Android system. The following behavior changes apply to all apps when they run on the Android 9 platform, regardless of the API level that they are targeting. All developers should review these changes and modify their apps to support them properly, where applicable to the app.

For changes that only affect apps that target API level 28 or higher, see Behavior changes: apps targeting API Level 28+ .

শক্তি ব্যবস্থাপনা

Android 9 introduces new features to improve device power management. These changes, along with features that were already present before Android 9, help to ensure that system resources are made available to the apps that need them the most.

For details, see Power management .

Privacy changes

To enhance user privacy, Android 9 introduces several behavior changes, such as limiting background apps' access to device sensors, restricting information retrieved from Wi-Fi scans, and new permission rules and permission groups related to phone calls, phone state, and Wi-Fi scans.

These changes affect all apps running on Android 9, regardless of target SDK version.

Limited access to sensors in background

Android 9 limits the ability for background apps to access user input and sensor data. If your app is running in the background on a device running Android 9, the system applies the following restrictions to your app:

Your app cannot access the microphone or camera.
Sensors that use the continuous reporting mode, such as accelerometers and gyroscopes, don't receive events.
Sensors that use the on-change or one-shot reporting modes don't receive events.

If your app needs to detect sensor events on devices running Android 9, use a foreground service .

Restricted access to call logs

Android 9 introduces the CALL_LOG permission group and moves the READ_CALL_LOG , WRITE_CALL_LOG , and PROCESS_OUTGOING_CALLS permissions into this group. In previous versions of Android, these permissions were located in the PHONE permission group.

This CALL_LOG permission group gives users better control and visibility to apps that need access to sensitive information about phone calls, such as reading phone call records and identifying phone numbers.

If your app requires access to call logs or needs to process outgoing calls, you must explicitly request these permissions from the CALL_LOG permission group. Otherwise, a SecurityException occurs.

Note: Because these permissions have changed groups and are granted at runtime, it's possible for the user to deny your app access to phone call logs information. In this case, your app should be able to handle the lack of access to information gracefully.

If your app is already following runtime permissions best practices , it can handle the change in permission group.

Restricted access to phone numbers

Apps running on Android 9 cannot read phone numbers or phone state without first acquiring the READ_CALL_LOG permission, in addition to the other permissions that your app's use cases require.

Phone numbers associated with incoming and outgoing calls are visible in the phone state broadcast , such as for incoming and outgoing calls and are accessible from the PhoneStateListener class. Without the READ_CALL_LOG permission, however, the phone number field that's provided in PHONE_STATE_CHANGED broadcasts and through PhoneStateListener is empty.

To read phone numbers from phone state, update your app to request the necessary permissions based on your use case:

To read numbers from the PHONE_STATE intent action , you need both the READ_CALL_LOG permission and the READ_PHONE_STATE permission.
To read numbers from onCallStateChanged() , you need the READ_CALL_LOG permission only. You don't need the READ_PHONE_STATE permission.

Restricted access to Wi-Fi location and connection information

In Android 9, the permission requirements for an app to perform Wi-Fi scans are more strict than in previous versions. For details, see Wi-Fi scanning restrictions .

Similar restrictions also apply to the getConnectionInfo() method, which returns a WifiInfo object describing the current Wi-Fi connection. You can only use this object's methods to retrieve SSID and BSSID values if the calling app has the following permissions:

ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION
ACCESS_WIFI_STATE

Retrieving the SSID or BSSID also requires location services to be enabled on the device (under Settings > Location ).

Information removed from Wi-Fi service methods

In Android 9, the following events and broadcasts don't receive information about the user's location or personally identifiable data:

The getScanResults() and getConnectionInfo() methods from WifiManager .
The discoverServices() and addServiceRequest() methods from WifiP2pManager .
The NETWORK_STATE_CHANGED_ACTION broadcast.

The NETWORK_STATE_CHANGED_ACTION system broadcast from Wi-Fi no longer contains SSID (previously EXTRA_SSID), BSSID (previously EXTRA_BSSID), or connection information (previously EXTRA_NETWORK_INFO). If your app needs this information, call getConnectionInfo() instead.

Telephony information now relies on device location setting

If the user has disabled device location on a device running Android 9, the following methods don't provide results:

Restrictions on use of non-SDK interfaces

To help ensure app stability and compatibility, the platform restricts the use of some non-SDK methods and fields; these restrictions apply whether you attempt to access these methods and fields directly, via reflection, or using JNI. In Android 9, your app can continue to access these restricted interfaces; the platform uses toasts and log entries to bring them to your attention. If your app shows such a toast, it is important that you pursue an implementation strategy other than the restricted interface. If you feel that no alternative strategy is feasible, you may file a bug to request reconsideration of the restriction.

Restrictions on Non-SDK Interfaces contains further important information. You should review it to ensure that your app continues to function properly.

Security behavior changes

Device security changes

Android 9 adds several capabilities that improve your app's security, regardless of which version your app targets.

TLS implementation changes

The system's TLS implementation has undergone several changes in Android 9:

If an instance of SSLSocket fails to connect while it's being created, the system throws an IOException instead of a NullPointerException .
The SSLEngine class cleanly handles any close_notify alerts that occur.

To learn more about making secure web requests in an Android app, see An HTTPS example .

Stricter SECCOMP filter

Android 9 further restricts the system calls that are available to apps. This behavior is an extension of the SECCOMP filter that Android 8.0 (API level 26) includes .

Cryptographic changes

Android 9 introduces several changes to the implementation and handling of cryptographic algorithms.

Conscrypt implementations of parameters and algorithms

Android 9 provides additional implementations of algorithm parameters in Conscrypt . These parameters include: AES, DESEDE, OAEP, and EC. The Bouncy Castle versions of these parameters and many algorithms have been deprecated as of Android 9.

If your app targets Android 8.1 (API level 27) or lower, you receive a warning when requesting the Bouncy Castle implementation of one of these deprecated algorithms. If you target Android 9, however, these requests each throw a NoSuchAlgorithmException .

অন্যান্য পরিবর্তন

Android 9 introduces several other changes related to cryptography:

When using PBE keys, if Bouncy Castle is expecting an initialization vector (IV) and your app doesn't supply one, you receive a warning.
The Conscrypt implementation of the ARC4 cipher allows you to specify either ARC4/ECB/NoPadding or ARC4/NONE/NoPadding .
The Crypto Java Cryptography Architecture (JCA) provider has been removed. As a result, if your app calls SecureRandom.getInstance("SHA1PRNG", "Crypto") , a NoSuchProviderException occurs.
If your app parses RSA keys from buffers that are larger than the key structure, an exception no longer occurs.

To learn more about using Android's cryptographic capabilities, see Cryptography .

Android secure encrypted files are no longer supported

Android 9 completely removes support for Android secure encrypted files (ASECs).

In Android 2.2 (API level 8), Android introduced ASECs to support apps-on-SD-card functionality. On Android 6.0 (API level 23), the platform introduced an adoptable storage device technology that developers can use in place of ASECs.

Updates to the ICU libraries

Android 9 uses version 60 of the ICU library. Android 8.0 (API level 26) and Android 8.1 (API level 27) use ICU 58.

ICU is used to provide public APIs beneath the android.icu package and is used internally in the Android platform for internationalization support. For example, it is used to implement Android classes in java.util , java.text , and android.text.format .

The update to ICU 60 contains many small but useful changes, including Emoji 5.0 data support and improved date/time formats, as documented in the ICU 59 and ICU 60 release notes.

Notable changes in this update:

The way the platform handles time zones has changed.
- The platform handles GMT and UTC better; UTC is no longer a synonym for GMT.
  ICU now provides translated zone names for GMT and UTC. This change affects android.icu formatting and parsing behavior for zones like "GMT", "Etc/GMT", "UTC", "Etc/UTC", and "Zulu".
- java.text.SimpleDateFormat now uses ICU to provide display names for UTC /GMT, meaning:
  - Formatting zzzz generates a long localized string for many locales. Previously, it produced "UTC" for UTC and strings like "GMT+00:00" for GMT.
  - Parsing zzzz recognizes strings like "Universal Coordinated Time", and "Greenwich Mean Time".
  - Apps may encounter compatibility problems if they assume that "UTC" or "GMT+00:00" are output for zzzz in all languages.
- The behavior of java.text.DateFormatSymbols.getZoneStrings() has changed:
  - As with SimpleDateFormat , UTC and GMT now have long names. DST variants of time zone names for the UTC zone, such as "UTC", "Etc/UTC", and "Zulu", become GMT+00:00, which is the standard fallback when there are no names available, rather than the hard-coded string UTC .
  - Some zone IDs are correctly recognized as synonyms for other zones, so that Android finds strings for archaic zone IDs, such as Eire , that previously could not be resolved.
- Asia/Hanoi is no longer a recognized zone. For this reason java.util.TimeZones.getAvailableIds() does not return this value, and java.util.TimeZone.getTimeZone() does not recognize it. This behavior is consistent with the existing android.icu behavior.
The android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) method may throw a ParseException even when parsing legitimate currency text. Avoid this problem by using NumberFormat.parseCurrency , available since Android 7.0 (API level 24), for PLURALCURRENCYSTYLE -style currency text.

Android Test changes

Android 9 introduces several changes to the Android Test framework's library and class structure. These changes help developers use framework-supported, public APIs, but the changes also allow for more flexibility in building and running tests using third-party libraries or custom logic.

Libraries removed from framework

Android 9 reorganizes the JUnit-based classes into three libraries: android.test.base , android.test.runner , and android.test.mock . This change allows you to run tests against a version of JUnit that works best with your project's dependencies. This version of JUnit might be different than the one that android.jar provides.

To learn more about how the JUnit-based classes are organized into these libraries, as well as how to prepare your app's project for writing and running tests, see Set up project for Android Test .

Test suite build changes

The addRequirements() method in the TestSuiteBuilder class has been removed, and the TestSuiteBuilder class itself been deprecated. The addRequirements() method had required developers to supply arguments whose types are hidden APIs, making the API invalid.

Java UTF decoder

UTF-8 is the default charset in Android. A UTF-8 byte sequence can be decoded by a String constructor, such as String(byte[] bytes) .

The UTF-8 decoder in Android 9 follows the Unicode standards more strictly than in previous versions. The changes include the following:

The non-shortest form of UTF-8, such as <C0, AF> , is treated as ill-formed.
The surrogate form of UTF-8, such as U+D800 .. U+DFFF , is treated as ill-formed.
The maximal subpart is replaced by a single U+FFFD . For example, in the byte sequence " 41 C0 AF 41 F4 80 80 41 ," the maximal subparts are " C0 ," " AF ," and " F4 80 80 ." " F4 80 80 " can be the initial subsequence of " F4 80 80 80 ", but " C0 " can't be the initial subsequence of any well-formed code unit sequence. Thus, the output should be " A\ufffd\ufffdA\ufffdA ."
To decode a modified UTF-8 / CESU-8 sequence in Android 9 or higher, use the DataInputStream.readUTF() method or the NewStringUTF() JNI method.

Hostname verification using a certificate

RFC 2818 describes two methods to match a domain name against a certificate—using the available names within the subjectAltName ( SAN ) extension, or in the absence of a SAN extension, falling back to the commonName ( CN ).

However, the fallback to the CN was deprecated in RFC 2818. For this reason, Android no longer falls back to using the CN . To verify a hostname, the server must present a certificate with a matching SAN . Certificates that don't contain a SAN matching the hostname are no longer trusted.

Network address lookups can cause network violations

Network address lookups that require name resolution can involve network I/O and are therefore considered blocking operations. Blocking operations on the main thread can cause pauses or jank.

The StrictMode class is a development tool that helps developers to detect problems in their code.

In Android 9 and higher, StrictMode detects network violations caused by network address lookups that require name resolution.

You should not ship your apps with StrictMode enabled. If you do, then your apps can experience exceptions, such as NetworkOnMainThreadException when using the detectNetwork() or detectAll() methods to get a policy that detects network violations.

Resolving a numeric IP address isn't considered a blocking operation. Numeric IP address resolution works the same as in versions before Android 9.

Socket tagging

In platform versions lower than Android 9, if a socket is tagged using the setThreadStatsTag() method, the socket is untagged when it's sent to another process using binder IPC with a ParcelFileDescriptor container.

In Android 9 and higher, the socket tag is kept when it's sent to another process using binder IPC. This change can affect network traffic statistics, for example, when using the queryDetailsForUidTag() method.

If you want to retain the behavior of the previous versions, which untags a socket that is sent to another process, you can call untagSocket() before sending the socket.

Reported amount of available bytes in socket

The available() method returns 0 when it's called after invoking the shutdownInput() method.

More detailed network capabilities reporting for VPNs

In Android 8.1 (API level 27) and lower, the NetworkCapabilities class only reported a limited set of information for VPNs, such as TRANSPORT_VPN , but omitting NET_CAPABILITY_NOT_VPN . This limited information made it difficult to determine if using a VPN would result in charges to the app's user. For example, checking NET_CAPABILITY_NOT_METERED would not determine whether the underlying networks were metered or not.

In Android 9 and higher, when a VPN calls the setUnderlyingNetworks() method, the Android system merges the transports and capabilities of any underlying networks and returns the result as the effective network capabilities of the VPN network.

In Android 9 and higher, apps that already check for NET_CAPABILITY_NOT_METERED receive the network capabilities of the VPN and the underlying networks.

Files in xt_qtaguid folder are no longer available to apps

Beginning with Android 9, apps are not allowed to have direct read access to files in the /proc/net/xt_qtaguid folder. The reason is to ensure consistency with some devices that don't have these files at all.

The public APIs that rely on these files, TrafficStats and NetworkStatsManager , continue to work as intended. However, the unsupported cutils functions, such as qtaguid_tagSocket() , may not work as expected—or at all— on different devices.

FLAG_ACTIVITY_NEW_TASK requirement is now enforced

With Android 9, you cannot start an activity from a non-activity context unless you pass the intent flag FLAG_ACTIVITY_NEW_TASK . If you attempt to start an activity without passing this flag, the activity does not start, and the system prints a message to the log.

Screen rotation changes

Beginning with Android 9, there are significant changes to the portrait rotation mode. In Android 8.0 (API level 26), users could toggle between auto-rotate and portrait rotation modes using a Quicksettings tile or Display settings. The portrait mode has been renamed rotation lock and it is active when auto-rotate is toggled off. There are no changes to auto-rotate mode.

When the device is in rotation lock mode, users can lock their screen to any rotation supported by the top, visible Activity. An Activity should not assume it will always be rendered in portrait. If the top Activity can be rendered in multiple rotations in auto-rotate mode, the same options should be available in rotation locked mode, with some exceptions based on the Activity's screenOrientation setting (see the table below).

Activities that request a specific orientation (for example, screenOrientation=landscape ) ignore the user lock preference and behave the same way as in Android 8.0.

The screen orientation preference can be set at the Activity level in the Android Manifest , or programmatically with setRequestedOrientation() .

The rotation lock mode works by setting the user rotation preference which the WindowManager uses when handling Activity rotation. The user rotation preference might be changed in the following cases. Note that there is a bias to return to the device's natural rotation, which is normally portrait for phone form factor devices:

When the user accepts a rotation suggestion the rotation preference changes to the suggestion.
When the user switches to a forced portrait app (including the lock screen or the launcher) the rotation preference changes to portrait.

The following table summarizes rotation behavior for the common screen orientations:

স্ক্রিন ওরিয়েন্টেশন	আচরণ
unspecified, user	In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts.
userLandscape	In auto-rotate and rotation lock the Activity can be rendered in either landscape or reverse landscape. Expect to support only landscape layouts.
userPortrait	In auto-rotate and rotation lock the Activity can be rendered in either portrait or reverse portrait. Expect to support only portrait layouts.
fullUser	In auto-rotate and rotation lock the Activity can be rendered in portrait or landscape (and the reverse). Expect to support both portrait and landscape layouts. Rotation lock users will be given the option to lock to reverse portrait, often 180º.
sensor, fullSensor, sensorPortrait, sensorLandscape	The rotation lock mode preference is ignored and is treated as if auto-rotate is active. Only use this in exceptional circumstances with very careful UX consideration.