SDK রানটাইম ওভারভিউ

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

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

অ্যান্ড্রয়েড ১৪-তে, আমরা একটি নতুন প্ল্যাটফর্ম ক্ষমতা যুক্ত করেছি যা তৃতীয় পক্ষের SDK গুলিকে SDK রানটাইম নামে একটি ডেডিকেটেড রানটাইম পরিবেশে চালানোর অনুমতি দেয়। SDK রানটাইম ব্যবহারকারীর ডেটা সংগ্রহ এবং ভাগ করে নেওয়ার ক্ষেত্রে নিম্নলিখিত শক্তিশালী সুরক্ষা এবং নিশ্চয়তা প্রদান করে:

• একটি পরিবর্তিত কার্যকরকরণ পরিবেশ
• SDK-এর জন্য সু-সংজ্ঞায়িত অনুমতি এবং ডেটা অ্যাক্সেস অধিকার

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

লক্ষ্য

এই প্রস্তাবটি নিম্নলিখিত লক্ষ্যগুলি অর্জনের চেষ্টা করে:

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

SDK গুলি একটি বিচ্ছিন্ন প্রক্রিয়ায় কার্যকর করা হয়

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

SDK-এর জন্য নতুন বিশ্বস্ত বিতরণ মডেল

অ্যাপ থেকে SDK-এর এই প্রস্তাবিত পৃথকীকরণ আরেকটি পৃথকীকরণ ধারণাকে উদ্বুদ্ধ করে, একটি SDK এবং অ্যাপ বিতরণের জন্য। এর জন্য একটি বিশ্বস্ত বিতরণ এবং ইনস্টলেশন প্রক্রিয়া প্রয়োজন, যাতে নিশ্চিত করা যায় যে একটি অ্যাপের SDK রানটাইমে সঠিক SDK ইনস্টল করা আছে।

এই ব্যবস্থা ব্যবহারকারী এবং অ্যাপ ডেভেলপারদের অবৈধ SDK লোড হওয়া থেকে রক্ষা করতে সাহায্য করে, একই সাথে অ্যাপ স্টোরগুলিকে অ্যাপ ডেভেলপারদের কাছ থেকে SDK বিতরণের বোঝা উল্লেখযোগ্যভাবে কমাতে সক্ষম করে।

বিতরণের জন্য অ্যাপ স্টোরে আপলোড করার আগে SDK গুলিকে আর স্ট্যাটিক্যালি লিঙ্ক এবং তাদের অ্যাপের সাথে প্যাকেজ করার প্রয়োজন নেই।

এই প্রক্রিয়াটিতে নিম্নলিখিত ধাপগুলি অন্তর্ভুক্ত রয়েছে:

1. SDK ডেভেলপাররা তাদের ভার্সন করা SDK গুলি অ্যাপ স্টোরগুলিতে আপলোড করে, অ্যাপগুলি থেকে আলাদা করে।
2. অ্যাপ ডেভেলপাররা তাদের SDK নির্ভরতাগুলি সংস্করণ অনুসারে নির্দিষ্ট করে, তৈরি করে এবং এমন একটি অ্যাপ রিলিজ আপলোড করে যাতে প্রকৃত SDK নির্ভরতা অন্তর্ভুক্ত থাকে না।
3. যখন কোনও ব্যবহারকারী এই অ্যাপটি ডাউনলোড করেন, তখন ইনস্টলেশন প্রক্রিয়াটি অ্যাপের নির্দিষ্ট SDK নির্ভরতা ব্যবহার করে অ্যাপ স্টোর থেকে ডাউনলোড করে।

এই অভিনব বিতরণ ব্যবস্থা নিম্নলিখিত শর্তাবলীর অধীনে স্বাধীন SDK আপডেট সক্ষম করে:

• ব্যাকওয়ার্ড সামঞ্জস্যপূর্ণ বাগ সংশোধন যা কোনও নতুন কার্যকারিতা, নতুন API, বিদ্যমান API-তে পরিবর্তন বা আচরণগত পরিবর্তন যোগ করে না।
• জালিয়াতি সনাক্তকরণ বা মূল্যায়ন ক্ষমতার ক্ষেত্রে পশ্চাদমুখী সামঞ্জস্যপূর্ণ উন্নতি।

এই ক্ষমতাগুলির বাস্তবায়ন স্টোর-নির্ভর।

নিম্নলিখিত চিত্রগুলি SDK বিতরণে প্রস্তাবিত পরিবর্তনগুলি চিত্রিত করে:

SDK এবং অ্যাপগুলি কীভাবে তৈরি, চালানো এবং বিতরণ করা হয় তাতে পরিবর্তন

