問題タブ [android-binder]

サービス アプリへのすべての RPC (プロバイダーまたは aidl) 呼び出しがブロックされるという問題が発生しました。

クライアントが呼び出す関数は単純なので、何時間もブロックされることはないと確信しています (デッドロックはありません)。

バインダードライバーに飛び込み、/sys/kernel/debug/binder に情報を見つけました。

-bidner/stats.txt から、「準備完了」のバインダー スレッドが見つかりませんでした:

-バインダー/プロセス/918 から、いくつかの受信トランザクションと保留中のトランザクションが見つかりました。-anr情報から、カーネルのCPU使用率が高いことがわかりました

-android-studioを介してandroidプロセスにデバッガーをアタッチしようとすると、まだpsを実行できるにもかかわらず、プロセスがandroid-studioに表示されないことがわかりました。

- gdb を試して、スレッドがすべての情報を適用し、多くのスレッド (またはすべて Java スレッド) が次のようにスタックを印刷します (無限のように見えます):

JDWP スレッド スタックが見つかりません

スレッド 35507 が見つかりません

このアプリは複雑すぎてすべてのコードをここに置くことはできません。参照コードを貼り付けてください。

-サービス：

-OnBind は次のように戻ります:

埋め込む：

-クライアント側：

その後、クライアントは getService によって返される IInterface を使用して RPC を実行できます。

Android 4.4.4 で Android アプリを作成しましたが、Android 4.0.0 で開発したいと考えています。バインダーであるサービスをフラグメントに送信する際に問題があります。

Android 4.4.4 では、次の行を使用します。

しかし、Android 4.0.0 でプロジェクトをビルドしようとすると、次のエラーが発生します: Call requires API level 18 (current min is 14): android.os.Bundle#putBinder less (Ctrl + F1)

Ice Scream Sandwich でプロジェクトをビルドしようとしたときに、自分のサービスであるバインダーをフラグメントに送信する方法がわかりません。

IPCIBinderを介して他のプロセスから運ばれたインスタンスのセキュリティ チェックを行う必要があります。これの作成者/受信者は、それを運ぶIPCの直接の呼び出し元ではない可能性があるため、単純に を使用することはできません。IBinderBinder.getCallingUid()

特定のインスタンスのUIDまたはPIDを検出するにはどうすればよいですか?IBinder

なぜgetServiceここでメソッドを使用するのですか?

例として、1 つの特定の API、TelephonyManager.getDeviceId を使用します。実装したいのは、TelephonyManager.getDeviceId をバイパスすることですが、デバイスの imi を取得することです。私はJavaとAndroidが初めてです。AndroidバインダーでのJavaリフレクションは、本当に頭痛の種です...

TelephonyManager のソース コードを調べたところ、IPhoneSubinfo を介して機能していることがわかりました。TelephonyManager ソース コード

たとえば、getDeviceId の場合、TelephonyManager のコードはほとんど

getSubscriberInfo はほとんど (実際にはバインダー プロキシを返します。)

これが私がやろうとしていることです:

step1、TelephonyManager インスタンスを取得します。

ステップ 2、リフレクションを使用して TelephonyManger のプライベート メソッド getSubscriberInfo を取得し、アクセス可能に設定してから、このメソッドを呼び出して IPoneSubInfo インスタンスを取得します。

ステップ 3、リフレクションを使用して IPhoneSubInfo のパブリック メソッド getDeviceId を取得し、このメソッドを呼び出して deviceid を取得します。

この間、TelephonyManager の getDeviceId は呼び出されません。それが私がやりたいことです。しかし、ステップ 3 で、IphoneSubInfo の getDeviceId から返された deviceid が null であり、null.toString() が例外を発生させます。

なにが問題ですか？このトピックに関するドキュメントやブログ投稿があれば歓迎します。

すべてのコードがここにあり、コードがすべてを教えてくれます:

IPC を使用すると、次の問題が発生します。

