1

私がする必要があることの簡単な説明: Android フレームワークを変更し、ユーザー空間で実行される C のプログラムと通信する必要があるアプリケーションを作成します。この C プログラムは基本的に、ドライバーや一連の API とのインターフェイスとして作成したスタブです。隠しメカニズムの単一のエントリ ポイントとしてのみ使用されるため、複雑さの点では実質的に空ですが、長さは数千行です。

私とインターンシップの家庭教師は、これをどのように行うべきかについて意見が分かれています。

1/ アプリケーションと変更されたフレームワーク (クライアント) はソケットを使用して C プログラムと通信し、C プログラムはデーモン (サーバー) になります。フレームワークは JNI (むしろ Java ソケット) を使用せず、アプリケーションはソケットの JNI 実装を使用し続ける必要がある場合があります (.apk 用の Java ソケットはまだ試していません)。これは動作することがテストされています。

2/ フレームワークとアプリケーションの両方が、ライブラリのように使用される C プログラムを呼び出します。これは、-IMO- Java から「実行」するか (悪い)、コード全体 (現時点では 2000 行以上) を JNI 内に実装することを意味します。

これに関する私の偏った意見: 1/

+ it's proven to work
+ there is a clear separation between low-level and high-level
+ there might be no JNI usage
+ because I use a C daemon, I can simulate the behaviour on x86 (using an environment provided by the manufacturer)
- architecture is somewhat complex
- depending on whether the .apk can use a java socket or not, the framework and the .apk won't use the exact same mechanisms to
interface with the daemon (java socket and JNI C socket)

2/

+ architecture would be simple (with the whole C in the JNI)
- maintaining is going to be a pain
- it's not simulable, development has to either be on target or on emulator
- the android FW has to use JNI (couldn't make this work so far because of a libc error)
- useless use of JNI (from what I understand, should be used for heavy calculations/low-level interfacing)

これを行う正しいAndroidの方法は何ですか? 1 つのメソッドは、対応するメソッドよりもエレガントに見えますか?

4

0 に答える 0