এটি একটি নমনীয় SDK রানটাইম এবং বিতরণ প্রযুক্তির জন্য একটি প্রাথমিক প্রস্তাব। নিম্নলিখিত বিভাগগুলি নিম্নলিখিত বিস্তৃত বিভাগগুলিতে ধারাবাহিক পরিবর্তনের প্রস্তাব করে:

• অ্যাক্সেস : অনুমতি, মেমরি, স্টোরেজ
• এক্সিকিউশন : ভাষা, রানটাইম পরিবর্তন, জীবনচক্র, মিডিয়া রেন্ডারিং
• যোগাযোগ : অ্যাপ-টু-এসডিকে এবং এসডিকে-টু-এসডিকে
• ডেভেলপমেন্ট : এই মডেলে কীভাবে তৈরি, ডিবাগ, পরীক্ষা করবেন
• বিতরণ : অ্যান্ড্রয়েড, অ্যাপস এবং SDK-এর বিভিন্ন সংস্করণে কীভাবে বিতরণ, আপডেট, রোলব্যাক করা যায়

এই নথিতে সাধারণ প্রশ্নগুলির সমাধানের জন্য একটি FAQ ও অন্তর্ভুক্ত রয়েছে।

এটি একটি প্রাথমিক নকশা প্রস্তাব, এবং আমরা বুঝতে পারি এটি বাস্তুতন্ত্রের কিছু সদস্যের জন্য একটি অর্থপূর্ণ পরিবর্তন হতে পারে। এই কারণেই আমরা সক্রিয়ভাবে আপনার প্রতিক্রিয়া জানাচ্ছি এবং আপনাকে ইস্যু ট্র্যাকারের মাধ্যমে তা করতে বলছি।

অ্যাক্সেস

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

SDK অনুমতি

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

• INTERNET : একটি ওয়েব পরিষেবার সাথে যোগাযোগ করতে সক্ষম হওয়ার জন্য ইন্টারনেট অ্যাক্সেস।
• ACCESS_NETWORK_STATE : নেটওয়ার্ক সম্পর্কে তথ্য অ্যাক্সেস করুন।
• READ_BASIC_PHONE_STATE : ফোনের অবস্থা সম্পর্কে তথ্য অ্যাক্সেস করুন, উদাহরণস্বরূপ মোবাইল নেটওয়ার্কের ধরণ।
• গোপনীয়তা-সংরক্ষণকারী API গুলি অ্যাক্সেস করার অনুমতি, যা ক্রস-অ্যাপ শনাক্তকারীগুলিতে অ্যাক্সেসের প্রয়োজন ছাড়াই মূল বিজ্ঞাপন ক্ষমতা প্রদান করে।
• AD_ID : বিজ্ঞাপন আইডি অনুরোধ করার ক্ষমতা। এটি অ্যাপের এই অনুমতির অ্যাক্সেস দ্বারাও সীমাবদ্ধ হবে।

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

স্মৃতি

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

স্টোরেজ

এই প্রস্তাবটি SDK-গুলিকে তাদের স্বাভাবিক ক্রিয়াকলাপের জন্য স্টোরেজ অ্যাক্সেসের প্রয়োজনীয়তার ভারসাম্য বজায় রাখতে এবং স্থায়ী স্টোরেজ ব্যবহার করে ক্রস-অ্যাপ এবং আন্তঃপ্রক্রিয়া ট্র্যাকিং কমিয়ে আনার লক্ষ্যে কাজ করে। আজ কীভাবে স্টোরেজ অ্যাক্সেস করা হয় তার জন্য আমরা নিম্নলিখিত আপডেটটি প্রস্তাব করছি:

• একটি অ্যাপ সরাসরি তার SDK স্টোরেজ অ্যাক্সেস করতে পারবে না, এবং বিপরীতভাবে।
• ডিভাইসের বাহ্যিক স্টোরেজ SDK-তে অ্যাক্সেসযোগ্য হবে না।
• প্রতিটি SDK রানটাইমের মধ্যে, সমস্ত SDK-এর জন্য অ্যাক্সেসযোগ্য স্টোরেজ এবং একটি নির্দিষ্ট SDK-এর জন্য ব্যক্তিগত স্টোরেজ উভয়ই থাকবে।

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

মৃত্যুদন্ড

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

কোড

