博客园_Terry_龙

Android 框架层为IMountService 增加新接口

2012-04-20T02:10:00Z

在为Android 增加多分区的支持时，可能会需要获得当前 USB 连接的挂载口，可能标准的Android 框架并未提供这样的接口给开发者，这时就需要我们自己为它提供接口了。先来看一下上层（应用）如何得到一个IMountService 的。

private synchronized IMountService getMountService() {
       if (mMountService == null) {
           IBinder service = ServiceManager.getService("mount");
           if (service != null) {
               mMountService = IMountService.Stub.asInterface(service);
           } else {
               Log.e(TAG, "Can't get mount service");
           }
       }
       return mMountService;
    }

关于Binder 可以参考下这篇文章：Android深入浅出之Binder机制 。

Android 2.2新增接口

Android 2.2为IMountService 新增接口非常容易，在frameworks/base/core/java/android/os/storage 有一个IMountService.aidl 文件，可以直接在这个文件里面新增一个接口提供给上层，如：

/*add by terry*/
String getUsbMountPointPath();

该文件负责生成IMountService.java文件，接着进入frameworks/base/services/java/com/android/server ，打开MountService.java 该文件继承于IMountService.aidl生成的类

class MountService extends IMountService.Stub

在这个类里面实现我们为IMountService.aidl 新增的接口

public String getUsbMountPointPath(){
return usbMountPointPath;
}

OK。通过上面的操作， StorageManage 就可以很方便的得到这个为其新增的接口，上层便可以访问了。

编译步骤：

1):编译framework/base (生成IMountService.java)

2):编译framework/base/service (编译MountService)

3):编译framework/base (编译StorageManage以提供给上层调用)

Android 4.0 以上新增接口

相比于Android 2.2，在Android 4.0框架层为IMountService 新增一个接口就显得比较复杂了。

按照Android 2.2 新增接口的方法，我们会先进入frameworks/base/core/java/android/os/storage 查找IMountService.aidl文件，进入目录，ls 一下，会发现并没有该文件，取而代之的是IMountService.java。这是怎么回事？打开该文件：映入眼帘首先会看到该警告：

/**
* WARNING! Update IMountService.h and IMountService.cpp if you change this
* file. In particular, the ordering of the methods below must match the
* _TRANSACTION enum in IMountService.cpp
*
* @hide - Applications should use android.os.storage.StorageManager to access
* storage functions.
*/

该警告提示我们，如果要修改这个文件，必须先修改IMountService.h 头文件和 IMountService.cpp 文件，并且还需要注意枚举里面的顺序。按照警告可以一步步修改了。

进入frameworks/base/include/storage 打开IMountService.h ，新增这个方法：

virtual int32_t getUsbMountPointPath() = 0 ;

完成后进入frameworks/base/libs/storage 打开IMountService.cpp ，在枚举里面新增方法枚举：

enum {
    TRANSACTION_registerListener = IBinder::FIRST_CALL_TRANSACTION,
    TRANSACTION_unregisterListener,
    TRANSACTION_isUsbMassStorageConnected,
    TRANSACTION_setUsbMassStorageEnabled,
    TRANSACTION_isUsbMassStorageEnabled,
    TRANSACTION_mountVolume,
    TRANSACTION_unmountVolume,
    TRANSACTION_formatVolume,
    TRANSACTION_getStorageUsers,
    TRANSACTION_getVolumeState,
    TRANSACTION_createSecureContainer,
    TRANSACTION_finalizeSecureContainer,
    TRANSACTION_destroySecureContainer,
    TRANSACTION_mountSecureContainer,
    TRANSACTION_unmountSecureContainer,
    TRANSACTION_isSecureContainerMounted,
    TRANSACTION_renameSecureContainer,
    TRANSACTION_getSecureContainerPath,
    TRANSACTION_getSecureContainerList,
    TRANSACTION_shutdown,
    TRANSACTION_finishMediaUpdate,
    TRANSACTION_mountObb,
    TRANSACTION_unmountObb,
    TRANSACTION_isObbMounted,
    TRANSACTION_getMountedObbPath,
    TRANSACTION_isExternalStorageEmulated,
    TRANSACTION_decryptStorage,
    TRANSACTION_encryptStorage,
    TRANSACTION_getUsbMountPointPath,
};

接着新增要实现的方法

  int32_t getUsbMountPointPath()
    {
      Parcel data, reply;
        data.writeInterfaceToken(IMountService::getInterfaceDescriptor());
        if (remote()->transact(TRANSACTION_getUsbMountPointPath, data, &reply) != NO_ERROR) {
            LOGD("getVolumeState could not contact remote\n");
            return -1;
        }
        int32_t err = reply.readExceptionCode();
        if (err < 0) {
            LOGD("getVolumeState caught exception %d\n", err);
            return err;
        }
        return reply.readInt32();

    }

OK，这个方法到了这里，CPP部分就算完成了。接下来可以为IMountService.java加接口了。

再次进入frameworks/base/core/java/android/os/storage ，打开IMountService.java 文件。

实现该接口，增加以下方法：

public String getUsbMountPointPath() throws RemoteException {

                Parcel _data = Parcel.obtain();
                Parcel _reply = Parcel.obtain();
                String _result;
                try {
                    _data.writeInterfaceToken(DESCRIPTOR);
                    mRemote.transact(Stub.TRANSACTION_getUsbMountPointPath, _data, _reply, 0);
                    _reply.readException();
                    _result = _reply.readString();
                } finally {
                    _reply.recycle();
                    _data.recycle();
                }
                return _result;
           }

增加这个常量：static final int TRANSACTION_getUsbMountPointPath = IBinder.FIRST_CALL_TRANSACTION + 28;

在onTransact方法里面增加一个case 判断：

case TRANSACTION_getUsbMountPointPath:{
                   data.enforceInterface(DESCRIPTOR);
                    String state = getUsbMountPointPath();
                    reply.writeNoException();
                    reply.writeString(state);
                   return true;
               }

最后，再增加一个该接口的方法

public String getUsbMountPointPath() throws RemoteException;

到此为止，为IMountService 增加接口所要做的必要步骤就算完成了。

编译步骤：

1):编译framework/base/libs/storage ，产生libstorage.a静态文件。

2):编译framework/base/native/android 产生libandroid.so动态库文件，该文件最终会被IMountService.java 使用。必须通过push 到 system/lib 目录下。

3) :编译framework/base/service 让getUsbMountPointPath 接口生效。

4):编译framework/base 这样我们就可以在使用StorageManage 来读取IMountService 的新接口了。

注：StorageManage 部分就不写了，可以借鉴其他的方法，添加一个可供上层访问的方法，这部分比较简单。StorageManage在2.2是隐藏的不被开发者使用的，在4.0后则可以正常使用。

本文链接

Android SDCard Mount 流程分析（二）

2012-04-12T02:09:00Z

上一篇关于Mount的分析，分析了main的作用和一些挂载系统的分析。下面深入分析Mount的流程走法。

Mount流程分为两个部分

主动挂载（插入SDCARD或者USB硬盘时系统自动挂载）
手动挂载（卸载SDCARD或者USB硬盘后，再点击加载设备的手动挂载）

不同挂载走的流程并不相同，比如手动挂载是由上层发命令给vold 执行挂动作，而主动挂载是由kernel 分命令给vold 再由vold 发挂载消息给上层，上层得到挂载消息和状态后再发命令给vold 执行挂载。主动挂载较之复杂些。不过虽然流程不一样，但最终还是要调用Volume的挂载函数，下面将详细介绍两者的行走的流程。

由于会涉及SDCARD或者USB硬盘，其中调用的方法就不详细说明，这里只说出当插入SDCARD或者USB硬盘会走的流程。

主动挂载

主动挂载时，会走向DirectVolume类，调用DirectVolume::mountVol方法，代码如下：

