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

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

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

ব্যাটারি এবং মেমরি

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

ডোজ

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

চিত্র 1. ব্যাটারির আয়ু উন্নত করতে ডোজ কীভাবে প্রথম স্তরের সিস্টেম কার্যকলাপ সীমাবদ্ধতা প্রয়োগ করে তার চিত্র।

যখন একটি ডিভাইস ব্যাটারি পাওয়ার চালু থাকে, এবং একটি নির্দিষ্ট সময়ের জন্য স্ক্রিন বন্ধ থাকে, তখন ডিভাইসটি Doze-এ প্রবেশ করে এবং বিধিনিষেধের প্রথম উপসেট প্রয়োগ করে: এটি অ্যাপ নেটওয়ার্ক অ্যাক্সেস বন্ধ করে, এবং কাজ এবং সিঙ্ক স্থগিত করে। Doze এ প্রবেশ করার পর ডিভাইসটি একটি নির্দিষ্ট সময়ের জন্য স্থির থাকলে, সিস্টেমটি PowerManager.WakeLock , AlarmManager অ্যালার্ম, GPS, এবং Wi-Fi স্ক্যানগুলিতে বাকি Doze বিধিনিষেধ প্রয়োগ করে৷ কিছু বা সমস্ত ডোজ বিধিনিষেধ প্রয়োগ করা হচ্ছে কিনা তা বিবেচনা না করেই, সিস্টেমটি সংক্ষিপ্ত রক্ষণাবেক্ষণের উইন্ডোগুলির জন্য ডিভাইসটিকে জাগিয়ে তোলে, যার সময় অ্যাপ্লিকেশনগুলিকে নেটওয়ার্ক অ্যাক্সেসের অনুমতি দেওয়া হয় এবং যে কোনও স্থগিত কাজ/সিঙ্কগুলি সম্পাদন করতে পারে।

চিত্র 2. ডিভাইস একটি নির্দিষ্ট সময়ের জন্য স্থির থাকার পরে কীভাবে Doze দ্বিতীয় স্তরের সিস্টেম কার্যকলাপ সীমাবদ্ধতা প্রয়োগ করে তার চিত্র।

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

প্রকল্প Svelte: পটভূমি অপ্টিমাইজেশান

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

মোবাইল ডিভাইসগুলি ঘন ঘন সংযোগের পরিবর্তনগুলি অনুভব করে, যেমন Wi-Fi এবং মোবাইল ডেটার মধ্যে সরানোর সময়৷ বর্তমানে, অ্যাপগুলি তাদের ম্যানিফেস্টে অন্তর্নিহিত CONNECTIVITY_ACTION সম্প্রচারের জন্য একটি রিসিভার নিবন্ধন করে সংযোগের পরিবর্তনের জন্য নিরীক্ষণ করতে পারে৷ যেহেতু অনেক অ্যাপ এই সম্প্রচার গ্রহণের জন্য নিবন্ধন করে, তাই একটি একক নেটওয়ার্ক সুইচ তাদের সকলকে জাগিয়ে তুলতে পারে এবং একবারে সম্প্রচার প্রক্রিয়া করতে পারে৷

একইভাবে, অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে, অ্যাপগুলি ক্যামেরার মতো অন্যান্য অ্যাপ থেকে অন্তর্নিহিত ACTION_NEW_PICTURE এবং ACTION_NEW_VIDEO সম্প্রচার পেতে নিবন্ধন করতে পারে। যখন একজন ব্যবহারকারী ক্যামেরা অ্যাপের মাধ্যমে একটি ছবি তোলেন, তখন এই অ্যাপগুলি সম্প্রচার প্রক্রিয়া করার জন্য জেগে ওঠে।

এই সমস্যাগুলি উপশম করতে, Android 7.0 নিম্নলিখিত অপ্টিমাইজেশানগুলি প্রয়োগ করে:

• Android 7.0 (API স্তর 24) এবং উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলি CONNECTIVITY_ACTION সম্প্রচার গ্রহণ করে না যদি তারা ম্যানিফেস্টে তাদের সম্প্রচার রিসিভার ঘোষণা করে। অ্যাপগুলি এখনও CONNECTIVITY_ACTION সম্প্রচার পাবে যদি তারা Context.registerReceiver() এর সাথে তাদের BroadcastReceiver নিবন্ধন করে এবং সেই প্রসঙ্গটি এখনও বৈধ থাকে৷
• সিস্টেমটি আর ACTION_NEW_PICTURE বা ACTION_NEW_VIDEO সম্প্রচার পাঠায় না৷ এই অপ্টিমাইজেশানটি সমস্ত অ্যাপকে প্রভাবিত করে, শুধুমাত্র Android 7.0 কে লক্ষ্য করে নয়৷

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

অ্যান্ড্রয়েড 7.0 (এপিআই লেভেল 24) এ ব্যাকগ্রাউন্ড অপ্টিমাইজেশান সম্পর্কে আরও তথ্যের জন্য এবং কীভাবে আপনার অ্যাপটিকে মানিয়ে নেবেন, পটভূমি অপ্টিমাইজেশন দেখুন।

অনুমতি পরিবর্তন

অ্যান্ড্রয়েড 7.0 অনুমতিতে পরিবর্তনগুলি অন্তর্ভুক্ত করে যা আপনার অ্যাপকে প্রভাবিত করতে পারে৷

ফাইল সিস্টেম অনুমতি পরিবর্তন

