এআইডিএল ব্যাকএন্ড

একটি এআইডিএল ব্যাকএন্ড হল স্টাব কোড তৈরির লক্ষ্য। একটি নির্দিষ্ট রানটাইম সহ একটি নির্দিষ্ট ভাষায় সর্বদা AIDL ফাইলগুলি ব্যবহার করুন। প্রেক্ষাপটের উপর নির্ভর করে, আপনার বিভিন্ন AIDL ব্যাকএন্ড ব্যবহার করা উচিত।

নিম্নলিখিত সারণীতে, API পৃষ্ঠের স্থায়িত্ব বলতে এই API পৃষ্ঠের বিরুদ্ধে কোড কম্পাইল করার ক্ষমতাকে বোঝায় যাতে কোডটি system.img libbinder.so বাইনারি থেকে স্বাধীনভাবে বিতরণ করা যায়।

AIDL এর নিম্নলিখিত ব্যাকএন্ড রয়েছে:

ব্যাকএন্ড ভাষা API পৃষ্ঠ সিস্টেম তৈরি করুন
জাভা জাভা SDK বা SystemApi (স্থিতিশীল*) সব
এনডিকে সি++ libbinder_ndk (স্থিতিশীল*) aidl_interface
সিপিপি সি++ libbinder (অস্থির) সব
মরিচা মরিচা libbinder_rs (স্থিতিশীল*) aidl_interface
  • এই API পৃষ্ঠতলগুলি স্থিতিশীল, কিন্তু অনেক API, যেমন পরিষেবা পরিচালনার জন্য, অভ্যন্তরীণ প্ল্যাটফর্ম ব্যবহারের জন্য সংরক্ষিত এবং অ্যাপগুলিতে উপলব্ধ নয়। অ্যাপে এআইডিএল কীভাবে ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য, অ্যান্ড্রয়েড ইন্টারফেস ডেফিনিশন ল্যাঙ্গুয়েজ (এআইডিএল) দেখুন।
  • মরিচা ব্যাকএন্ড অ্যান্ড্রয়েড 12 এ চালু করা হয়েছিল; এনডিকে ব্যাকএন্ড অ্যান্ড্রয়েড 10 হিসাবে উপলব্ধ।
  • মরিচা ক্রেটটি libbinder_ndk এর উপরে নির্মিত, যা এটিকে স্থিতিশীল এবং বহনযোগ্য হতে দেয়। APEXes সিস্টেমের দিকে স্ট্যান্ডার্ড উপায়ে বাইন্ডার ক্রেট ব্যবহার করে। মরিচা অংশটি একটি এপেক্সে বান্ডিল করা হয় এবং এর ভিতরে পাঠানো হয়। এই অংশটি libbinder_ndk.so সিস্টেম পার্টিশনের উপর নির্ভর করে।

সিস্টেম তৈরি করুন

ব্যাকএন্ডের উপর নির্ভর করে, স্টাব কোডে AIDL কম্পাইল করার দুটি উপায় রয়েছে। বিল্ড সিস্টেম সম্পর্কে আরো বিস্তারিত জানার জন্য, সুং মডিউল রেফারেন্স দেখুন।

কোর বিল্ড সিস্টেম

যেকোন cc_ বা java_ Android.bp module (বা তাদের Android.mk সমতুল্য), আপনি AIDL ( .aidl ) ফাইলগুলিকে সোর্স ফাইল হিসেবে নির্দিষ্ট করতে পারেন। এই ক্ষেত্রে, AIDL এর জাভা বা CPP ব্যাকএন্ড ব্যবহার করা হয় (NDK ব্যাকএন্ড নয়), এবং সংশ্লিষ্ট AIDL ফাইলগুলি ব্যবহার করার জন্য ক্লাসগুলি স্বয়ংক্রিয়ভাবে মডিউলে যোগ করা হয়। আপনি একটি aidl: গ্রুপের অধীনে এই মডিউলগুলিতে local_include_dirs (যা বিল্ড সিস্টেমকে সেই মডিউলে AIDL ফাইলের রুট পাথ বলে) মত বিকল্পগুলি নির্দিষ্ট করতে পারেন।

মরিচা ব্যাকএন্ড শুধুমাত্র মরিচা ব্যবহার করার জন্য। rust_ মডিউলগুলি ভিন্নভাবে পরিচালনা করা হয় যাতে AIDL ফাইলগুলি উত্স ফাইল হিসাবে নির্দিষ্ট করা হয় না। পরিবর্তে, aidl_interface মডিউলটি aidl_interface_name -rust নামক একটি rustlib তৈরি করে, যার সাথে লিঙ্ক করা যেতে পারে। বিস্তারিত জানার জন্য, মরিচা এআইডিএল উদাহরণ দেখুন।

aidl_interface

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

প্রকারভেদ

প্রকারের জন্য একটি রেফারেন্স বাস্তবায়ন হিসাবে aidl কম্পাইলার বিবেচনা করুন। যখন আপনি একটি ইন্টারফেস তৈরি করেন, তখন aidl --lang=<backend> ... ব্যবহার করুন ফলে ইন্টারফেস ফাইলটি দেখতে। আপনি যখন aidl_interface মডিউল ব্যবহার করেন, আপনি out/soong/.intermediates/ <path to module> / এ আউটপুট দেখতে পারেন।