অ্যান্ড্রয়েড কোড (অ্যাপস এবং SDK) মূলত অ্যান্ড্রয়েড রানটাইম (ART) দ্বারা ব্যাখ্যা করা হয়, কোডটি কোটলিন বা জাভাতে লেখা হোক না কেন। ART এর সমৃদ্ধতা এবং এটি যে ভাষা গঠন করে, তার সাথে বিকল্পগুলির সাথে তুলনা করলে এটি যে যাচাইযোগ্যতা প্রদান করে - বিশেষ করে নেটিভ কোড - তা কার্যকারিতা এবং গোপনীয়তার মধ্যে যথাযথ ভারসাম্য বজায় রাখে বলে মনে হয়। আমরা প্রস্তাব করছি যে রানটাইম-সক্ষম SDK কোডে JNI অ্যাক্সেস সমর্থন করার পরিবর্তে কেবল Dex বাইটকোড থাকে।

আমরা জানি যে কাস্টম প্যাকেজড SQLite ব্যবহারের মতো কিছু ব্যবহারের ঘটনা রয়েছে, যা নেটিভ কোড ব্যবহারের কারণে, Android SDK-এর অন্তর্নির্মিত SQLite সংস্করণের মতো বিকল্প দিয়ে প্রতিস্থাপন করতে হবে।

SELinux সম্পর্কে

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

• সীমিত সংখ্যক সিস্টেম পরিষেবা অ্যাক্সেসযোগ্য হবে। ( সক্রিয় নকশার অধীনে )
• SDK গুলি শুধুমাত্র তাদের APK-তে কোড লোড এবং এক্সিকিউট করতে সক্ষম হবে।
• সিস্টেম বৈশিষ্ট্যের একটি সীমিত সেট অ্যাক্সেসযোগ্য হবে। ( সক্রিয় নকশার অধীনে )

এপিআই

SDK রানটাইমের মধ্যে প্রতিফলন এবং ইনভোকিং API ব্যবহার অনুমোদিত। তবে, একটি SDK অন্য রানটাইম-সক্ষম SDK-তে প্রতিফলন বা ইনভোক API ব্যবহার করতে পারবে না। আমরা ভবিষ্যতের আপডেটে নিষিদ্ধ API-এর সম্পূর্ণ প্রস্তাব শেয়ার করব।

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

SDK রানটাইম API গুলি শুধুমাত্র ফোরগ্রাউন্ডে চলমান অ্যাপগুলি থেকে অ্যাক্সেসযোগ্য। ব্যাকগ্রাউন্ডে থাকা অ্যাপগুলি থেকে SdkSandboxManager API গুলি অ্যাক্সেস করার চেষ্টা করলে একটি SecurityException থ্রো করা হয়।

পরিশেষে, RE-SDK গুলি যেকোনো সময় ব্যবহারকারীর বিজ্ঞপ্তি পাঠানোর জন্য বিজ্ঞপ্তি API ব্যবহার করতে পারে না।

জীবনচক্র

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

• ব্যবহারকারী অথবা অপারেটিং সিস্টেম অ্যাপটি বন্ধ করতে পারে। SDK রানটাইম স্বয়ংক্রিয়ভাবে এর সাথে সাথেই বন্ধ হয়ে যাবে।

• মেমোরি চাপের কারণে, অথবা উদাহরণস্বরূপ, SDK-তে একটি অপ্রয়োজনীয় ব্যতিক্রমের কারণে, অপারেটিং সিস্টেম SDK রানটাইম বন্ধ করে দিতে পারে।

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

  অ্যান্ড্রয়েড ১৪ এবং তার পরবর্তী সংস্করণের জন্য, অ্যাপের প্রক্রিয়া অগ্রাধিকার এবং SDK রানটাইম সারিবদ্ধ। ActivityManager.RunningAppProcessInfo.importance এর জন্য প্রক্রিয়া অগ্রাধিকার অ্যাপের জন্য গুরুত্ব এবং SDK রানটাইম প্রায় একই হওয়া উচিত।

  যদি অ্যাপটি সক্রিয় থাকাকালীন SDK রানটাইম বন্ধ হয়ে যায়—উদাহরণস্বরূপ, যদি SDK-তে কোনও অ-পরিচালিত ব্যতিক্রম থাকে—তাহলে SDK রানটাইম অবস্থা, পূর্বে লোড করা সমস্ত SDK এবং রিমোট ভিউ সহ, হারিয়ে যায়। অ্যাপ ডেভেলপার নিম্নলিখিত যেকোনো পদ্ধতি ব্যবহার করে SDK রানটাইম বন্ধ করার সাথে মোকাবিলা করতে পারেন:

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

  এই জীবনচক্র মডেলটি ভবিষ্যতের আপডেটগুলিতে পরিবর্তন সাপেক্ষে।

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

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

বিশেষ ক্ষেত্রে

নিম্নলিখিত ঘটনাগুলি অসমর্থিত, এবং অপ্রত্যাশিত আচরণের জন্ম দিতে পারে:

• যদি একাধিক অ্যাপ একই UID শেয়ার করে, তাহলে SDK রানটাইম সঠিকভাবে কাজ নাও করতে পারে। ভবিষ্যতে শেয়ার করা UID-এর জন্য সমর্থন যোগ করা হতে পারে।
• একাধিক প্রক্রিয়া সম্পন্ন অ্যাপের জন্য, SDK লোড করা মূল প্রক্রিয়াতেই করা উচিত।

মিডিয়া রেন্ডারিং

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

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

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

সিস্টেমের স্বাস্থ্য

আমরা শেষ ব্যবহারকারী ডিভাইসের উপর SDK রানটাইমের সিস্টেম স্বাস্থ্যের উপর প্রভাব কমাতে চাই এবং এটি করার উপায়গুলি ডিজাইন করছি। তবে সম্ভবত, খুব সীমিত সিস্টেম রিসোর্স সহ কিছু এন্ট্রি-লেভেল অ্যান্ড্রয়েড 14 ডিভাইস, যেমন Android (Go সংস্করণ) , সিস্টেম স্বাস্থ্যের উপর প্রভাবের কারণে SDK রানটাইম সমর্থন করবে না। আমরা শীঘ্রই SDK রানটাইম সফলভাবে ব্যবহারের জন্য প্রয়োজনীয় ন্যূনতম প্রয়োজনীয়তাগুলি ভাগ করে নেব।

যোগাযোগ

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

অ্যাপ-টু-এসডিকে

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

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

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

সাধারণ মিথস্ক্রিয়া মডেলটি নিম্নরূপ হবে:

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

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

এই প্ল্যাটফর্মটি অ্যাপগুলির জন্য নতুন API প্রকাশ করবে যাতে SDK রানটাইম প্রক্রিয়ায় গতিশীলভাবে SDK লোড করা যায়, প্রক্রিয়ার অবস্থার পরিবর্তন সম্পর্কে বিজ্ঞপ্তি পাওয়া যায় এবং SDK রানটাইমে লোড করা SDK-গুলির সাথে ইন্টারঅ্যাক্ট করা যায়।

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

অ্যাপটি নিম্নলিখিত ধাপগুলির মাধ্যমে SDK রানটাইম প্রক্রিয়ায় চলমান SDK-এর সাথে যোগাযোগ করে:

1. কোনও অ্যাপ SDK-এর সাথে ইন্টারঅ্যাক্ট করার আগে, অ্যাপটি প্ল্যাটফর্মটিকে SDK লোড করার অনুরোধ করবে। সিস্টেমের অখণ্ডতা নিশ্চিত করার জন্য, অ্যাপগুলি তাদের ম্যানিফেস্ট ফাইলে কোন SDK গুলি লোড করতে চায় তা নির্দিষ্ট করবে এবং এই SDK গুলিই কেবল লোড করার অনুমতি পাবে।

   নিম্নলিখিত কোড স্নিপেটটি একটি চিত্রিত API উদাহরণ প্রদান করে:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. SDK লোড হয়ে গেছে বলে বিজ্ঞপ্তি পায় এবং এটি তার ইন্টারফেসটি ফেরত দেয়। এই ইন্টারফেসটি অ্যাপ প্রক্রিয়া দ্বারা ব্যবহারের জন্য তৈরি। প্রক্রিয়া সীমানার বাইরে ইন্টারফেসটি ভাগ করে নেওয়ার জন্য, এটিকে একটি IBinder অবজেক্ট হিসাবে ফেরত পাঠাতে হবে।

   বাউন্ড সার্ভিসেস গাইডে IBinder প্রদানের বিভিন্ন উপায় রয়েছে। আপনি যেভাবেই বেছে নিন না কেন, এটি SDK এবং কলার অ্যাপের মধ্যে সামঞ্জস্যপূর্ণ হতে হবে। চিত্রগুলিতে AIDL কে উদাহরণ হিসেবে ব্যবহার করা হয়েছে।

3. SdkSandboxManager IBinder ইন্টারফেস গ্রহণ করে এবং অ্যাপে ফেরত পাঠায়।

4. অ্যাপটি IBinder পায় এবং এটিকে SDK ইন্টারফেসে কাস্ট করে, এর ফাংশনগুলিকে কল করে:

   IBinder binder = sandboxSdk.getInterface();
   ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
   mySdkInterface.something();
   

অ্যাপটি এই পদক্ষেপগুলি অনুসরণ করে SDK থেকে মিডিয়া রেন্ডার করতে পারে:

1. এই ডকুমেন্টের মিডিয়া রেন্ডারিং বিভাগে যেমন ব্যাখ্যা করা হয়েছে, একটি অ্যাপকে ভিউতে মিডিয়া রেন্ডার করার জন্য একটি SDK পেতে হলে, অ্যাপটি requestSurfacePackage() এ কল করতে পারে এবং উপযুক্ত SurfaceControlViewHost.SurfacePackage আনতে পারে।

   নিম্নলিখিত কোড স্নিপেটটি একটি চিত্রিত API উদাহরণ প্রদান করে:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. এরপর অ্যাপটি SurfaceView এ setChildSurfacePackage API-এর মাধ্যমে SurfaceView এ ফিরে আসা SurfacePackage এম্বেড করতে পারে।

   নিম্নলিখিত কোড স্নিপেটটি একটি চিত্রিত API উদাহরণ প্রদান করে:

   SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
   

আমাদের প্রস্তাব হল IBinder এবং requestSurfacePackage() API গুলি জেনেরিক হবে এবং সরাসরি অ্যাপ দ্বারা কল করার উদ্দেশ্যে নয়। পরিবর্তে, এই API গুলিকে উপরে আলোচিত জেনারেটেড API রেফারেন্স দ্বারা একটি "shim" স্তরে কল করা হবে, যাতে অ্যাপ ডেভেলপারদের উপর বোঝা কমানো যায়।

SDK-থেকে-SDK

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

বিবেচনা করার জন্য দুটি মূল ঘটনা রয়েছে:

• যখন উভয় SDK রানটাইম-সক্ষম থাকে । এই ক্ষেত্রে, উভয় SDKই SDK রানটাইমে তার সমস্ত সুরক্ষা সহ চলছে। SDKগুলি আজকের মতো কোনও অ্যাপের মধ্যে যোগাযোগ করতে সক্ষম নয়। ফলস্বরূপ, সমস্ত লোড করা RE-SDK-এর জন্য SandboxedSdk অবজেক্ট আনা সক্ষম করার জন্য SdkSandboxController এ একটি API যোগ করা হয়েছে। এটি একটি RE-SDK-কে SDK রানটাইমে লোড করা অন্যান্য SDK-এর সাথে যোগাযোগ করতে দেয়।
• যখন শুধুমাত্র একটি SDK রানটাইম-সক্ষম থাকে ।
  • যদি অ্যাপে কলিং SDK চলমান থাকে, তাহলে এটি SDK রানটাইমের মধ্যে দ্বিতীয় SDK-তে কল করা অ্যাপের থেকে আলাদাভাবে কাজ করে না।
  • যদি কলিং SDK SDK রানটাইমের মধ্যে চলমান থাকে, তাহলে এই প্রস্তাবনাটি অ্যাপ-টু-SDK বিভাগে বর্ণিত IBinder ব্যবহার করে এমন একটি পদ্ধতি প্রকাশ করার পরামর্শ দেয় যা অ্যাপের কোডটি প্রদত্ত কলব্যাকগুলি শোনে, প্রক্রিয়া করে এবং প্রতিক্রিয়া জানায়।
  • রানটাইম-সক্ষম নয় এমন বিজ্ঞাপন SDK গুলি নিজেদের নিবন্ধন করতে সক্ষম নাও হতে পারে, আমরা একটি মধ্যস্থতা SDK তৈরির প্রস্তাব করছি যাতে অ্যাপের সরাসরি নির্ভরতা হিসাবে যেকোনো অংশীদার বা অ্যাপ SDK অন্তর্ভুক্ত থাকে এবং নিবন্ধন পরিচালনা করে। এই মধ্যস্থতা SDK রানটাইম-সক্ষম নয় এমন SDK বা অন্যান্য অ্যাপ নির্ভরতা এবং অ্যাডাপ্টার হিসাবে কাজ করে রানটাইম সক্ষম মধ্যস্থতার মধ্যে যোগাযোগ স্থাপন করে।

SDK-SDK যোগাযোগের জন্য বৈশিষ্ট্য সেটটি নিম্নলিখিত বিভাগে বিভক্ত করা হয়েছে:

• SDK রানটাইমের মধ্যে SDK-SDK যোগাযোগ (সর্বশেষ ডেভেলপার প্রিভিউতে উপলব্ধ)
• অ্যাপ এবং SDK রানটাইমের মধ্যে SDK-SDK যোগাযোগ (সর্বশেষ ডেভেলপার প্রিভিউতে উপলব্ধ)
• মধ্যস্থতার জন্য ভিউ এবং রিমোট রেন্ডারিং কীভাবে কাজ করবে (প্রস্তাবটি উন্নয়নাধীন)