int DirectVolume::mountVol() {
    char errmsg[255];
    dev_t deviceNodes[64];

    int i, n = 0;

    if (getState() == Volume::State_NoMedia) {
        snprintf(errmsg, sizeof(errmsg),
                 "Volume %s %s mount failed - no media",
                 getLabel(), getMountpoint());
        mVm->getBroadcaster()->sendBroadcast(
                                         ResponseCode::VolumeMountFailedNoMedia,
                                         errmsg, false);
        errno = ENODEV;
        return -1;
    } else if (getState() != Volume::State_Idle) {
        errno = EBUSY;
        return -1;
    }

    n = getDeviceNodes((dev_t *) &deviceNodes, 64);

    if (!n) {
        SLOGE("Failed to get device nodes (%s)\n", strerror(errno));
        return -1;
    }
    bool mounted = false;

    for (i = 0; i < n; i++) {
        mDevNodeIndex = deviceNodes[i];
        //XXX: hack mountpoint
        if ( mMountpointParsed ) { free(mMountpointParsed); mMountpointParsed = NULL; }
        mMountpointParsed = getParsedMountPoint(mMountpoint, i);

        if (isMountpointMounted(getMountpoint())) {
            SLOGW("Volume is idle but appears to be mounted - fixing");
            setState(Volume::State_Mounted);
            // mCurrentlyMountedKdev = XXX
            errno = EBUSY;
            continue;
        }

        if (!Volume::mountVol()) {
            mounted = true;
        }

        mState = Volume::State_Idle;
    }

    if ( mMountpointParsed ) { free(mMountpointParsed); mMountpointParsed = NULL; }

    if ( mounted ) {
        // at least on partition has been mounted successful, mark disk as mounted
        setState(Volume::State_Mounted);
        return 0;
    }

    SLOGE("Volume %s found no suitable devices for mounting :(\n", getLabel());
    setState(Volume::State_Idle);

    return -1;
}

代码加亮部分，蓝色部分，会循环整个设备节点系统目录位于(/dev/block/vold)，然后调用红色部分代码，调用Volume的挂载方法。

这里，无论是SDCARD或者USB硬盘在主动挂载时，都会走DirectVolume。

手动挂载

手动挂载是由上层发Mount 命令，代码位于MountService里面的doMountVolume方法，具体如何实现我们先不深究，它这里通过发送socket(mount)命令到Vold 的CommandListener里面的CommandListener::VolumeCmd::runCommand方法进入代码这里：

else if (!strcmp(argv[1], "mount")) {
        if (argc != 3) {
            cli->sendMsg(ResponseCode::CommandSyntaxError, "Usage: volume mount <path>", false);
            return 0;
        }

        if(!strcmp(argv[2],"firstMount")){
            VolumeCollection::iterator i;
              if(mVolumes!=NULL){
              for (i = mVolumes->begin(); i != mVolumes->end(); ++i) {
              if (strcmp("/sdcard", (*i)->getMountpoint())) {
                  vm->mountVolume((*i)->getMountpoint());
               }
            }
         }
        }else{
           vm->mountVolume(argv[2]);
        }

    }

这里执行挂载动作，看上面蓝色代码是为了系统第一次启动上层发送命令firstMount给CommandListener执行挂载USB硬盘的动作，红色代码即是核心要挂载的方法，调用的VolumeManage的mountVolume 方法，只需传入挂载点。该方法代码是：

int VolumeManager::mountVolume(const char *label) {
    Volume *v = lookupVolume(label);

    if (!v) {
        errno = ENOENT;
        return -1;
    }

    return v->mountVol();
}

可以看出，这里同样调用的是Volume的mountVol方法，殊途同归，接下来着重看一下Volume类里面这个mountVol方法，究竟干了些啥。

Volume::mountVol 方法深究

别的先不管，来看一下代码

int Volume::mountVol() {
    int rc = 0;
    char errmsg[255];
    const char *mountPath;

        char devicePath[255];

        sprintf(devicePath, "/dev/block/vold/%d:%d", MAJOR(mDevNodeIndex),
                MINOR(mDevNodeIndex));//得到设备节点,如:/dev/block/vold/8:1

        SLOGI("%s being considered for volume %s ...major : %d minor: %d\n", devicePath, getLabel(),
         MAJOR(mDevNodeIndex),MINOR(mDevNodeIndex));

        errno = 0;
        setState(Volume::State_Checking);//设置状态为checking整型为3

        // TODO: find a way to read the filesystem ID
        bool isFatFs = true;
        bool isNtfsFS = true;
//检查设备格式是否为Fat32
        if (Fat::check(devicePath)) {
            if (errno == ENODATA) {
                SLOGW("%s does not contain a FAT filesystem\n", devicePath);
                isFatFs = false;
            } else {
              errno = EIO;
              /* Badness - abort the mount */
              SLOGE("%s failed FS checks (%s)", devicePath, strerror(errno));
              setState(Volume::State_Idle);
              return -1;
            }
        }

//创建挂载目录
       // create mountpoint
        if (mkdir(getMountpoint(), 0755)) {
            if (errno != EEXIST) {
                SLOGE("Failed to create mountpoint %s (%s)", getMountpoint(), strerror(errno));
                return -1;
            }
        }

        /*
         * Mount the device on our internal staging mountpoint so we can
         * muck with it before exposing it to non priviledged users.
         */
        errno = 0;
//如果为sdcard则挂载到/mnt/secure/staging，否则挂载到挂载点
if(!strcmp(getLabel(),"sdcard"))
            mountPath="/mnt/secure/staging";
        else
            mountPath=getMountpoint();
//接下来就是不同格式不同的挂载，这里支持两种格式：fat32,Ntfs
        if ( isFatFs ) {
            if (Fat::doMount(devicePath,mountPath, false, false, 1000, 1015, 0702, true)) {
                SLOGE("%s failed to mount via VFAT (%s)\n", devicePath, strerror(errno));

                isFatFs = false;
            }
            isNtfsFS = false;
        }

        if ( isNtfsFS ) {
            if (Ntfs::doMount(devicePath, mountPath, true)) {
                SLOGE("%s failed to mount via NTFS (%s)\n", devicePath, strerror(errno));
                isNtfsFS = false;
            }
        }

        if ( !isFatFs && !isNtfsFS ) {
            // unsupported filesystem
            return -1;
        }

        SLOGI("Device %s, target %s mounted @ /mnt/secure/staging", devicePath, getMountpoint());


        if ( !strcmp(getLabel(), "sdcard") ) {

            protectFromAutorunStupidity();

            if (createBindMounts()) {
                SLOGE("Failed to create bindmounts (%s)", strerror(errno));
                umount("/mnt/secure/staging");
                setState(Volume::State_Idle);
                return -1;
            }
        }

        /*
         * Now that the bindmount trickery is done, atomically move the
         * whole subtree to expose it to non priviledged users.
* 如果为sdcard则将/mnt/secure/staging 目录移动到挂载点，并将该目录unmount
         */
        if(!strcmp(getLabel(),"sdcard")){
          if (doMoveMount("/mnt/secure/staging", getMountpoint(), false)) {
              SLOGE("Failed to move mount (%s)", strerror(errno));
              umount("/mnt/secure/staging");
              setState(Volume::State_Idle);
               return -1;
          }
       }
        setState(Volume::State_Mounted);//设置状态到MountService
        mCurrentlyMountedKdev = mDevNodeIndex;

        return 0;

}

注意：原生的代码可能跟上面贴出来的代码有点不同，上面的代码是增加了Ntfs-3g挂载的支持和多分区挂载的支持，但基本流程是相同的。

代码有详细的注释，这里要注意的是：sdcard和USB的支持不同，sdcard 挂载时需要先挂载到临时目录/mnt/secure/staging，然后再移动到最终需要挂载的挂载点，而USB硬盘特别是多分区的支持，不用先挂载到临时目录，而是可以支持挂载到想要挂载的挂载点，这里是比较需要注意到的地方(在这里栽过跟头，会出现“随机性的挂载失败”)。

ok.

本文链接

Android SDCard Mount 流程分析（一）

2012-04-05T03:01:00Z

前段时间对Android 的SDCard unmount 流程进行了几篇简短的分析，由于当时只是纸上谈兵，没有实际上的跟进，可能会有一些误导人或者小错误。今天重新梳理了头绪，针对mount的流程再重新分析一次。

本篇大纲

android 系统如何开机启动监听mount服务
默认设备节点在Android 系统的哪个目录
vold.fstab 配置文件的分析
vold 里面启动页面main做了些什么

android 系统如何开机启动监听mount服务

android sdcard 热插拔监测和执行操作是由一个启动文件vold 所统领的，系统开机会读取初始化配置文件init.rc，该文件位于比如我的板子是：device/ti/omap3evm/init.rc，具体根据自己平台查找。里面有一个是默认启动vold 服务的代码，如下：

