Tag: Android

Zircon内核与LK内核的关系

Zircon内核与LK内核的关系

LK(Little Kernel)是一个为嵌入式应用设计的微系统内核,它为FreeRTOS、ThreadX这样的商业项目提供了一个不错的选择。这些系统仅提供有限的内存、有限的外设和任务集;Zircon运行在那些拥有快速处理器、不定大小内存、能够挂载任意外设的现代手机、PC等末端计算设备上。 Zircon内部构建在LK层之上;Zircon有进程的概念,LK则没有;Zircon的进程构建在LK的线程、内存结构之上。 更多的不同点: Zircon有一类用户模式的支持,LK没有; Zircon是一个对象句柄系统,LK没有这个概念; Zircon有能力安全模型,在LK里所有代码都是被信任的。 随着时间的推移,为了满足新的需求、更好的适应上层系统,低层次的结构也可能会改变。 原文链接: https://fuchsia.googlesource.com/zircon/+/HEAD/docs/zx_and_lk.md 延伸: LK: https://github.com/littlekernel/lk/wiki/Introduction LK内核正在被使用的场景:Android的bootloader和Trusted Execution Environment

Android共享热点IP问题引发的“血案”

Android共享热点IP问题引发的“血案”

今天一朋友问Android手机的Wi-Fi共享热点IP能不能修改,他那边一直是192.168.43.*,自己记得在设置里面没有这个选项,便回复了他不能修改。后来猜测Android源码可能为了刻意避开常用局域网路由器192.168.0/1/2.*段,特意设置的其他网段,但会不会存在与基站代理在一个网段后冲突自我协调的机制呢?(当然这个可能性很低,一般基站的代理服务器分配的都是10.*段的内网地址),既然有了这个问题,那索性看看源码怎么设置的。 涉水 首先想到的是到StackOverFlow上看看有没有相关问题,搜索得之, http://stackoverflow.com/a/31238229/4865380 确实有人提到修改Hotspot网关的问题,给出的具体源码是在WiFiStateMachine.java中硬编码了192.168.43.1这个网关地址,这就解释了为什么共享出去的IP地址都是192.168.43.*了。手机用户想修改它,duang然是不可能了。 挣扎 从AOSP的master中去查找上文提到的platform/framework/base/wifi/java/android/net/WiFiStateMachine.java却消失了踪影,寻寻觅觅发现已经被移到platform/framework/opt/net/wifi/service/java/com/android/server/wifi/WiFiStateMachine.java。一看就对源码分析不熟悉,这些模块搬家的消息都不知道,其实从5.0之后opt/net/wifi之后就有了,部分代码被迁移到这里。 但是,但是,这个文件里面再也没有发现startTethering()方法,而且硬编码的代码也被移除了,难道5.0之后热点网关IP的配置又被更改了?继续跟踪文件diff发现有一次提交提到AP: https://android.googlesource.com/platform/frameworks/opt/net/wifi/+/d4f347f7de30834317dd1561dc806eccb1c4f277

这次提交说明有关于AP热点配置在WiFiStateMachine.java中的代码被迁移到SoftAPManager,然后通过SoftAPManager来集成,同时也提到了AP这块代码放在WiFiStateMachine代码不够清晰。 继续挣扎 既然知道了代码迁移过程,那就需要跟着去寻找SoftAPManager。这个文件和WiFiStateMachine.java在同一包下,打开文件一看还是没有发现对于IP地址的硬编码部分,只能再次寻求log,这个文件的修改历史记录比较少,其中最老的一条对应于上文提到的AP状态管理通过SoftAPManager。通过历史查看这次修改发现了从WiFiStateMachine.java迁移过来的硬编码IP地址的代码。既然在创建时代码还存在,那么次新一条的历史记录就更加让人着迷了:

时隔上次迁移到SoftAPManager.java的三个月后,这块逻辑又要被搬家了,归宿就是Tether模块,这么一波三折到底是Android源码,修改的简直是猝不及防。 上岸 上面提交记录中,提到的Tethering&TetherInterfaceStateMachine在platform/frameworks/base/services/core/java/com/android/server/connectivity/下面,关于硬编码的部分被迁移到TetherInterfaceStateMachine.java。

硬编码IP的方式并没有改变,至此终于将代码的变化追踪完了,结果还是一套硬编码方式。当然乐在于真正找到了答案。

Android 物联网SDK

Android 物联网SDK

原文链接 支持库 主要包含两方面的支持:外部器件 IO API、用户驱动API 外部器件 IO API实现了相关的工业标准协议和接口,可以让App与传感器和制动元件进行通信。支持的接口主要有:GPIO、PWM、I2C、SPI、UART。 https://developer.android.com/things/sdk/pio/index.html 用户驱动API扩展自Android framework的Service组件,它允许App注入硬件事件到framework层,其他的Apps就可以通过标准的Android API来访问这些事件信息。 https://developer.android.com/things/sdk/drivers/index.html 与AndroidOS相比的变更 应用变化 Android Things中系统应用将不复存在,Content Provider也消失了,所以在开发应用时就不要通过Intent调用如下API了: CalendarContract ContactsContract DocumentsContract DownloadManager MediaStore Settings Telephony UserDictionary VoicemailContract 显示不再是必须 Android Things的应用与传统的应用开发一样,提供了相同的UI工具集来支持显示,在图形模式下窗口会以*真实*全屏的方式显示,没有状态栏和导航栏,即便你从底部滑动也不会出现,整个屏幕完全交由用户操控。 当然了,Android Things的显示屏并不是必须的。在一个无屏的设备上App的activities还是主组件,framework依然会分发输入事件到获得焦点的前台activity上。应用不能通过其他应用的组件(比如service)来接收键盘事件或者移动事件。 主Activity支持 Android Things自动运行一个App在manifest中定义的”home activity”作为系统启动后入口,这个activity必须包含一个由CATEGORY_DEFAULT和IOT_LAUNCHER组成的intent-filter。 为了方便开发,这个activity还需要包含一个CATEGORY_LAUNCHER的intent-filter,这样Android Studio才能在发布和调试时作为默认activity来启动。

Google Services支持的变化 Android Things支持一系列的Google APIs。在这里需要用户输入和授权的API都不支持。下表列出了支持的API和不支持的API: 支持的APIs 不支持的APIs Cast Drive Firebase Analytics […]