জাভা বা এআইডিএল টাইপ C++ প্রকার NDK প্রকার মরিচা ধরন
boolean bool bool bool
byte 8 int8_t int8_t i8
char char16_t char16_t u16
int int32_t int32_t i32
long int64_t int64_t i64
float float float f32
double double double f64
String android::String16 std::string ইন: &str
আউট: String
android.os.Parcelable android::Parcelable N/A N/A
IBinder android::IBinder ndk::SpAIBinder binder::SpIBinder
T[] std::vector<T> std::vector<T> মধ্যে: &[T]
আউট: Vec<T>
byte[] std::vector std::vector 1 মধ্যে: &[u8]
আউট: Vec<u8>
List<T> std::vector<T> 2 std::vector<T> 3 In: In: &[T] 4
আউট: Vec<T>
FileDescriptor android::base::unique_fd N/A N/A
ParcelFileDescriptor android::os::ParcelFileDescriptor ndk::ScopedFileDescriptor binder::parcel::ParcelFileDescriptor
ইন্টারফেসের ধরন ( T ) android::sp<T> std::shared_ptr<T> 7 binder::Strong
পার্সেলযোগ্য প্রকার ( T ) T T T
ইউনিয়নের ধরন ( T ) 5 T T T
T[N] 6 std::array<T, N> std::array<T, N> [T; N]

1. Android 12 বা উচ্চতর সংস্করণে, বাইট অ্যারেগুলি সামঞ্জস্যের কারণে int8_t এর পরিবর্তে uint8_t ব্যবহার করে৷

2. C++ ব্যাকএন্ড List<T> সমর্থন করে যেখানে T হল String , IBinder , ParcelFileDescriptor বা parcelable এর মধ্যে একটি। অ্যান্ড্রয়েড 13 বা উচ্চতর, T অ্যারে ব্যতীত যেকোন নন-প্রিমিটিভ টাইপ (ইন্টারফেসের ধরন সহ) হতে পারে। AOSP T[] মত অ্যারে প্রকার ব্যবহার করার পরামর্শ দেয়, কারণ তারা সমস্ত ব্যাকএন্ডে কাজ করে।

3. NDK ব্যাকএন্ড List<T> সমর্থন করে যেখানে T হল String , ParcelFileDescriptor বা পার্সেলেবলের একটি। অ্যান্ড্রয়েড 13 বা উচ্চতর সংস্করণে, T অ্যারে ব্যতীত যেকোন নন-প্রিমিটিভ টাইপ হতে পারে।

4. রাস্ট কোডের জন্য প্রকারগুলি ভিন্নভাবে পাস করা হয় তা নির্ভর করে সেগুলি ইনপুট (একটি যুক্তি), বা একটি আউটপুট (একটি ফেরত মান)।

5. ইউনিয়ন প্রকারগুলি Android 12 এবং উচ্চতর সংস্করণে সমর্থিত।

6. অ্যান্ড্রয়েড 13 বা উচ্চতর, স্থির আকারের অ্যারে সমর্থিত। স্থির-আকারের অ্যারেতে একাধিক মাত্রা থাকতে পারে (উদাহরণস্বরূপ, int[3][4] )। জাভা ব্যাকএন্ডে, স্থির-আকারের অ্যারেগুলিকে অ্যারের প্রকার হিসাবে উপস্থাপন করা হয়।

7. একটি বাইন্ডার SharedRefBase অবজেক্ট ইনস্ট্যান্ট করতে, SharedRefBase::make\<My\>(... args ...) ব্যবহার করুন। এই ফাংশনটি একটি std::shared_ptr\<T\> অবজেক্ট তৈরি করে, যা অভ্যন্তরীণভাবেও পরিচালিত হয়, যদি বাইন্ডার অন্য প্রক্রিয়ার মালিকানাধীন হয়। বস্তুটি অন্য উপায়ে তৈরি করা দ্বিগুণ মালিকানার কারণ।

8. এছাড়াও Java বা AIDL টাইপ byte[] ।

দিকনির্দেশনা (ইন, আউট এবং ইনআউট)

ফাংশনে আর্গুমেন্টের ধরন নির্দিষ্ট করার সময়, আপনি এগুলিকে in , out , বা inout হিসাবে নির্দিষ্ট করতে পারেন। এটি আইপিসি কলের জন্য তথ্য পাঠানোর দিকটিকে নিয়ন্ত্রণ করে।

  • in আর্গুমেন্ট স্পেসিফায়ার নির্দেশ করে যে কলারের কাছ থেকে কলকারীর কাছে ডেটা চলে গেছে। in স্পেসিফায়ার হল ডিফল্ট দিক, কিন্তু যদি ডেটা প্রকারগুলিও out হতে পারে, তাহলে আপনাকে অবশ্যই দিকটি নির্দিষ্ট করতে হবে।

  • out আর্গুমেন্ট স্পেসিফায়ার মানে কলে থেকে কলারের কাছে ডাটা চলে যায়।

  • inout আর্গুমেন্ট স্পেসিফায়ার হল এই দুটির সমন্বয়। যাইহোক, আমরা inout আর্গুমেন্ট স্পেসিফায়ার ব্যবহার এড়ানোর পরামর্শ দিচ্ছি। আপনি যদি একটি সংস্করণযুক্ত ইন্টারফেস এবং একটি পুরানো কলির সাথে inout ব্যবহার করেন, তবে অতিরিক্ত ক্ষেত্রগুলি যেগুলি শুধুমাত্র কলারে উপস্থিত থাকে সেগুলি তাদের ডিফল্ট মানগুলিতে পুনরায় সেট করা হয়। Rust এর ক্ষেত্রে, একটি সাধারণ inout প্রকার &mut T গ্রহণ করে এবং একটি তালিকা inout প্রকার &mut Vec<T> গ্রহণ করে। 

