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

মতামত প্রদান

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

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

অ্যান্ড্রয়েড 13-এ, আমরা একটি নতুন প্ল্যাটফর্মের ক্ষমতা যুক্ত করেছি যা তৃতীয়-পক্ষের 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 ইন্টারফেসের সাথে যোগাযোগ করে। এই ইন্টারফেসগুলি SDK রানটাইম প্রক্রিয়ার মধ্যে একটি প্রক্রিয়ার সীমানা অতিক্রম করে SDK-তে কল করার জন্য।

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

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

ডিস্ট্রিবিউশনের জন্য অ্যাপ স্টোরে আপলোড করার আগে SDKগুলিকে তাদের অ্যাপগুলির সাথে স্ট্যাটিকভাবে লিঙ্ক এবং প্যাকেজ করার প্রয়োজন হবে না। পরিবর্তে নিম্নলিখিত প্রক্রিয়া ঘটবে:

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

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

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

চিত্রের আগে
SDK রানটাইম প্রবর্তনের আগে, ডেভেলপাররা তাদের SDK সরাসরি অ্যাপে পাঠায়।
ডায়াগ্রামের পর
SDK রানটাইম, d প্রবর্তনের পরে, SDK বিকাশকারীরা একটি অ্যাপ স্টোরে তাদের SDK প্রকাশ করতে একটি SDK আপলোড UI ব্যবহার করবে৷ অ্যাপ স্টোরটি তখন শেষ-ব্যবহারকারী ডিভাইসে যেকোনো 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-তে একটি আন-হ্যান্ডেল করা ব্যতিক্রম।

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

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

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

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

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

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

নন-আরই SDKগুলি তাদের এমবেডেড অ্যাপে উপলব্ধ স্ট্যান্ডার্ড OS আদিম ব্যবহার করা চালিয়ে যেতে পারে-সেবা, ক্রিয়াকলাপ এবং সম্প্রচার সহ-যেখানে RE SDKগুলি পারে না৷

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

নিম্নলিখিত ক্ষেত্রে অসমর্থিত, এবং অপ্রত্যাশিত আচরণ হতে পারে:

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

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

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

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

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

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

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

যোগাযোগ

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

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

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

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

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

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

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

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

ডায়াগ্রাম
সিকোয়েন্স ডায়াগ্রাম যা অ্যাপ এবং SDK স্টার্টআপের সময় অ্যাপ-টু-SDK ইন্টারঅ্যাকশন দেখায়।

SDK রানটাইম প্রক্রিয়ায় গতিশীলভাবে SDK লোড করার জন্য প্ল্যাটফর্মটি অ্যাপগুলির জন্য নতুন API প্রকাশ করবে, প্রক্রিয়াটির অবস্থার পরিবর্তন সম্পর্কে বিজ্ঞপ্তি পাবে এবং 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 রেফারেন্স দ্বারা একটি "শিম" স্তরে, অ্যাপ বিকাশকারীদের উপর বোঝা কমাতে বলা হবে।

SDK থেকে SDK

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

বিবেচনা করার জন্য দুটি মূল ক্ষেত্রে আছে:

  • যখন উভয় SDK রানটাইম-সক্ষম থাকে । এই ক্ষেত্রে, উভয় SDK এর সমস্ত সুরক্ষা সহ SDK রানটাইমে চলছে৷ SDK গুলি আজকের মতো একটি অ্যাপের মধ্যে যোগাযোগ করতে সক্ষম নয়৷ ফলস্বরূপ, SdkSandboxController এ একটি API যোগ করা হয়েছে যাতে সমস্ত লোড করা RE-SDK-এর জন্য SandboxedSdk অবজেক্ট আনা সম্ভব হয়। এটি একটি RE-SDK কে SDK রানটাইমে লোড করা অন্যান্য SDK-এর সাথে যোগাযোগ করতে দেয়৷
  • যখন শুধুমাত্র একটি SDK রানটাইম-সক্ষম থাকে ।
    • অ্যাপটিতে কলিং SDK চালু থাকলে, এটি SDK রানটাইমের মধ্যে দ্বিতীয় SDK-এ কল করা অ্যাপ থেকে আলাদাভাবে কাজ করে না।
    • যদি কলিং SDK SDK Runtime এর মধ্যে চলছে, তাহলে এই প্রস্তাবটি অ্যাপ-টু-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 অন্য অ্যাপের সাথে সম্পর্কিত একটি ক্রিয়াকলাপ চালু করতে পারে, তবে অভিপ্রায়ে কী পাঠানো যেতে পারে তার সীমাবদ্ধতার সাথে। উদাহরণস্বরূপ, এই অভিপ্রায়ে কোনো অতিরিক্ত বা কাস্টম অ্যাকশন যোগ করা যাবে না।
  • 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 রানটাইম পরিবেশে 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 বিকাশকারীরা সম্ভবত অ-আর-সক্ষম ডিভাইসগুলির জন্য সমর্থন চালিয়ে যেতে চাইবে, যেমন Android 12 বা তার কম এবং নথির সিস্টেম হেলথ বিভাগে উল্লিখিত হিসাবে, খুব সীমিত সিস্টেম সংস্থান সহ এন্ট্রি-লেভেল অ্যান্ড্রয়েড 13 ডিভাইসগুলি। SDK বিকাশকারীরা RE এবং নন-RE পরিবেশ সমর্থন করার জন্য একটি একক কোড-বেস ধরে রাখতে পারে তা নিশ্চিত করার জন্য আমরা পদ্ধতির মাধ্যমে কাজ করছি।

