Tag Archives: Android

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手机的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

原文链接

支持库

主要包含两方面的支持:外部器件 IO API用户驱动API

  • 外部器件 IO API实现了相关的工业标准协议和接口,可以让App与传感器和制动元件进行通信。支持的接口主要有:GPIOPWMI2CSPIUART

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
Firebase Cloud Messaging (FCM)
Firebase Crash Reporting
Firebase Realtime Database
Firebase Remote Config
Firebase Storage
Fit
Instance ID
Location
Nearby
Places
Mobile Vision
AdMob
Android Pay
Firebase App Indexing
Firebase Authentication
Firebase Dynamic Links
Firebase Invites
Firebase Notifications
Maps
Play Games
Search
Sign-In
  • 权限

运行时授权在这里不能够提供支持,因为没有UI来提供授权对话框的显示,所以App开发者需要在manifest中将所有权限列出。所有正常和高危权限均会在安装时统一授予。

  • 通知

由于没有系统级别的状态栏和UI窗口支持,所以通知服务不会支持,在App中要避免调用NotificationManager。