interface IRepeatExamples {
    MyParcelable RepeatParcelable(MyParcelable token); // implicitly 'in'
    MyParcelable RepeatParcelableWithIn(in MyParcelable token);
    void RepeatParcelableWithInAndOut(in MyParcelable param, out MyParcelable result);
    void RepeatParcelableWithInOut(inout MyParcelable param);
}

UTF-8 এবং UTF-16

CPP ব্যাকএন্ডের সাহায্যে, আপনি স্ট্রিংগুলি UTF-8 বা UTF-16 কিনা তা চয়ন করতে পারেন৷ স্বয়ংক্রিয়ভাবে UTF-8 এ রূপান্তর করতে AIDL-এ স্ট্রিংগুলিকে @utf8InCpp String হিসাবে ঘোষণা করুন। NDK এবং মরিচা ব্যাকএন্ড সবসময় UTF-8 স্ট্রিং ব্যবহার করে। utf8InCpp টীকা সম্পর্কে আরও তথ্যের জন্য, utf8InCpp দেখুন।

শূন্যতা

আপনি @nullable এর সাথে নাল হতে পারে এমন ধরনের টীকা দিতে পারেন। nullable টীকা সম্পর্কে আরও তথ্যের জন্য, nullable দেখুন।

কাস্টম পার্সেবল

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

এখানে একটি AIDL পার্সেলযোগ্য ঘোষণার একটি উদাহরণ:

    package my.pack.age;
    parcelable Foo;

ডিফল্টরূপে, এটি একটি জাভা পার্সেলেবল ঘোষণা করে যেখানে my.pack.age.Foo হল একটি জাভা ক্লাস যা Parcelable ইন্টারফেস বাস্তবায়ন করে।

AIDL-এ একটি কাস্টম CPP ব্যাকএন্ড পার্সেলযোগ্য ঘোষণার জন্য, cpp_header ব্যবহার করুন:

    package my.pack.age;
    parcelable Foo cpp_header "my/pack/age/Foo.h";

my/pack/age/Foo.h এ C++ বাস্তবায়ন এইরকম দেখাচ্ছে:

    #include <binder/Parcelable.h>

    class MyCustomParcelable : public android::Parcelable {
    public:
        status_t writeToParcel(Parcel* parcel) const override;
        status_t readFromParcel(const Parcel* parcel) override;

        std::string toString() const;
        friend bool operator==(const MyCustomParcelable& lhs, const MyCustomParcelable& rhs);
        friend bool operator!=(const MyCustomParcelable& lhs, const MyCustomParcelable& rhs);
    };

AIDL-এ একটি কাস্টম NDK পার্সেলযোগ্য ঘোষণার জন্য, ndk_header ব্যবহার করুন:

    package my.pack.age;
    parcelable Foo ndk_header "android/pack/age/Foo.h";

android/pack/age/Foo.h এ NDK বাস্তবায়ন এইরকম দেখাচ্ছে:

    #include <android/binder_parcel.h>

    class MyCustomParcelable {
    public:

        binder_status_t writeToParcel(AParcel* _Nonnull parcel) const;
        binder_status_t readFromParcel(const AParcel* _Nonnull parcel);

        std::string toString() const;

        friend bool operator==(const MyCustomParcelable& lhs, const MyCustomParcelable& rhs);
        friend bool operator!=(const MyCustomParcelable& lhs, const MyCustomParcelable& rhs);
    };

অ্যান্ড্রয়েড 15-এ, AIDL-এ একটি কাস্টম মরিচা পার্সেলযোগ্য ঘোষণার জন্য, rust_type ব্যবহার করুন:

package my.pack.age;
@RustOnlyStableParcelable parcelable Foo rust_type "rust_crate::Foo";

rust_crate/src/lib.rs এ মরিচা বাস্তবায়ন এইরকম দেখাচ্ছে:

use binder::{
    binder_impl::{BorrowedParcel, UnstructuredParcelable},
    impl_deserialize_for_unstructured_parcelable, impl_serialize_for_unstructured_parcelable,
    StatusCode,
};

#[derive(Clone, Debug, Eq, PartialEq)]
struct Foo {
    pub bar: String,
}

impl UnstructuredParcelable for Foo {
    fn write_to_parcel(&self, parcel: &mut BorrowedParcel) -> Result<(), StatusCode> {
        parcel.write(&self.bar)?;
        Ok(())
    }

    fn from_parcel(parcel: &BorrowedParcel) -> Result<Self, StatusCode> {
        let bar = parcel.read()?;
        Ok(Self { bar })
    }
}

impl_deserialize_for_unstructured_parcelable!(Foo);
impl_serialize_for_unstructured_parcelable!(Foo);

তারপরে আপনি এই পার্সেলেবলটিকে এআইডিএল ফাইলগুলিতে একটি টাইপ হিসাবে ব্যবহার করতে পারেন, তবে এটি এআইডিএল দ্বারা তৈরি করা হবে না। < এবং == CPP এবং NDK ব্যাকএন্ড কাস্টম পার্সেলেবলের জন্য অপারেটরদেরকে সেগুলিকে union ব্যবহার করার জন্য প্রদান করুন।

ডিফল্ট মান

স্ট্রাকচার্ড পার্সেবলগুলি আদিম, String ক্ষেত্র এবং এই ধরণের অ্যারের জন্য প্রতি-ক্ষেত্র ডিফল্ট মান ঘোষণা করতে পারে।

    parcelable Foo {
      int numField = 42;
      String stringField = "string value";
      char charValue = 'a';
      ...
    }

