标签: android-binder

我认为我追踪了内存泄漏,并想确认我认为Android的Binder如何实现的可能性.在这种情况下,我有一个服务和一个活动,每个都在他们自己的过程中.我创建了一个AIDL,它允许我通过ipc方法将Call从对象传递给Service,然后在服务完成所请求的任务时调​​用回调.

很长一段时间我都在想:如果我将一个新的Callback对象传递给Service,并且我没有在我的Activity中保留一个指向Callback对象的指针,为什么垃圾收集器不会继续并在我的Activity中收集回调处理？由于这似乎没有发生,JVM如何知道何时在我的Activity中垃圾收集回调.

我认为答案是Binder系统在Activity进程中保留一个指向我的Callback的指针,直到Service进程中相应的Callback对象调用了finalize()方法,然后向Activity发送一条消息以释放指针.它是否正确？如果不是,它是如何工作的？

我相信它是并且它导致有趣的情况,如果活动中的回调指向非常占用内存的东西,则在收集服务中的回调之前不会收集它.如果服务内存不足,它可能不会长时间收集回调,并且回调可能只是在活动中积累,直到活动中出现OutOfMemoryError.

我已经用我的界面定义了一个AIDL文件.像这样的东西:

interface IResPlugin {
    int discoverType();
    Map onClick( in int id, in Map state );
    int getLayoutId(in int option);
    int getMeasures();
    String getName();
}

Eclipse自动生成gen文件夹中的IResplugin.java,但它做错了.这是Eclipse生成的代码:

public java.util.Map onClick(int id, java.util.Map state) throws android.os.RemoteException
{
    android.os.Parcel _data = android.os.Parcel.obtain();
    android.os.Parcel _reply = android.os.Parcel.obtain();
    java.util.Map _result;
    try {
        _data.writeInterfaceToken(DESCRIPTOR);
        _data.writeInt(id);
        _data.writeMap(state);
        mRemote.transact(Stub.TRANSACTION_onClick, _data, _reply, 0);
        _reply.readException();
        _result = _reply.readHashMap(cl);
    }
    finally {
        _reply.recycle();
        _data.recycle();
    }
    return _result;
}

该行_result = _replu.readHashMap(cl)崩溃,因为该cl对象不存在.如果我手动添加这一行(缺少类加载器),Eclipse将自己的版本替换为生成的版本(并且再次,错误).

有任何想法吗？

我正在开发一个项目,我们在android系统中添加了一些非标准的安全功能,我有一些严重的问题需要调整Binder.

有没有人对Binder系统有深入的了解,并且知道为什么Binder"阻止"转移包裹的过程,以及接收过程如何解除阻塞？

最近我读了Android源代码,发现在进行一些BinderIPC调用时总会调用一对方法.我看了评论,但我不清楚根本原因.这对方法如下:

final long origId = Binder.clearCallingIdentity();

//other local method.

Binder.restoreCallingIdentity(origId);

有谁知道这对方法的功能是什么？它似乎与许可有关.

我正在制作使用 Binder 相互通信的小型 Android 应用程序。

据我所知，Android Binder 具有最大事务大小 (1MB)。例如，TransactionTooLargeException当应用程序尝试使用 Binder 事务发送大于 1MB 的消息时抛出。

我不明白为什么这是有限的。是否有任何理由限制最大交易大小？LinuxSOCK_STREAM也是 IPC，但它没有限制。

这个限制有什么合理的理由吗？Android 文档似乎没有解释为什么他们将事务大小限制为 1MB。（“Binder 事务缓冲区有一个有限的固定大小”那么他们为什么要限制缓冲区？）。

如果框架没有限制 IPC 大小，是否有任何关键情况？据我所知，即使没有最大 IPC 大小的限制，Linux 也能很好地工作。

请注意,虽然我在Android的上下文中问这个问题,但更多的是关于pipe(2)的一般unix问题......

要将大量数据从一个进程传输到另一个进程,可以使用ParcelFileDescritor.createPipe(),然后通过绑定器将管道的读取端发送到另一个进程.ParcelFileDescritor.createPipe()直接映射到unix管道(2)系统调用.

虽然FD通过绑定器安全地传输到另一个进程,但由于FD最终只是一个int,它是否有可能被恶意进程发现,甚至猜到,打开并读取？

从我的阅读来看,这似乎归结为通过默默无闻的安全.只要你不知道,并且无法猜出FD int值,那就没关系了.匿名管道不会暴露出以其他方式发现FD的方法.但理论上似乎有人可以编写一个具有大量线程的应用程序,这些线程不断尝试基于随机int值打开整数,可能会利用一些模式来选择数字并最终利用管道(2).

我目前正在研究活页夹的一般工作方式。通过查看以下项目：

https://github.com/qianjigui/android_system_service_example https://github.com/cloudchou/NativeBinderJavaClientDemo

我了解可以在

• 本机服务 <-> Java 客户端
• 本地服务 <-> 本地客户端
• Java 服务 <-> Java 客户端

一直困扰着我的最后一个问题是，以下是否可能......？

• Java 服务 <-> 本地客户端

我找不到任何实际实现这一点的文章或代码，也没有人讨论它的可能性。据我了解，交易完全基于 .aidl 描述，因此实现语言无关紧要，因此上述内容应该是可能的。但我只想确定...

我遇到了将活动绑定到活动的问题.我得到playing_service == null.我找不到我做错了什么.为什么playing_service null？

MyActivity类:

private playService playing_service=null;

private ServiceConnection service_conn=new ServiceConnection(){
    public void onServiceConnected(ComponentName className, IBinder service) {
        LocalBinder binder=(LocalBinder)service;
        playing_service=binder.getService();
    }
    public void onServiceDisconnected(ComponentName arg0) {
        // TODO Auto-generated method stub

    }
};

public void playTrack(View view){       
        Intent i=new Intent(this,playService.class);
        i.setAction("com.c0dehunter.soundrelaxer.PLAY");
        bindService(i,service_conn,Context.BIND_AUTO_CREATE);

        if(playing_service==null) //here I get true,
             //if I try to access playing_service I get NullPointerException

    }
}

playService类:

private final IBinder binder=new LocalBinder();

public int onStartCommand(Intent intent, int flags, int startId){       
     return 1; //dummy
}

@Override
public …

如何在C++中使用Android binder IPC在进程间共享文件描述符？你也可以发贴例子吗？

标有" oneway "关键字的AIDL方法和接口是远程进程的异步Binder调用,并且据说不保证调用的顺序.另一方面,Dianne Hackborn(Binder的作者)的最后评论( https://groups.google.com/forum/#!topic/android-developers/FFY-hg2Jx0M)说:

"交付顺序与目标对象相关联(因此您可以在不同的接口上接收不按顺序的呼叫)"

这似乎暗示,调用相同的接口保持他们的顺序.

任何人都可以澄清这个吗？