私のアクティビティはサービスにバインドされています。私のアクティビティがサービスにバインドされている場合 ( http://www.survivingwithandroid.com/2014/01/android-bound-service-ipc-with-messenger-2.htmlと非常によく似てい ます)、次の問題に直面しています:

· 通常、すべてが正常に機能し、メッセージは双方向で正常に機能します · ただし、いくつかのアクティビティが強制終了された後、サービスからアクティビティに送信されるすべてのメッセージが破損しています (msg.what が 0 になり、メッセージに添付されたデータ バンドルが失われます) · 問題を再現するためのキル数は、使用している携帯電話によって異なります。サムスン ギャラクシー エースのようなフィーチャー フォンでは、新しい携帯電話よりも再現しやすいようです。

サービスを再起動してアクティビティを再度バインドすると、問題は完全に修正されますが、なぜ発生するのでしょうか? そして、どうすればこの状態に陥らないようにできるでしょうか?

このバウンド サービス ドキュメントの例を参照してください: https://developer.android.com/guide/components/bound-services.html

Binder は、インターフェース IBinder を実装するクラスです。ただし、この例では、なぜIBinder mBinder代わりにBinder mBinder?を使用するのか理解できません。IBinderでさらに複雑にするのはなぜですか? また、 LocalServiceのインスタンスを返すためだけにLocalBinderクラスが必要なのはなぜですか?

https://developer.android.com/guide/components/bound-services.htmlから:

サービスが独自のアプリケーションに対してプライベートであり、クライアントと同じプロセスで実行される場合 (これは一般的です)、Binder クラスを拡張し、onBind() からそのインスタンスを返すことによって、インターフェイスを作成する必要があります。クライアントは Binder を受け取り、それを使用して、Binder 実装または Service で使用可能なパブリック メソッドに直接アクセスできます。

これは、サービスが独自のアプリケーションの単なるバックグラウンド ワーカーである場合に推奨される手法です。この方法でインターフェイスを作成しない唯一の理由は、サービスが他のアプリケーションによって、または別のプロセスで使用されるためです。

インターフェイスが異なるプロセス間で機能する必要がある場合は、Messenger を使用してサービスのインターフェイスを作成できます...

これは、プロセス間通信に Binder を使用しないことを暗示しているようですが、IBinderドキュメントには反対のことが書かれています。

リモート可能オブジェクトの基本インターフェイス。インプロセスおよびクロスプロセス コールを実行する際に高いパフォーマンスを発揮するように設計された、軽量のリモート プロシージャ コール メカニズムのコア部分です。このインターフェイスは、リモート可能なオブジェクトと対話するための抽象プロトコルを記述します。このインターフェイスを直接実装しないでください。代わりに、Binder から拡張してください。

重要な IBinder API は、Binder.onTransact() に対応する transact() です。これらのメソッドを使用すると、それぞれ IBinder オブジェクトに呼び出しを送信し、Binder オブジェクトに着信する呼び出しを受信できます。このトランザクション API は同期的であるため、ターゲットが Binder.onTransact() から戻るまで、transact() への呼び出しは返されません。これは、ローカル プロセスに存在するオブジェクトを呼び出すときに想定される動作であり、基になるプロセス間通信 (IPC) メカニズムにより、プロセス間を移動するときにこれらの同じセマンティクスが適用されることが保証されます。

そしてBinderドキュメント：

ただし、Binder から直接派生させて独自のカスタム RPC プロトコルを実装するか、生の Binder オブジェクトを直接インスタンス化して、プロセス間で共有できるトークンとして使用することができます。

このクラスは基本的な IPC プリミティブです...

他の多くのページでも、IPC コンテキストでバインダーについて言及しています。私は何を誤解していますか？

これがばかげた質問である場合は申し訳ありません。私はAndroidが初めてです。

バインダー サービスを使用するライブラリを使用するライブラリを作成しました。つまり、私のライブラリには、バインダーを使用するライブラリ クラスから派生したクラスがあります。

私のライブラリは、プラットフォームに依存しない方法で API を介してそのデータを提供することを目的としています (バインダーの依存関係を公開することはできません)。この議論では、「開始」と「停止」機能があるとしましょう。Start は、ref-count がゼロの場合にサービスを起動し、ref カウントをインクリメントします。Stop は ref カウントをデクリメントし、ref カウントがゼロになると、すべてをシャットダウンし、クリーンアップ コードを実行したいなどの理由があります。

私が見つけることができるすべてのドキュメントには、バインダー イベントを受け取るには startThreadPool と joinThreadPool を呼び出す必要があると書かれています。ただし、joinThreadPool はブロックするため、Start 関数は戻りません。

これは、バインダー サブスクリプションがスレッドで発生する必要があることを意味します。しかし、joinThreadPool への呼び出しを独自のスレッドに入れたとしても、joinThreadPool をきれいに終了させる方法がわからないので、クリーンアップできます。

そこで、アトミックが設定されている間、startThreadPool を呼び出してスリープ ループでスピンするスレッドを作成してみました。Stop はアトミックをクリアします。これは理論的には機能しますが、API を使用しているプロセスを終了しようとすると、クリーンアップ コードが実行される前に「バインダー終了」イベントが発生することがデバッグで示されているようです。

基本的な質問は次のとおりです。ブロックしない方法でバインダーを使用し、バインダーを残してクリーンアップするにはどうすればよいですか?

AMOLED ディスプレイのエネルギー消費量を調べようとしているため、実行時に Android フォンのフレーム バッファの変化を検出したいと考えています。

Android フレームワークが SurfaceManager ライブラリを使用して、フレームを結合、構築、画面に投影することを読みました。また、SurfaceManager は Android Binder を使用して Linux カーネルのフレーム バッファを管理します。

私の質問は、SurfaceManager と Android Binder を使用して Linux からフレーム バッファに正確にアクセスするにはどうすればよいですか?