Sym

先开个头，准备这与一篇struct hw_module_t HAL_MODULE_INFO_SYM 相关的文章。 Hal层的库文件是怎么被上层调用的？上层调用时的入口(相当于main)又是什么呢？它就是HAL_MODULE_INFO_SYM。 下gps.default.so库为例子，上层gpstest.apk打开后，会在/system/lib/hw/下面寻找gps.default.so(也可能是gps.$(platform).so)的这个库，gps.defualt.so的入口就是HAL_MODULE_INFO_SYM, 从此再去调用hal层里的open,init,write,read等接口，hal再通过这个接口去设备结点读写。 简单是这样，深入的可以在网上找，相关的资料比较多，不深入说了。 ———————————————— 来源： oschina 链接： https://my.oschina.net/u/920274/blog/3189436

函数调用栈，利用NDK 的 arm-linux-andr oideabi-addr2line.exe 提供的命令行来手动查看 libunity.sym.so 的信息 bulgy 的so自动处理 的so是不带符号信息的，因此就算上传了so也是无法查看函数调用栈信息的，因此需要借助NDK查看 android-ndk-r10e\android-ndk-r10e \toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin> arm-linux-androideabi-addr2line -f -e libunity.sym.so 002de41 002de41 为函数地址 来源： oschina 链接： https://my.oschina.net/u/1391394/blog/3045856

一、Camera 架构 NOTE：这是 Android Camera API 1 ，Camera 的架构与 Android 整体架构是保持一致的： Framework ： Camera.java Android Runtime : android_hardware_Camera.cpp Library : Client (Camera.cpp, ICameraClient.cpp, etc...) Server (CameraService.cpp, ICameraService.cpp, etc...) HAL : CameraHardwareInterface.h 　　架构简图: 　　　　　　　 　　根据架构简图可以看到，实际上 Camera 的架构与 Android 架构是一一对应的，上层应用调用 Camera 相关的方法后，指令依次通过框架层、运行时环境、本地库、硬件抽象层，最终到达具体设备。设备执行动作后，获得的数据又会沿着反方向依次发送到最上层。 需要注意的是，在本地库这一层中，涉及到一个 C/S 结构： 即通过客户端与服务端的交互来传递指令与数据。 实际上，只有服务端与 HAL 层进行沟通。 由于客户端与服务端是不同的进程，它们之间需要依靠 IPC Binder 机制 来进行通讯。 　　相关源码位置（Android 7.1 源码）: Application：

简介 这一篇笔记，我们将从 hw_get_module() 函数入手，去探究 Libraries 层是如何调用 HAL 层的库中的函数的。 CameraService 是在开机时就会启动的，而当它第一次启动时，就会调用一个名为 onFirstRef() 的成员函数，我们所要探究的内容就是从这里开始的。 NOTE： 这一部分主要参考： Android–hw_get_module解析 本来想一天内应该能搞定这篇记录，结果公司这边正好有个项目要做，于是只能在闲暇时间慢慢写出来了。 hw_get_module() 1. CameraService 1.1 CameraService.cpp 位置：framework/av/services/camera/libcameraservice/CameraService.cpp CameraService::onFirstRef()： 首先调用其基类的 onFirstRef 函数。 更新 notifier （这个 BatteryNotifier 好像是个单例，看类名好像和电池有关）。 通过 hw_get_module 函数获取 rawModule。 注意 rawModule 是 camera_module_t 类型。 利用 rawModule 创建 mModule 的实例，mModule 是 CameraModule 类。

我必须承认，学习eosio一直没有闲庭信步的感觉，我可以看到为什么很多人说它有一个陡峭的学习曲线。随着eosio软件继续经历大量快速发展，文档数量有限，很少有工作实例可供参考。我已经被困了好几次，也希望帮助改善下一个开发人员的体验。在本文中，我将通过将其分解为单独的部分来讨论 eosio.token 合约。 什么是eosio.token合约？ eosio.token合约允许创建许多不同的代币。这使任何人都能够创建和发送代币。每个代币必须由 issuer 帐户发行。由于帐户可以包含多方，因此你可以使用具有所有者和活动权限的普通帐户或自定义配置帐户来创建和管理代币。每个代币都是 asset 类型，如下所示： 1000000000.0000 SYS 1.0000 SYMBOL 0.10 SYS asset 类型是一个数字（如果我没记错的话可以达到18位小数）和一个可以在1-7个大写字母之间的符号。此合约有三个操作可用于与之交互。它们是：创建，发布和转账。 创建用于定义新代币的特征。这包括代币 asset 符号，最大供应量以及允许发出代币的帐户。创建还会将新代币配置保留在区块链上。这意味着新代币配置的存储必须由某人放置。正如你稍后将看到的，部署此合约的帐户（在我们的案例中为'eosio.token'）也将支付代币配置存储。 发布用于增加代币的有效供应。可以持续发出代币，直到达到最大供应量