গড়ে তোলে

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

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

যদিও আমরা আশা করি যে ডিবাগবিলিটির জন্য ডিবাগ বিল্ডে উপস্থিত থাকার জন্য একটি DEBUG বিল্ডের সমস্ত কোড এবং চিহ্নগুলিকে অন্তর্ভুক্ত করতে হবে, রিলিজ বিল্ডে ঐচ্ছিকভাবে সমস্ত অ্যাপ স্টোর-ডিস্ট্রিবিউটেড SDKs (RE বা না) চূড়ান্ত আর্টিফ্যাক্ট থেকে সরানো হবে৷

আমরা এখানে আমাদের ডিজাইনের পর্যায়ে রয়েছি এবং এটি বাস্তবায়িত হওয়ার সাথে সাথে আরও ভাগ করব।

SDK ডেভেলপার

একটি SDK-এর নন-RE এবং RE সংস্করণগুলি বিতরণের জন্য একটি একক শিল্পকর্মে তৈরি করা যেতে পারে তা নিশ্চিত করার জন্য আমরা একটি পথে কাজ করছি৷ এটি অ্যাপ ডেভেলপারদের একটি SDK-এর RE এবং নন-RE সংস্করণের জন্য আলাদা বিল্ড সমর্থন করতে বাধা দেবে।

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

টেস্টিং

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

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

এসডিকে বিকাশকারী

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

বিতরণ

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

  • এসডিকেগুলির গুণমান এবং ধারাবাহিকতা নিশ্চিত করুন।
  • এসডিকে বিকাশকারীদের জন্য স্ট্রিমলাইন প্রকাশনা।
  • ইনস্টলড অ্যাপ্লিকেশনগুলিতে এসডিকে মাইনর সংস্করণ আপডেটগুলির দ্রুত রোলআউট।

এসডিকে বিতরণকে সমর্থন করার জন্য, একটি অ্যাপ স্টোর সম্ভবত নিম্নলিখিত বেশিরভাগ ক্ষমতা সরবরাহ করতে হবে:

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

সময়ের সাথে সাথে বিকশিত বিধিনিষেধ

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

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

FAQ

  1. বিজ্ঞাপন-সম্পর্কিত এসডিকে কী?

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

  2. কোনও এসডিকে কি এসডিকে রানটাইম চালাতে পারে?

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

  3. প্রক্রিয়াটির জাভা-ভিত্তিক রানটাইমের মধ্যে বিচ্ছিন্নতার পরিবর্তে প্রক্রিয়া বিচ্ছিন্নতা কেন বেছে নিন?

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

  4. এসডিকে এসডিকে রানটাইম প্রক্রিয়াতে সরানো কি ডাউনলোডের আকার বা স্থান সঞ্চয় সরবরাহ করবে?

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

  5. অ্যাপটি যখন পটভূমিতে যায় তখন কী ধরণের অ্যাপ লাইফসাইকেল ইভেন্টগুলি এসডিকে এসডিকে রানটাইমে অ্যাক্সেস পাবে?

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

{% শব্দার্থে %} {% endverbatim %} {% শব্দার্থে %} {% endverbatim %}