service vold /system/bin/vold
socket vold stream 0660 root mount
ioprio be 2

如果要对该文件做出修改之类，要重新编一下boot.img 镜像文件，烧录进android 系统，之后可以在android的文件系统根目录找到init.rc文件。上述代码为启动vold 启动文件，也可以在init.rc 增加多一些我们想要的文件目录，比如增加一个可以存放多分区挂载的目录等，这个是后话。

默认设备节点在Android 系统的哪个目录

usbdisk 或者 sdcard 热插拔的时候，kernel 会发出命令执行mount或者unmount 操作，但这都是驱动级的。而mount 目录会在android 的文件系统目录下：/dev/block/vold 这个目录由vold 生成，用来存放所有的usbdisk 或者 sdcard 的设备节点。代码位于main里面最优先执行：

mkdir("/dev/block/vold", 0755);

可以根据这个目录找到如下节点：

sh-4.1# ls /dev/block/vold/
179:0 179:1 8:0 8:1 8:2 8:3 8:4

节点的小介绍：

0代表当前的整个设备，1代码当前设备的分区名称代号。

所以你会发现，sdcard只有一个分区它却生成了两个如：179:0 179:1

而usbdisk 有四个分区，它会生成五个设备节点： 8:0 8:1 8:2 8:3 8:4 就是这个原因。

vold.fstab 配置文件的分析

vold 里面会通过指定文件来读取预先配置好的sdcard或者多分区配置文件，该文件位于

/system/core/rootdir/etc/vold.fstab

如以下的配置文件为：

dev_mount sdcard /mnt/sdcard auto /devices/platform/goldfish_mmc.0 /devices/platform/msm_sdcc.2/mmc_host/mmc1

dev_mount 代表挂载格式

sdcard 代表挂载的标签

/mnt/sdcard 代表挂载点

auto 为自定义选项可以为任何，但必须在main 里面自己判断比如这里的意思为自动挂载

后面两个目录为设备路径，第一个如果被占用会选择第二个

配置文件可以根据自己的需要编写，并不是固定的，但最好遵循google vold 启动文件代码的格式编写，要不然会给我们修改代码或者增加多分区功能带来不小的麻烦，如以下我自己编写的多分区挂载支持vold.fstab 配置文件：

dev_mount sdcard external /mnt/sdcard auto /devices/platform/mmci-omap-hs.0/mmc_host/mmc0 /devices/platform/mmci-omap-hs.0/mmc_host/mmc1
dev_mount usb1 external /mnt/usbdisk/usb1-disk%d all /devices/platform/ehci-omap.0/usb1/1-2/1-2.1/
dev_mount usb2 external /mnt/usbdisk/usb2-disk%d all /devices/platform/ehci-omap.0/usb1/1-2/1-2.2/
dev_mount usb3 external /mnt/usbdisk/usb3-disk%d all /devices/platform/ehci-omap.0/usb1/1-2/1-2.3/

该文件修改后经系统编译会在android 系统目录里/system/etc/vold.fstab找到。

/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/ 代表要挂载的USB口。

vold.fstab 只是一个单纯的配置文件，具体的读取和取数据还是要靠main里面的process_config函数。看代码，里面正有一段用来读取配置文件：

if (!(fp = fopen("/etc/vold.fstab", "r"))) {
return -1;
}

在这个函数里面会根据读取到的数据存放起来，然后满足条件时执行操作。比如代码里面的：

if (!strcmp(type, "dev_mount")) {
            DirectVolume *dv = NULL;
            char *part;

            if (!(part = strtok_r(NULL, delim, &save_ptr))) {
                SLOGE("Error parsing partition");
                goto out_syntax;
            }
            if (strcmp(part, "auto") && atoi(part) == 0) {
                SLOGE("Partition must either be 'auto' or 1 based index instead of '%s'", part);
                goto out_syntax;
            }

            if (!strcmp(part, "auto")) {
                dv = new DirectVolume(vm, label, mount_point, -1);
            } else {
                dv = new DirectVolume(vm, label, mount_point, atoi(part));
            }

            while ((sysfs_path = strtok_r(NULL, delim, &save_ptr))) {
                if (*sysfs_path != '/') {
                    /* If the first character is not a '/', it must be flags */
                    break;
                }
                if (dv->addPath(sysfs_path)) {
                    SLOGE("Failed to add devpath %s to volume %s", sysfs_path,
                         label);
                    goto out_fail;
                }
            }

            /* If sysfs_path is non-null at this point, then it contains
             * the optional flags for this volume
             */
            if (sysfs_path)
                flags = parse_mount_flags(sysfs_path);
            else
                flags = 0;
            dv->setFlags(flags);

            vm->addVolume(dv);
        }

DirectVolume后面会讲到，执行mount 和unmount 都是它在做。

另外，有时后读取配置文件会有问题，这是因为它读取是通过指标下标递增的方式在读，如果有问题可以跟踪打印一下配置文件，看哪里需要修改。

vold 里面启动页面main做了些什么

main 主要是初始化socket 连接监听数据变化，在系统起来时第一时间启动，并且通过读取配置文件来识别usb口或者sdcard 的设备地址，来mount 或者unmount 。其它执行mount 、 unmount 或者删除节点等操作都是由上层或者framework 发送命令给main让其通知volumeManage 执行相应的操作。

本文链接

Android SDCard UnMounted 流程分析（三）

2012-03-22T12:40:00Z

前篇地址

Android SDCard UnMounted 流程分析（一）

Android SDCard UnMounted 流程分析（二）

前一篇讲到SDCard unmout onEvent 发送socket 到框架层，接下来分析框架层得到数据后的流程。

MoutService

当android 系统启动时，system将MountService 添加到启动服务里面，而MountService 会开启一个线程来运行NativeDaemonConnector，由它来监听vold的消息，代码：

mConnector = new NativeDaemonConnector(this, "vold", MAX_CONTAINERS * 2, VOLD_TAG);
mReady = false;
Thread thread = new Thread(mConnector, VOLD_TAG);
thread.start();

该函数运行在MountService的构造函数里面，而NativeDaemonConnector 本身就是继承自Runnable。

NativeDaemonConnector

Framework与vold 的通信是通过socket来实现的，不过该socket 由　android做了一个封装，LocalSocket 实现的socket功能。

NativeDaecomConnector 位于framework/base/service/java/com/android/server目录下，监听vold 的消息代码在继承自Runnable对象的run方法里面：

@Override
    public void run() {
        HandlerThread thread = new HandlerThread(TAG + ".CallbackHandler");
        thread.start();
        mCallbackHandler = new Handler(thread.getLooper(), this);

        while (true) {
            try {
                listenToSocket();
            } catch (Exception e) {
                Slog.e(TAG, "Error in NativeDaemonConnector", e);
                SystemClock.sleep(5000);
            }
        }
}

NativeDaemonConnector 类实例化了一个LocalSocket来与vold 通信。LocalSocket　里面有一个类LocalSocketImpl，该类部分是通过JNI实现的。

关于socket 内部如何通信，这个不是我们所关心的内容，因为如果要深入进去估计没完没了，有兴趣的朋友可以参考源码进入SocketListener查看：

建立连接

SocketListener::SocketListener

当main初始化CommandListener 后，会为socketName 传入一个叫vold 的字符串

SocketListener::startListener

等待并接收连接请求

SocketListener::runListener

获得命令参数

bool FrameworkListener::onDataAvailable

dispatchCommand 到相应的命令类,并返回一部分消息给上层

FrameworkListener::dispatchCommand

再回过头看NativeDaemonConnector 的listenToSocket，代码中实例化了一个LocalSocketAddress的实例，并传入一个叫"vold"字符串的socket 名称，这与CommandListener中继承了FrameworkListener时给的"vold"名称是一致的，两个socket名称一致则可以互相进行通讯了，代码如下：