জাভা ব্যাকএন্ডে, যখন ডিফল্ট মান অনুপস্থিত থাকে, ক্ষেত্রগুলি আদিম প্রকারের জন্য শূন্য মান হিসাবে আরম্ভ করা হয় এবং ননপ্রিমিটিভ প্রকারের জন্য null ।

অন্যান্য ব্যাকএন্ডে, ক্ষেত্রগুলি ডিফল্ট প্রারম্ভিক মানগুলির সাথে আরম্ভ করা হয় যখন ডিফল্ট মানগুলি সংজ্ঞায়িত করা হয় না। উদাহরণস্বরূপ, C++ ব্যাকএন্ডে, String ক্ষেত্রগুলি একটি খালি স্ট্রিং হিসাবে আরম্ভ করা হয় এবং List<T> ক্ষেত্রগুলি একটি খালি vector<T> >। @nullable ক্ষেত্রগুলি null-value ক্ষেত্র হিসাবে আরম্ভ করা হয়।

ইউনিয়ন

AIDL ইউনিয়নগুলিকে ট্যাগ করা হয়েছে এবং তাদের বৈশিষ্ট্যগুলি সমস্ত ব্যাকএন্ডে একই রকম৷ এগুলি প্রথম ক্ষেত্রের ডিফল্ট মান অনুসারে তৈরি করা হয়েছে এবং তাদের সাথে যোগাযোগ করার একটি ভাষা-নির্দিষ্ট উপায় রয়েছে: 

    union Foo {
      int intField;
      long longField;
      String stringField;
      MyParcelable parcelableField;
      ...
    }

জাভা উদাহরণ 

    Foo u = Foo.intField(42);              // construct

    if (u.getTag() == Foo.intField) {      // tag query
      // use u.getIntField()               // getter
    }

    u.setSringField("abc");                // setter

C++ এবং NDK উদাহরণ 

    Foo u;                                            // default constructor

    assert (u.getTag() == Foo::intField);             // tag query
    assert (u.get<Foo::intField>() == 0);             // getter

    u.set<Foo::stringField>("abc");                   // setter

    assert (u == Foo::make<Foo::stringField>("abc")); // make<tag>(value)

মরিচা উদাহরণ

মরিচায়, ইউনিয়নগুলি enums হিসাবে প্রয়োগ করা হয় এবং সুস্পষ্ট গেটার এবং সেটার নেই। 

    let mut u = Foo::Default();              // default constructor
    match u {                                // tag match + get
      Foo::IntField(x) => assert!(x == 0);
      Foo::LongField(x) => panic!("Default constructed to first field");
      Foo::StringField(x) => panic!("Default constructed to first field");
      Foo::ParcelableField(x) => panic!("Default constructed to first field");
      ...
    }
    u = Foo::StringField("abc".to_string()); // set

ত্রুটি হ্যান্ডলিং

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

ত্রুটি সহ আউটপুট পরামিতি

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

কোন ত্রুটি মান ব্যবহার করতে হবে

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

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

জাভাতে, ত্রুটিগুলি ব্যতিক্রমগুলিতে ম্যাপ করে, যেমন android.os.RemoteException । পরিষেবা-নির্দিষ্ট ব্যতিক্রমগুলির জন্য, Java ব্যবহারকারী-সংজ্ঞায়িত ত্রুটি সহ android.os.ServiceSpecificException ব্যবহার করে।

অ্যান্ড্রয়েডে নেটিভ কোড ব্যতিক্রম ব্যবহার করে না। CPP ব্যাকএন্ড android::binder::Status ব্যবহার করে। NDK ব্যাকএন্ড ndk::ScopedAStatus ব্যবহার করে। এআইডিএল দ্বারা উত্পন্ন প্রতিটি পদ্ধতি এইগুলির মধ্যে একটি প্রদান করে, পদ্ধতির অবস্থা উপস্থাপন করে। মরিচা ব্যাকএন্ড NDK-এর মতো একই ব্যতিক্রম কোড মান ব্যবহার করে, কিন্তু ব্যবহারকারীর কাছে সেগুলি সরবরাহ করার আগে সেগুলিকে নেটিভ রাস্ট ত্রুটি ( StatusCode , ExceptionCode ) এ রূপান্তরিত করে। পরিষেবা-নির্দিষ্ট ত্রুটির জন্য, প্রত্যাবর্তিত Status বা ScopedAStatus ব্যবহারকারী-সংজ্ঞায়িত ত্রুটি সহ EX_SERVICE_SPECIFIC ব্যবহার করে৷

অন্তর্নির্মিত ত্রুটি প্রকারগুলি নিম্নলিখিত ফাইলগুলিতে পাওয়া যাবে:

ব্যাকএন্ড সংজ্ঞা
জাভা android/os/Parcel.java
সিপিপি binder/Status.h
এনডিকে android/binder_status.h
মরিচা android/binder_status.h

বিভিন্ন ব্যাকএন্ড ব্যবহার করুন

এই নির্দেশাবলী Android প্ল্যাটফর্ম কোডের জন্য নির্দিষ্ট। এই উদাহরণগুলি একটি সংজ্ঞায়িত প্রকার, my.package.IFoo ব্যবহার করে। মরিচা ব্যাকএন্ড কীভাবে ব্যবহার করবেন তার নির্দেশাবলীর জন্য, Android Rust প্যাটার্নে Rust AIDL উদাহরণ দেখুন।

আমদানি প্রকার

