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

নতুন ফিচার ও ক্ষমতার সাথে, Android 7.0-এ বিভিন্ন সিস্টেম ও API আচরণ পরিবর্তন অন্তর্ভুক্ত আছে। এই ডকুমেন্ট কিছু গুরুত্বপূর্ণ পরিবর্তন হাইলাইট করে যা আপনাকে বুঝতে হবে এবং আপনার অ্যাপে সেগুলি বিবেচনা করতে হবে।

আপনি আগে Android-এর জন্য কোনও অ্যাপ প্রকাশ করে থাকলে, মনে রাখবেন যে প্ল্যাটফর্মে করা এইসব পরিবর্তনের ফলে আপনার অ্যাপ প্রভাবিত হতে পারে।

ব্যাটারি ও মেমরি

Android 7.0-এ সিস্টেমের আচরণে পরিবর্তন করা হয়েছে যার লক্ষ্য হল ডিভাইসের ব্যাটারির আয়ু উন্নত করা এবং RAM-এর ব্যবহার কমানো। এইসব পরিবর্তন আপনার অ্যাপের সিস্টেম রিসোর্স অ্যাক্সেস করার ক্ষমতাকে প্রভাবিত করতে পারে, সেইসাথে নির্দিষ্ট ইমপ্লিসিট ইনটেন্ট ব্যবহার করে আপনার অ্যাপ অন্যান্য অ্যাপের সাথে যেভাবে ইন্টার‍্যাক্ট করে তাও প্রভাবিত হতে পারে।

ডজ করুন

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

ব্যাটারির আয়ু বাড়াতে Doze কীভাবে সিস্টেম অ্যাক্টিভিটির উপর প্রথম লেভেলের বিধিনিষেধ প্রয়োগ করে তার ইলাস্ট্রেশন

ছবি ১. ব্যাটারির আয়ু বাড়াতে Doze কীভাবে সিস্টেম অ্যাক্টিভিটির উপর প্রথম লেভেলের বিধিনিষেধ আরোপ করে তার ইলাস্ট্রেশন।

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

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

ছবি ২. ডিভাইসটি নির্দিষ্ট সময়ের জন্য স্থির থাকার পরে Doze কীভাবে সিস্টেম অ্যাক্টিভিটি সংক্রান্ত বিধিনিষেধের দ্বিতীয় লেভেল প্রয়োগ করে তার ইলাস্ট্রেশন।

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

Project Svelte: ব্যাকগ্রাউন্ড অপ্টিমাইজেশন

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

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

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

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

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

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

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

অনুমতি সংক্রান্ত পরিবর্তন

Android 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 অ্যাক্সেস করার সময় লিগ্যাসি অ্যাপ্লিকেশন অ্যাক্সেস করা যায় না এমন পাথে শেষ হতে পারে। Android 7.0 বা তার পরবর্তী ভার্সনকে টার্গেট করা অ্যাপ COLUMN_LOCAL_FILENAME অ্যাক্সেস করার চেষ্টা করলে SecurityException ট্রিগার করে। যেসব লিগ্যাসি অ্যাপ্লিকেশন DownloadManager.Request.setDestinationInExternalFilesDir() বা DownloadManager.Request.setDestinationInExternalPublicDir() ব্যবহার করে ডাউনলোডের লোকেশন সর্বজনীন লোকেশনে সেট করে, সেগুলি এখনও COLUMN_LOCAL_FILENAME-এ পাথ অ্যাক্সেস করতে পারে, তবে এই পদ্ধতি ব্যবহার করার জন্য একেবারেই উৎসাহ দেওয়া হয় না। DownloadManager-এর মাধ্যমে প্রকাশ করা ফাইল অ্যাক্সেস করার পছন্দসই উপায় হল ContentResolver.openFileDescriptor() ব্যবহার করা।

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

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

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

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

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

স্ক্রিন জুম

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

Android 7.0 সিস্টেম ইমেজ চলছে এমন ডিভাইসের জুম না করা ডিসপ্লে সাইজ স্ক্রিনে দেখানো হচ্ছে
Android 7.0 সিস্টেম ইমেজ রান করছে এমন ডিভাইসের ডিসপ্লে সাইজ বাড়ানোর প্রভাব স্ক্রিনে দেখানো হচ্ছে