প্রিমিটিভ ডিজাইন করার সময় নিম্নলিখিত ব্যবহারের বিষয়গুলি বিবেচনাধীন রয়েছে:

1. মধ্যস্থতা এবং বিডিং । অনেক বিজ্ঞাপনী SDK একটি মধ্যস্থতা বা বিডিং ক্ষমতা প্রদান করে যার মাধ্যমে SDK বিজ্ঞাপনের ছাপ (মধ্যস্থতা) বা নিলাম (বিডিং) চালানোর জন্য সংকেত সংগ্রহের জন্য অন্যান্য বিভিন্ন SDK কল করে। সাধারণত সমন্বয়কারী SDK সমন্বয়কারী SDK দ্বারা সজ্জিত একটি অ্যাডাপ্টারের মাধ্যমে অন্যান্য SDK কল করে। উপরের আদিম দিকগুলি বিবেচনা করে, সমন্বয়কারী SDK, RE বা না, স্বাভাবিক ক্রিয়াকলাপের জন্য সমস্ত RE এবং নন-RE SDK অ্যাক্সেস করতে সক্ষম হওয়া উচিত। এই প্রসঙ্গে রেন্ডারিং তদন্তের একটি সক্রিয় ক্ষেত্র।
2. বৈশিষ্ট্য আবিষ্কার । কিছু SDK পণ্যে ছোট SDK থাকে যা আন্তঃ-SDK আবিষ্কারের প্রক্রিয়ার মাধ্যমে, অ্যাপ ডেভেলপারের কাছে উন্মুক্ত করা চূড়ান্ত বৈশিষ্ট্য সেট নির্ধারণ করে। নিবন্ধন এবং আবিষ্কারের আদিমগুলি এই ব্যবহারের ক্ষেত্রে সক্ষম হবে বলে আশা করা হচ্ছে।
3. প্রকাশক-সাবস্ক্রিপশন মডেল । কিছু SDK এমনভাবে ডিজাইন করা হয় যাতে ইভেন্টের একটি কেন্দ্রীয় প্রকাশক থাকে যেখানে অন্যান্য SDK বা অ্যাপ কলব্যাকের মাধ্যমে বিজ্ঞপ্তির জন্য সাবস্ক্রাইব করতে পারে। উপরের প্রিমিটিভগুলি এই ব্যবহারের ক্ষেত্রে সমর্থন করা উচিত।

অ্যাপ-টু-অ্যাপ

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

• SDK তার ম্যানিফেস্টে <service> , <contentprovider> , অথবা <activity> এর মতো উপাদানগুলিকে সংজ্ঞায়িত করতে পারে না।
• SDK কোনও ContentProvider প্রকাশ করতে বা কোনও সম্প্রচার পাঠাতে পারে না।
• SDK অন্য অ্যাপের সাথে সম্পর্কিত একটি কার্যকলাপ চালু করতে পারে, তবে Intent-এ কী পাঠানো যেতে পারে তার সীমাবদ্ধতা রয়েছে। উদাহরণস্বরূপ, এই Intent-এ কোনও অতিরিক্ত বা কাস্টম অ্যাকশন যোগ করা যাবে না।
• SDK শুধুমাত্র পরিষেবার একটি অ্যালাউলিস্ট শুরু করতে বা এর সাথে সংযুক্ত করতে পারে।
• SDK শুধুমাত্র সিস্টেম ContentProvider এর একটি উপসেট (যেমন com.android.providers.settings.SettingsProvider ) অ্যাক্সেস করতে সক্ষম, যেখানে প্রাপ্ত ডেটাতে শনাক্তকারীর অভাব থাকে এবং ব্যবহারকারীর আঙ্গুলের ছাপ তৈরি করতে ব্যবহার করা যায় না। এই চেকগুলি ContentResolver ব্যবহার করে ContentProvider অ্যাক্সেস করার ক্ষেত্রেও প্রযোজ্য।
• SDK শুধুমাত্র সুরক্ষিত ব্রডকাস্ট রিসিভারের একটি উপসেট (যেমন android.intent.action.AIRPLANE_MODE ) অ্যাক্সেস করতে সক্ষম।

ম্যানিফেস্ট ট্যাগ