সংজ্ঞায়িত টাইপটি একটি ইন্টারফেস, পার্সেলেবল বা ইউনিয়ন হোক না কেন, আপনি এটি জাভাতে আমদানি করতে পারেন: 

import my.package.IFoo;

অথবা CPP ব্যাকএন্ডে: 

#include <my/package/IFoo.h>

অথবা NDK ব্যাকএন্ডে (অতিরিক্ত aidl নেমস্পেসটি লক্ষ্য করুন): 

#include <aidl/my/package/IFoo.h>

অথবা মরিচা ব্যাকএন্ডে: 

use my_package::aidl::my::package::IFoo;

যদিও আপনি জাভাতে একটি নেস্টেড টাইপ আমদানি করতে পারেন, CPP এবং NDK ব্যাকএন্ডে আপনাকে অবশ্যই এর রুট টাইপের জন্য হেডার অন্তর্ভুক্ত করতে হবে। উদাহরণস্বরূপ, my/package/IFoo.aidl এ সংজ্ঞায়িত একটি নেস্টেড টাইপ Bar আমদানি করার সময় ( IFoo হল ফাইলের রুট টাইপ) আপনাকে অবশ্যই CPP ব্যাকএন্ডের জন্য <my/package/IFoo.h> (বা NDK ব্যাকএন্ডের জন্য <aidl/my/package/IFoo.h> ) অন্তর্ভুক্ত করতে হবে।

একটি ইন্টারফেস প্রয়োগ করুন

একটি ইন্টারফেস বাস্তবায়ন করতে, আপনাকে অবশ্যই নেটিভ স্টাব ক্লাস থেকে উত্তরাধিকারসূত্রে প্রাপ্ত হতে হবে। একটি ইন্টারফেসের বাস্তবায়নকে প্রায়শই একটি পরিষেবা বলা হয় যখন এটি পরিষেবা পরিচালক বা android.app.ActivityManager সাথে নিবন্ধিত হয় এবং যখন এটি কোনও পরিষেবার ক্লায়েন্ট দ্বারা নিবন্ধিত হয় তখন একটি কলব্যাক বলা হয়৷ যাইহোক, সঠিক ব্যবহারের উপর নির্ভর করে ইন্টারফেস বাস্তবায়ন বর্ণনা করতে বিভিন্ন নাম ব্যবহার করা হয়। স্টাব ক্লাস বাইন্ডার ড্রাইভারের কাছ থেকে কমান্ড পড়ে এবং আপনি যে পদ্ধতিগুলি প্রয়োগ করেন তা কার্যকর করে। কল্পনা করুন যে আপনার কাছে এইরকম একটি AIDL ফাইল আছে: 

    package my.package;
    interface IFoo {
        int doFoo();
    }

জাভাতে, আপনাকে অবশ্যই জেনারেট করা Stub ক্লাস থেকে প্রসারিত করতে হবে: 

    import my.package.IFoo;
    public class MyFoo extends IFoo.Stub {
        @Override
        int doFoo() { ... }
    }

CPP ব্যাকএন্ডে: 

    #include <my/package/BnFoo.h>
    class MyFoo : public my::package::BnFoo {
        android::binder::Status doFoo(int32_t* out) override;
    }

NDK ব্যাকএন্ডে (অতিরিক্ত aidl নেমস্পেসটি লক্ষ্য করুন): 

    #include <aidl/my/package/BnFoo.h>
    class MyFoo : public aidl::my::package::BnFoo {
        ndk::ScopedAStatus doFoo(int32_t* out) override;
    }

মরিচা ব্যাকএন্ডে: 

    use aidl_interface_name::aidl::my::package::IFoo::{BnFoo, IFoo};
    use binder;

    /// This struct is defined to implement IRemoteService AIDL interface.
    pub struct MyFoo;

    impl Interface for MyFoo {}

    impl IFoo for MyFoo {
        fn doFoo(&self) -> binder::Result<()> {
           ...
           Ok(())
        }
    }

অথবা অ্যাসিঙ্ক মরিচা সহ: 

    use aidl_interface_name::aidl::my::package::IFoo::{BnFoo, IFooAsyncServer};
    use binder;

    /// This struct is defined to implement IRemoteService AIDL interface.
    pub struct MyFoo;

    impl Interface for MyFoo {}

    #[async_trait]
    impl IFooAsyncServer for MyFoo {
        async fn doFoo(&self) -> binder::Result<()> {
           ...
           Ok(())
        }
    }

নিবন্ধন করুন এবং পরিষেবা পান

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

জাভাতে: 

    import android.os.ServiceManager;
    // registering
    ServiceManager.addService("service-name", myService);
    // return if service is started now
    myService = IFoo.Stub.asInterface(ServiceManager.checkService("service-name"));
    // waiting until service comes up (new in Android 11)
    myService = IFoo.Stub.asInterface(ServiceManager.waitForService("service-name"));
    // waiting for declared (VINTF) service to come up (new in Android 11)
    myService = IFoo.Stub.asInterface(ServiceManager.waitForDeclaredService("service-name"));

CPP ব্যাকএন্ডে: 

    #include <binder/IServiceManager.h>
    // registering
    defaultServiceManager()->addService(String16("service-name"), myService);
    // return if service is started now
    status_t err = checkService<IFoo>(String16("service-name"), &myService);
    // waiting until service comes up (new in Android 11)
    myService = waitForService<IFoo>(String16("service-name"));
    // waiting for declared (VINTF) service to come up (new in Android 11)
    myService = waitForDeclaredService<IFoo>(String16("service-name"));

