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 এর প্রস্থ।

একটি Android 7.0 সিস্টেম ইমেজ চলমান ডিভাইসের আনজুম না করা ডিসপ্লে সাইজ দেখানো স্ক্রীন
একটি Android 7.0 সিস্টেম ইমেজ চলমান একটি ডিভাইসের প্রদর্শনের আকার বৃদ্ধির প্রভাব দেখায় স্ক্রীন৷

চিত্র 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 দিয়ে আপনার সমস্ত নন-NDK লাইব্রেরি প্যাকেজ করেছেন।
  • 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-এ অবচয় ।
,

নতুন বৈশিষ্ট্য এবং ক্ষমতার পাশাপাশি, 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 এপিআই যখন নির্দিষ্ট শর্তগুলি যেমন একটি আনমেটারড নেটওয়ার্কের সাথে সংযোগ স্থাপন করা হয় তখন নেটওয়ার্ক অপারেশনগুলির সময়সূচী করার জন্য একটি শক্তিশালী প্রক্রিয়া সরবরাহ করে। এমনকি সামগ্রী সরবরাহকারীদের পরিবর্তনের প্রতিক্রিয়া জানাতে আপনিও JobScheduler ব্যবহার করতে পারেন।

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

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

অ্যান্ড্রয়েড 7.0 এর মধ্যে অনুমতিগুলির পরিবর্তনগুলি অন্তর্ভুক্ত রয়েছে যা আপনার অ্যাপ্লিকেশনটিকে প্রভাবিত করতে পারে।

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

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

  • প্রাইভেট ফাইলগুলির ফাইলের অনুমতিগুলি আর মালিকের দ্বারা স্বাচ্ছন্দ্য বোধ করা উচিত নয় এবং MODE_WORLD_READABLE এবং/অথবা MODE_WORLD_WRITEABLE ব্যবহার করে এটি করার চেষ্টা করা একটি SecurityException ট্রিগার করবে।

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

  • পাসিং file:// প্যাকেজ ডোমেনের বাইরে ইউআরআইগুলি অ্যাক্সেসযোগ্য পথ দিয়ে রিসিভারটি ছেড়ে যেতে পারে। অতএব, একটি file:// ইউআরআই একটি 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() ব্যবহার করছে।

অ্যাপ্লিকেশনগুলির মধ্যে ফাইল ভাগ করে নেওয়া

অ্যান্ড্রয়েড .0.০ লক্ষ্য করে অ্যাপ্লিকেশনগুলির জন্য, অ্যান্ড্রয়েড ফ্রেমওয়ার্কটি StrictMode এপিআই নীতি প্রয়োগ করে যা আপনার অ্যাপ্লিকেশনটির বাইরে file:// ইউআরআইদের এক্সপোজিং নিষিদ্ধ করে। যদি কোনও ফাইল ইউআরআইযুক্ত কোনও অভিপ্রায় আপনার অ্যাপ্লিকেশনটি ছেড়ে যায় তবে অ্যাপ্লিকেশনটি FileUriExposedException ব্যতিক্রমের সাথে ব্যর্থ হয়।

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

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

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

স্ক্রীন জুম

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

স্ক্রিনটি অ্যান্ড্রয়েড 7.0 সিস্টেম ইমেজ চালানো ডিভাইসের আনজুমড ডিসপ্লে আকার দেখায়
স্ক্রিনটি অ্যান্ড্রয়েড 7.0 সিস্টেম চিত্র চালানো কোনও ডিভাইসের ডিসপ্লে আকার বাড়ানোর প্রভাব দেখায়

চিত্র 3. ডানদিকে স্ক্রিনটি অ্যান্ড্রয়েড 7.0 সিস্টেম চিত্র চালানো কোনও ডিভাইসের ডিসপ্লে আকার বাড়ানোর প্রভাব দেখায়।

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

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

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

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

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

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

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

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

প্ল্যাটফর্ম লাইব্রেরিতে সংযুক্ত এনডিকে অ্যাপ্লিকেশন

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

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

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

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

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

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

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

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

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

বেসরকারী লাইব্রেরিগুলি লোড করার সমস্যাগুলি সনাক্ত করতে আপনাকে সহায়তা করতে, লগক্যাট একটি সতর্কতা বা রানটাইম ত্রুটি তৈরি করতে পারে। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশনটি এপিআই স্তর 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

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

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)

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

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

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

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

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

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

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

কাজের জন্য Android

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

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

টীকা ধরে রাখা

অ্যান্ড্রয়েড .0.০ একটি বাগ ঠিক করে যেখানে টীকাগুলির দৃশ্যমানতা উপেক্ষা করা হচ্ছে। এই সমস্যাটি রানটাইমকে টীকাগুলি অ্যাক্সেস করতে সক্ষম করেছে যা এটি সক্ষম হওয়া উচিত ছিল না। এই টীকাগুলি অন্তর্ভুক্ত:

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

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

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

অ্যান্ড্রয়েড 7.0 এইচটিটিপিএস এবং অন্যান্য টিএলএস/এসএসএল ট্র্যাফিকের জন্য অ্যাপ্লিকেশন দ্বারা ব্যবহৃত ডিফল্ট টিএলএস/এসএসএল কনফিগারেশনে নিম্নলিখিত পরিবর্তনগুলি করে:

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

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

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

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

অ্যান্ড্রয়েড 7.0 লক্ষ্য করে অ্যাপ্লিকেশনগুলি

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

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

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

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

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

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

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

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

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

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

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

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

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