private void listenToSocket() throws IOException {
        LocalSocket socket = null;
    Slog.w(TAG,String.format("NativeDaemonConnector--->listenToSocket:start"));
        try {
            socket = new LocalSocket();
            LocalSocketAddress address = new LocalSocketAddress(mSocket,
                    LocalSocketAddress.Namespace.RESERVED);

            socket.connect(address);

            InputStream inputStream = socket.getInputStream();
            mOutputStream = socket.getOutputStream();

            mCallbacks.onDaemonConnected();

            byte[] buffer = new byte[BUFFER_SIZE];
            int start = 0;

            while (true) {
                int count = inputStream.read(buffer, start, BUFFER_SIZE - start);
                if (count < 0) break;

                // Add our starting point to the count and reset the start.
                count += start;
                start = 0;

                for (int i = 0; i < count; i++) {
                    if (buffer[i] == 0) {
                        String event = new String(buffer, start, i - start);//解析socket 的数据并获取event
                        if (LOCAL_LOGD) Slog.d(TAG, String.format("RCV <- {%s}", event));

                        String[] tokens = event.split(" ", 2);
                        try {
                            int code = Integer.parseInt(tokens[0]);

                            if (code >= ResponseCode.UnsolicitedInformational) {
                                mCallbackHandler.sendMessage(
                                        mCallbackHandler.obtainMessage(code, event));//发送消息给handler
                            } else {
                                try {
                                    mResponseQueue.put(event);
                                } catch (InterruptedException ex) {
                                    Slog.e(TAG, "Failed to put response onto queue", ex);
                                }
                            }
                        } catch (NumberFormatException nfe) {
                            Slog.w(TAG, String.format("Bad msg (%s)", event));
                        }
                        start = i + 1;
                    }
                }

                // We should end at the amount we read. If not, compact then
                // buffer and read again.
                if (start != count) {
                    final int remaining = BUFFER_SIZE - start;
                    System.arraycopy(buffer, start, buffer, 0, remaining);
                    start = remaining;
                } else {
                    start = 0;
                }
            }
        } catch (IOException ex) {
            Slog.e(TAG, "Communications error", ex);
            throw ex;
        } finally {
            synchronized (mDaemonLock) {
                if (mOutputStream != null) {
                    try {
                        mOutputStream.close();
                    } catch (IOException e) {
                        Slog.w(TAG, "Failed closing output stream", e);
                    }
                    mOutputStream = null;
                }
            }

            try {
                if (socket != null) {
                    socket.close();
                }
            } catch (IOException ex) {
                Slog.w(TAG, "Failed closing socket", ex);
            }
        }
}

上面代码，通过socket 并event 解析出来，并通handler 发送到handleMessage 中，当handleMessage接收到传过来的消息时，会调用MountService 的onEvent 方法将code和event和sdcard 的状态传递进去。代码如下：

public boolean handleMessage(Message msg) {
        String event = (String) msg.obj;
        Slog.w(TAG,String.format("NativeDaemonConnector--->handleMessage the event value is "+event));
        try {
            if (!mCallbacks.onEvent(msg.what, event, event.split(" "))) {
                Slog.w(TAG, String.format(
                        "Unhandled event '%s'", event));
            }
        } catch (Exception e) {
            Slog.e(TAG, String.format(
                    "Error handling '%s'", event), e);
        }
        return true;
}

又回到MountService ，在onEvent里面当接收到的code ==VoldResponseCode.VolumeBadRemoval时会调用updatePublicVolumeState，发送unmount改变的广播，代码如下：

else if (code == VoldResponseCode.VolumeBadRemoval) {
                if (DEBUG_EVENTS) Slog.i(TAG, "Sending unmounted event first");
                /* Send the media unmounted event first */
                updatePublicVolumeState(path, Environment.MEDIA_UNMOUNTED);
                action = Intent.ACTION_MEDIA_UNMOUNTED;

                if (DEBUG_EVENTS) Slog.i(TAG, "Sending media bad removal");
                updatePublicVolumeState(path, Environment.MEDIA_BAD_REMOVAL);
                action = Intent.ACTION_MEDIA_BAD_REMOVAL;}

到这里，进入updatePublicVolumeState看该函数里的主要代码：

synchronized (mListeners) {
            for (int i = mListeners.size() -1; i >= 0; i--) {
                MountServiceBinderListener bl = mListeners.get(i);
                try {
                    Slog.w(TAG,"MountService--->updatePublicVolumeState-->bl.mListener.onStorageStateChanged");
                    bl.mListener.onStorageStateChanged(path, oldState, state);
                } catch (RemoteException rex) {
                    Slog.e(TAG, "Listener dead");
                    mListeners.remove(i);
                } catch (Exception ex) {
                    Slog.e(TAG, "Listener failed", ex);
                }
            }
        }
}

并且调用sendStorageIntent 方法将SDCard的Action:android.intent.action.MEDIA_BAD_REMOVAL 和dat：file:///mnt/sdcard 通过这个广播发送出去，代码如下：

    private void sendStorageIntent(String action, String path) {
        Intent intent = new Intent(action, Uri.parse("file://" + path));
        // add StorageVolume extra
        intent.putExtra(StorageVolume.EXTRA_STORAGE_VOLUME, mVolumeMap.get(path));
        Slog.d(TAG, "sendStorageIntent " + intent);
        mContext.sendBroadcast(intent);
    }

再回到 updatePublicVolumeState　，调用了stateChange 后，将状态为632的标识发送到NativeDaemonConnector 的handlemessage，当NativeDaemonConnector 发现SDCard的状态发送改变时，比如unmount 的时候，从632（VolumeBadRemoval）变到605（VolumeStateChange）到onEvent，当onEvent再次得到请求时，进入判断会直接执行notifyVolumeStateChange 函数，代码如下：

if (code == VoldResponseCode.VolumeStateChange) {
            /*
             * One of the volumes we're managing has changed state.
             * Format: "NNN Volume <label> <path> state changed
             * from <old_#> (<old_str>) to <new_#> (<new_str>)"
             */
            notifyVolumeStateChange(
                    cooked[2], cooked[3], Integer.parseInt(cooked[7]),
                            Integer.parseInt(cooked[10]));
}

notifyStateChange 会调用updatePublicVolumeState通知packageManger　SDCard己经unmount.

再回到Vold

由于vold 启动文件一开始就启动了CommandListener的runcommand由于socket 一直在通讯，当发现值改变后，进入以下代码runCommand 方法里面:

else if (!strcmp(argv[1], "unmount")) {
        if (argc < 3 || argc > 4 ||
           ((argc == 4 && strcmp(argv[3], "force")) &&
            (argc == 4 && strcmp(argv[3], "force_and_revert")))) {
            cli->sendMsg(ResponseCode::CommandSyntaxError, "Usage: volume unmount <path> [force|force_and_revert]", false);
            return 0;
        }

        bool force = false;
        bool revert = false;
        if (argc >= 4 && !strcmp(argv[3], "force")) {
            force = true;
        } else if (argc >= 4 && !strcmp(argv[3], "force_and_revert")) {
            force = true;
            revert = true;
        }
        rc = vm->unmountVolume(argv[2], force, revert);
}

这时调用VolumeManage的unmoutVolume。该方法来源于Volume 的unmountVol，调用这个函数会unmount 三个挂载点，并同时调用setState通知框架unmount 成功，可以改变UI等一系列动作。

最后总结

MountService: 实现用于管理存储设备的后台服务

StorageManage:访问MountService 接口，并向应用层提供接口

PackageMangeService:是用于管理系统中所有apk，当SDCard发生变化时，向应用层发送消息

NativeDaemonConnector:创建socket实现mountservice 和vold 的通信

可以这么说：当vold 捕获到uevent 事件，会将事件消息通知framework,framework 进行判断，然后再下发执行命令。

粗糙图

最后附一张比较粗糙的结构图，时间较急，没仔细画好

本文链接

Android SDCard UnMounted 流程分析（二）

2012-03-22T07:47:00Z

上一篇讲到通过NetlinkManager发送uevent 命令到NetlinkHandler 的onEvent，代码如下：

void NetlinkHandler::onEvent(NetlinkEvent *evt) {
    VolumeManager *vm = VolumeManager::Instance();
    const char *subsys = evt->getSubsystem();

    if (!subsys) {
        SLOGW("No subsystem found in netlink event");
        return;
    }
    SLOGD("NetlinkHandler:OnEvent subsys values is %s",subsys);
    if (!strcmp(subsys, "block")) {
        SLOGD("NetlinkHandler:onEvent");
        vm->handleBlockEvent(evt);
    }
}