যখন SDK ইনস্টল করা হয়, তখন PackageManager SDK এর ম্যানিফেস্ট পার্স করে এবং নিষিদ্ধ ম্যানিফেস্ট ট্যাগ উপস্থিত থাকলে SDK ইনস্টল করতে ব্যর্থ হয়। উদাহরণস্বরূপ, SDK ম্যানিফেস্টে <service>, <activity>, <provider> , অথবা <receiver> এর মতো উপাদানগুলিকে সংজ্ঞায়িত নাও করতে পারে এবং <permission> ঘোষণা নাও করতে পারে। ইনস্টলেশন ব্যর্থ ট্যাগগুলি SDK রানটাইমে সমর্থিত নয়। যে ট্যাগগুলি ইনস্টলেশন ব্যর্থ করে না কিন্তু নীরবে উপেক্ষা করা হয় সেগুলি ভবিষ্যতের Android সংস্করণগুলিতে সমর্থিত হতে পারে।

এই চেকগুলি SDK বান্ডেল তৈরি করতে ব্যবহৃত যেকোনো বিল্ড টাইম টুল দ্বারা এবং অ্যাপ্লিকেশন স্টোরে আপলোড করার সময়ও প্রয়োগ করা যেতে পারে।

কার্যকলাপ সহায়তা

SDK রানটাইম পরিবেশে থাকা SDK গুলি তাদের ম্যানিফেস্ট ফাইলে কোনও অ্যাক্টিভিটি ট্যাগ যোগ করতে পারে না এবং Context.startActivity ব্যবহার করে তাদের নিজস্ব অ্যাক্টিভিটি শুরু করতে পারে না। পরিবর্তে, অনুরোধ করা হলে প্ল্যাটফর্মটি SDK গুলির জন্য অ্যাক্টিভিটি তৈরি করে এবং SDK গুলির সাথে শেয়ার করে।

প্ল্যাটফর্ম অ্যাক্টিভিটি হলো android.app.Activity । প্ল্যাটফর্ম অ্যাক্টিভিটি অ্যাপের যেকোনো একটি অ্যাক্টিভিটি থেকে শুরু হয় এবং অ্যাপ টাস্কের অংশ। FLAG_ACTIVITY_NEW_TASK সমর্থিত নয়।

একটি SDK-কে কার্যকলাপ শুরু করার জন্য, এটিকে SdkSandboxActivityHandler টাইপের একটি ইনস্ট্যান্স নিবন্ধন করতে হবে যা অ্যাপটি কার্যকলাপ শুরু করার জন্য SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) কল করলে কার্যকলাপ তৈরি সম্পর্কে অবহিত করতে ব্যবহৃত হয়।

একটি কার্যকলাপের অনুরোধের প্রবাহ নিম্নলিখিত গ্রাফে দেখানো হয়েছে।

উন্নয়ন

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

রচনা

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

অ্যাপ ডেভেলপাররা

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

• নাম: SDK বা লাইব্রেরির প্যাকেজের নাম।
• প্রধান সংস্করণ: SDK এর প্রধান সংস্করণ কোড।
• সার্টিফিকেট ডাইজেস্ট: SDK বিল্ডের সার্টিফিকেট ডাইজেস্ট। একটি নির্দিষ্ট বিল্ডের জন্য, আমরা SDK ডেভেলপারকে প্রাসঙ্গিক অ্যাপ স্টোরের মাধ্যমে এই মানটি সংগ্রহ এবং নিবন্ধন করার প্রস্তাব দিচ্ছি।

এটি শুধুমাত্র অ্যাপ স্টোর-বিতরণ করা SDK-এর ক্ষেত্রে প্রযোজ্য, RE হোক বা না হোক। SDK-কে স্ট্যাটিক্যালি লিঙ্ক করা অ্যাপগুলি বর্তমান নির্ভরতা প্রক্রিয়া ব্যবহার করবে।

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

SDK ডেভেলপাররা

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

• নাম: SDK বা লাইব্রেরির প্যাকেজের নাম।
• প্রধান সংস্করণ: SDK এর প্রধান সংস্করণ কোড।
• মাইনর ভার্সন: SDK এর মাইনর ভার্সন কোড।

যদি RE SDK ডেভেলপারদের বিল্ড-টাইম নির্ভরতা হিসেবে অন্যান্য RE SDK থাকে, তাহলে তাদের সম্ভবত অ্যাপ ডেভেলপার যেভাবে একই নির্ভরতা ঘোষণা করে, সেইভাবে সেগুলিকে ঘোষণা করতে হবে। নন-RE SDK-এর উপর নির্ভরশীল RE SDK-গুলি স্ট্যাটিকভাবে তাদের লিঙ্ক করবে। এটি এমন সমস্যা তৈরি করতে পারে যা বিল্ডের সময় বা পরীক্ষা পাসের সময় সনাক্ত করা যেতে পারে যদি নন-RE SDK-গুলির কার্যকারিতা প্রয়োজন হয় যা SDK রানটাইম সমর্থন করে না, অথবা যদি এটি অ্যাপের প্রক্রিয়ায় চলতে হয়।

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