ব্যক্তিগত ফাইলগুলির নিরাপত্তা উন্নত করার জন্য, Android 7.0 বা উচ্চতরকে লক্ষ্য করে এমন অ্যাপগুলির ব্যক্তিগত ডিরেক্টরি অ্যাক্সেস সীমিত করেছে ( 0700 )৷ এই সেটিং ব্যক্তিগত ফাইলের মেটাডেটা ফাঁস প্রতিরোধ করে, যেমন তাদের আকার বা অস্তিত্ব। এই অনুমতি পরিবর্তনের একাধিক পার্শ্ব প্রতিক্রিয়া রয়েছে:

• ব্যক্তিগত ফাইলের ফাইলের অনুমতিগুলি মালিকের দ্বারা আর শিথিল করা উচিত নয়, এবং MODE_WORLD_READABLE এবং/অথবা MODE_WORLD_WRITEABLE ব্যবহার করে এটি করার একটি প্রচেষ্টা একটি SecurityException ট্রিগার করবে৷

  দ্রষ্টব্য: এখনও পর্যন্ত, এই নিষেধাজ্ঞা সম্পূর্ণরূপে প্রয়োগ করা হয়নি। অ্যাপগুলি এখনও নেটিভ API বা File API ব্যবহার করে তাদের ব্যক্তিগত ডিরেক্টরিতে অনুমতিগুলি পরিবর্তন করতে পারে। যাইহোক, আমরা দৃঢ়ভাবে নিরুৎসাহিত করি ব্যক্তিগত ডিরেক্টরির অনুমতি শিথিল করা।

• প্যাকেজ ডোমেনের বাইরে file:// URI গুলি পাস করা হলে রিসিভার একটি অ্যাক্সেসযোগ্য পথ দিয়ে চলে যেতে পারে। অতএব, একটি file:// URI পাস করার প্রচেষ্টা একটি FileUriExposedException ট্রিগার করে। একটি ব্যক্তিগত ফাইলের বিষয়বস্তু ভাগ করার প্রস্তাবিত উপায় হল FileProvider ব্যবহার করা।
• DownloadManager আর ফাইলের নামে ব্যক্তিগতভাবে সঞ্চিত ফাইল শেয়ার করতে পারবে না। COLUMN_LOCAL_FILENAME অ্যাক্সেস করার সময় লিগ্যাসি অ্যাপ্লিকেশনগুলি একটি অ্যাক্সেসযোগ্য পথের সাথে শেষ হতে পারে। COLUMN_LOCAL_FILENAME অ্যাক্সেস করার চেষ্টা করার সময় অ্যান্ড্রয়েড 7.0 বা উচ্চতরকে লক্ষ্য করা অ্যাপগুলি একটি SecurityException ট্রিগার করে। Legacy অ্যাপ্লিকেশানগুলি যেগুলি DownloadManager.Request.setDestinationInExternalFilesDir() বা DownloadManager.Request.setDestinationInExternalPublicDir() ব্যবহার করে একটি সর্বজনীন অবস্থানে ডাউনলোডের অবস্থান সেট করে সেগুলি এখনও COLUMN_LOCAL_FILENAME এ পাথ অ্যাক্সেস করতে পারে, তবে, এই পদ্ধতিটি দৃঢ়ভাবে নিরুৎসাহিত করা হয়৷ DownloadManager দ্বারা প্রকাশিত একটি ফাইল অ্যাক্সেস করার পছন্দের উপায় হল ContentResolver.openFileDescriptor() ব্যবহার করা।

অ্যাপের মধ্যে ফাইল শেয়ার করা

Android 7.0-কে টার্গেট করা অ্যাপগুলির জন্য, Android ফ্রেমওয়ার্ক StrictMode API নীতি প্রয়োগ করে যা আপনার অ্যাপের বাইরে file:// URIs প্রকাশ করা নিষিদ্ধ করে। যদি একটি ফাইল ইউআরআই সমন্বিত একটি উদ্দেশ্য আপনার অ্যাপ ছেড়ে চলে যায়, তবে অ্যাপটি একটি FileUriExposedException ব্যতিক্রম সহ ব্যর্থ হয়।

অ্যাপ্লিকেশনগুলির মধ্যে ফাইলগুলি ভাগ করতে, আপনাকে একটি content:// URI পাঠাতে হবে এবং URI-তে একটি অস্থায়ী অ্যাক্সেসের অনুমতি দিতে হবে৷ এই অনুমতি দেওয়ার সবচেয়ে সহজ উপায় হল FileProvider ক্লাস ব্যবহার করে। অনুমতি এবং ফাইল শেয়ার করার বিষয়ে আরও তথ্যের জন্য, ফাইল শেয়ার করা দেখুন।

অ্যাক্সেসিবিলিটি উন্নতি

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

স্ক্রীন জুম

অ্যান্ড্রয়েড 7.0 ব্যবহারকারীদের ডিসপ্লে সাইজ সেট করতে সক্ষম করে যা স্ক্রিনের সমস্ত উপাদানকে বড় করে বা সঙ্কুচিত করে, যার ফলে স্বল্প দৃষ্টিসম্পন্ন ব্যবহারকারীদের জন্য ডিভাইস অ্যাক্সেসযোগ্যতা উন্নত হয়। ব্যবহারকারীরা sw320dp এর ন্যূনতম স্ক্রিনের প্রস্থের পরে স্ক্রীন জুম করতে পারে না, যা একটি সাধারণ মাঝারি আকারের ফোন, Nexus 4 এর প্রস্থ।