在NetlinkHandler 里面得一个VolumeManager，当收到的命令为block时调用VolumnManager的handleBlockEvent，如上加红加粗的代码。

handleBlockEvent实则是通过一个循环将事先将main事先读取的配置文件:etc/vold.fstab存进VolumeCollection，得到VolumeCollection的对象，然后调用Volume 的handleBlockEvent，如代码：

void VolumeManager::handleBlockEvent(NetlinkEvent *evt) {
    const char *devpath = evt->findParam("DEVPATH");

    /* Lookup a volume to handle this device */
    VolumeCollection::iterator it;
    bool hit = false;
    for (it = mVolumes->begin(); it != mVolumes->end(); ++it) {
        if (!(*it)->handleBlockEvent(evt)) {
#ifdef NETLINK_DEBUG
            SLOGD("Device '%s' event handled by volume %s\n", devpath, (*it)->getLabel());
#endif
            hit = true;
            break;
        }
    }

    if (!hit) {
#ifdef NETLINK_DEBUG
        SLOGW("No volumes handled block event for '%s'", devpath);
#endif
    }

看一下Volume 的handleblockEvent代码：

int Volume::handleBlockEvent(NetlinkEvent *evt) {
errno = ENOSYS;
return -1;

看起来好像没做什么事，其实真的实现在于Volume 的子类，DirectVolume，DirectVolme 中重写了handleBlockEvent，看代码：

int DirectVolume::handleBlockEvent(NetlinkEvent *evt) {
    const char *dp = evt->findParam("DEVPATH");

    PathCollection::iterator  it;
    for (it = mPaths->begin(); it != mPaths->end(); ++it) {
        if (!strncmp(dp, *it, strlen(*it))) {
            /* We can handle this disk */
            int action = evt->getAction();
            const char *devtype = evt->findParam("DEVTYPE");

            if (action == NetlinkEvent::NlActionAdd) {
                int major = atoi(evt->findParam("MAJOR"));
                int minor = atoi(evt->findParam("MINOR"));
                char nodepath[255];

                snprintf(nodepath,
                         sizeof(nodepath), "/dev/block/vold/%d:%d",
                         major, minor);
                if (createDeviceNode(nodepath, major, minor)) {
                    SLOGE("Error making device node '%s' (%s)", nodepath,
                                                               strerror(errno));
                }
                if (!strcmp(devtype, "disk")) {
                    handleDiskAdded(dp, evt);
                } else {
                    handlePartitionAdded(dp, evt);
                }
            } else if (action == NetlinkEvent::NlActionRemove) {
                if (!strcmp(devtype, "disk")) {
                    handleDiskRemoved(dp, evt);
                } else {
                    SLOGD("DirectVolume:handleBlockEvent--->handlePartitionRemoved");
                    handlePartitionRemoved(dp, evt);
                }
            } else if (action == NetlinkEvent::NlActionChange) {
                if (!strcmp(devtype, "disk")) {
                    handleDiskChanged(dp, evt);
                } else {
                    handlePartitionChanged(dp, evt);
                }
            } else {
                    SLOGW("Ignoring non add/remove/change event");
            }

            return 0;
        }
    }
    errno = ENODEV;
    return -1;
}

因为我的板子还未完善，所以这里它认为我的sdcard是一个分区，但无关紧要，原理一样，就根据分区的代码跟踪。:handlePartitionRemoved，由于代码过多，只贴出核心代码：

void DirectVolume::handlePartitionRemoved(const char *devpath, NetlinkEvent *evt) {

if ((dev_t) MKDEV(major, minor) == mCurrentlyMountedKdev) {
        /*
         * Yikes, our mounted partition is going away!
         */

        snprintf(msg, sizeof(msg), "Volume %s %s bad removal (%d:%d)",
                 getLabel(), getMountpoint(), major, minor);
        SLOGD("DirectVolume:(dev_t) MKDEV(major, minor) == mCurrentlyMountedKdev:%d,msg is :%s.",mCurrentlyMountedKdev,msg);
        mVm->getBroadcaster()->sendBroadcast(ResponseCode::VolumeBadRemoval,
                                             msg, false);

    if (mVm->cleanupAsec(this, true)) {
            SLOGE("Failed to cleanup ASEC - unmount will probably fail!");
        }

        if (Volume::unmountVol(true, false)) {
            SLOGE("Failed to unmount volume on bad removal (%s)",
                 strerror(errno));
            // XXX: At this point we're screwed for now
        } else {
            SLOGD("Crisis averted");
        }
    }
}

到此，直接调用父类的unmountVol方法，unmountVol会通过setState通知框架状态改变。代码太多，只推荐核心代码：

int Volume::unmountVol(bool force, bool revert) {
setState(Volume::State_Unmounting);
}

而setState会通过socket将msg消息传给框架

mVm->getBroadcaster()->sendBroadcast(ResponseCode::VolumeStateChange,
msg, false);

接下去的步骤是关于socket的操作，就不深入了。

小结

　到了这一步，Vold 向上层反馈的动作基本己经完成，下一篇文章将会讲解Framework 如何取得Vold 反馈过来的数据。

本文链接

Android SDCard UnMounted 流程分析（一）

2012-03-22T06:53:00Z

Android SDCard框架

Android SDCard框架，我们修改一般涉及到四大模块

Linux Kernel 用于检测热拔插，作为框架开发者来说，这者不用涉及
Vold 作为Kernel 与 Framework 之间的桥梁
Framework 操作Vold ,给Vold 下发操作命令
UI　与Framework 交互，用于挂载/卸载SD卡

框架涉及的源码位置

Vold :System/vold

为vold 提供接口：System/Netd

其他涉及的部分：System/core/libsysutils/src

System/core/include/sysutils

Framework:frameworks/base/services/java/com/android/server

访问和提供接口类：framework/base/core/java/android/os/storage/

可能还要参考的库：framework/base/libs/storage

framework/base/native

UI:Settings/src/com/android/setting/deviceinfo

SDCard UnMounted流程分析

初始化

VolumeManager, CommandListener, NetlinkManager 都是在 main()函数里面初始化的。

其中 VolumeManager,NetlinkManager 内部采用单例模式。

(1) Class NetlinkManager 主要是创建于内核通信的 socket,接收来自底层的信息,然后传交给VolumeManager 处理。

(2) class CommandListener 主要收到上层 MountService 通过 doMountVolume 发来的命令,分析后,转交给 VolumeManager 处理;VolumeManager 处理信息后,或报告给上层 MountService,

或交给 volume 执行具体操作。CommandListener在main()初始化后，之后开始监听，会开一个线程不停的监听来自内核的消息。

深入main文件

在Vold 的main.cpp里面，启动一个线程用来监听kernel 发出unMounted 的uevent事件，代码：

NetlinkManager *nm;
//NetlinkManager内部使用的单例模式
if (!(nm = NetlinkManager::Instance())) {
        SLOGE("Unable to create NetlinkManager");
        exit(1);
    };

//开始监听，从服务启动就一直监听
if (nm->start()) {
        SLOGE("Unable to start NetlinkManager (%s)", strerror(errno));
        exit(1);
}

NetlinkManager的start 函数是实例化了一个NetlinkHandler（继承关系：NetlinkHandler->NetlinkListener->SocketLinstener），并调用handler 的start方法，如下代码：

mHandler = new NetlinkHandler(mSock);
    if (mHandler->start()) {
        SLOGE("Unable to start NetlinkHandler: %s", strerror(errno));
        return -1;
}

深入NetlinkHandler 的start函数，见代码：

int NetlinkHandler::start() {
return this->startListener();
}

上面有说过NetlinkHandler其实是SocketLinstener的子类，NetlinkHandler直接调用父类的startListener 方法，startListener开启了一个线程用来执行threadStart函数，代码太多，贴出主心代码：

if (pthread_create(&mThread, NULL, SocketListener::threadStart, this)) {
SLOGE("pthread_create (%s)", strerror(errno));
return -1;
}

而threadStart函数则调用了runListener方法，代码如下：

void *SocketListener::threadStart(void *obj) {
    SocketListener *me = reinterpret_cast<SocketListener *>(obj);

    me->runListener();
    pthread_exit(NULL);
    return NULL;
}

runListener会判断socket 有无信息可读，不会阻滞UI，最后调用onDataAvailable函数，代码：

void SocketListener::runListener() {

SocketClientCollection *pendingList = new SocketClientCollection();

//代码有所省略

while (!pendingList->empty()) {

/* Pop the first item from the list */

it = pendingList->begin();

SocketClient* c = *it;

pendingList->erase(it);

/* Process it, if false is returned and our sockets are

* connection-based, remove and destroy it */

if (!onDataAvailable(c) && mListen) {

/* Remove the client from our array */

pthread_mutex_lock(&mClientsLock);

for (it = mClients->begin(); it != mClients->end(); ++it) {

if (*it == c) {

mClients->erase(it);

break;

}

pthread_mutex_unlock(&mClientsLock);

/* Remove our reference to the client */

c->decRef();

}

}
}

onDataAvailable会处理来自uEvent 的命令，并最终调用onEvent函数,onDataAvailable 位于System/core/libsysutils/src/NetlinkListener.cpp　这个主要处理一些socket方法的知识，一般不用修改。

最后由Netlinklinstener 来解析 ,代码：

bool NetlinkListener::onDataAvailable(SocketClient *cli)
{
    int socket = cli->getSocket();
    ssize_t count;

    count = TEMP_FAILURE_RETRY(uevent_kernel_multicast_recv(socket, mBuffer, sizeof(mBuffer)));
    if (count < 0) {
        SLOGE("recvmsg failed (%s)", strerror(errno));
        return false;
    }

    NetlinkEvent *evt = new NetlinkEvent();
    if (!evt->decode(mBuffer, count, mFormat)) {
        SLOGE("Error decoding NetlinkEvent");
    } else {
        onEvent(evt);
    }

    delete evt;
    return true;
}

小结

NetlinkManager其实就是用来处理uEvent 命令，并最终发送到vold/NetlinkHandler 的onEvent 。

本文链接

Android RenderScript 使用 Struct 及其下标的赋值

2012-03-09T07:45:00Z

这是一个关于RenderScript如何使用 Struct 的文章，是学习RenderScript 一个必须要掌握的基础知识点。

大纲

如何定义Struct
如何得到指针长度并循环为指针赋值
整体DEMO代码

如何定义Struct

RenderScript 里面定义结构有两种定义方法，参考如下：

typedef struct tempArray
{
float2 position;
float size;
} Array_T;

Array_T *myArray;

//定义一个struct

typedef struct __attribute__((packed, aligned(4))) tempArray {
int temp;
} Array_T;
Array_T *myArray;

RenderScript 定义Struct 成功后，会自动生成一个java文件，如上面的tempArray名称的结构，会生产这个文件:ScriptField_tempArray,代码如下：

/*
* Copyright (C) 2011 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*      http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

/*
* This file is auto-generated. DO NOT MODIFY!
* The source Renderscript file: /home/terry/workspace/RenderScriptsArray/src/com/xuzhi/renderScriptArray/array.rs
*/
package com.xuzhi.renderScriptArray;

import android.renderscript.*;
import android.content.res.Resources;

/**
* @hide
*/
public class ScriptField_tempArray extends android.renderscript.Script.FieldBase {
    static public class Item {
        public static final int sizeof = 4;

        int temp;

        Item() {
        }

    }

    private Item mItemArray[];
    private FieldPacker mIOBuffer;
    public static Element createElement(RenderScript rs) {
        Element.Builder eb = new Element.Builder(rs);
        eb.add(Element.I32(rs), "temp");
        return eb.create();
    }

    public  ScriptField_tempArray(RenderScript rs, int count) {
        mItemArray = null;
        mIOBuffer = null;
        mElement = createElement(rs);
        init(rs, count);
    }

    public  ScriptField_tempArray(RenderScript rs, int count, int usages) {
        mItemArray = null;
        mIOBuffer = null;
        mElement = createElement(rs);
        init(rs, count, usages);
    }

    private void copyToArrayLocal(Item i, FieldPacker fp) {
        fp.addI32(i.temp);
    }

    private void copyToArray(Item i, int index) {
        if (mIOBuffer == null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */);
        mIOBuffer.reset(index * Item.sizeof);
        copyToArrayLocal(i, mIOBuffer);
    }

    public synchronized void set(Item i, int index, boolean copyNow) {
        if (mItemArray == null) mItemArray = new Item[getType().getX() /* count */];
        mItemArray[index] = i;
        if (copyNow)  {
            copyToArray(i, index);
            FieldPacker fp = new FieldPacker(Item.sizeof);
            copyToArrayLocal(i, fp);
            mAllocation.setFromFieldPacker(index, fp);
        }

    }

    public synchronized Item get(int index) {
        if (mItemArray == null) return null;
        return mItemArray[index];
    }

    public synchronized void set_temp(int index, int v, boolean copyNow) {
        if (mIOBuffer == null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */);
        if (mItemArray == null) mItemArray = new Item[getType().getX() /* count */];
        if (mItemArray[index] == null) mItemArray[index] = new Item();
        mItemArray[index].temp = v;
        if (copyNow)  {
            mIOBuffer.reset(index * Item.sizeof);
            mIOBuffer.addI32(v);
            FieldPacker fp = new FieldPacker(4);
            fp.addI32(v);
            mAllocation.setFromFieldPacker(index, 0, fp);
        }

    }

    public synchronized int get_temp(int index) {
        if (mItemArray == null) return 0;
        return mItemArray[index].temp;
    }

    public synchronized void copyAll() {
        for (int ct = 0; ct < mItemArray.length; ct++) copyToArray(mItemArray[ct], ct);
        mAllocation.setFromFieldPacker(0, mIOBuffer);
    }

    public synchronized void resize(int newSize) {
        if (mItemArray != null)  {
            int oldSize = mItemArray.length;
            int copySize = Math.min(oldSize, newSize);
            if (newSize == oldSize) return;
            Item ni[] = new Item[newSize];
            System.arraycopy(mItemArray, 0, ni, 0, copySize);
            mItemArray = ni;
        }

        mAllocation.resize(newSize);
        if (mIOBuffer != null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */);
    }
}

生成的代码是提供给你做内存分配和操作类似数组的功能。

如何得到指针长度并循环为指针赋值

RenderScript 有两个函数是专门用来获取指针长度的：

rsGetAllocation：返回一个己经分配过地址的指针

rsAllocationGetDimX ：获取返回指针的长度

通过将这两个函数做组合使用可以返回指针长度,代码如下：

const int size = rsAllocationGetDimX(rsGetAllocation(myArray));

取得了长度即可以为指针内部变量赋值，代码如下：

for(int i=0;i<size;i++){
        array->temp=i;    //循环赋值

    rsDebug("current value is ====>", array->temp);    //打印当前值
    //指向下个指针
        array++;

}

整体DEMO代码

本DEMO没有任何界面，只是演示如何使用struct并打印出指针下标原素的值，如此简单，涉及的rs文件代码如下：

#pragma version(1)
#pragma rs java_package_name(com.xuzhi.renderScriptArray)

#include "rs_graphics.rsh"

static int initialized = 0;

//定义一个struct
typedef struct __attribute__((packed, aligned(4))) tempArray {
     int temp;
} Array_T;
Array_T *myArray;

static void  initArray(){
    Array_T *array=myArray;
    //得到struct长度
    //1.返回一个己经分配过地址的指针
    //2.获取返回指针的长度
    const int size = rsAllocationGetDimX(rsGetAllocation(myArray));
    for(int i=0;i<size;i++){
        array->temp=i;    //循环赋值

    rsDebug("current value is ====>", array->temp);    //打印当前值
    //指向下个指针
        array++;
    }
}

int root(){
rsgClearColor(0.0f, 1.0f, 0.0f, 1.0f);
if(initialized==0){
    initArray();
    initialized=1;
    }

    return 16;

}

java 代码如下：

package com.xuzhi.renderScriptArray;

import android.app.Activity;
import android.content.Context;
import android.content.res.Resources;
import android.os.Bundle;
import android.renderscript.Allocation;
import android.renderscript.RSSurfaceView;
import android.renderscript.RenderScriptGL;

public class RenderScriptsArrayActivity extends Activity {



    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new renderScriptView(this));
    }


    public class renderScriptRS {

        private ScriptC_array mScript;

        private ScriptField_tempArray array;

        RenderScriptGL mRS;

        public renderScriptRS(RenderScriptGL rs,Resources resource) {
            // TODO Auto-generated constructor stub
            mRS=rs;
            //初始化struct 并为其指定有多少个下标
            array=new ScriptField_tempArray(mRS, 10,Allocation.USAGE_SCRIPT|Allocation.USAGE_GRAPHICS_VERTEX);

            //实始化CcriptC
            mScript=new ScriptC_array(mRS, resource, R.raw.array);
            //绑定struct
            mScript.bind_myArray(array);
            //绑定脚本
            mRS.bindRootScript(mScript);

        }
    }



    public class renderScriptView extends RSSurfaceView {
        private RenderScriptGL mRS;
        private renderScriptRS mRender;

        public renderScriptView(Context context) {
            super(context);
            // TODO Auto-generated constructor stub
        }


        @Override
        protected void onAttachedToWindow() {
            super.onAttachedToWindow();
            android.util.Log.e("rs", "onAttachedToWindow");
            if (mRS == null) {
                RenderScriptGL.SurfaceConfig sc = new RenderScriptGL.SurfaceConfig();
                mRS = createRenderScriptGL(sc);
                mRender = new renderScriptRS(mRS, getResources());
            }
        }

        @Override
        protected void onDetachedFromWindow() {
            super.onDetachedFromWindow();
            if (mRS != null) {
                mRS = null;
                destroyRenderScriptGL();
            }
        }

    }
}

都加了注释了，最主要的四段代码标注了红色，要注意。

运行结果：

03-09 15:47:50.492: D/RenderScript(2298): current value is ====> 0  0x0
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 1  0x1
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 2  0x2
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 3  0x3
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 4  0x4
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 5  0x5
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 6  0x6
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 7  0x7
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 8  0x8
03-09 15:47:50.507: D/RenderScript(2298): current value is ====> 9  0x9

本文链接

Android RenderScript 关于Compute 的使用

2012-03-05T07:23:00Z

RenderScript 不仅可以用来画图，而且可以用来做密集的计算操作。目前的API可以使用到的是利用CPU的核心优势来帮我们做计算。在未来，可能会包括GPU和DSP处理器上做精密计算。

创建一个Compute 的RenderScript

下面有一张图详细的介绍了勾划了一个Compute 的 RenderScript:

图解：Andriod 有一个RenderScript Compute 的引擎来支持做精密计算，后期google 会不断扩展这个引擎让其支持更多的精密计算如上面提到的GPU、DSP等等，创建Compute RenderScript 同样的也必须写一个.rs 文件，做运行时生成对象读取调用。之后在Android 上层实现计算功能。另，（必须显示在应用上调用forEach_root或者在RenderScript 运行时运件中.rs，调用rsForEach()，Compute 才会自动调用硬件支持核心来计算） .

参照DEMO

在上层调用forEach_root 计算的DEMO
在RenderScript 运行时调用rsForEach计算的DEMO

其实，两个DEMO都实现了同一样的功能，就是将一张图片使用滤镜效果将其变颜色RGB值变成灰尘色，而另一张则原样显示，该DEMO参考了SDK中的HelloWorldCompute DEMO，而唯一与SDK中不一样的地方是在：SDK是在于上层调用forEach_root方法进行计算，而我使用的是在.rs 中调用rsForEach方法进行计算。两者功能相同，实现效果不一样而已。

在上层调用forEach_root 计算的DEMO

区别的代码在于：

SDK DEMO

.rs文件：

#pragma version(1)
#pragma rs java_package_name(com.example.android.rs.hellocompute)

const static float3 gMonoMult = {0.299f, 0.587f, 0.114f};

void root(const uchar4 *v_in, uchar4 *v_out) {
    float4 f4 = rsUnpackColor8888(*v_in);

    float3 mono = dot(f4.rgb, gMonoMult);
    //dot:[0]*[0]+[1]*[1]+[2]*[2]
    *v_out = rsPackColorTo8888(mono);
}

createScript方法：

private void createScript() {
        mRS = RenderScript.create(this);


        mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn,
                                                    Allocation.MipmapControl.MIPMAP_NONE,
                                                    Allocation.USAGE_SCRIPT);
        mOutAllocation = Allocation.createTyped(mRS, mInAllocation.getType());

        mScript = new ScriptC_mono(mRS, getResources(), R.raw.mono);

        mScript.forEach_root(mInAllocation, mOutAllocation);//通知RenderScript Compute Runtime
        mOutAllocation.copyTo(mBitmapOut);
}