বিল্ডস

অ্যাপ ডেভেলপাররা

We expect app developers would experience little change in the build step. SDK dependencies, whether locally distributed or app store-distributed (RE or not), would need to exist on the machine for linting, compilation, and builds. We are proposing that Android Studio abstract these details from the app developer with normal usage and make this as transparent as possible.

Although we expect a DEBUG build would need to include all the code and symbols to be present in the DEBUG build for debuggability, RELEASE builds would optionally have all the app store-distributed SDKs (RE or not) removed from the final artifact.

We are earlier in our design phase here and will share more as it materializes.

SDK developers

We are working on a path to ensure that non-RE and RE versions of an SDK can be built into a single artifact for distribution. This would prevent app developers from needing to support separate builds for RE and non-RE versions of an SDK.

Much like for apps, any app store-distributed dependency SDKs would need to exist on the machine for linting, compilation, and builds, and we expect Android Studio should facilitate this seamlessly.

পরীক্ষামূলক

অ্যাপ ডেভেলপাররা

As described in our proposal, app developers would be able to test their apps on devices running Android 14 how they normally would. After they've built their app, the app would be able to be installed on an RE device or emulator. This installation process would ensure the correct SDKs get installed into the SDK Runtime for the device or emulator, whether the SDKs were pulled from a remote SDK repository or cache from the build system.

SDK developers

SDK developers generally use in-house test apps on devices and emulators to test their development. Our proposal doesn't change this, and in-app validation would follow the same steps as outlined for app developers above, with a single build artifact for both RE and non-RE apps. SDK developers will be able to step through their code whether it's in the SDK Runtime or not, though there may be some limitations on advanced debugging and profiling tools. This is an active area of investigation.

বিতরণ

The separation of an app from its SDKs has created the possibility for app store distribution of SDKs. This is a platform feature, not specific to any distribution channel.

This offers the following benefits:

• Ensure the quality and consistency of SDKs.
• Streamline publication for SDK developers.
• Expedite rollout of SDK critical patch updates to installed apps.

To support SDK distribution, a distribution channel would need to support the following capabilities:

• SDK developers can publish their SDKs to the store or platform, and perform maintenance operations.
• Ensure the integrity of SDKs, apps, and resolve their dependencies.
• Deploy SDKs onto devices in a consistently reliable and performant manner.

Evolving restrictions over time

We expect the restrictions faced by code in the SDK runtime to evolve with later versions of Android. To ensure application compatibility, we won't change these restrictions with mainline module updates for a given SDK level. Behavior associated with a given targetSdkVersion is preserved until support for that targetSdkVersion is deprecated through app store policy, and targetSdkVersion deprecation might happen at a faster cadence than for apps. Expect restrictions to change frequently across Android SDK versions, especially in the first few releases.

Additionally, we're building a canary mechanism to allow external and internal testers to join a group that gets the proposed set of restrictions for the next version of Android. This will help us get feedback and confidence on the proposed changes to the set of restrictions.

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

1. What is an advertising-related SDK?

   An ad-related SDK is one that facilitates any part of the targeting of users with messages for commercial ends, on apps that are not owned by the advertiser. This includes, but is not limited to, analytics SDKs where user groups can be created for subsequent targeting, ad serving SDKs, anti-abuse and anti-fraud SDKs for ads, engagement SDKs, and attribution SDKs.

2. Can any SDK run in the SDK Runtime?

   Although the initial focus is for ad-related SDKs, developers of non-ad-related SDKs that seek a pro-privacy posture and believe they can operate under the conditions outlined above can share feedback about their SDKs running in the SDK Runtime. The SDK Runtime isn't designed to be compatible with all SDK designs, however. Beyond the documented limitations, the SDK Runtime is likely unsuitable for SDKs that need real-time or high throughput communications with the hosting app.

3. Why choose process isolation instead of isolation within a process's Java-based runtime?

   Currently, the Java-based runtime doesn't readily facilitate the security boundaries necessary for the privacy assurances that are desired for Android users. Attempting to implement something like this would likely require a multi-year effort, without a guarantee of success. Therefore, the Privacy Sandbox uses use process boundaries, a time-tested and well-understood technology.

4. Would moving SDKs into the SDK Runtime process provide download size or space savings?

   If multiple apps are integrated with runtime-enabled SDKs of the same version, then this can reduce download size and disk space.

5. What kind of app lifecycle events such as when the app goes to the background, will SDKs have access to in the SDK Runtime?

   We are actively working on design support for notifying SDK runtime on app-level lifecycle events of its client application (eg app going into background, app going into foreground). Design and sample code will be shared in an upcoming developer preview.