চিত্র 3. ডানদিকের স্ক্রীনটি Android 7.0 সিস্টেম ইমেজ চালিত একটি ডিভাইসের ডিসপ্লে সাইজ বাড়ানোর প্রভাব দেখায়।

যখন ডিভাইসের ঘনত্ব পরিবর্তিত হয়, সিস্টেমটি নিম্নলিখিত উপায়ে চলমান অ্যাপ্লিকেশনগুলিকে অবহিত করে:

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

বেশিরভাগ অ্যাপের এই বৈশিষ্ট্যটিকে সমর্থন করার জন্য কোনও পরিবর্তন করতে হবে না, তবে অ্যাপগুলি Android সেরা অনুশীলনগুলি অনুসরণ করে। পরীক্ষা করার জন্য নির্দিষ্ট জিনিস:

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

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

• px ইউনিটের সাথে মাত্রা নির্দিষ্ট করা এড়িয়ে চলুন, কারণ সেগুলি স্ক্রীনের ঘনত্বের সাথে স্কেল করে না। পরিবর্তে, ঘনত্ব-স্বাধীন পিক্সেল ( dp ) ইউনিট সহ মাত্রা নির্দিষ্ট করুন৷

সেটআপ উইজার্ডে দৃষ্টি সেটিংস

অ্যান্ড্রয়েড 7.0 ওয়েলকাম স্ক্রিনে ভিশন সেটিংস অন্তর্ভুক্ত করে, যেখানে ব্যবহারকারীরা একটি নতুন ডিভাইসে নিম্নলিখিত অ্যাক্সেসিবিলিটি সেটিংস সেট আপ করতে পারেন: ম্যাগনিফিকেশন জেসচার , ফন্ট সাইজ , ডিসপ্লে সাইজ এবং টকব্যাক ৷ এই পরিবর্তনটি বিভিন্ন স্ক্রীন সেটিংস সম্পর্কিত বাগগুলির দৃশ্যমানতা বাড়ায়। এই বৈশিষ্ট্যটির প্রভাব মূল্যায়ন করতে, এই সেটিংস সক্ষম করে আপনার অ্যাপগুলি পরীক্ষা করা উচিত। আপনি সেটিংস > অ্যাক্সেসযোগ্যতার অধীনে সেটিংস খুঁজে পেতে পারেন।

প্ল্যাটফর্ম লাইব্রেরির সাথে লিঙ্ক করা NDK অ্যাপস

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

আপনার অ্যাপ ব্যক্তিগত প্ল্যাটফর্ম API অ্যাক্সেস করার চেষ্টা করতে পারে এমন তিনটি উপায় রয়েছে:

• আপনার অ্যাপ সরাসরি ব্যক্তিগত প্ল্যাটফর্ম লাইব্রেরি অ্যাক্সেস করে। সেই লাইব্রেরিগুলির নিজস্ব অনুলিপি অন্তর্ভুক্ত করতে বা সর্বজনীন NDK API ব্যবহার করতে আপনার অ্যাপটি আপডেট করা উচিত।
• আপনার অ্যাপ একটি তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করে যা ব্যক্তিগত প্ল্যাটফর্ম লাইব্রেরিগুলি অ্যাক্সেস করে। এমনকি আপনি যদি নিশ্চিত হন যে আপনার অ্যাপটি সরাসরি ব্যক্তিগত লাইব্রেরিগুলিতে অ্যাক্সেস করে না, তবুও আপনাকে এই দৃশ্যের জন্য আপনার অ্যাপটি পরীক্ষা করা উচিত।
• আপনার অ্যাপ একটি লাইব্রেরি উল্লেখ করে যা এর APK-এ অন্তর্ভুক্ত নয়। উদাহরণস্বরূপ, এটি ঘটতে পারে যদি আপনি OpenSSL-এর নিজের কপি ব্যবহার করার চেষ্টা করেন কিন্তু এটিকে আপনার অ্যাপের APK দিয়ে বান্ডিল করতে ভুলে যান। অ্যাপটি সাধারণত অ্যান্ড্রয়েড প্ল্যাটফর্মের সংস্করণে চলতে পারে যাতে libcrypto.so অন্তর্ভুক্ত থাকে। যাইহোক, অ্যাপটি অ্যান্ড্রয়েডের পরবর্তী সংস্করণগুলিতে ক্র্যাশ হতে পারে যেগুলিতে এই লাইব্রেরি অন্তর্ভুক্ত নয় (যেমন, Android 6.0 এবং পরবর্তী)। এটি ঠিক করতে, নিশ্চিত করুন যে আপনি আপনার সমস্ত নন-এনডিকে লাইব্রেরিগুলিকে আপনার APK দিয়ে বান্ডিল করেছেন৷

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