在RenderScript 运行时调用rsForEach计算的DEMO

.rs文件：

#pragma version(1)
#pragma rs java_package_name(com.xuzhi.renderScriptCompute)

rs_allocation gIn;
rs_allocation gOut;

rs_script gScript;

const static float3 gMonoMult={0.299f,0.587f,0.114f};

void root(const uchar4 *v_in, uchar4 *v_out, const void *usrData, uint32_t x, uint32_t y){

//将一个uchar4 的颜色解压为float4
    float4 f4=rsUnpackColor8888(*v_in);

    //dot:[0]*[0]+[1]*[1]+[2]*[2]
    float3 mono=dot(f4.rgb,gMonoMult);
    //打包uchar4，alpha 默认为1.0
    *v_out=rsPackColorTo8888(mono);

}

void filter(){
//调用RenderScript 进行处理(操作输入的图片然后把处理的结果放到输出结果中)，最后把处理完的数据存回bitmap ，在ImageView显示出来
     rsForEach(gScript, gIn, gOut);
}

createScript方法：

  private void createScript() {
        mRS = RenderScript.create(this);
        //从一个bitmap 创建一个allocation
        mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn,
                Allocation.MipmapControl.MIPMAP_NONE, Allocation.USAGE_SCRIPT);

        mOutAllocation=Allocation.createTyped(mRS, mInAllocation.getType());

        mScript=new ScriptC_mono(mRS, getResources(), R.raw.mono);
        mScript.set_gIn(mInAllocation);

        mScript.set_gOut(mOutAllocation);

        mScript.set_gScript(mScript);

        mScript.invoke_filter();//通知RenderScript Compute Runtime

        mOutAllocation.copyTo(mBitmapOut);


}