ছবি ৩. ডানদিকের স্ক্রিনে Android 7.0 সিস্টেম ইমেজ রান করছে এমন ডিভাইসের ডিসপ্লে সাইজ বাড়ানোর প্রভাব দেখানো হয়েছে।

ডিভাইসের ডেনসিটি পরিবর্তন হলে, সিস্টেম নিম্নলিখিত উপায়ে চালু থাকা অ্যাপকে বিজ্ঞপ্তি পাঠায়:

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

এই ফিচার কাজ করার জন্য বেশিরভাগ অ্যাপে কোনও পরিবর্তন করতে হয় না, তবে অ্যাপগুলিকে Android-এর পেশাদার পদ্ধতি অনুসরণ করতে হবে। নির্দিষ্ট কিছু জিনিস চেক করতে হবে:

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

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

  • px ইউনিটে ডাইমেনশন উল্লেখ করবেন না, কারণ স্ক্রিন ডেনসিটির সাথে এটি স্কেল করা যায় না। পরিবর্তে, density-independent pixel (dp) ইউনিটের মাধ্যমে ডাইমেনশন নির্দিষ্ট করুন।

সেট-আপ উইজার্ডে ভিশন সেটিংস

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

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

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

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

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

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

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

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

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

লাইব্রেরি টার্গেট API লেভেল ডায়নামিক লিঙ্কার ব্যবহার করে রানটাইম অ্যাক্সেস Android 7.0 (API লেভেল ২৪) আচরণ ভবিষ্যতে Android প্ল্যাটফর্মের আচরণ
NDK Public যেকোনও অ্যাক্সেস করার উপযুক্ত প্রত্যাশিতভাবে কাজ করে প্রত্যাশিতভাবে কাজ করে
ব্যক্তিগত (সাময়িকভাবে অ্যাক্সেসযোগ্য ব্যক্তিগত লাইব্রেরি) ২৩ বা তার কম সাময়িকভাবে অ্যাক্সেসযোগ্য প্রত্যাশিতভাবে কাজ করে, তবে আপনি একটি লগক্যাট সতর্কতা পান। রানটাইম সমস্যা
ব্যক্তিগত (সাময়িকভাবে অ্যাক্সেসযোগ্য ব্যক্তিগত লাইব্রেরি) ২৪ বা তার বেশি বিধিনিষেধযুক্ত রানটাইম সমস্যা রানটাইম সমস্যা
ব্যক্তিগত (অন্যান্য) যেকোনও বিধিনিষেধযুক্ত রানটাইম সমস্যা রানটাইম সমস্যা

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

ব্যক্তিগত লাইব্রেরি লোড করার সময় সমস্যা শনাক্ত করতে আপনাকে সাহায্য করার জন্য, logcat একটি সতর্কতা বা রানটাইম সমস্যা তৈরি করতে পারে। যেমন, আপনার অ্যাপ API লেভেল ২৩ বা তার কম টার্গেট করলে এবং Android 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 লেভেল ২৪ বা তার বেশি টার্গেট করলে, 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-এর সাথে ডাইনামিকভাবে লিঙ্ক করে, তাহলে আপনি এই logcat আউটপুটগুলিও দেখতে পারেন। Android 7.0 NDK-তে readelf টুল আপনাকে নিম্নলিখিত কমান্ড রান করে প্রদত্ত .so ফাইলের সব ডায়নামিকালি লিঙ্ক করা শেয়ার করা লাইব্রেরির তালিকা তৈরি করতে দেয়: 

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

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