এই বিধিনিষেধটি বর্তমানে প্রকাশিত অ্যাপগুলিতে যে প্রভাব ফেলতে পারে তা কমাতে, লাইব্রেরির একটি সেট যা উল্লেখযোগ্য ব্যবহার দেখতে পায় — যেমন libandroid_runtime.so , libcutils.so , libcrypto.so , এবং libssl.so — সাময়িকভাবে Android 7.0-এ অ্যাক্সেসযোগ্য (API লেভেল 24) API লেভেল 23 বা তার নিচের টার্গেট করা অ্যাপের জন্য। যদি আপনার অ্যাপ এই লাইব্রেরিগুলির মধ্যে একটি লোড করে, logcat একটি সতর্কতা তৈরি করে এবং আপনাকে অবহিত করার জন্য লক্ষ্য ডিভাইসে একটি টোস্ট উপস্থিত হয়। আপনি যদি এই সতর্কতাগুলি দেখতে পান, তাহলে আপনার অ্যাপটি আপডেট করা উচিত যাতে সেই লাইব্রেরিগুলির নিজস্ব অনুলিপি অন্তর্ভুক্ত করা বা শুধুমাত্র সর্বজনীন NDK API ব্যবহার করা উচিত। অ্যান্ড্রয়েড প্ল্যাটফর্মের ভবিষ্যত প্রকাশগুলি ব্যক্তিগত লাইব্রেরিগুলির ব্যবহার সম্পূর্ণরূপে সীমাবদ্ধ করতে পারে এবং আপনার অ্যাপ ক্র্যাশ করতে পারে৷

সমস্ত অ্যাপ একটি রানটাইম ত্রুটি তৈরি করে যখন তারা একটি API কল করে যা সর্বজনীন বা অস্থায়ীভাবে অ্যাক্সেসযোগ্য নয়। ফলাফল হল যে System.loadLibrary এবং dlopen(3) উভয়ই NULL ফেরত দেয়, এবং আপনার অ্যাপ ক্র্যাশ হতে পারে। ব্যক্তিগত প্ল্যাটফর্ম API-এর ব্যবহার অপসারণ করতে আপনার অ্যাপ কোড পর্যালোচনা করা উচিত এবং Android 7.0 (API স্তর 24) চালিত একটি ডিভাইস বা এমুলেটর ব্যবহার করে আপনার অ্যাপগুলিকে পুঙ্খানুপুঙ্খভাবে পরীক্ষা করা উচিত। আপনি যদি নিশ্চিত না হন যে আপনার অ্যাপ ব্যক্তিগত লাইব্রেরি ব্যবহার করে কিনা, আপনি রানটাইম ত্রুটি সনাক্ত করতে logcat চেক করতে পারেন।

একটি অ্যাপ থেকে ব্যক্তিগত নেটিভ লাইব্রেরি এবং এর টার্গেট এপিআই লেভেলের ( android:targetSdkVersion ) ব্যবহারের উপর নির্ভর করে নিম্নলিখিত সারণীটি বর্ণনা করে।

লাইব্রেরি	লক্ষ্য API স্তর	গতিশীল লিঙ্কারের মাধ্যমে রানটাইম অ্যাক্সেস	Android 7.0 (API স্তর 24) আচরণ	ভবিষ্যতের অ্যান্ড্রয়েড প্ল্যাটফর্মের আচরণ
এনডিকে পাবলিক	যে কোন	অ্যাক্সেসযোগ্য	আশানুরূপ কাজ করে	আশানুরূপ কাজ করে
ব্যক্তিগত (অস্থায়ীভাবে অ্যাক্সেসযোগ্য ব্যক্তিগত লাইব্রেরি)	23 বা কম	সাময়িকভাবে অ্যাক্সেসযোগ্য	প্রত্যাশিত হিসাবে কাজ করে, কিন্তু আপনি একটি logcat সতর্কতা পাবেন।	রানটাইম ত্রুটি
ব্যক্তিগত (অস্থায়ীভাবে অ্যাক্সেসযোগ্য ব্যক্তিগত লাইব্রেরি)	24 বা তার বেশি	সীমাবদ্ধ	রানটাইম ত্রুটি	রানটাইম ত্রুটি
ব্যক্তিগত (অন্যান্য)	যে কোন	সীমাবদ্ধ	রানটাইম ত্রুটি	রানটাইম ত্রুটি

আপনার অ্যাপ ব্যক্তিগত লাইব্রেরি ব্যবহার করে কিনা তা পরীক্ষা করুন

ব্যক্তিগত লাইব্রেরি লোড করার সমস্যাগুলি সনাক্ত করতে আপনাকে সাহায্য করার জন্য, logcat একটি সতর্কতা বা রানটাইম ত্রুটি তৈরি করতে পারে। উদাহরণস্বরূপ, যদি আপনার অ্যাপটি API লেভেল 23 বা তার নিচের দিকে লক্ষ্য করে এবং অ্যান্ড্রয়েড 7.0 চালিত একটি ডিভাইসে একটি ব্যক্তিগত লাইব্রেরি অ্যাক্সেস করার চেষ্টা করে, তাহলে আপনি নিম্নলিখিতগুলির মতো একটি সতর্কতা দেখতে পাবেন:

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

এই logcat সতর্কতাগুলি আপনাকে বলে যে কোন লাইব্রেরি একটি প্রাইভেট প্ল্যাটফর্ম API অ্যাক্সেস করার চেষ্টা করছে, কিন্তু আপনার অ্যাপ ক্র্যাশ করবে না। অ্যাপটি যদি API লেভেল 24 বা তার বেশি লক্ষ্য করে, তবে, logcat নিম্নলিখিত রানটাইম ত্রুটি তৈরি করে এবং আপনার অ্যাপ ক্র্যাশ হতে পারে:

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