NDK ব্যাকএন্ডে (অতিরিক্ত aidl নেমস্পেসটি লক্ষ্য করুন): 

    #include <android/binder_manager.h>
    // registering
    binder_exception_t err = AServiceManager_addService(myService->asBinder().get(), "service-name");
    // return if service is started now
    myService = IFoo::fromBinder(ndk::SpAIBinder(AServiceManager_checkService("service-name")));
    // is a service declared in the VINTF manifest
    // VINTF services have the type in the interface instance name.
    bool isDeclared = AServiceManager_isDeclared("android.hardware.light.ILights/default");
    // wait until a service is available (if isDeclared or you know it's available)
    myService = IFoo::fromBinder(ndk::SpAIBinder(AServiceManager_waitForService("service-name")));

মরিচা ব্যাকএন্ডে:

use myfoo::MyFoo;
use binder;
use aidl_interface_name::aidl::my::package::IFoo::BnFoo;

fn main() {
    binder::ProcessState::start_thread_pool();
    // [...]
    let my_service = MyFoo;
    let my_service_binder = BnFoo::new_binder(
        my_service,
        BinderFeatures::default(),
    );
    binder::add_service("myservice", my_service_binder).expect("Failed to register service?");
    // Does not return - spawn or perform any work you mean to do before this call.
    binder::ProcessState::join_thread_pool()
}

অ্যাসিঙ্ক মরিচা ব্যাকএন্ডে, একটি একক-থ্রেডেড রানটাইম সহ: 

use myfoo::MyFoo;
use binder;
use binder_tokio::TokioRuntime;
use aidl_interface_name::aidl::my::package::IFoo::BnFoo;

#[tokio::main(flavor = "current_thread")]
async fn main() {
    binder::ProcessState::start_thread_pool();
    // [...]
    let my_service = MyFoo;
    let my_service_binder = BnFoo::new_async_binder(
        my_service,
        TokioRuntime(Handle::current()),
        BinderFeatures::default(),
    );

    binder::add_service("myservice", my_service_binder).expect("Failed to register service?");

    // Sleeps forever, but does not join the binder threadpool.
    // Spawned tasks run on this thread.
    std::future::pending().await
}

অন্যান্য বিকল্পগুলির থেকে একটি গুরুত্বপূর্ণ পার্থক্য হল যে আপনি async Rust এবং একটি একক-থ্রেডেড রানটাইম ব্যবহার করার সময় join_thread_pool কল করবেন না । এর কারণ হল আপনাকে টোকিওকে একটি থ্রেড দিতে হবে যেখানে এটি তৈরি করা কাজগুলি সম্পাদন করতে পারে। নিম্নলিখিত উদাহরণে, মূল থ্রেড সেই উদ্দেশ্যটি পরিবেশন করে। প্রধান থ্রেডে tokio::spawn execute ব্যবহার করে যে কোনো কাজ তৈরি করা হয়।

অ্যাসিঙ্ক মরিচা ব্যাকএন্ডে, একটি মাল্টিথ্রেডেড রানটাইম সহ: 

use myfoo::MyFoo;
use binder;
use binder_tokio::TokioRuntime;
use aidl_interface_name::aidl::my::package::IFoo::BnFoo;

#[tokio::main(flavor = "multi_thread", worker_threads = 2)]
async fn main() {
    binder::ProcessState::start_thread_pool();
    // [...]
    let my_service = MyFoo;
    let my_service_binder = BnFoo::new_async_binder(
        my_service,
        TokioRuntime(Handle::current()),
        BinderFeatures::default(),
    );

    binder::add_service("myservice", my_service_binder).expect("Failed to register service?");

    // Sleep forever.
    tokio::task::block_in_place(|| {
        binder::ProcessState::join_thread_pool();
    });
}

মাল্টিথ্রেডেড টোকিও রানটাইম সহ, তৈরি করা কাজগুলি মূল থ্রেডে কার্যকর হয় না। তাই, প্রধান থ্রেডে join_thread_pool কল করা আরও বোধগম্য হয় যাতে মূল থ্রেডটি নিষ্ক্রিয় না হয়। অ্যাসিঙ্ক প্রসঙ্গ ছেড়ে যেতে আপনাকে অবশ্যই block_in_place এ কলটি মুড়ে দিতে হবে।

যখন একটি বাইন্ডার হোস্টিং পরিষেবা মারা যায় তখন আপনি একটি বিজ্ঞপ্তি পাওয়ার জন্য অনুরোধ করতে পারেন৷ এটি কলব্যাক প্রক্সি ফাঁস এড়াতে বা ত্রুটি পুনরুদ্ধারে সহায়তা করতে পারে৷ বাইন্ডার প্রক্সি অবজেক্টে এই কলগুলি করুন।

  • জাভাতে, android.os.IBinder::linkToDeath ব্যবহার করুন।
  • CPP ব্যাকএন্ডে, android::IBinder::linkToDeath ব্যবহার করুন।
  • NDK ব্যাকএন্ডে, AIBinder_linkToDeath ব্যবহার করুন।
  • মরিচা ব্যাকএন্ডে, একটি DeathRecipient অবজেক্ট তৈরি করুন, তারপর my_binder.link_to_death(&mut my_death_recipient) কল করুন। নোট করুন যে DeathRecipient কলব্যাকের মালিক, তাই যতক্ষণ আপনি বিজ্ঞপ্তি পেতে চান ততক্ষণ আপনাকে সেই বস্তুটিকে জীবিত রাখতে হবে।