এই ধরনের সমস্যা সমাধান করতে এবং ভবিষ্যতে প্ল্যাটফর্ম আপডেট করার সময় আপনার অ্যাপ যাতে ক্র্যাশ না করে তা নিশ্চিত করতে, আপনি এইসব পদক্ষেপ নিতে পারেন:

  • আপনার অ্যাপ যদি ব্যক্তিগত প্ল্যাটফর্ম লাইব্রেরি ব্যবহার করে, তাহলে আপনাকে এটি আপডেট করতে হবে যাতে এতে সেই লাইব্রেরির নিজস্ব কপি অন্তর্ভুক্ত থাকে বা পাবলিক NDK API ব্যবহার করতে হবে।
  • আপনার অ্যাপ যদি এমন কোনও থার্ড-পার্টি লাইব্রেরি ব্যবহার করে যা ব্যক্তিগত চিহ্ন অ্যাক্সেস করে, তাহলে লাইব্রেরি আপডেট করার জন্য লাইব্রেরির লেখকের সাথে যোগাযোগ করুন।
  • আপনার APK-এর সাথে সব নন-NDK লাইব্রেরি প্যাকেজ করেছেন কিনা তা ভাল করে দেখে নিন।
  • getJavaVM এবং getJNIEnv-এর পরিবর্তে libandroid_runtime.so থেকে স্ট্যান্ডার্ড 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 লেভেল ২৪) টার্গেট করা প্রোফাইল ও ডিভাইস-মালিক অ্যাপের জন্য, ডিভাইস নীতি কন্ট্রোলার (DPC) DevicePolicyManager.setCertInstallerPackage() কল করার আগে আপনাকে ডেলিগেট করা সার্টিফিকেট ইনস্টলার ইনস্টল করতে হবে। ইনস্টলার আগে থেকে ইনস্টল করা না থাকলে, সিস্টেম একটি IllegalArgumentException দেখায়।
  • ডিভাইস অ্যাডমিনের জন্য পাসওয়ার্ড রিসেট করার বিধিনিষেধ এখন প্রোফাইল মালিকের ক্ষেত্রে প্রযোজ্য। ডিভাইস অ্যাডমিনরা আর DevicePolicyManager.resetPassword() ব্যবহার করে পাসওয়ার্ড মুছে ফেলতে বা আগে থেকে সেট করা পাসওয়ার্ড পরিবর্তন করতে পারবেন না। ডিভাইস অ্যাডমিন এখনও পাসওয়ার্ড সেট করতে পারবেন, তবে শুধুমাত্র ডিভাইসে কোনও পাসওয়ার্ড, পিন বা প্যাটার্ন না থাকলে।
  • বিধিনিষেধ সেট করা থাকলেও ডিভাইস ও প্রোফাইলের মালিক অ্যাকাউন্ট ম্যানেজ করতে পারবেন। ডিভাইসের মালিক এবং প্রোফাইলের মালিক অ্যাকাউন্ট ম্যানেজমেন্ট API কল করতে পারেন এমনকি DISALLOW_MODIFY_ACCOUNTS ব্যবহারকারীর উপর বিধিনিষেধ থাকলেও।
  • ডিভাইসের মালিক সেকেন্ডারি ব্যবহারকারীদের ম্যানেজ করতে পারবেন। কোনও ডিভাইস ডিভাইস মালিক মোডে চললে, DISALLOW_ADD_USER সংক্রান্ত বিধিনিষেধ অটোমেটিক সেট হয়ে যায়। এটি ব্যবহারকারীদের ম্যানেজ না করা সেকেন্ডারি ব্যবহারকারী তৈরি করা থেকে আটকায়। এছাড়াও, CreateUser() এবং createAndInitializeUser() পদ্ধতি বন্ধ করা হয়েছে; নতুন DevicePolicyManager.createAndManageUser() পদ্ধতি সেগুলির জায়গা নিয়েছে।
  • ডিভাইসের মালিকরা ডিভাইস শনাক্তকারী অ্যাক্সেস করতে পারবেন। ডিভাইসের মালিক DevicePolicyManager.getWifiMacAddress() ব্যবহার করে ডিভাইসের ওয়াই-ফাই MAC অ্যাড্রেস অ্যাক্সেস করতে পারবেন। ডিভাইসে ওয়াই-ফাই কখনও চালু করা না হয়ে থাকলে, এই পদ্ধতি null ভ্যালু দেখায়।
  • 'অফিস মোড' সেটিং অফিস অ্যাপের অ্যাক্সেস নিয়ন্ত্রণ করে। অফিস মোড বন্ধ থাকলে, সিস্টেম লঞ্চার অফিসের অ্যাপগুলিকে গ্রে-আউট করে দেখায় যে সেগুলি উপলভ্য নেই। অফিস মোড আবার চালু করলে স্বাভাবিক আচরণ ফিরে আসে।
  • সেটিংস UI থেকে ক্লায়েন্ট সার্টিফিকেট চেন ও সংশ্লিষ্ট ব্যক্তিগত কী সহ PKCS #12 ফাইল ইনস্টল করার সময়, চেনে থাকা CA সার্টিফিকেট আর বিশ্বস্ত ক্রেডেনশিয়াল স্টোরেজে ইনস্টল করা হয় না। অ্যাপ পরে ক্লায়েন্ট সার্টিফিকেট চেন উদ্ধার করার চেষ্টা করলে, এটি KeyChain.getCertificateChain()-এর ফলাফলের উপর কোনও প্রভাব ফেলে না। প্রয়োজন হলে, .crt বা .cer ফাইল এক্সটেনশনের অধীনে DER-এনকোডেড ফর্ম্যাট সহ সেটিংস UI আলাদাভাবে ব্যবহার করে বিশ্বস্ত ক্রেডেনশিয়াল স্টোরেজে CA সার্টিফিকেট ইনস্টল করতে হবে।
  • Android 7.0 থেকে শুরু করে, ফিঙ্গারপ্রিন্টের এনরোলমেন্ট এবং স্টোরেজ ব্যবহারকারী প্রতি ম্যানেজ করা হয়। Android 7.0 (API লেভেল ২৪) ভার্সনে চলা ডিভাইসে প্রোফাইল মালিকের ডিভাইস নীতি ক্লায়েন্ট (DPC) API লেভেল ২৩ (বা তার কম) টার্গেট করলে, ব্যবহারকারী ডিভাইসে ফিঙ্গারপ্রিন্ট সেট করতে পারবেন, তবে অফিস অ্যাপ্লিকেশন ডিভাইসের ফিঙ্গারপ্রিন্ট অ্যাক্সেস করতে পারবে না। DPC-এর টার্গেট API লেভেল ২৪ বা তার বেশি হলে, ব্যবহারকারী সেটিংস > সুরক্ষা > ওয়ার্ক প্রোফাইল সুরক্ষা বিকল্পে গিয়ে ওয়ার্ক প্রোফাইলের জন্য নির্দিষ্টভাবে ফিঙ্গারপ্রিন্ট সেট করতে পারবেন।
  • DevicePolicyManager.getStorageEncryptionStatus()-এর মাধ্যমে একটি নতুন এনক্রিপশন স্ট্যাটাস ENCRYPTION_STATUS_ACTIVE_PER_USER ফেরত পাঠানো হয়, যাতে বোঝা যায় যে এনক্রিপশন অ্যাক্টিভ আছে এবং এনক্রিপশন কী ব্যবহারকারীর সাথে যুক্ত আছে। DPC, API লেভেল ২৪ এবং তার উপরের লেভেলকে টার্গেট করলে তবেই নতুন স্ট্যাটাস রিটার্ন করা হয়। আগের API লেভেল টার্গেট করা অ্যাপের ক্ষেত্রে, ENCRYPTION_STATUS_ACTIVE ফেরত পাঠানো হয়, এমনকি এনক্রিপশন কী ব্যবহারকারী বা প্রোফাইলের জন্য নির্দিষ্ট হলেও।
  • Android 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 লেভেল ২৪) বা তার পরবর্তী যেকোনও ভার্সনকে টার্গেট করছে। Android 7.0-এর সাথে কম্পাইল করা অ্যাপ, অথবা Android 7.0 বা তার পরবর্তী ভার্সনে targetSdkVersion সেট করা অ্যাপকে অবশ্যই এই আচরণগুলি সঠিকভাবে সাপোর্ট করার জন্য তাদের অ্যাপগুলি পরিবর্তন করতে হবে, যেখানে অ্যাপের ক্ষেত্রে প্রযোজ্য।

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

Android 7.0 (API লেভেল 24) ডিফল্ট serialVersionUID-এর গণনায় একটি সমস্যার সমাধান করেছে যেখানে এটি স্পেসিফিকেশনের সাথে মেলেনি।

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

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

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

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

স্পষ্ট করে বলতে গেলে, এই পরিবর্তনটি API লেভেল ২৩ বা তার কম টার্গেট করা অ্যাপ, serialVersionUID ফিল্ড আছে এমন ক্লাস বা স্ট্যাটিক ইনিশিয়ালাইজার পদ্ধতি আছে এমন ক্লাসের উপর প্রভাব ফেলে না।

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

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

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

    Android 7.0 (API লেভেল ২৪) এবং তার পরবর্তী ভার্সন টার্গেট করা অ্যাপগুলি ডেনসিটি পরিবর্তনের কারণে অটোমেটিক বন্ধ হয়ে যায় না; তবে, কনফিগারেশন পরিবর্তনের ক্ষেত্রে সেগুলি এখনও খারাপভাবে প্রতিক্রিয়া জানাতে পারে।

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