আপনি এই লগক্যাট আউটপুটগুলিও দেখতে পারেন যদি আপনার অ্যাপ তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করে যা গতিশীলভাবে ব্যক্তিগত প্ল্যাটফর্ম API-এর সাথে লিঙ্ক করে। Android 7.0DK-এর রিডেলফ টুল আপনাকে নিম্নলিখিত কমান্ডটি চালিয়ে একটি প্রদত্ত .so ফাইলের সমস্ত গতিশীলভাবে লিঙ্ক করা শেয়ার্ড লাইব্রেরির একটি তালিকা তৈরি করতে দেয়:

aarch64-linux-android-readelf -dW libMyLibrary.so

আপনার অ্যাপ আপডেট করুন

এই ধরনের ত্রুটিগুলি ঠিক করতে এবং ভবিষ্যতে প্ল্যাটফর্ম আপডেটগুলিতে আপনার অ্যাপ ক্র্যাশ না হয় তা নিশ্চিত করতে এখানে কিছু পদক্ষেপ নিতে পারেন:

• যদি আপনার অ্যাপ ব্যক্তিগত প্ল্যাটফর্ম লাইব্রেরি ব্যবহার করে, তাহলে সেই লাইব্রেরির নিজস্ব অনুলিপি অন্তর্ভুক্ত করতে বা সর্বজনীন NDK API ব্যবহার করতে আপনার এটি আপডেট করা উচিত।
• যদি আপনার অ্যাপটি ব্যক্তিগত চিহ্নগুলি অ্যাক্সেস করে এমন একটি তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করে, লাইব্রেরি আপডেট করতে লাইব্রেরির লেখকের সাথে যোগাযোগ করুন।
• নিশ্চিত করুন যে আপনি আপনার APK দিয়ে আপনার সমস্ত নন-এনডিকে লাইব্রেরি প্যাকেজ করেছেন।
• libandroid_runtime.so থেকে getJavaVM এবং getJNIEnv এর পরিবর্তে স্ট্যান্ডার্ড JNI ফাংশন ব্যবহার করুন:

  AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
  AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
  JavaVM::AttachCurrentThread from <jni.h>.
  

• libcutils.so থেকে ব্যক্তিগত property_get প্রতীকের পরিবর্তে __system_property_get ব্যবহার করুন। এটি করার জন্য, নিম্নলিখিত অন্তর্ভুক্ত সহ __system_property_get ব্যবহার করুন:

  #include <sys/system_properties.h>

  দ্রষ্টব্য: সিস্টেম বৈশিষ্ট্যগুলির উপলব্ধতা এবং বিষয়বস্তু CTS এর মাধ্যমে পরীক্ষা করা হয় না। এই বৈশিষ্ট্যগুলি সম্পূর্ণরূপে ব্যবহার করা এড়াতে একটি ভাল সমাধান হবে।

• libcrypto.so থেকে SSL_ctrl চিহ্নের একটি স্থানীয় সংস্করণ ব্যবহার করুন। উদাহরণ স্বরূপ, আপনার .so ফাইলে libcyrpto.a স্থিরভাবে লিঙ্ক করা উচিত, অথবা BoringSSL/OpenSSL থেকে libcrypto.so এর একটি গতিশীলভাবে লিঙ্ক করা সংস্করণ অন্তর্ভুক্ত করা উচিত এবং এটিকে আপনার APK এ প্যাকেজ করা উচিত৷

কাজের জন্য Android

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