কলারের তথ্য

একটি কার্নেল বাইন্ডার কল গ্রহণ করার সময়, কলার তথ্য বিভিন্ন API-এ উপলব্ধ। প্রসেস আইডি (পিআইডি) একটি লেনদেন পাঠানোর প্রক্রিয়ার Linux প্রসেস আইডিকে বোঝায়। ইউজার আইডি (UI) বলতে লিনাক্স ইউজার আইডি বোঝায়। একটি একমুখী কল গ্রহণ করার সময়, কলিং পিআইডি 0 হয়। একটি বাইন্ডার লেনদেন প্রসঙ্গের বাইরে, এই ফাংশনগুলি বর্তমান প্রক্রিয়ার পিআইডি এবং ইউআইডি ফিরিয়ে দেয়।

জাভা ব্যাকএন্ডে: 

    ... = Binder.getCallingPid();
    ... = Binder.getCallingUid();

CPP ব্যাকএন্ডে: 

    ... = IPCThreadState::self()->getCallingPid();
    ... = IPCThreadState::self()->getCallingUid();

NDK ব্যাকএন্ডে: 

    ... = AIBinder_getCallingPid();
    ... = AIBinder_getCallingUid();

মরিচা ব্যাকএন্ডে, ইন্টারফেস প্রয়োগ করার সময়, নিম্নলিখিতটি নির্দিষ্ট করুন (এটিকে ডিফল্ট করার অনুমতি দেওয়ার পরিবর্তে): 

    ... = ThreadState::get_calling_pid();
    ... = ThreadState::get_calling_uid();

বাগ রিপোর্ট এবং পরিষেবার জন্য ডিবাগিং API

যখন বাগ রিপোর্ট চালানো হয় (উদাহরণস্বরূপ, adb bugreport সহ), তারা বিভিন্ন সমস্যা ডিবাগ করতে সহায়তা করার জন্য সিস্টেমের চারপাশ থেকে তথ্য সংগ্রহ করে। AIDL পরিষেবাগুলির জন্য, বাগ রিপোর্টগুলি বাগ রিপোর্টে তাদের তথ্য ডাম্প করতে পরিষেবা পরিচালকের সাথে নিবন্ধিত সমস্ত পরিষেবাগুলিতে বাইনারি dumpsys ব্যবহার করে৷ এছাড়াও আপনি dumpsys SERVICE [ARGS] এর সাথে একটি পরিষেবা থেকে তথ্য পেতে কমান্ড লাইনে dumpsys ব্যবহার করতে পারেন। C++ এবং Java ব্যাকএন্ডে, addService এ অতিরিক্ত আর্গুমেন্ট ব্যবহার করে আপনি কোন ক্রমে পরিষেবাগুলি ডাম্প করা হবে তা নিয়ন্ত্রণ করতে পারেন। ডিবাগ করার সময় একটি পরিষেবার পিআইডি পেতে আপনি dumpsys --pid SERVICE ব্যবহার করতে পারেন।

আপনার পরিষেবাতে কাস্টম আউটপুট যোগ করতে, আপনার সার্ভার অবজেক্টে dump পদ্ধতিটি ওভাররাইড করুন যেমন আপনি একটি AIDL ফাইলে সংজ্ঞায়িত অন্য কোনো IPC পদ্ধতি প্রয়োগ করছেন। এটি করার সময়, অ্যাপের অনুমতি android.permission.DUMP এ ডাম্পিং সীমাবদ্ধ করুন বা নির্দিষ্ট UID-তে ডাম্পিং সীমাবদ্ধ করুন।

জাভা ব্যাকএন্ডে: 

    @Override
    protected void dump(@NonNull FileDescriptor fd, @NonNull PrintWriter fout,
        @Nullable String[] args) {...}

CPP ব্যাকএন্ডে: 

    status_t dump(int, const android::android::Vector<android::String16>&) override;

NDK ব্যাকএন্ডে: 

    binder_status_t dump(int fd, const char** args, uint32_t numArgs) override;

মরিচা ব্যাকএন্ডে, ইন্টারফেস প্রয়োগ করার সময়, নিম্নলিখিতটি নির্দিষ্ট করুন (এটিকে ডিফল্ট করার অনুমতি দেওয়ার পরিবর্তে): 

    fn dump(&self, mut file: &File, args: &[&CStr]) -> binder::Result<()>

দুর্বল পয়েন্টার ব্যবহার করুন

আপনি একটি বাইন্ডার বস্তুর একটি দুর্বল রেফারেন্স ধরে রাখতে পারেন।

যদিও জাভা WeakReference সমর্থন করে, এটি নেটিভ লেয়ারে দুর্বল বাইন্ডার রেফারেন্স সমর্থন করে না।

CPP ব্যাকএন্ডে, দুর্বল টাইপ হল wp<IFoo> ।

NDK ব্যাকএন্ডে, ScopedAIBinder_Weak ব্যবহার করুন: 

#include <android/binder_auto_utils.h>

AIBinder* binder = ...;
ScopedAIBinder_Weak myWeakReference = ScopedAIBinder_Weak(AIBinder_Weak_new(binder));

মরিচা ব্যাকএন্ডে, WpIBinder বা Weak<IFoo> ব্যবহার করুন : 

let weak_interface = myIface.downgrade();
let weak_binder = myIface.as_binder().downgrade();

গতিশীলভাবে ইন্টারফেস বর্ণনাকারী পান

ইন্টারফেস বর্ণনাকারী একটি ইন্টারফেসের ধরন সনাক্ত করে। এটি ডিবাগ করার সময় বা আপনার কাছে একটি অজানা বাইন্ডার থাকলে দরকারী।