总结

两种方法无论怎么变化，最终的上的都是要通知RenderScript Compute 运行时做计算功能。运行效果：

代码下载：

RenderScript->Compute

本文链接

关于Android RenderScript 的详细说明和一些实用文档

2012-03-02T07:15:00Z

RenderScript 是一种低级的高性能编程语言，用于3D渲染和处理密集型计算（3D播放等和关于CPU密集型的计算）。一直以来Android 在绘图性能的表现一直差强人意，引入NDK之后才有所改善，而在Honeycomb 中发布了RenderScript 这一杀手级在Framework 后，大大的增加了Android 本地语言的执行能力和计算能力。以下是参考一些网上总结的几点：

编程语言和可移植性

RenderScript 采用了c99语法（标准C来自1999年，最新标准是C11，来自2011年），新的应用编程接口（API）最终编译成原生代码。这意味着做为Android 图形开发者就不得不再系统的学习一套API，因为它的API并非人人都清楚，而Google 对于RenderScript 这方面的文档又少之又少。

RenderScript 无法从其他C应用程序移植过来，不过它在Android 设备上比NDK 更常见。相比于NDK的可移植性要弱一些，记得以前移植过一个C程序叫Cadaver的webdav客户端就是使用的NDK，所以这点来说RenderScript 的移植性可以说有待改善。

编译和调试

RenderScript 在机器上进行第一遍编译，然后在目标设备上进行最后一遍编译（Just-In-Time Compiling），因而带来更高效的原生二进制代码。这也就是意味着，凡是支持RenderScript 的设备都可以运行你的代码。不用管什么架构。

目前，RenderScript 带来的代码只能在主处理器上运行，它会自动生成可利用多个核心的代码（如果设备上有多个核心）。就因此，编译出来的程序是针对该机器的最佳优化，这解决了Device Fragmentation,也就是说开发者再也不必担心使用者的手机、平板够不够好、有没有GPU...等等问题，全都交给RenderScript 去担心就好。没有GPU,RenderScript 写好的程序就交由CPU来处理（背后的编译技术其实是使用的LLVM）。

性能