• DPC এটি সেট করার আগে আপনাকে অবশ্যই একটি অর্পিত শংসাপত্র ইনস্টলার ইনস্টল করতে হবে৷ Android 7.0 (API স্তর 24) কে লক্ষ্য করে প্রোফাইল এবং ডিভাইস-মালিক উভয় অ্যাপের জন্য, ডিভাইস নীতি নিয়ন্ত্রক (DPC) DevicePolicyManager.setCertInstallerPackage() কল করার আগে আপনাকে অর্পিত শংসাপত্র ইনস্টলারটি ইনস্টল করতে হবে। যদি ইনস্টলারটি ইতিমধ্যে ইনস্টল করা না থাকে, তাহলে সিস্টেমটি একটি IllegalArgumentException নিক্ষেপ করে।
• ডিভাইস প্রশাসকদের জন্য পাসওয়ার্ড সীমাবদ্ধতা রিসেট এখন প্রোফাইল মালিকদের জন্য প্রযোজ্য। ডিভাইস প্রশাসকরা আর DevicePolicyManager.resetPassword() ব্যবহার করে পাসওয়ার্ড মুছে ফেলতে বা ইতিমধ্যে সেট করা পাসওয়ার্ড পরিবর্তন করতে পারবেন না। ডিভাইস প্রশাসকরা এখনও একটি পাসওয়ার্ড সেট করতে পারেন, কিন্তু শুধুমাত্র যখন ডিভাইসে কোনো পাসওয়ার্ড, পিন বা প্যাটার্ন থাকে না।
• বিধিনিষেধ সেট করা থাকলেও ডিভাইস এবং প্রোফাইল মালিকরা অ্যাকাউন্ট পরিচালনা করতে পারেন। DISALLOW_MODIFY_ACCOUNTS ব্যবহারকারীর বিধিনিষেধ থাকলেও ডিভাইসের মালিক এবং প্রোফাইল মালিকরা অ্যাকাউন্ট ম্যানেজমেন্ট API-কে কল করতে পারেন৷
• ডিভাইস মালিকরা সেকেন্ডারি ব্যবহারকারীদের আরও সহজে পরিচালনা করতে পারেন। যখন একটি ডিভাইস ডিভাইস মালিক মোডে চলছে, তখন DISALLOW_ADD_USER সীমাবদ্ধতা স্বয়ংক্রিয়ভাবে সেট করা হয়৷ এটি ব্যবহারকারীদের অব্যবস্থাপিত সেকেন্ডারি ব্যবহারকারী তৈরি করতে বাধা দেয়। উপরন্তু, CreateUser() এবং createAndInitializeUser() পদ্ধতিগুলি অবমূল্যায়িত করা হয়েছে; নতুন DevicePolicyManager.createAndManageUser() পদ্ধতি তাদের প্রতিস্থাপন করে।
• ডিভাইসের মালিকরা ডিভাইস শনাক্তকারী অ্যাক্সেস করতে পারেন। একজন ডিভাইস মালিক DevicePolicyManager.getWifiMacAddress() ব্যবহার করে একটি ডিভাইসের Wi-Fi MAC ঠিকানা অ্যাক্সেস করতে পারেন। যদি ডিভাইসে Wi-Fi কখনও সক্ষম না করা থাকে, তাহলে এই পদ্ধতিটি null এর একটি মান প্রদান করে।
• কাজের মোড সেটিং কাজের অ্যাপগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করে। যখন কাজের মোড বন্ধ থাকে তখন সিস্টেম লঞ্চার নির্দেশ করে যে কাজের অ্যাপগুলি ধূসর করে অনুপলব্ধ। কাজের মোড আবার সক্রিয় করা স্বাভাবিক আচরণ পুনরুদ্ধার করে।
• একটি ক্লায়েন্ট শংসাপত্র চেইন এবং সেটিংস UI থেকে সংশ্লিষ্ট ব্যক্তিগত কী ধারণকারী একটি PKCS #12 ফাইল ইনস্টল করার সময়, চেইনের CA শংসাপত্রটি বিশ্বস্ত শংসাপত্র সঞ্চয়স্থানে আর ইনস্টল করা হয় না। এটি KeyChain.getCertificateChain() এর ফলাফলকে প্রভাবিত করে না যখন অ্যাপগুলি পরে ক্লায়েন্ট সার্টিফিকেট চেইন পুনরুদ্ধার করার চেষ্টা করে। প্রয়োজনে, CA শংসাপত্রটি .crt বা .cer ফাইল এক্সটেনশনের অধীনে একটি DER-এনকোডেড বিন্যাস সহ আলাদাভাবে সেটিংস UI এর মাধ্যমে বিশ্বস্ত শংসাপত্র সঞ্চয়স্থানে ইনস্টল করা উচিত।
• অ্যান্ড্রয়েড 7.0 থেকে শুরু করে, ব্যবহারকারী পিছু ফিঙ্গারপ্রিন্ট তালিকাভুক্তি এবং স্টোরেজ পরিচালনা করা হয়। যদি কোনও প্রোফাইল মালিকের ডিভাইস পলিসি ক্লায়েন্ট (DPC) Android 7.0 (API স্তর 24) চালিত একটি ডিভাইসে API স্তর 23 (বা নিম্ন) লক্ষ্য করে, ব্যবহারকারী এখনও ডিভাইসে আঙুলের ছাপ সেট করতে সক্ষম, কিন্তু কাজের অ্যাপ্লিকেশনগুলি ডিভাইসের ফিঙ্গারপ্রিন্ট অ্যাক্সেস করতে পারে না। যখন DPC এপিআই লেভেল 24 এবং তার উপরে লক্ষ্য করে, ব্যবহারকারী সেটিংস > সিকিউরিটি > ওয়ার্ক প্রোফাইল সিকিউরিটি এ গিয়ে কাজের প্রোফাইলের জন্য বিশেষভাবে ফিঙ্গারপ্রিন্ট সেট করতে পারেন।
• DevicePolicyManager.getStorageEncryptionStatus() দ্বারা একটি নতুন এনক্রিপশন স্ট্যাটাস ENCRYPTION_STATUS_ACTIVE_PER_USER ফেরত দেওয়া হয়েছে, যাতে বোঝানো যায় যে এনক্রিপশন সক্রিয় আছে এবং এনক্রিপশন কী ব্যবহারকারীর সাথে সংযুক্ত আছে। নতুন স্ট্যাটাস শুধুমাত্র তখনই ফেরত দেওয়া হয় যখন DPC টার্গেট করে API লেভেল 24 এবং তার উপরে। পূর্ববর্তী API স্তরগুলিকে লক্ষ্য করে এমন অ্যাপগুলির জন্য, ENCRYPTION_STATUS_ACTIVE ফেরত দেওয়া হয়, এমনকি যদি এনক্রিপশন কী ব্যবহারকারী বা প্রোফাইলের জন্য নির্দিষ্ট হয়।
• অ্যান্ড্রয়েড 7.0-এ, ডিভাইসটিতে একটি পৃথক কাজের চ্যালেঞ্জ সহ একটি ওয়ার্ক প্রোফাইল ইনস্টল করা থাকলে সাধারণত সম্পূর্ণ ডিভাইসটিকে প্রভাবিত করে এমন বেশ কয়েকটি পদ্ধতি ভিন্নভাবে আচরণ করে। পুরো ডিভাইসটিকে প্রভাবিত করার পরিবর্তে, এই পদ্ধতিগুলি শুধুমাত্র কাজের প্রোফাইলে প্রযোজ্য। (এই ধরনের পদ্ধতির সম্পূর্ণ তালিকা DevicePolicyManager.getParentProfileInstance() ডকুমেন্টেশনে রয়েছে।) উদাহরণস্বরূপ, DevicePolicyManager.lockNow() পুরো ডিভাইসটিকে লক করার পরিবর্তে শুধুমাত্র কাজের প্রোফাইল লক করে। এই পদ্ধতিগুলির প্রতিটির জন্য, আপনি DevicePolicyManager এর প্যারেন্ট ইনস্ট্যান্সে মেথডটি কল করে পুরানো আচরণ পেতে পারেন; আপনি DevicePolicyManager.getParentProfileInstance() কল করে এই অভিভাবককে পেতে পারেন। সুতরাং উদাহরণস্বরূপ, আপনি যদি প্যারেন্ট ইনস্ট্যান্সের lockNow() পদ্ধতিতে কল করেন, পুরো ডিভাইসটি লক হয়ে যায়।

টীকা ধরে রাখা

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

• VISIBILITY_BUILD : শুধুমাত্র নির্মাণের সময় দৃশ্যমান হওয়ার উদ্দেশ্যে।
• VISIBILITY_SYSTEM : রানটাইমে দৃশ্যমান হওয়ার উদ্দেশ্যে, কিন্তু শুধুমাত্র অন্তর্নিহিত সিস্টেমে।

যদি আপনার অ্যাপ এই আচরণের উপর নির্ভর করে থাকে, তাহলে অনুগ্রহ করে টীকাগুলিতে একটি ধারণ নীতি যোগ করুন যা রানটাইমে উপলব্ধ হতে হবে। আপনি @Retention(RetentionPolicy.RUNTIME) ব্যবহার করে তা করেন।

TLS/SSL ডিফল্ট কনফিগারেশন পরিবর্তন

Android 7.0 HTTPS এবং অন্যান্য TLS/SSL ট্রাফিকের জন্য অ্যাপ দ্বারা ব্যবহৃত ডিফল্ট TLS/SSL কনফিগারেশনে নিম্নলিখিত পরিবর্তনগুলি করে:

• RC4 সাইফার স্যুটগুলি এখন অক্ষম৷
• CHACHA20-POLY1305 সাইফার স্যুটগুলি এখন সক্ষম৷

RC4 ডিফল্টরূপে অক্ষম করা হলে HTTPS বা TLS/SSL সংযোগে বিচ্ছেদ ঘটতে পারে যখন সার্ভার আধুনিক সাইফার স্যুটগুলির সাথে আলোচনা করে না। শক্তিশালী এবং আরও আধুনিক সাইফার স্যুট এবং প্রোটোকল সক্ষম করতে সার্ভারের কনফিগারেশন উন্নত করাই পছন্দের সমাধান। আদর্শভাবে, TLSv1.2 এবং AES-GCM সক্ষম করা উচিত, এবং ফরোয়ার্ড সিক্রেসি সাইফার স্যুট (ECDHE) সক্ষম করা উচিত এবং পছন্দ করা উচিত।

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

দ্রষ্টব্য: এই পরিবর্তনগুলি WebView এর সাথে সম্পর্কিত নয়।

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

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

সিরিয়ালাইজেশন পরিবর্তন

অ্যান্ড্রয়েড 7.0 (এপিআই স্তর 24) ডিফল্ট সিরিয়াল সংস্করণ ইউআইডির গণনায় একটি বাগ সংশোধন করেছে যেখানে এটি স্পেসিফিকেশনের সাথে মেলেনি।

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

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

এই সমস্যাগুলি সমাধান করার জন্য ত্রুটি বার্তা থেকে stream classdesc serialVersionUID মান সহ যে কোনও প্রভাবিত ক্লাসে একটি serialVersionUID ক্ষেত্র যোগ করতে হবে, যেমন এই ক্ষেত্রে 1234 । এই পরিবর্তনটি সিরিয়ালাইজেশন কোড লেখার জন্য সমস্ত ভাল অনুশীলনের সুপারিশ মেনে চলে এবং Android এর সমস্ত সংস্করণে কাজ করবে৷

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

স্পষ্ট করার জন্য, এই পরিবর্তনটি এমন অ্যাপগুলিকে প্রভাবিত করে না যেগুলি API স্তরগুলিকে 23 বা তার নীচের লক্ষ্য করে, যে ক্লাসগুলির একটি serialVersionUID ক্ষেত্র রয়েছে বা একটি স্ট্যাটিক ইনিশিয়ালাইজার পদ্ধতি রয়েছে এমন ক্লাসগুলিকে।

অন্যান্য গুরুত্বপূর্ণ পয়েন্ট

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

  এই আচরণটি যাতে না ঘটে তা নিশ্চিত করতে আপনার অ্যাপটি পরীক্ষা করা উচিত। ডিডিএমএসের মাধ্যমে ম্যানুয়ালি অ্যাপটি মেরে ফেলার সময় আপনি একটি অভিন্ন ক্র্যাশ ঘটিয়ে তা করতে পারেন।

  অ্যানড্রয়েড 7.0 (API লেভেল 24) এবং তার উপরে লক্ষ্য করা অ্যাপগুলি ঘনত্বের পরিবর্তনে স্বয়ংক্রিয়ভাবে মারা যায় না; যাইহোক, তারা এখনও কনফিগারেশন পরিবর্তনের জন্য খারাপভাবে সাড়া দিতে পারে।