জাভাতে, আপনি কোড সহ ইন্টারফেস বর্ণনাকারী পেতে পারেন যেমন: 

    service = /* get ahold of service object */
    ... = service.asBinder().getInterfaceDescriptor();

CPP ব্যাকএন্ডে: 

    service = /* get ahold of service object */
    ... = IInterface::asBinder(service)->getInterfaceDescriptor();

NDK এবং মরিচা ব্যাকএন্ড এই ক্ষমতা সমর্থন করে না।

স্থিরভাবে ইন্টারফেস বর্ণনাকারী পান

কখনও কখনও (যেমন @VintfStability পরিষেবাগুলি নিবন্ধন করার সময়), আপনাকে জানতে হবে ইন্টারফেস বর্ণনাকারীটি স্থিরভাবে কী। জাভাতে, আপনি কোড যোগ করে বর্ণনাকারী পেতে পারেন যেমন: 

    import my.package.IFoo;
    ... IFoo.DESCRIPTOR

CPP ব্যাকএন্ডে: 

    #include <my/package/BnFoo.h>
    ... my::package::BnFoo::descriptor

NDK ব্যাকএন্ডে (অতিরিক্ত aidl নেমস্পেসটি লক্ষ্য করুন): 

    #include <aidl/my/package/BnFoo.h>
    ... aidl::my::package::BnFoo::descriptor

মরিচা ব্যাকএন্ডে: 

    aidl::my::package::BnFoo::get_descriptor()

Enum পরিসীমা

নেটিভ ব্যাকএন্ডে, আপনি একটি enum গ্রহণ করতে পারে এমন সম্ভাব্য মানগুলির উপর পুনরাবৃত্তি করতে পারেন। কোড আকার বিবেচনার কারণে, এটি জাভাতে সমর্থিত নয়।

AIDL-এ সংজ্ঞায়িত একটি enum MyEnum জন্য, পুনরাবৃত্তি নিম্নরূপ প্রদান করা হয়।

CPP ব্যাকএন্ডে: 

    ::android::enum_range<MyEnum>()

NDK ব্যাকএন্ডে: 

   ::ndk::enum_range<MyEnum>()

মরিচা ব্যাকএন্ডে: 

    MyEnum::enum_values()

থ্রেড ব্যবস্থাপনা

একটি প্রক্রিয়ায় libbinder প্রতিটি উদাহরণ একটি থ্রেডপুল বজায় রাখে। বেশিরভাগ ব্যবহারের ক্ষেত্রে, এটি ঠিক একটি থ্রেডপুল হওয়া উচিত, সমস্ত ব্যাকএন্ড জুড়ে ভাগ করা। একমাত্র ব্যতিক্রম যদি বিক্রেতা কোড /dev/vndbinder সাথে কথা বলার জন্য libbinder এর অন্য একটি অনুলিপি লোড করে। এটি একটি পৃথক বাইন্ডার নোডে রয়েছে, তাই থ্রেডপুল ভাগ করা হয় না।

জাভা ব্যাকএন্ডের জন্য, থ্রেডপুল শুধুমাত্র আকারে বৃদ্ধি করতে পারে (কারণ এটি ইতিমধ্যেই শুরু হয়েছে): 

    BinderInternal.setMaxThreads(<new larger value>);

CPP ব্যাকএন্ডের জন্য, নিম্নলিখিত ক্রিয়াকলাপগুলি উপলব্ধ: 

    // set max threadpool count (default is 15)
    status_t err = ProcessState::self()->setThreadPoolMaxThreadCount(numThreads);
    // create threadpool
    ProcessState::self()->startThreadPool();
    // add current thread to threadpool (adds thread to max thread count)
    IPCThreadState::self()->joinThreadPool();

একইভাবে, NDK ব্যাকএন্ডে: 

    bool success = ABinderProcess_setThreadPoolMaxThreadCount(numThreads);
    ABinderProcess_startThreadPool();
    ABinderProcess_joinThreadPool();

মরিচা ব্যাকএন্ডে: 

    binder::ProcessState::start_thread_pool();
    binder::add_service("myservice", my_service_binder).expect("Failed to register service?");
    binder::ProcessState::join_thread_pool();

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

সংরক্ষিত নাম

C++, Java, এবং Rust কিছু নাম কীওয়ার্ড হিসেবে বা ভাষা-নির্দিষ্ট ব্যবহারের জন্য সংরক্ষণ করে। যদিও AIDL ভাষার নিয়মের উপর ভিত্তি করে বিধিনিষেধ প্রয়োগ করে না, একটি সংরক্ষিত নামের সাথে মেলে এমন ক্ষেত্র বা টাইপ নাম ব্যবহার করে C++ বা Java এর জন্য একটি সংকলন ব্যর্থ হতে পারে। মরিচা-এর জন্য, ক্ষেত্র বা প্রকারের নামকরণ করা হয়েছে কাঁচা শনাক্তকারী সিনট্যাক্স ব্যবহার করে, যা r# উপসর্গ ব্যবহার করে অ্যাক্সেসযোগ্য।

আমরা আপনার AIDL সংজ্ঞাগুলিতে সংরক্ষিত নামগুলি ব্যবহার করা এড়ানোর পরামর্শ দিই যেখানে সম্ভব unergonomic বাইন্ডিং বা সম্পূর্ণ সংকলন ব্যর্থতা এড়াতে।

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

এড়ানোর জন্য নাম: