API স্তর: 21
নতুন বৈশিষ্ট্য এবং ক্ষমতার পাশাপাশি, Android 5.0-এ বিভিন্ন ধরনের সিস্টেম পরিবর্তন এবং API আচরণ পরিবর্তন অন্তর্ভুক্ত রয়েছে। এই দস্তাবেজটি কিছু মূল পরিবর্তনগুলিকে হাইলাইট করে যা আপনাকে বুঝতে হবে এবং আপনার অ্যাপ্লিকেশানগুলিতে অ্যাকাউন্ট করতে হবে৷
আপনি যদি আগে Android এর জন্য একটি অ্যাপ প্রকাশ করে থাকেন, তাহলে জেনে রাখুন যে আপনার অ্যাপটি Android 5.0-এ এই পরিবর্তনগুলির দ্বারা প্রভাবিত হতে পারে।
নতুন প্ল্যাটফর্ম বৈশিষ্ট্যগুলির একটি উচ্চ-স্তরের চেহারার জন্য, পরিবর্তে Android Lollipop হাইলাইটগুলি দেখুন৷
ভিডিও
ডেভ বাইট: অ্যান্ড্রয়েড 5.0-এ নতুন কী আছে
অ্যান্ড্রয়েড রানটাইম (ART)
অ্যান্ড্রয়েড 5.0-এ ART রানটাইম প্ল্যাটফর্ম ডিফল্ট হিসাবে Dalvik প্রতিস্থাপন করে। এআরটি রানটাইম একটি পরীক্ষামূলক ভিত্তিতে অ্যান্ড্রয়েড 4.4 এ চালু করা হয়েছিল।
ART-এর নতুন বৈশিষ্ট্যগুলির একটি সংক্ষিপ্ত বিবরণের জন্য, দেখুন ART এর পরিচয় । কিছু প্রধান নতুন বৈশিষ্ট্য হল:
- আগাম-সময় (AOT) সংকলন
- উন্নত আবর্জনা সংগ্রহ (GC)
- উন্নত ডিবাগিং সমর্থন
বেশিরভাগ অ্যান্ড্রয়েড অ্যাপ্লিকেশানগুলি ART এর অধীনে কোনও পরিবর্তন ছাড়াই কাজ করা উচিত। যাইহোক, ডালভিকে কাজ করে এমন কিছু কৌশল ART-তে কাজ করে না। সবচেয়ে গুরুত্বপূর্ণ বিষয় সম্পর্কে তথ্যের জন্য, Android রানটাইম (ART) এ অ্যাপ আচরণ যাচাইকরণ দেখুন। বিশেষ মনোযোগ দিন যদি:
- C/C++ কোড চালানোর জন্য আপনার অ্যাপ জাভা নেটিভ ইন্টারফেস (JNI) ব্যবহার করে।
- আপনি বিকাশের সরঞ্জামগুলি ব্যবহার করেন যা অ-মানক কোড তৈরি করে (যেমন কিছু অস্পষ্টকারী)।
- আপনি কৌশলগুলি ব্যবহার করেন যা আবর্জনা সংগ্রহের কম্প্যাক্ট করার সাথে বেমানান।
বিজ্ঞপ্তি
নিশ্চিত করুন যে আপনার বিজ্ঞপ্তিগুলি এই Android 5.0 পরিবর্তনগুলিকে বিবেচনায় নেয়৷ অ্যান্ড্রয়েড 5.0 এবং উচ্চতর সংস্করণের জন্য আপনার বিজ্ঞপ্তিগুলি ডিজাইন করার বিষয়ে আরও জানতে, বিজ্ঞপ্তি ডিজাইন গাইডটি দেখুন৷
উপাদান নকশা শৈলী
নতুন ম্যাটেরিয়াল ডিজাইন উইজেটগুলির সাথে মেলে সাদা (বা খুব হালকা) ব্যাকগ্রাউন্ডের উপরে গাঢ় টেক্সট দিয়ে বিজ্ঞপ্তিগুলি আঁকা হয়৷ নিশ্চিত করুন যে আপনার সমস্ত বিজ্ঞপ্তি নতুন রঙের স্কিমের সাথে সঠিক দেখাচ্ছে৷ যদি আপনার বিজ্ঞপ্তিগুলি ভুল মনে হয়, সেগুলি ঠিক করুন:
- আপনার আইকন চিত্রের পিছনে একটি বৃত্তে একটি উচ্চারণ রঙ সেট করতে
setColor()ব্যবহার করুন। - রঙ জড়িত সম্পদ আপডেট বা অপসারণ. সিস্টেমটি অ্যাকশন আইকনে এবং প্রধান বিজ্ঞপ্তি আইকনে সমস্ত নন-আলফা চ্যানেলকে উপেক্ষা করে। আপনার অনুমান করা উচিত যে এই আইকনগুলি শুধুমাত্র আলফা-ই হবে। সিস্টেমটি সাদা রঙে নোটিফিকেশন আইকন এবং গাঢ় ধূসর রঙে অ্যাকশন আইকন আঁকে।
শব্দ এবং কম্পন
আপনি যদি বর্তমানে Ringtone , MediaPlayer , বা Vibrator ক্লাস ব্যবহার করে আপনার বিজ্ঞপ্তিতে শব্দ এবং কম্পন যোগ করছেন, তাহলে এই কোডটি সরিয়ে দিন যাতে সিস্টেম অগ্রাধিকার মোডে সঠিকভাবে বিজ্ঞপ্তিগুলি উপস্থাপন করতে পারে৷ পরিবর্তে, শব্দ এবং কম্পন যোগ করতে Notification.Builder পদ্ধতি ব্যবহার করুন।
ডিভাইসটিকে RINGER_MODE_SILENT এ সেট করার ফলে ডিভাইসটিকে নতুন অগ্রাধিকার মোডে প্রবেশ করতে হবে। আপনি যদি RINGER_MODE_NORMAL বা RINGER_MODE_VIBRATE এ সেট করেন তাহলে ডিভাইসটি অগ্রাধিকার মোড ছেড়ে যায়।
পূর্বে, অ্যান্ড্রয়েড ট্যাবলেট ডিভাইসে ভলিউম নিয়ন্ত্রণ করতে STREAM_MUSIC মাস্টার স্ট্রিম হিসেবে ব্যবহার করত। Android 5.0-এ, ফোন এবং ট্যাবলেট উভয় ডিভাইসের জন্য মাস্টার ভলিউম স্ট্রীম এখন একীভূত, এবং STREAM_RING বা STREAM_NOTIFICATION দ্বারা নিয়ন্ত্রিত।
লক স্ক্রিন দৃশ্যমানতা
ডিফল্টরূপে, বিজ্ঞপ্তিগুলি এখন Android 5.0-এ ব্যবহারকারীর লক স্ক্রিনে উপস্থিত হয়৷ ব্যবহারকারীরা সংবেদনশীল তথ্য প্রকাশ করা থেকে রক্ষা করতে বেছে নিতে পারেন, এই ক্ষেত্রে সিস্টেম স্বয়ংক্রিয়ভাবে বিজ্ঞপ্তি দ্বারা প্রদর্শিত টেক্সট সংশোধন করে। এই সংশোধন করা বিজ্ঞপ্তিটি কাস্টমাইজ করতে, setPublicVersion() ব্যবহার করুন।
বিজ্ঞপ্তিতে যদি ব্যক্তিগত তথ্য না থাকে, অথবা আপনি বিজ্ঞপ্তিতে মিডিয়া প্লেব্যাক নিয়ন্ত্রণের অনুমতি দিতে চান, তাহলে setVisibility() পদ্ধতিতে কল করুন এবং বিজ্ঞপ্তির দৃশ্যমানতার স্তরটি VISIBILITY_PUBLIC এ সেট করুন।
মিডিয়া প্লেব্যাক
আপনি যদি মিডিয়া প্লেব্যাক স্ট্যাটাস বা ট্রান্সপোর্ট কন্ট্রোল উপস্থাপন করে এমন বিজ্ঞপ্তিগুলি প্রয়োগ করেন, তাহলে একটি কাস্টম RemoteViews.RemoteView অবজেক্টের পরিবর্তে নতুন Notification.MediaStyle টেমপ্লেট ব্যবহার করার কথা বিবেচনা করুন৷ আপনি যে পদ্ধতিই বেছে নিন না কেন, বিজ্ঞপ্তির দৃশ্যমানতা VISIBILITY_PUBLIC এ সেট করা নিশ্চিত করুন যাতে আপনার নিয়ন্ত্রণগুলি লক স্ক্রীন থেকে অ্যাক্সেসযোগ্য হয়৷ মনে রাখবেন যে Android 5.0 থেকে শুরু করে, সিস্টেমটি আর লক স্ক্রিনে RemoteControlClient অবজেক্টগুলি দেখায় না। আরও তথ্যের জন্য, দেখুন আপনার অ্যাপ RemoteControlClient ব্যবহার করে কিনা ।
হেড-আপ বিজ্ঞপ্তি
যখন ডিভাইসটি সক্রিয় থাকে (অর্থাৎ, ডিভাইসটি আনলক করা থাকে এবং এর স্ক্রীন চালু থাকে) তখন বিজ্ঞপ্তিগুলি এখন একটি ছোট ভাসমান উইন্ডোতে প্রদর্শিত হতে পারে (এটিকে একটি হেড-আপ বিজ্ঞপ্তিও বলা হয়)৷ এই বিজ্ঞপ্তিগুলি আপনার বিজ্ঞপ্তির কমপ্যাক্ট ফর্মের মতোই দেখা যায়, শুধুমাত্র হেড-আপ বিজ্ঞপ্তিটি অ্যাকশন বোতামগুলিও দেখায়। ব্যবহারকারীরা বর্তমান অ্যাপটি ছেড়ে না দিয়ে একটি হেড-আপ বিজ্ঞপ্তিতে কাজ করতে বা খারিজ করতে পারেন।
হেড-আপ বিজ্ঞপ্তিগুলিকে ট্রিগার করতে পারে এমন অবস্থার উদাহরণগুলির মধ্যে রয়েছে:
- ব্যবহারকারীর কার্যকলাপ ফুলস্ক্রিন মোডে রয়েছে (অ্যাপটি
fullScreenIntentব্যবহার করে) - বিজ্ঞপ্তির উচ্চ অগ্রাধিকার রয়েছে এবং রিংটোন বা কম্পন ব্যবহার করে
যদি আপনার অ্যাপ এই পরিস্থিতিতে যেকোনও ক্ষেত্রে বিজ্ঞপ্তি প্রয়োগ করে, নিশ্চিত করুন যে হেড-আপ বিজ্ঞপ্তিগুলি সঠিকভাবে উপস্থাপন করা হয়েছে।
মিডিয়া কন্ট্রোল এবং রিমোট কন্ট্রোল ক্লায়েন্ট
RemoteControlClient ক্লাস এখন অবহেলিত। যত তাড়াতাড়ি সম্ভব নতুন MediaSession API এ স্যুইচ করুন।
Android 5.0-এ লক স্ক্রিনগুলি আপনার MediaSession বা RemoteControlClient এর জন্য পরিবহন নিয়ন্ত্রণগুলি দেখায় না৷ পরিবর্তে, আপনার অ্যাপটি একটি বিজ্ঞপ্তির মাধ্যমে লক স্ক্রীন থেকে মিডিয়া প্লেব্যাক নিয়ন্ত্রণ প্রদান করতে পারে। লক করা এবং আনলক করা ডিভাইস জুড়ে ব্যবহারকারীদের জন্য একটি সামঞ্জস্যপূর্ণ অভিজ্ঞতা প্রদান করার সময় এটি আপনার অ্যাপটিকে মিডিয়া বোতামগুলির উপস্থাপনার উপর আরও নিয়ন্ত্রণ দেয়।
Android 5.0 এই উদ্দেশ্যে একটি নতুন Notification.MediaStyle টেমপ্লেট প্রবর্তন করেছে৷ Notification.MediaStyle আপনার অ্যাপের মিডিয়া প্লেব্যাক বিজ্ঞপ্তিগুলিতে এমবেড করা কমপ্যাক্ট বোতামগুলিতে Notification.Builder.addAction() এর সাথে যোগ করা বিজ্ঞপ্তিগুলিকে রূপান্তর করে৷ আপনার সেশন টোকেন setSession() পদ্ধতিতে পাঠান যাতে সিস্টেমকে জানানো হয় যে এই বিজ্ঞপ্তিটি একটি চলমান মিডিয়া সেশন নিয়ন্ত্রণ করে।
বিজ্ঞপ্তির দৃশ্যমানতা VISIBILITY_PUBLIC এ সেট করা নিশ্চিত করুন যাতে বিজ্ঞপ্তিটিকে যেকোনো লক স্ক্রিনে (নিরাপদ বা অন্যথায়) দেখানোর জন্য নিরাপদ হিসেবে চিহ্নিত করা যায়। আরও তথ্যের জন্য, লক স্ক্রিন বিজ্ঞপ্তিগুলি দেখুন।
আপনার অ্যাপ Android TV বা Wear প্ল্যাটফর্মে চলমান থাকলে মিডিয়া প্লেব্যাক নিয়ন্ত্রণগুলি প্রদর্শন করতে, MediaSession ক্লাসটি প্রয়োগ করুন। আপনার অ্যাপ্লিকেশানের যদি Android ডিভাইসে মিডিয়া বোতাম ইভেন্টগুলি গ্রহণ করার প্রয়োজন হয় তবে আপনার MediaSession প্রয়োগ করা উচিত।
RecentTasks() পান
অ্যান্ড্রয়েড 5.0-এ নতুন সমসাময়িক নথি এবং অ্যাক্টিভিটি টাস্ক ফিচারের প্রবর্তনের সাথে সাথে (নীচে সাম্প্রতিক স্ক্রিনে সমসাময়িক নথি এবং ক্রিয়াকলাপগুলি দেখুন), ব্যবহারকারীর গোপনীয়তা উন্নত করতে ActivityManager.getRecentTasks() পদ্ধতিটি এখন বাতিল করা হয়েছে৷ পশ্চাদপদ সামঞ্জস্যের জন্য, এই পদ্ধতিটি এখনও কলিং অ্যাপ্লিকেশনের নিজস্ব কাজ এবং সম্ভবত অন্যান্য অ-সংবেদনশীল কাজগুলি (যেমন হোম) সহ তার ডেটার একটি ছোট উপসেট ফেরত দেয়। যদি আপনার অ্যাপটি তার নিজস্ব কাজগুলি পুনরুদ্ধার করতে এই পদ্ধতিটি ব্যবহার করে তবে সেই তথ্য পুনরুদ্ধার করার পরিবর্তে getAppTasks() ব্যবহার করুন।
Android NDK-এ 64-বিট সমর্থন
Android 5.0 64-বিট সিস্টেমের জন্য সমর্থন প্রবর্তন করে। 64-বিট বর্ধিতকরণ ঠিকানার স্থান বৃদ্ধি করে এবং কর্মক্ষমতা উন্নত করে, যদিও এখনও বিদ্যমান 32-বিট অ্যাপগুলিকে সম্পূর্ণরূপে সমর্থন করে। 64-বিট সমর্থন ক্রিপ্টোগ্রাফির জন্য OpenSSL-এর কর্মক্ষমতাও উন্নত করে। এছাড়াও, এই রিলিজটি নতুন নেটিভ মিডিয়া NDK API, সেইসাথে নেটিভ OpenGL ES (GLES) 3.1 সমর্থন প্রবর্তন করে।
Android 5.0 এ প্রদত্ত 64-বিট সমর্থন ব্যবহার করতে, Android NDK পৃষ্ঠা থেকে NDK Revision 10c ডাউনলোড এবং ইনস্টল করুন। NDK-তে গুরুত্বপূর্ণ পরিবর্তন এবং বাগ ফিক্স সম্পর্কে আরও তথ্যের জন্য রিভিশন 10c রিলিজ নোট পড়ুন।
একটি পরিষেবাতে আবদ্ধ
Context.bindService() পদ্ধতির জন্য এখন একটি স্পষ্ট Intent প্রয়োজন, এবং যদি একটি অন্তর্নিহিত অভিপ্রায় দেওয়া হয় তবে একটি ব্যতিক্রম নিক্ষেপ করে। আপনার অ্যাপটি সুরক্ষিত তা নিশ্চিত করতে, আপনার Service শুরু বা আবদ্ধ করার সময় একটি স্পষ্ট অভিপ্রায় ব্যবহার করুন এবং পরিষেবাটির জন্য অভিপ্রায় ফিল্টার ঘোষণা করবেন না।
ওয়েবভিউ
Android 5.0 আপনার অ্যাপের জন্য ডিফল্ট আচরণ পরিবর্তন করে।
- যদি আপনার অ্যাপ এপিআই লেভেল 21 বা তার বেশি টার্গেট করে:
- সিস্টেম ডিফল্টরূপে মিশ্র বিষয়বস্তু এবং তৃতীয় পক্ষের কুকিজ ব্লক করে। মিশ্র সামগ্রী এবং তৃতীয় পক্ষের কুকিজকে অনুমতি দিতে, যথাক্রমে
setMixedContentMode()এবংsetAcceptThirdPartyCookies()পদ্ধতিগুলি ব্যবহার করুন৷ - সিস্টেম এখন আঁকতে এইচটিএমএল ডকুমেন্টের কিছু অংশ বুদ্ধিমত্তার সাথে বেছে নেয়। এই নতুন ডিফল্ট আচরণ মেমরি পদচিহ্ন কমাতে এবং কর্মক্ষমতা বাড়াতে সাহায্য করে। আপনি যদি একবারে পুরো নথিটি রেন্ডার করতে চান,
enableSlowWholeDocumentDraw()কল করে এই অপ্টিমাইজেশনটি অক্ষম করুন।
- সিস্টেম ডিফল্টরূপে মিশ্র বিষয়বস্তু এবং তৃতীয় পক্ষের কুকিজ ব্লক করে। মিশ্র সামগ্রী এবং তৃতীয় পক্ষের কুকিজকে অনুমতি দিতে, যথাক্রমে
- যদি আপনার অ্যাপ 21-এর থেকে কম API স্তরগুলিকে লক্ষ্য করে: সিস্টেমটি মিশ্র বিষয়বস্তু এবং তৃতীয় পক্ষের কুকিজকে অনুমতি দেয় এবং সর্বদা পুরো ডকুমেন্ট একবারে রেন্ডার করে।
কাস্টম অনুমতি জন্য স্বতন্ত্রতা প্রয়োজনীয়তা
অনুমতির ওভারভিউতে নথিভুক্ত হিসাবে, Android অ্যাপগুলি প্ল্যাটফর্মের পূর্ব-নির্ধারিত সিস্টেম অনুমতিগুলি ব্যবহার না করেই মালিকানাধীন উপায়ে উপাদানগুলিতে অ্যাক্সেস পরিচালনা করার উপায় হিসাবে কাস্টম অনুমতিগুলিকে সংজ্ঞায়িত করতে পারে। অ্যাপগুলি তাদের ম্যানিফেস্ট ফাইলগুলিতে ঘোষিত <permission> উপাদানগুলিতে কাস্টম অনুমতিগুলি সংজ্ঞায়িত করে।
এমন কিছু সংখ্যক পরিস্থিতি রয়েছে যেখানে কাস্টম অনুমতি সংজ্ঞায়িত করা একটি বৈধ এবং নিরাপদ পদ্ধতি। যাইহোক, কাস্টম অনুমতিগুলি তৈরি করা কখনও কখনও অপ্রয়োজনীয় এবং এমনকি অনুমতিগুলির জন্য নির্ধারিত সুরক্ষা স্তরের উপর নির্ভর করে একটি অ্যাপের সম্ভাব্য ঝুঁকিও প্রবর্তন করতে পারে৷
অ্যান্ড্রয়েড 5.0-এ একটি আচরণের পরিবর্তন রয়েছে যাতে শুধুমাত্র একটি অ্যাপ প্রদত্ত কাস্টম অনুমতি সংজ্ঞায়িত করতে পারে, যদি না অনুমতি সংজ্ঞায়িত অন্যান্য অ্যাপের মতো একই কী দিয়ে স্বাক্ষর করা হয়।
ডুপ্লিকেট কাস্টম অনুমতি ব্যবহার করে অ্যাপ্লিকেশন
যে কোনো অ্যাপ তার ইচ্ছামত কাস্টম অনুমতি সংজ্ঞায়িত করতে পারে, তাই এমন হতে পারে যে একাধিক অ্যাপ একই কাস্টম অনুমতি নির্ধারণ করতে পারে। উদাহরণস্বরূপ, যদি দুটি অ্যাপ একই ধরনের ক্ষমতা প্রদান করে, তবে তারা তাদের কাস্টম অনুমতিগুলির জন্য একই লজিক্যাল নাম পেতে পারে। অ্যাপ্লিকেশানগুলি সাধারণ পাবলিক লাইব্রেরি বা কোড উদাহরণগুলিও অন্তর্ভুক্ত করতে পারে যেগুলি নিজেরাই একই কাস্টম অনুমতি সংজ্ঞা অন্তর্ভুক্ত করে।
অ্যান্ড্রয়েড 4.4 এবং তার আগে, ব্যবহারকারীরা একটি প্রদত্ত ডিভাইসে এই জাতীয় একাধিক অ্যাপ ইনস্টল করতে সক্ষম হয়েছিল, যদিও সিস্টেমটি প্রথম ইনস্টল করা অ্যাপ দ্বারা নির্দিষ্ট সুরক্ষা স্তর নির্ধারণ করেছিল।
Android 5.0 থেকে শুরু করে, সিস্টেমটি বিভিন্ন কী দিয়ে স্বাক্ষর করা অ্যাপগুলির জন্য কাস্টম অনুমতিগুলিতে একটি নতুন স্বতন্ত্রতা বিধিনিষেধ প্রয়োগ করে৷ এখন একটি ডিভাইসে শুধুমাত্র একটি অ্যাপ একটি প্রদত্ত কাস্টম অনুমতি নির্ধারণ করতে পারে (যেমন এটির নাম দ্বারা নির্ধারিত), যদি না অনুমতি নির্ধারণকারী অন্য অ্যাপটি একই কী দিয়ে স্বাক্ষর করা হয়। ব্যবহারকারী যদি একটি ডুপ্লিকেট কাস্টম অনুমতি সহ একটি অ্যাপ ইনস্টল করার চেষ্টা করে এবং অনুমতিটি সংজ্ঞায়িত করে এমন রেসিডেন্ট অ্যাপের মতো একই কী দিয়ে সাইন ইন না করা হয়, তবে সিস্টেম ইনস্টলেশন ব্লক করে।
আপনার অ্যাপ্লিকেশন জন্য বিবেচনা
অ্যান্ড্রয়েড 5.0 এবং পরবর্তীতে, অ্যাপগুলি তাদের নিজস্ব কাস্টম অনুমতিগুলি ঠিক আগের মতোই সংজ্ঞায়িত করা চালিয়ে যেতে পারে এবং <uses-permission> > পদ্ধতির মাধ্যমে অন্যান্য অ্যাপ থেকে কাস্টম অনুমতির অনুরোধ করতে পারে। যাইহোক, Android 5.0-এ প্রবর্তিত নতুন প্রয়োজনীয়তার সাথে, আপনার অ্যাপে সম্ভাব্য প্রভাবগুলি সাবধানে মূল্যায়ন করা উচিত।
এখানে বিবেচনা করার জন্য কিছু পয়েন্ট আছে:
- আপনার অ্যাপ কি তার ম্যানিফেস্টে কোনো
<permission>উপাদান ঘোষণা করে? যদি তাই হয়, তাহলে কি আসলেই আপনার অ্যাপ বা পরিষেবার সঠিক ফাংশনের জন্য প্রয়োজনীয়? অথবা আপনি পরিবর্তে একটি সিস্টেম ডিফল্ট অনুমতি ব্যবহার করতে পারেন? - আপনার অ্যাপে যদি
<permission>উপাদান থাকে, আপনি কি জানেন সেগুলি কোথা থেকে এসেছে? - আপনি কি আসলেই অন্য অ্যাপের জন্য
<uses-permission>এর মাধ্যমে আপনার কাস্টম অনুমতির অনুরোধ করতে চান? - আপনি কি আপনার অ্যাপে বয়লারপ্লেট বা উদাহরণ কোড ব্যবহার করছেন যাতে
<permission>উপাদান রয়েছে? এই অনুমতি উপাদান আসলে প্রয়োজনীয়? - আপনার কাস্টম অনুমতিগুলি কি এমন নামগুলি ব্যবহার করে যা সাধারণ বা সাধারণ পদগুলির উপর ভিত্তি করে যা অন্য অ্যাপগুলি ভাগ করতে পারে?
নতুন ইনস্টল এবং আপডেট
উপরে উল্লিখিত হিসাবে, Android 4.4 বা তার আগের ডিভাইসগুলিতে আপনার অ্যাপের নতুন ইনস্টল এবং আপডেটগুলি প্রভাবিত হয় না এবং আচরণে কোনও পরিবর্তন হয় না। Android 5.0 বা তার পরে চলমান ডিভাইসগুলিতে নতুন ইনস্টল এবং আপডেটের জন্য, সিস্টেমটি আপনার অ্যাপের ইনস্টলেশন বাধা দেয় যদি এটি একটি কাস্টম অনুমতি নির্ধারণ করে যা ইতিমধ্যেই একটি বিদ্যমান বাসিন্দা অ্যাপ দ্বারা সংজ্ঞায়িত করা হয়েছে।
Android 5.0 সিস্টেম আপডেট সহ বিদ্যমান ইনস্টলগুলি৷
যদি আপনার অ্যাপটি কাস্টম অনুমতি ব্যবহার করে এবং ব্যাপকভাবে বিতরণ এবং ইনস্টল করা হয়, তাহলে ব্যবহারকারীরা তাদের ডিভাইসগুলিকে Android 5.0-এ আপডেট করার সময় এটি প্রভাবিত হওয়ার সম্ভাবনা রয়েছে। সিস্টেম আপডেট ইনস্টল করার পরে, সিস্টেম তাদের কাস্টম অনুমতিগুলির একটি চেক সহ ইনস্টল করা অ্যাপগুলিকে পুনরায় যাচাই করে। যদি আপনার অ্যাপটি এমন একটি কাস্টম অনুমতি সংজ্ঞায়িত করে যা ইতিমধ্যেই অন্য অ্যাপ দ্বারা সংজ্ঞায়িত করা হয়েছে যা ইতিমধ্যেই যাচাই করা হয়েছে এবং আপনার অ্যাপটি অন্য অ্যাপের মতো একই কী দিয়ে সাইন ইন করা না থাকে, তাহলে সিস্টেমটি আপনার অ্যাপ পুনরায় ইনস্টল করবে না ।
সুপারিশ
Android 5.0 বা তার পরবর্তী সংস্করণে চলমান ডিভাইসগুলিতে, আমরা সুপারিশ করি যে আপনি অবিলম্বে আপনার অ্যাপটি পরীক্ষা করুন, প্রয়োজনীয় কোনো সমন্বয় করুন এবং আপনার ব্যবহারকারীদের কাছে যত তাড়াতাড়ি সম্ভব আপডেট করা সংস্করণ প্রকাশ করুন।
- আপনি যদি আপনার অ্যাপে কাস্টম অনুমতি ব্যবহার করে থাকেন, তাহলে সেগুলোর উৎস এবং আপনার আসলে সেগুলি প্রয়োজন কিনা তা বিবেচনা করুন। আপনার অ্যাপ থেকে সমস্ত
<permission>উপাদানগুলি সরান, যদি না আপনি নিশ্চিত হন যে সেগুলি আপনার অ্যাপের সঠিক কার্যকারিতার জন্য প্রয়োজনীয়। - যেখানে সম্ভব সিস্টেম ডিফল্ট অনুমতি দিয়ে আপনার কাস্টম অনুমতি প্রতিস্থাপন বিবেচনা করুন.
- আপনার অ্যাপের কাস্টম অনুমতির প্রয়োজন হলে, আপনার অ্যাপের জন্য অনন্য হওয়ার জন্য আপনার কাস্টম অনুমতিগুলিকে পুনঃনামকরণ করুন, যেমন আপনার অ্যাপের সম্পূর্ণ প্যাকেজের নামের সাথে যুক্ত করে।
- যদি আপনার কাছে বিভিন্ন কী দিয়ে সাইন করা অ্যাপগুলির একটি স্যুট থাকে এবং অ্যাপগুলি একটি কাস্টম অনুমতির মাধ্যমে একটি ভাগ করা উপাদান অ্যাক্সেস করে, তবে নিশ্চিত করুন যে কাস্টম অনুমতিটি ভাগ করা উপাদানটিতে শুধুমাত্র একবার সংজ্ঞায়িত করা হয়েছে। যে অ্যাপগুলি শেয়ার্ড কম্পোনেন্ট ব্যবহার করে তাদের নিজেদের কাস্টম অনুমতি সংজ্ঞায়িত করা উচিত নয়, বরং
<uses-permission>পদ্ধতির মাধ্যমে অ্যাক্সেসের অনুরোধ করা উচিত। - যদি আপনার কাছে একই কী দিয়ে স্বাক্ষরিত অ্যাপগুলির একটি স্যুট থাকে, প্রতিটি অ্যাপ প্রয়োজন অনুযায়ী একই কাস্টম অনুমতি(গুলি) সংজ্ঞায়িত করতে পারে — সিস্টেম অ্যাপগুলিকে স্বাভাবিক উপায়ে ইনস্টল করার অনুমতি দেয়।
TLS/SSL ডিফল্ট কনফিগারেশন পরিবর্তন
Android 5.0 HTTPS এবং অন্যান্য TLS/SSL ট্র্যাফিকের জন্য অ্যাপগুলির দ্বারা ব্যবহৃত ডিফল্ট TLS/SSL কনফিগারেশন পরিবর্তন করে:
- TLSv1.2 এবং TLSv1.1 প্রোটোকল এখন সক্রিয় করা হয়েছে,
- AES-GCM (AEAD) সাইফার স্যুটগুলি এখন সক্ষম করা হয়েছে,
- MD5, 3DES, রপ্তানি, এবং স্ট্যাটিক কী ECDH সাইফার স্যুটগুলি এখন অক্ষম করা হয়েছে,
- ফরোয়ার্ড সিক্রেসি সাইফার স্যুট (ECDHE এবং DHE) পছন্দ করা হয়।
এই পরিবর্তনগুলি HTTPS বা TLS/SSL কানেক্টিভিটিতে বিচ্ছেদের দিকে নিয়ে যেতে পারে নীচে তালিকাভুক্ত অল্প সংখ্যক ক্ষেত্রে।
মনে রাখবেন যে Google Play পরিষেবাগুলি থেকে সুরক্ষা প্রদানকারী ইনস্টলার ইতিমধ্যেই Android 2.3-এ Android প্ল্যাটফর্ম সংস্করণগুলিতে এই পরিবর্তনগুলি অফার করে৷
সার্ভার কোনো সক্রিয় সাইফার স্যুট সমর্থন করে না
উদাহরণস্বরূপ, একটি সার্ভার শুধুমাত্র 3DES বা MD5 সাইফার স্যুট সমর্থন করতে পারে। শক্তিশালী এবং আরও আধুনিক সাইফার স্যুট এবং প্রোটোকল সক্ষম করতে সার্ভারের কনফিগারেশন উন্নত করাই পছন্দের সমাধান। আদর্শভাবে, TLSv1.2 এবং AES-GCM সক্ষম করা উচিত এবং ফরোয়ার্ড সিক্রেসি সাইফার স্যুটগুলি (ECDHE, DHE) সক্ষম করা উচিত এবং পছন্দ করা উচিত৷
একটি বিকল্প হল সার্ভারের সাথে যোগাযোগ করার জন্য একটি কাস্টম SSLSocketFactory ব্যবহার করার জন্য অ্যাপটি সংশোধন করা। কারখানাটি SSLSocket দৃষ্টান্ত তৈরি করার জন্য ডিজাইন করা উচিত যেখানে ডিফল্ট সাইফার স্যুটগুলি ছাড়াও সার্ভারের দ্বারা প্রয়োজনীয় কিছু সাইফার স্যুট রয়েছে৷
অ্যাপ সার্ভারের সাথে সংযোগ করতে ব্যবহৃত সাইফার স্যুট সম্পর্কে ভুল অনুমান করছে
উদাহরণ স্বরূপ, কিছু অ্যাপে একটি কাস্টম X509TrustManager থাকে যা ভেঙে যায় কারণ এটি authType প্যারামিটারটি RSA হওয়ার আশা করে কিন্তু ECDHE_RSA বা DHE_RSA এর সম্মুখীন হয়।
সার্ভার TLSv1.1, TLSv1.2 বা নতুন TLS এক্সটেনশনের প্রতি অসহিষ্ণু
উদাহরণস্বরূপ, সার্ভারের সাথে TLS/SSL হ্যান্ডশেক ভুলভাবে প্রত্যাখ্যান করা হয়েছে বা স্টল করা হয়েছে। TLS/SSL প্রোটোকল মেনে চলার জন্য সার্ভার আপগ্রেড করাই পছন্দের সমাধান। এটি সার্ভারকে সফলভাবে এই নতুন প্রোটোকলগুলির সাথে আলোচনা করতে বা TLSv1 বা পুরানো প্রোটোকলগুলির সাথে আলোচনা করতে এবং TLS এক্সটেনশানগুলিকে উপেক্ষা করতে সাহায্য করবে যা এটি বুঝতে পারে না৷ কিছু ক্ষেত্রে সার্ভারে TLSv1.1 এবং TLSv1.2 নিষ্ক্রিয় করা সার্ভার সফ্টওয়্যার আপগ্রেড না হওয়া পর্যন্ত একটি স্টপগ্যাপ পরিমাপ হিসাবে কাজ করতে পারে।
একটি বিকল্প হল সার্ভারের সাথে যোগাযোগ করার জন্য একটি কাস্টম SSLSocketFactory ব্যবহার করার জন্য অ্যাপটি সংশোধন করা। ফ্যাক্টরিটি কেবলমাত্র সেই প্রোটোকলগুলির সাহায্যে SSLSocket দৃষ্টান্ত তৈরি করার জন্য ডিজাইন করা উচিত যা সার্ভার দ্বারা সঠিকভাবে সমর্থিত।
পরিচালিত প্রোফাইলের জন্য সমর্থন
ডিভাইস অ্যাডমিনিস্ট্রেটররা একটি ডিভাইসে একটি পরিচালিত প্রোফাইল যোগ করতে পারেন। এই প্রোফাইলটি অ্যাডমিনিস্ট্রেটরের মালিকানাধীন, ব্যবহারকারীর ব্যক্তিগত প্রোফাইল এবং এর স্টোরেজ স্পেস ব্যবহারকারীর নিয়ন্ত্রণে রেখে প্রশাসককে পরিচালিত প্রোফাইলের উপর নিয়ন্ত্রণ দেয়৷ এই পরিবর্তনটি নিম্নলিখিত উপায়ে আপনার বিদ্যমান অ্যাপের আচরণকে প্রভাবিত করতে পারে।
উদ্দেশ্য হ্যান্ডলিং
ডিভাইস প্রশাসকরা পরিচালিত প্রোফাইল থেকে সিস্টেম অ্যাপ্লিকেশনগুলিতে অ্যাক্সেস সীমাবদ্ধ করতে পারে৷ এই ক্ষেত্রে, যদি একটি অ্যাপ পরিচালিত প্রোফাইল থেকে এমন একটি অভিপ্রায় ফায়ার করে যা সাধারণত সেই অ্যাপ্লিকেশন দ্বারা পরিচালনা করা হবে এবং পরিচালিত প্রোফাইলে অভিপ্রায়ের জন্য কোনও উপযুক্ত হ্যান্ডলার নেই, তাহলে অভিপ্রায় একটি ব্যতিক্রম ঘটায়। উদাহরণস্বরূপ, ডিভাইস অ্যাডমিনিস্ট্রেটর সিস্টেমের ক্যামেরা অ্যাপ্লিকেশন অ্যাক্সেস করা থেকে পরিচালিত প্রোফাইলে অ্যাপ্লিকেশনগুলিকে সীমাবদ্ধ করতে পারে৷ যদি আপনার অ্যাপটি পরিচালিত প্রোফাইলে চলছে এবং MediaStore.ACTION_IMAGE_CAPTURE এর জন্য startActivityForResult() কে কল করে, এবং পরিচালিত প্রোফাইলে এমন কোনও অ্যাপ না থাকে যা উদ্দেশ্য পরিচালনা করতে পারে, তাহলে এটি একটি ActivityNotFoundException হিসাবে পরিণত হয়।
গুলি চালানোর আগে যেকোনো উদ্দেশ্যের জন্য অন্তত একজন হ্যান্ডলার আছে কিনা তা পরীক্ষা করে আপনি এটি প্রতিরোধ করতে পারেন। একটি বৈধ হ্যান্ডলার চেক করতে, Intent.resolveActivity() কল করুন। আপনি এটি করার একটি উদাহরণ দেখতে পারেন ফটোগুলি সহজভাবে নিন: ক্যামেরা অ্যাপের সাথে একটি ফটো নিন ৷
প্রোফাইল জুড়ে ফাইল শেয়ার করা
প্রতিটি প্রোফাইলের নিজস্ব ফাইল স্টোরেজ আছে। যেহেতু একটি ফাইল ইউআরআই ফাইল স্টোরেজের একটি নির্দিষ্ট অবস্থানকে নির্দেশ করে, এর মানে হল যে একটি ফাইল ইউআরআই যা একটি প্রোফাইলে বৈধ তা অন্যটিতে বৈধ নয়। এটি সাধারণত একটি অ্যাপের জন্য একটি সমস্যা নয়, যা সাধারণত এটি তৈরি করা ফাইলগুলি অ্যাক্সেস করে। যাইহোক, যদি কোনও অ্যাপ কোনও উদ্দেশ্যের সাথে একটি ফাইল সংযুক্ত করে, তাহলে একটি ফাইল URI সংযুক্ত করা নিরাপদ নয়, কারণ কিছু পরিস্থিতিতে, উদ্দেশ্যটি অন্য প্রোফাইলে পরিচালনা করা যেতে পারে। উদাহরণস্বরূপ, একটি ডিভাইস প্রশাসক নির্দিষ্ট করতে পারে যে ছবি ক্যাপচার ইভেন্টগুলি ব্যক্তিগত প্রোফাইলে ক্যামেরা অ্যাপ দ্বারা পরিচালনা করা উচিত। যদি পরিচালিত প্রোফাইলে কোনও অ্যাপের দ্বারা উদ্দেশ্যটি বরখাস্ত করা হয়, তবে ক্যামেরাটিকে এমন একটি অবস্থানে চিত্রটি লিখতে সক্ষম হতে হবে যেখানে পরিচালিত প্রোফাইলের অ্যাপগুলি এটি পড়তে পারে।
নিরাপদ থাকার জন্য, যখন আপনাকে একটি উদ্দেশ্যের সাথে একটি ফাইল সংযুক্ত করতে হবে যা একটি প্রোফাইল থেকে অন্য প্রোফাইলে ক্রস করতে পারে, তখন আপনাকে ফাইলটির জন্য একটি সামগ্রী URI তৈরি এবং ব্যবহার করা উচিত৷ বিষয়বস্তু URI-এর সাথে ফাইল শেয়ার করার বিষয়ে আরও তথ্যের জন্য, ফাইল শেয়ার করা দেখুন। উদাহরণস্বরূপ, ডিভাইস প্রশাসক ACTION_IMAGE_CAPTURE ব্যক্তিগত প্রোফাইলে ক্যামেরা দ্বারা পরিচালনা করার অনুমতি দিতে পারে৷ গুলি চালানোর অভিপ্রায়ের EXTRA_OUTPUT ফটোটি কোথায় সংরক্ষণ করা উচিত তা নির্দিষ্ট করে একটি বিষয়বস্তু URI থাকা উচিত৷ ক্যামেরা অ্যাপটি সেই URI দ্বারা নির্দিষ্ট করা অবস্থানে ছবিটি লিখতে পারে এবং যে অ্যাপটি অভিপ্রায় ত্যাগ করেছে সে সেই ফাইলটি পড়তে সক্ষম হবে, এমনকি অ্যাপটি অন্য প্রোফাইলে থাকলেও।
লকস্ক্রিন উইজেট সমর্থন সরানো হয়েছে
অ্যান্ড্রয়েড 5.0 লকস্ক্রিন উইজেটগুলির জন্য সমর্থন সরিয়ে দেয়; এটি হোম স্ক্রিনে উইজেট সমর্থন করে চলেছে।