• অ্যান্ড্রয়েড 7.0-এর অ্যাপগুলি কনফিগারেশন পরিবর্তনগুলিকে সুন্দরভাবে পরিচালনা করতে সক্ষম হওয়া উচিত এবং পরবর্তী শুরুতে ক্র্যাশ হওয়া উচিত নয়। আপনি ফন্ট সাইজ ( সেটিং > ডিসপ্লে > ফন্ট সাইজ ) পরিবর্তন করে এবং তারপর সাম্প্রতিক থেকে অ্যাপটি পুনরুদ্ধার করে অ্যাপের আচরণ যাচাই করতে পারেন।
• অ্যান্ড্রয়েডের পূর্ববর্তী সংস্করণগুলিতে একটি ত্রুটির কারণে, সিস্টেমটি একটি কঠোর-মোড লঙ্ঘন হিসাবে মূল থ্রেডের একটি TCP সকেটে লেখার পতাকাঙ্কিত করেনি। অ্যান্ড্রয়েড 7.0 এই বাগ সংশোধন করে। যে অ্যাপগুলি এই আচরণটি প্রদর্শন করে তারা এখন একটি android.os.NetworkOnMainThreadException নিক্ষেপ করে৷ সাধারণত, প্রধান থ্রেডে নেটওয়ার্ক ক্রিয়াকলাপ সম্পাদন করা একটি খারাপ ধারণা কারণ এই অপারেশনগুলির সাধারণত একটি উচ্চ লেটেন্সি থাকে যা ANR এবং জ্যাঙ্কের কারণ হয়৷
• Debug.startMethodTracing() পদ্ধতির পরিবারটি এখন SD কার্ডের শীর্ষ স্তরের পরিবর্তে শেয়ার্ড স্টোরেজে আপনার প্যাকেজ-নির্দিষ্ট ডিরেক্টরিতে আউটপুট সংরক্ষণ করতে ডিফল্ট। এর মানে হল এই APIগুলি ব্যবহার করার জন্য অ্যাপগুলিকে আর WRITE_EXTERNAL_STORAGE অনুমতির অনুরোধ করতে হবে না৷
• অনেক প্ল্যাটফর্ম API এখন Binder লেনদেন জুড়ে পাঠানো বড় পেলোডের জন্য পরীক্ষা করা শুরু করেছে, এবং সিস্টেমটি এখন নীরবে লগিং বা দমন করার পরিবর্তে, RuntimeExceptions হিসাবে TransactionTooLargeExceptions পুনরায় থ্রো করে। একটি সাধারণ উদাহরণ হল Activity.onSaveInstanceState() -এ অত্যধিক ডেটা সঞ্চয় করা, যার ফলে ActivityThread.StopInfo একটি RuntimeException নিক্ষেপ করে যখন আপনার অ্যাপ Android 7.0 কে লক্ষ্য করে।
• যদি একটি অ্যাপ একটি View Runnable টাস্ক পোস্ট করে এবং View একটি উইন্ডোতে সংযুক্ত না থাকে, তাহলে সিস্টেমটি Runnable টাস্কটিকে View সাথে সারিবদ্ধ করে; View একটি উইন্ডোতে সংযুক্ত না হওয়া পর্যন্ত Runnable টাস্কটি কার্যকর হয় না। এই আচরণ নিম্নলিখিত বাগ সংশোধন করে:
  • যদি একটি অ্যাপ উদ্দিষ্ট উইন্ডোর UI থ্রেড ব্যতীত অন্য কোনো থ্রেড থেকে একটি View পোস্ট করে, তাহলে Runnable এর ফলে ভুল থ্রেডে চলতে পারে।
  • যদি Runnable টাস্কটি লুপার থ্রেড ছাড়া অন্য কোনো থ্রেড থেকে পোস্ট করা হয়, তাহলে অ্যাপটি Runnable টাস্কটি প্রকাশ করতে পারে।
• DELETE_PACKAGES অনুমতি সহ Android 7.0-এ একটি অ্যাপ যদি একটি প্যাকেজ মুছে ফেলার চেষ্টা করে, কিন্তু একটি ভিন্ন অ্যাপ সেই প্যাকেজটি ইনস্টল করে থাকে, তাহলে সিস্টেমটির ব্যবহারকারীর নিশ্চিতকরণ প্রয়োজন৷ এই পরিস্থিতিতে, অ্যাপগুলিকে PackageInstaller.uninstall() চালু করার সময় রিটার্ন স্ট্যাটাস হিসাবে STATUS_PENDING_USER_ACTION আশা করা উচিত।
• ক্রিপ্টো নামক JCA প্রদানকারীকে অবমূল্যায়ন করা হয়েছে, কারণ এর একমাত্র অ্যালগরিদম, SHA1PRNG, ক্রিপ্টোগ্রাফিকভাবে দুর্বল। অ্যাপ্লিকেশানগুলি আর SHA1PRNG ব্যবহার করতে পারে না (অনিরাপদভাবে) কীগুলি অর্জন করতে, কারণ এই সরবরাহকারীটি আর উপলব্ধ নেই৷ আরও তথ্যের জন্য, ব্লগ পোস্ট দেখুন নিরাপত্তা "Crypto" প্রদানকারী Android N-এ অবচয় ।