Category Archives: 技术

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。

Android 物联网初探

Android OS作为现今智能手机操作系统的老大,对智能设备的流行起到重要作用,从手机、平板到TV、手表、汽车等等,无处不在,无所不包,已然是现实意义的便携式设备OS的代表,虽然不同的设备厂商各怀鬼胎、高度定制,但不可否认Android OS确实推动了产业的迅速发展。随着智能设备的微型化和物联网的发展,Android团队也为我们带来了在物联网领域的又一力作-Android Things。与Android Wear、Android Auto一样,Android Things同样承袭了不开源的路子,预计后续开源的可能性也比较低。

Google在物联网领域主要有两方面:Android ThingsWeave

Android Things(原名为“Brillo”)是基于Android OS面向终端设备的一套定制化OS,旨在为了解决异构SoC物联网设备、不同传感器的数据处理等提出的一套解决方案,开发者只需要关注上层应用级别的数据传输和处理,同时还支持自定义传感器等元件的驱动。

Weave主要解决物联网对于后端数据传输和设备交互的需求,通过Google 的基础设施来采集、传输、交换、分析物联网的海量数据,同时联合其他厂商定义了一系列操纵设备指令使得设备可以通过Google Assistant这样的语音交互助手来完成对物联网设备的操控。

Android Things基于Android OS,在软件架构上没有太大的改动。

Android OS Architecture

Linux KernelHALNative C/C++ LibrariesAPI Framework沿袭了原有的架构和代码。在Framework同一层级上增加了Google Services(Google Mobile Services),这一模块是Google对Android设备提供完整移动服务的核心,在国内的Android手机上由于不可抗拒的原因无法提供服务,如果有幸能够买到Nexus、Pixel系列的手机,其实这些手机ROM的软件架构于此基本一致。除此之外还包含有一套IoT设备专有的支持库,它扩展了Android核心Framework API,以此来支持更多的传感器或者其他手机上不存在的硬件设备。

与手机平板相比,在App层面上有一个重大的区别,那就是Android Things的单应用运行模式。这意味着IoT设备在开机启动后第一个运行的应用就是当前开发的应用,即刻提供服务,像手机的电话、通讯录、日历、相机、Launcher等系统应用在此平台下都不再存在,这对开发者来说可能是一大变化。

Android Things Architecture

Android Things提供了对于物联网设备无差异的支持,但对于不同设备制造商、不同类型的传感器的数据传输、交换还是存在着巨大的鸿沟,这就是Weave存在的意义。Weave被定义为一个物联网的通信平台。不同OEM生产的物联网设备嵌入Weave SDK,然后通过Google Cloud基础设施与Weave服务器之间进行数据交换和收集。Weave联合一部分厂商定义了许多设备可操纵参数,比如灯的开关亮度、插座的开关、空调通风量等等,同时约束了一系列的设备注册流程和安全协议,通过这一系列的操作,可以让OEM厂商只需要关注设备本身以及提供的特定服务而无需关注设备与服务器之间的交互和数据传输。说到底这是一套完整的物联网数据交换解决方案,Google的野心也并非仅此而已,Google Cloud的基础设施,人机交互的指令定义,Google Assistant的原生支持,通道与终端的完整控制使得Google不再像Android OS一样脱缰狂奔,而是牢牢把握在自己手中。

Weave虽好,OEM厂商对此的支持又如何?这还是一个疑问,当前的SDK只支持Linux、高通、Marvell的特定芯片,同样的疑问还有,无法访问Google Services的中国用户怎么办?联想到之前推出的Android Wear中国版,或许是一个选择。