RenderScript 有类似于CUDA的Compute API用于计算，配置和设置相对比较容易。最终的运行速度实际上要比胜过于NDK 的实现方式，需要编写的代码比较少。而RenderScript 最适合用于做3D的用户界面或高性能计算任务。而上面的编译和调试所说的一样，随着最后一遍的编译可以通过硬件直接或得性能的提升。

最后

引入RenderScript 并不是来代替NDK的，而是给开发者多一种选择。

如何学习？

关于官方的文档

http://developer.android.com/guide/topics/renderscript/index.html 这是官方RenderScript 的首页

http://developer.android.com/guide/topics/renderscript/graphics.html 关于图形方面的知识

http://developer.android.com/guide/topics/renderscript/compute.html 关于计算方面的知识

国外一个比较不错的开发者的博客，目前只有两篇：

http://blog.iangclifton.com/2011/08/24/renderscript-101-part-1-renderscript-basics-tutorial/

http://blog.iangclifton.com/2011/08/24/renderscript-101-part-2-renderscript-interaction/

另外那些rs文件里面的函数如何寻找？

4.0的请到框架这里查找相应的头文件：

frameworks/base/libs/rs/scriptc，这里包含以下的头文件

rs_allocation.rsh rs_atomic.rsh rs_cl.rsh rs_core.rsh rs_debug.rsh rs_graphics.rsh rs_math.rsh rs_matrix.rsh rs_object.rsh rs_quaternion.rsh rs_time.rsh rs_types.rsh

或者在SDK的platform 下也可以找到。

对应的文档在下面：

&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;br id="-moz-br-"&gt;&lt;/body&gt;&lt;/html&gt;

另外：

想学好RenderScript 必须先看一下关于图形学方面的知识和熟悉OpenGL方面的知识，路遥遥呀。。。。

本文链接

Android RenderScript 的使用基础篇

2012-03-01T05:54:00Z

准备上4.0项目，最近接触API 的时候看到了RenderScript 。通过运行google 那几个项目发现这个真是一个非常不错的API，但是google 所提供的文档非常少，有助于了解计算机图形计算，虽然我们做应用编程的不一定要涉及这块，但涉猎一下总是不错的。

RenderScript 是Android 平台上的一种类C脚本语言。要在我们程序上实现RenderScript 渲染功能，最少需要实现的几个功能如下，以一个Hello Wold 为例：

helloworld.rs 实现RenderScript 的代码
RenderScriptRS.java 一个辅助类，简化操作RenderScript (非必要)
RenderScriptView.java 一个继承于RSSurfaceView的类，用于显示RenderScript 的渲染或者用来处理用户的触摸等视图
RenderScriptHelloWorldActivity.java 这个不用多说，Android 应用程序的界面类

当创建一个RenderScript 的项目的时候，必须在包名下创建一个以rs为后缀的文件(位于我们Activity 同包名下)，如本篇文章使用的helloworld.rs文件.

#pragma version(1)
#pragma rs java_package_name(com.xuzhi.rs.helloworld)

#include "rs_graphics.rsh"

int gTouchX;
int gTouchY;

void init(){
    gTouchX=50.0f;
    gTouchY=50.0f;
}

//application main
int root(void){
    rsgClearColor(0.0f,1.0f,0.0f,0.0f);//颜色更改为no red,full green,no blue,no opacity ，的RGBA值
    rsgFontColor(1.0f,0.0f,1.0f,1.0f);//设置字体颜色
    rsgDrawText("my first renderscript application",gTouchX,gTouchY);//根据应用传上来的x,y 将字画在屏幕对应的坐标上
    rsDebug("======my renderscript debug========",rsUptimeMillis());//打印日志
    return 20;
}

注解：

#pragma:简单的可以理解告诉或者通知编译器编译这个文件时需要的参数或者指定编译的版本等，跟编译器有关。

void init():这个函数作一些初始化动作

int root(viod):程序入口，根据返回值(ms)作刷新。比如上面写的20相当于每20毫秒刷新一次。

root 函数下rsgClearColor,rsgFontColor,rsgDrawText都位于rs_graphics.rsh头文件下。

rsDebug是打印日志函数，位于rs_core.rsh头文件。

在上面的代码中，日志将己每20毫秒打印一次这样的日志：03-01 11:09:18.289: D/RenderScript(1838): ======my renderscript debug======== 600462 0x9298e

rsUptimeMillis则定义在rs_time.rsh头文件中。

目前有关于RenderScript调用的函数位于我们SDK目录下(platforms/android-*[目前11-15]/renderscript/include)目录里面的头文件中。

好了，rs文件己经编写完成，接着往下走。

下一步，为了方便调用RenderScript 这里创建了一个辅助类，RenderScriptRS.java。

/**
* Render Script help
* @author terry
*
*/
public class RenderScriptRS {

    private RenderScriptGL mRS;

    private ScriptC_hellowold mScript;

    public RenderScriptRS(RenderScriptGL rs,Resources resource) {
        // TODO Auto-generated constructor stub
        mRS=rs;
        mScript=new ScriptC_helloworld(mRS, resource, R.raw.hellowold);
        mRS.bindRootScript(mScript); //绑定脚本
    }

    /**
     * 传入坐标
     * @param x
     * @param y
     */
    public void onActionDown(int x,int y){
        mScript.set_gTouchX(x);
        mScript.set_gTouchY(y);
    }
}

目前我们所做的一切都是要使用到的RenderScriptGL(RenderScript 图形的衍生)，实例化RenderScriptGL并绑定脚本。如果你的开发ADT高于或者是1.5的话Eclipse 会根据你的rs文件生成ScriptC_你的rs文件为名的java类。如上面代码的ScriptC_helloworld一样，并且在资源目录res/raw生成一个.bc的文件，在实例化ScriptC_hellowold会需要传进去。

下一步，创建RenderScriptView.java,让其可以显示在界面上。

import android.content.Context;
import android.renderscript.RSSurfaceView;
import android.renderscript.RenderScriptGL;
import android.renderscript.RenderScriptGL.SurfaceConfig;
import android.view.MotionEvent;

public class RenderScriptView extends RSSurfaceView {

    private RenderScriptGL mRS;

    private RenderScriptRS mRender;

    public RenderScriptView(Context context) {
        super(context);
        // TODO Auto-generated constructor stub
        initRenderScript();
    }

    /**
     * 初始化RenderScriptRS
     */
    private void initRenderScript() {
        if (mRS == null) {
            RenderScriptGL.SurfaceConfig config = new SurfaceConfig();
            mRS = createRenderScriptGL(config);

            mRender = new RenderScriptRS(mRS, getResources());

        }
    }

    @Override
    protected void onDetachedFromWindow() {
        // Handle the system event and clean up
        mRender = null;
        if (mRS != null) {
            mRS = null;
            destroyRenderScriptGL();
        }
    }

    @Override
    protected void onAttachedToWindow() {
        // TODO Auto-generated method stub
        super.onAttachedToWindow();
        initRenderScript();
    }

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        // TODO Auto-generated method stub
        /**
         * 传入点击坐标
         */
        if (event.getAction() == MotionEvent.ACTION_DOWN) {
            mRender.onActionDown((int) event.getX(), (int) event.getY());
            return true;
        }

        return false;
    }
}

RSSurfaceView扩展自SurfaceView，用来显示这些需要渲染的图形界面。

上述代码的initRenderScript方法，如果RenderScriptGL 未实例化，就需要创建一个SurfaceConfig(这是用来控制深度的颜色，深度缓冲区等等，这里使用默认)，并且让它实现自身的onTouchEvent事件，传入x,y坐标轴进入RenderScript，改变文本显示的位置(跟随鼠标的点击点变化)。

最后的界面只需要让它显示出来即可：

public class RenderScriptHelloWorldActivity extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new RenderScriptView(this));
    }
}

这一系列的步骤可以用一张图来做说明，详细的规划了RenderScript 的图形概述：

这是一个简单的DEMO，介绍了RenderScript 使用的一些基本步骤，详细的使用后面会慢慢提到。最后通过上面的代码可以看到的运行效果如下：

另外，后文还会提供一些详细的文档和例子。比如：

rs_graphics
rs_core
rs_math
rs_time

上面这四个的头文件的API。

代码可以在Android 4.0中找到，RenderScript->Helloworld。
注：模拟器无法运行。

本文链接