如何看待鸿蒙os里全是android痕迹? 第1页

1 2 3 4

menggexiansheng 网友的相关建议:

最好别认真看代码，否则真是成了安卓套壳了，这能不兼容安卓才怪了。

       HomoDroid OS 2.0 Copyright (C) 2013 Android Open Source Project rename adb_debug.exe hdc.exe rename AdbWinUsbApi.dll HdcWinApi.dll rename AdbWinUsbApi.dll HdcWinUsbApi.dll replace Adb Hdc HdcWinApi.dll replace Adb Hdc HdcWinUsbApi.dll

       DevEco Studio x Intellij HomoDroid Studio √

组件包括方法全都改了名连 adb 都改叫 hdc 整就一翻版

兼容 Android，太强了！（华为HDC 成功连接 Android 设备）

华为的开发者工具使用教程——“下载Android Studio”

建议程序员赶紧改一下网页，改成Homo Studio 应该就OK了。

文件对比如下：

接下来的2.0、3.0、4.0迭代建议，雇佣更多人手，加快进行文件名汉化和替换。

把开源的代码改到文科生完全看不出区别，除非高手能从构架的角度领悟，为止。

rewrgf 网友的相关建议:

android是开源系统，在android开源框架的基础上做自己的修改，合理合法，而且也节约了很多不必要的“反复造轮子”工作。

美国是坏，但美国的东西好，我们又可以用，那为什么不拿来用呢？取其善者而用之，而不是像美国人那样，遇到中国的东西，都是邪恶的，要禁止销毁，最后导致自己死伤惨重。

wang-peng-cheng-63-31 网友的相关建议:

看了很多这个问题下“实锤”的证据，在我看来一点也没有惊喜，因为九月份刚发布的时候，根据当时TV上的HarmonyOS已经分析得差不多了。

我把九月份写的那个长文的一部分放在这里吧。

2. 当我们在讨论Android时，我们在讨论什么？

此部分讨论Android相关的定义，作者自身能力有限，有问题请斧正。

2.1 Android的定义

对于很多做安卓开发的人来说，这也是个很难回答的问题。

上图为Android官方文档的架构图。从下往上依次分为 Linux 内核、硬件抽象层（HAL）、系统 Native 库和 Android 运行时环境、Java 框架层以及应用层这 5 层架构，其中每一层都包含大量的子模块或子系统。

那么，当我们在说Android系统时，我们指的是什么？

Linux 内核吗？很显然，不是。但它和Android没有关系吗？并不。很简单的例子，图中的Binder就是Android特有的东西。
硬件抽象层（HAL）吗？是，也不是。是是因为它确实是Android定义的，而不是是因为它只是一个抽象层，具体实现需要自己写。
系统 Native 库和 Android 运行时环境吗？Android 运行时环境当然是。系统 Native 库呢？不全是，其中的OpenGL、WebKit、Libc等等，不是Android特有的。
Java 框架层以及应用层当然是。其中的Java Core，也是重新实现的。

所以，Android这个词所代表的，应该包括：

Binder等Linux内核模块；
硬件抽象层（HAL）；
Android的Native 库和 Android 运行时环境；
上层Framework和应用。

严格意义上，Android应该称为Android Application Platform（安卓应用平台）。

对于普通用户而言，看到的是应用；对于Android应用开发者，看到的是Java API Framework以及少部分NDK提供的接口；对于Android底层开发人员，看到的Android Runtime以及Native 库；对于摄像头、传感器模块等厂商，看到的是硬件抽象层；Linux内核部分，绝大多数人不会涉及，一般是由手机产商定制修改Linux内核，以及更下层的Bootloader。

定义1 含卓量（Android Content）——在一个整体规模为M的系统A中，包含的Android特有的组件的大小为S，那么，称该系统A的含卓量为。

引理1 对于Android系统架构的每一层，其所占的比重不同。

定义2 卓重（Android Weight）——在Android系统，每一层的所占的比重为：

Linux 内核：10%
硬件抽象层（HAL）：15%
系统 Native 库和 Android 运行时环境：40%
Java 框架层以及应用层：35%

以上比重仅为作者个人意见。

2.2 ”掏空“安卓需要几步？

首先，我们需要定义，什么是”掏空”安卓？很显然，就是让安卓应用在用户无感知、代码无修改的情况下，正常运行。

以密码学的形式化安全性证明的形式，那就是：

已知原生安卓系统Alice和掏空后的安卓系统Bob，给定任意应用package和输入input，以及output=OS(package, input)，其中OS可为Alice或 Bob中的任意一个。对于一个任意多项式时间用户Adv(app, input, output)，无法有效判断OS=Alice还是OS=Bob。我们称满足这个掏空不可区分性（Hollowing Indistinguishability）的，为选择应用分析（Chosen Package Analysis） 下的IND-CPA掏空。

（讲人话就是：给定应用和输入，从获得的输出中，无法区分其来自原生安卓系统还是”掏空“后的安卓系统）

当然，我们在实际中，并不使用这么简陋的定义，在安卓官网上有CTS（Compatibility Test Suite）测试套件，只有通过了CTS，才是安卓，并不是看到有Android的字样就是安卓了。

根据”掏空“的字面含义，最终一定会留有一个视界（俗称”壳“）。”壳“的厚度有大有小，我们称”壳“最薄的系统形态为究极态。

很显然，究极态系统的最小包含为：Java Framework API、NDK接口和系统应用。关于这点，我确信已发现了一种美妙的证法，可惜这里空白的地方太小，写不下。

在此基础上，我们可以定义以下几种”掏空“模型：

内核”掏空“（Kernel Hollowing）：替换Linux kernel，重新实现Binder等接口，并且要提供包含POSIX等的Linux kernel接口；
硬件抽象层”掏空“（HAL Hollowing）：修改HAL的描述，并且根据新的HAL重写驱动；上层使用者按需修改；
运行时库”掏空“（Runtime Libraries Hollowing）：重新实现运行时，并且要保证Java Framework API不变，以及提供相同的NDK接口；
框架和应用“掏空”（Framework and Application Hollowing）：Java Framework的包名、类名、方法签名等不变，修改Java层实现、资源文件等，例如权限申请实现、UI的默认样式；替换系统默认应用为自定义应用，等等。

当然，还有一种更极端的无余（Nothing Left）”掏空“模型，将Java Framework API以及NDK接口也替换掉。但也很显然，没有了最外面的”壳“，应用没有支撑点，我们只会看个寂寞。

对于以上的几种”掏空“模型，都有一些难点和弊端：

内核”掏空“：设计、架构、性能优良的内核很难实现，并且保证系统调用的兼容性是一个苦力活；
硬件抽象层”掏空“：现有驱动将报废，需要重新编写；一般不建议这么做；
运行时库”掏空“：同时受到上层Framework和底层接口的限制；无法避免地需要依赖Binder、HAL等底层实现；
框架和应用“掏空”：现在很多手机厂商采用的方式，改动较小，但可能引入一些API的兼容性问题（因为有很多实现使用了私有API）。

根据定义可以知道，这几种模型不是互斥的，可以进行组合。

从目前能被感知的层面来看，HarmonyOS有的东西是：

硬件抽象层
运行时库
Java Framework和JS Framework

缺少的（也很难验证的）是，是所谓的“微内核”，目前内核依然是Linux（可能有定制修改）。

客观对比目前HarmonyOS和Android的框架，二者的区别并不是很大。如果单独把HarmonyOS的东西拎出来，缺少的是一个独立的应用启动器（Launcher），也就是现在的.hap里的那个entry.apk承担的角色，以及为啥Ability编译之后自动会包装上Activity、Service等的壳。

其他回答说的能看到http://android.xxx的包、能调用Android特有的资源等，这是因为这些东西就是Android的东西啊！目前不管是手机还是TV还是手表，都是把HarmonyOS和Android放在一起，二者是平行的两套框架。

我们以为的“掏空”，应该是上面这种，里面是HarmonyOS，外面是Android；而实际上，目前其实是下面这种，HarmonyOS和Android各自有独立的部分，但也有交集。

而至于“套皮”，只是因为从Android的视角来看，看到的都是Android。前面也提到过，所谓被“掏空”的Android的最小子集也应该包括Framework和NDK接口，技术上来说，除非看到源码，否则应用层是不可能感知到区别的，这是很难证明或者证伪的东西。

当然，我可以明确地猜测，明年四月份开源的面向4G内存以下的代码（也就是手表、车机、电视等的），肯定可以看到作为submodule的AOSP。

HarmonyOS吸引人的东西（至少对我来说），是它提供的硬件虚拟化、分布式特性。如果说做的还不好的地方，那就是目前的UX还不是很人性化，以及Ability框架还比较受限。至于什么独立的应用格式、独立进程啥的，除了证明“HarmonyOS是一个所谓的<独立自主系统>”，还有什么意义吗？

现在这个放出来的系统，可以发现，Android部分其实锁死在了Android 10（和EMUI 11一样），而按照菊厂的规则，EMUI的版本和Android大版本本来应该是一致的。这个Android部分的东西，估计以后也不会按照大版本来更新了，而是选择性地将AOSP里的新特性增加到HarmonyOS里，慢慢过渡。其它回答也提到了，这个会是个大问题，以后Android部分的兼容性会越来越成为负担。

说了这么多，我只想说，与其在这里打嘴炮，还不如去赚华为的钱。不管是不是安卓套壳，华为以后都会大力宣传，三百亿的营销费用，何不赚一点到自己口袋里？（本条五毛，括号里记得删掉）

bj365 网友的相关建议:

“像真的也就是说：不是真的”。

jia-jin-71-12 网友的相关建议:

1月23日更新：这篇回答近期被B站和头条某视频以“指责鸿蒙”为由挂了起来，于是额外写了一些对于鸿蒙项目的看法：

我们其实不介意Harmony OS是不是借鉴了AOSP，就算真全扒下来也无所谓，开源软件有多个发行版再正常不过，二次开发比原版叫座的例子也比比皆是。Ubuntu也是基于Debian开发，没人因此觉得它就低后者一头、不是成功产品。

我们反感的是，各种证据都甩脸上了（ADB^[1]、安卓包名的“鸿蒙系统”^[2]、“为旧版本鸿蒙开发”^[3]），不少人仍预设立场，扯些自己都不明白的术语，无限臆想Harmony OS的“绝对自主”和神化一家商业公司；以及开发团队对“Harmony OS和AOSP的渊源”始终含糊其辞，公关稿里一句老实话都没有。

华为^[4]、三星和索尼等大厂，本就反哺了Android不少特性，跳过Google版本号搞二次开发再正常不过。谁也没期望Harmony OS一步登天，借鉴的部分大大方方地借鉴，遵守各项开源许可证，谁也说不出半个不字。能吃透Android系统，已经超越市面上大部分开发团队了，就算真是二次开发也光荣得很。

闪烁其词、利用民众朴素的民族情绪，赚商业吆喝乃至打压竞争对手才是不光荣的。

对开发难度的忽略、对一家企业的无限拔高，从长远看对整个行业是有害的，建议回去读读鲁迅先生的《中国人失去自信力了吗》。

顺便反驳几种未经调查的经典伪论证：

“如果用了Android的代码，那Google法务部怎么不起诉？”

关Google法务部什么事？

Android系统本身是AOSP（Android Open Source Project）的开源内容，任何人都可以遵照Apache许可证拿去商用，甚至闭源，而无需Google专门授权。只有Google Mobile Service等少数几个带Google商标的组件，才是需Google授权的私产。

这就是为什么华为被制裁后，用不了Google组件，却能接着更新Android安全补丁。

至于是否遵守Apache许可的问题，确实是值得讨论的，不过这么多年，也没听说Apache基金会牵头起诉过谁。

“鸿蒙已经开源了，开发板都有了，用的是C++不是Java，自己不会去看看吗？”

OpenHarmony这个嵌入式操作系统和手机的Harmony OS 2.0是一回事？

目前公开全量源代码的，是第一版Open Harmony这个低功耗IoT系统，适用于内存小于128MB的嵌入式设备，liteos内核^[5]；不是手机上的Harmony OS 2.0。

OpenHarmony 1.0应该是鸿蒙项目的初衷（物联网系统），用C语言很正常。liteos 确实是实时内核，但这种低功耗轻量kernel方案^[6]移植不到手机的 Harmony OS 2.0 上。后者至今仍是闭源，从第一批OTA升级用户的反馈看，用的似乎是Linux 4.14 kernel。

“非要揪着不放让自己人下不来台？”

我对华为没有批判的意思，也不认为HOS和AOSP如果存在渊源是什么让人难堪的事情，只是希望对任何一家商业公司，都应持实事求是的态度。

中国科技行业几十年来一直被西方封锁，能走到今日，是靠帮亲不帮理地一味护短，还是靠实事求是？ To C的产品必然要经受讨论甚至批驳，心系科技行业不代表只能褒扬，开放理性的舆论才有助于整个行业良性发展。

重视研发值得赞扬，营销方式该吐槽还是要吐槽，本就是两回事。

华为最大的贡献，是证明了“技工贸”和“贸工技”哪条路才是中国该追求的。它只是万千民营企业中的一个，一样采取剥削剩余劳动价值的再生产模式，一样要警惕其垄断市场。

它不是电网、地铁公交这种担负政治任务做赔本生意的国企，更不是全民所有。它的一切活动，都是追求利润的正常商业活动，别的企业有的偷奸耍滑它也有（偷换闪存、屏幕抽奖、二五一事件），没必要过度神化，就像没必要过分贬低。

它也不是中国唯一的科研机构——集成电路领域就有中芯国际、上海微电子、合肥长鑫、长江存储、龙芯、兆芯和上下游一系列企业，BIS的实体清单上还有其他几百家中国企业和科研院所。中国科技产业的希望在于整个行业乃至产学研的良性发展，从不只靠哪一家公司引领。

美国人制裁华为，我们是要声援它。但过度神化而忽略其商业本质，并不利于公平竞争，更不利于科技行业的良性发展。目光要放长远，没必要听不得人说华为一个不字。

参考

^ https://www.zhihu.com/question/339790377
^ https://www.zhihu.com/question/339790377/answer/1634756413
^ https://www.zhihu.com/question/339790377/answer/1632355872
^三星与华为则深入参与到了整个Android系统从基础代码到最终成型的过程之中。 https://m.newseed.cn/news/1353716
^OpenHarmony介绍 https://gitee.com/openharmony/docs/blob/master/get-code/%E6%BA%90%E7%A0%81%E8%8E%B7%E5%8F%96.md#openharmony%E4%BB%8B%E7%BB%8D
^Huawei LiteOS是华为面向物联网领域开发的一个基于实时内核的轻量级操作系统。 https://github.com/LiteOS/LiteOS

qu-yu-64 网友的相关建议:

刚好手头有一些现成的工具和数据，就来简单分析一下鸿蒙的代码里有多少是和AOSP（Android Open Source Project）相关的。说实话，AOSP到底包含哪些项目，这个范围感觉不太好界定啊，太多Repo。我之前抓取过Android的Security Bulletin，我们就假定Security Bulletin（https://source.android.com/security）里提到的相关Repo都算是AOSP吧。

那么首先需要把AOSP的Repo都Clone到本地，按照Security Bulletin里的信息，我Clone了下列Repo：

我们姑且认为这些Repo都算是AOSP的吧。

其次是下载鸿蒙的代码，按照这里：https://device.harmonyos.com/en/docs/start/get-code/oem_sourcecode_guide-0000001050769927 和这里：https://gitee.com/openharmony/docs/tree/master/get-code 的介绍，从这个链接可以下载OpenHarmony的全量代码：https://repo.huaweicloud.com/harmonyos/os/1.0/code-1.0.tar.gz 关于鸿蒙的代码解释，我看到有些博客里介绍得挺好的，例如：https://blog.csdn.net/kuangyufei/article/details/111938348 ，这时候我们可以预期：至少在Android的kernel.common和鸿蒙的code-1.0kernel里应该会有一些重复的，但其他的项目到底有没有重复的，这个还不好说。

把两部分代码都下载下来，我们这里只分析C/C++代码（OpenHarmony的压缩包code-1.0解压之后是没有Java代码的，AOSP里倒是有很多Java代码）。首先第一个问题是，OpenHarmony和AOSP里各有多少C、C++代码呢，用一段Python程序可以统计一下：

       import os   file_count=0 for dirpath, dirnames, filenames in os.walk('code-1.0'):  for file in filenames:   if(file.endswith(".c") or file.endswith(".cpp") or file.endswith(".h") or file.endswith(".cc") or file.endswith(".hpp") or file.endswith(".hxx") or file.endswith(".cxx") or file.endswith(".c++")):    file_count=file_count+1  print(file_count)

我们用这段代码统计AOSP，会发现有98764个C/C++文件，而统计OpenHarmony，有29204个C/C++文件。说实话，都比我预想的要少一些。那搞清楚了文件数量，接下来我们需要对这些源码做一些处理了。我们这里选择用最简单的Clone Detection的方法，Tokenization之后用Bag of Words来计算即可。

不过说实话，要把这十几万个C/C++文件tokenize，也不是那么容易的事情，我试了一下srcML（https://www.srcml.org/），可是它处理OpenHarmony的时候，到几千个文件的时候就不动了（也有可能是我机子的问题，我是在一台笔记本上跑的），我也懒得查找原因，尝试换另外一个工具Understand（https://licensing.scitools.com/download）。tokenization的过程中我们需要把代码注释全都删掉，因为注释会妨碍相似度的计算。

另外，Understand虽然顺利处理了OpenHarmony，但对AOSP这一百多个项目，如果统一处理的话，就会报错，呵呵，没办法，但也是预料之中。只能挨个项目处理了，用一段python代码批量处理一下：

       import os import shutil  AOSP_dir="AOSP" result_dir=AOSP_dir+'-filter'  if(os.path.exists(result_dir)):     shutil.rmtree(result_dir) os.mkdir(result_dir)  dirs=os.listdir(AOSP_dir) for each_dir in dirs:     if(os.path.isdir(AOSP_dir+'/'+each_dir)):         print("uperl C-File-DeleteComments.pl "+AOSP_dir+'/'+each_dir)         os.system("uperl C-File-DeleteComments.pl "+AOSP_dir+'/'+each_dir)

其中那个Perl脚本的作用就是使用Understand删掉C、C++代码中的注释，并且进行tokenization，同时，为了提高效率，也删除了源码中所有String。经过漫长的等待，终于完成了。然后再处理成下游工具需要的格式，这里我们用一个轻量级的工具来做clone detection：

https://github.com/microsoft/near-duplicate-code-detector 这个工具的输入是类似于这种输入：

                {         "filename"         :         "CVE-2014-9322-1-espfix.h"         ,         "tokens"         :[         "#"         ,         "ifdef"         ,         "_ASM_X86_ESPFIX_H"         ,         "#"         ,         "define"         ,         "_ASM_X86_ESPFIX_H"         ,         "#"         ,         "ifdef"         ,         "CONFIG_X86_64"         ,         "#"         ,         "include"         ,         "<asm/percpu.h>"         ,         "DECLARE_PER_CPU_READ_MOSTLY"         ,         "("         ,         "unsigned"         ,         "long"         ,         ","         ,         "espfix_stack"         ,         ")"         ,         ";"         ,         "DECLARE_PER_CPU_READ_MOSTLY"         ,         "("         ,         "unsigned"         ,         "long"         ,         ","         ,         "espfix_waddr"         ,         ")"         ,         ";"         ,         "extern"         ,         "void"         ,         "init_espfix_bsp"         ,         "("         ,         "void"         ,         ")"         ,         ";"         ,         "extern"         ,         "void"         ,         "init_espfix_ap"         ,         "("         ,         "void"         ,         ")"         ,         ";"         ,         "#"         ,         "endif"         ,         "#"         ,         "endif"         ]}

具体可以参考上面这个工具的ReadMe。这样我们生成了两个tokenization以后的文件，分别是：Harmony.jsonl.gz和AOSP.jsonl.gz，然后把它们放到一个目录下，就可以用这个工具检测了。运行了5、6个小时之后有结果了，需要注意，这两个项目都有大量的项目内克隆，我们关心的是他们之间的克隆，过滤了一下输出，只找到了937对克隆，其中有一个文件来自AOSP kernel.common的有201对。而Harmony那边的文件，很多是在third_party，vendor这样的目录，其实严格意义上都算不得克隆。

结论：没有发现目前OpenHarmony全量压缩包中有大量AOSP代码。应该注意到，OpenHarmony全量压缩包只开源了“第一个版本支持128K-128M设备上运行”的系统代码，类似于AOSP中platform.frameworks.av，platform.frameworks.base这些repo提供的功能都还没有开源（或者是我没有找对地方？），要兼容Android应用，必然会引入一些ART，framework这些代码。这也是为什么目前OpenHarmony压缩包里没有Java代码的原因。

克隆检测的结果，具体含义大家一看便知：

CloneDetectionResultsAOSP.csv

130.4K

百度网盘

liu-shu-bin-57 网友的相关建议:

鸿蒙目前推出的版本，都是安卓内核的。

这点华为自己也承认。

本来一个稳定的商用内核就不是这么快能出来的，再等个三四年就算快的了。华为有选择的说实话很娴熟，让人不爽但抓不到直接把柄。

kaveil 网友的相关建议:

用安卓的内核是因为需要兼容安卓app，减少app开发者的工作量。鸿蒙系统就像一个大房子，安卓只是鸿蒙旗下的一员，未来还会有微软的win10等更多的系统加入到鸿蒙这个大家庭中来。对于iOS这种死不悔改，坚决不与华为交流技术的强硬派，鸿蒙系统将会把他们拒之门外。

以上不是我说的，是我爸听某瓜视频上的专家说的，为这事我已经被他开除国籍了。

bu-dong-xing-guang-50 网友的相关建议:

01.06更新在最后

12.25更新2

鸿蒙2.0中有安卓彩蛋吗？

鸿蒙2.0中，无法通过设置界面系统版本号打开彩蛋了。那么鸿蒙中是否仍保留了安卓彩蛋呢？

通过查Android源码，可知Android设置里的彩蛋对应Activity为"android/com.android.internal.app.PlatLogoActivity"。

经验证，鸿蒙2.0中可以使用Android插件化hook方式启动。代码见截图

12.25更新

评论说可以试试Ability和Activity间能不能通过Android的Intent跳转，我去验证与研究了一下。

结论1：可以使用Android的Intent，从Ability A跳到Ability B，完全没问题。

结论2：如果你的Ability类名是小写开头，就呵呵了

例如MainAbility跳转到SecondAbility，那么对应代码：

鸿蒙版：

       Intent intent = new Intent(); Operation operation = new Intent.OperationBuilder()     .withDeviceId("")     .withBundleName("com.example.harmonystudy")     .withAbilityName("com.example.harmonystudy.SecondAbility")     .build(); intent.setOperation(operation); component.getContext().startAbility(intent, 0);

Android API版（引用了android.jar）：

       Activity currentActivity = MyUtils.getCurrentActivity();  // 引入android.jar,反射ActivityThread得到 android.content.Intent androidIntent = new android.content.Intent(); androidIntent.setClassName(currentActivity, "com.example.harmonystudy.SecondAbilityShellActivity"); currentActivity.startActivity(androidIntent);

其原理是鸿蒙在APP编译时，在module的build目录下，会生成Android套壳的代码，然后编译出鸿蒙安装包hap中的apk文件。只要知道ShellActivity的名称，就可以使用Android API跳转了。

通过多创建几个Ability，发现其规律是：

对于 Xxx(Ability).java，build路径下总会生成一个唯一对应的 Xxx(Ability)ShellActivity.java

如果Ability类名的首字母小写，会发生什么？

1.创建Foobar（首字母大写），dummy（首字母小写）两个Ability

2.查看config.json自动生成配置

3.查看build目录下生成的Activity类

4.查看build下生成的AndroidManifest.xml

估计配置文件的名称是通过类名填充；但生成Java类时候没做判断，直接首字母大写。

结果就很悲剧：要么找不到对应的类，要么匹配不上配置文件……怎么也无法启动

当你调用鸿蒙API跳转，首字母小写

       java.lang.ClassNotFoundException: Didn't find class "com.example.harmonystudy.dummyShellActivity"

鸿蒙API，首字母大写

       com.example.harmonystudy E 01100/AbilityShell: DistributedManager::fetchAbilities sendRequest failed com.example.harmonystudy E 01100/AppExecFwk: [d5eec4a2b934462, 0, 0] ContextDeal::startAbility fetchAbilities failed

Android API，首字母大写类名

       Unable to find explicit activity class {com.example.harmonystudy/com.example.harmonystudy.DummyShellActivity}; have you declared this activity in your AndroidManifest.xml

Android API，首字母小写类名

       java.lang.ClassNotFoundException: Didn't find class "com.example.harmonystudy.dummyShellActivity"

在build目录中，只能找到Ability和Activity在名称上的关系。那么实际程序运行中，Ability和Activity是如何对应的？通过Android Intent跳转Activity，鸿蒙如何找到相应的Ability？

通过反编译 /system/framework/boot-zframework.z.vdex ，可以在 AbilityShellConverterUtils 这个类中找到两者相互转换的方法。

vdex的反编译需要借助这个工具

12.22更新

逆向分析各位大佬说的差不多了。

下面介绍一下，

通过简单配置，使用Android API开发鸿蒙APP

1.在DevEco IDE中创建一个鸿蒙应用。然后将Android SDK下的 android.jar 拷贝至 libs 目录

2.由于不需要将这个android.jar打包至应用的hap中，所以改一下编译配置

修改build.gradle，将相应的 implementation 改为 compileOnly

       dependencies {     // implementation fileTree(dir: 'libs', include: ['*.jar', '*.har'])    // 原来的配置     compileOnly fileTree(dir: 'libs', include: ['*.jar', '*.har'])  // 更改后     testCompile'junit:junit:4.12' }

3.同步一下工程，发现没有错误

4.新建一个空白Ability，IDE自动创建了一个带Helloworld的布局。我们可以用这个页面进行简单的测试：只要能成功调用Android API，并执行相应逻辑就可以。

（1）首先测试Android的Handler。在Text控件的点击事件中，post一条消息

       @Override     public void onStart(Intent intent) {         super.onStart(intent);         super.setUIContent(ResourceTable.Layout_ability_second);         Text helloworld = (Text) findComponentById(ResourceTable.Id_text_helloworld);         helloworld.setClickedListener(new Component.ClickedListener() {             @Override             public void onClick(Component component) {                 // 调用Android的Handler                 new Handler().post(new Runnable() {                     @Override                     public void run() {                         // 更改Text内容                         helloworld.setText("通过Handler更新文字");                     }                 });             }         });     }

(2) 第二个测试，通过反射获取Activity，向页面中添加一个Android TextView

       // 上面点击代码中添加一行调用 new Handler().post(new Runnable() {     @Override     public void run() {         ......         // 向当前页面添加控件         manipulateAndroidActivity();     } });  // 通过Android API，向鸿蒙应用界面中添加控件 private void manipulateAndroidActivity() {         Activity activity = MyUtils.getCurrentActivity();         FrameLayout decorView = (FrameLayout) activity.getWindow().getDecorView();         TextView someText = new TextView(activity);         someText.setText("添加一个Android TextView");         someText.setTextSize(20);         FrameLayout.LayoutParams params = new FrameLayout.LayoutParams(                 FrameLayout.LayoutParams.WRAP_CONTENT,                 FrameLayout.LayoutParams.WRAP_CONTENT);         params.gravity = Gravity.CENTER;         someText.setLayoutParams(params);         decorView.addView(someText); }  //反射获取Android的Activity public static Activity getCurrentActivity () {         try {             Class activityThreadClass = Class.forName("android.app.ActivityThread");             Object activityThread = activityThreadClass.getMethod("currentActivityThread").invoke(                     null);             Field activitiesField = activityThreadClass.getDeclaredField("mActivities");             activitiesField.setAccessible(true);             Map activities = (Map) activitiesField.get(activityThread);             for (Object activityRecord : activities.values()) {                 Class activityRecordClass = activityRecord.getClass();                 Field pausedField = activityRecordClass.getDeclaredField("paused");                 pausedField.setAccessible(true);                 if (!pausedField.getBoolean(activityRecord)) {                     Field activityField = activityRecordClass.getDeclaredField("activity");                     activityField.setAccessible(true);                     Activity activity = (Activity) activityField.get(activityRecord);                     return activity;                 }             }         } catch (Exception e) {             e.printStackTrace();         }          return null;     }

执行效果：

经过上面的配置，你就可以愉快的用Android SDK开发鸿蒙应用了。

如果想实现一个功能，鸿蒙SDK没提供怎么办？那就调用Android SDK接口实现啊……

等等，你问为什么鸿蒙APP里还能这么干？呵呵

原回答论述部分删掉了，简要说明下个人观点：

鸿蒙的技术方案，让Android生态碎片化问题更严重，增加了开发者的适配工作。随着Android大版本升级，这一方案的技术成本也急剧上升。

最后提供一些大佬的分析文章

hanyu-liu 网友的相关建议:

谢邀！

作为从Android 2.3干到今天的老Android码农，我来说几句自己的看法。内容基本来自对一个专栏文章的回复：Simon菌：关于鸿蒙os2.0安装旧版Android软件出现"专为旧版鸿蒙打造"的简单猜测

// ************ 12月23日添加一些内容在末尾 ************

// ************ 正式开始 ************

定性

华为鸿蒙系统成熟度非常低，离真正“开宗立派”还有很长的距离。你问真正行业里混的，有人信华为的PPT吗？没有啊，谁不知道他是画大饼？一个这种鸿蒙PPT描述的规模的东西，真开始做，有很多指标都会在以年为单位的尺度上有反应，比如招聘的侧重和数量，内部人员的调动，re-org，对外的tech talk/paper/专利等等，但这些华为目前都不明显，所以鸿蒙吹水是明摆的事。

同行

看见一些没见过世面的小朋友，发现鸿蒙里面有几个“Android”关键字就见猎心喜，感觉实锤了，然后再批判一番，我认为大可不必。华为这套玩法，简直再普遍不过了，就是还啥也没有呢，就先带节奏嘛。我举两个美国带节奏的例子: Google Duplex，Google IO上放了个Demo，说是AI帮你给理发店餐馆打电话订位子，后来有媒体揭露，说你这个是假的，比如这个：

最后Google自己也比较尴尬，冷处理了。另一个是马斯克提出的Hyperloop。这东西怎么说呢，当年提出来的时候，尬吹的人也不少，但稍微有点自然科学常识的人都知道那东西不靠谱，但马斯克敢吹啊，敢吹就有人信。最后，这两个例子的节奏都带起来的，上了新闻头版，后面的事呢，也就那么回事了。

环境

在中美贸易战这个大环境下，有些人舔美，有些人仇美，两个光谱极端之间人更多，也没必要回避。但总体来说，老百姓朴素的情感需求在这，华为选择画这个饼，回应这种需求，我持中立态度。毕竟这种节奏带起来有好处，反噬的风险也存在，自己要为自己的选择负责。

看待

华为作为中国难得的做实业做出成绩的公司，被美国总统点名针对打击的公司。我建议是应该给予一定的包容和鼓励。华为搞鸿蒙的出发点是对的，但宣传的手段有问题，已经跟某些美国公司、资本家一样下流了，这个我们是要批评的。只要我们通过合法的手段表达理性的批评，言之有据，对华为的意义就是正面的，冷嘲热讽大可不必。因为我们最终目的还是要督促他，把这个画的饼做出来。从抄抄改改开始，也可以接受，继续保持开放的态度展示自己的工作就可以了。

最后，HarmonyOS到底是个什么，这个饼多大，还缺了那些东西，要依据这个华为鸿蒙 HarmonyOS - 手机开发者 Beta 版本，不是媒体的宣传。有些媒体用华为炒流量，蹭的你恶心了，这笔帐不该算在华为身上。

// ************ 12月23日 ************

最近有人批评我说，你一个码工为什么不讨论技术，写一堆东西什么都没说，这些留言虽然yygq，但也有道理，因为我确实没说技术。但我内心又有所不甘，因为正经讨论的技术其实不少，但也没咱们这个问题下某些yygq的赞多啊：

回到这个问题，我认为鸿蒙这个东西，不但是有技术背景的人想要讨论，没技术背景的人也想要被科普，到底华为的东西行不行，是不是跟以前的那些骗子一样？毕竟鸿蒙这个东西愿景有点大，出现的时间点有点敏感，出现的动机有点复杂。所以我结合我有限的理解，想跟非技术背景的知友，分享一个简单的，没有技术细节的结论：谨慎乐观。这个结论的意思就是：华为画了个很大的饼，现在很多地方都是临时方案，或仓促的。因为这个工程是个过程，roadmap也不是到今年就结束了，未来还有很多的可能，但至少华为认真的设计了这个饼，逻辑是自洽的，而且也动起来了，现在不是盖棺定论的时候。

当然，有些人反复纠缠在“安卓套壳”这四个字上，我觉得咱们有必要把“安卓”，“套壳”这些东西都说明白了，有了标准再说是不是“安卓套壳”，再说“是/否”背后代表的含义是什么。至于你喜欢或不喜欢，那是你的主观选择，我给予尊重。

首先，我贴一张我在其他问题下面跟一个有技术背景的知友讨论的截图，后来我跟其他朋友分享并讨论了我的这个观点，其中有些大佬觉得，我说的话太不严谨，对“Android套壳”意见比较大。。。我觉得人家说的有道理，咱们就从这个角度展开讨论。

鸿蒙OS做没做完

根据华为自己定的roadmap，现在还没做完，大概明年才可能有手机这个级别的细节放出来，用在智能手表上的应该是成熟度高一些的，毕竟本来也没用Google的Wear OS。

兼容还是套壳

如果你没有技术背景，你可以这么认为，给手机级别硬件用的鸿蒙还没有完工呢，现在开发环境的测试手机是“AOSP套壳”！当然，这个套壳有不同的解释，有些比较恶毒的解释，就是“鸿蒙”替换“Android”。这个说法其实是不完全的！根据现有的信息，鸿蒙App会有一个AOSP的shadow app（影子App），这个影子App相当于一个启动器，他是一个纯粹的AOSP App，但没有实现细节，他会通过一些我们还不知道的手段，去运行鸿蒙App。这个所谓的“手段”，我们并不知道细节，但至少具有以下几个特点：

这个“手段”是运行在一个AOSP为基底的OS中，并不是完全摒弃了AOSP；
这个“手段”跟AOSP ART是什么关系，现在还不好说，但它肯定不是ART！因为鸿蒙的dex没法直接在ART上执行。它可以是ART的拓展，即魔改的ART；也可以是ART的兄弟，另一个runtime，现在信息不多，不好说；

所以，更严谨的说，我截图里的说法是不准确的，是错的，人家做的工作比我想象的多，至少“AOSP套壳”不是简单的改名字，而是在AOSP的基础上做了很多加法。已经初步实践自己的系统层，即下图中“基础服务”这一层的东西了。

鸿蒙SDK和Android SDK的关系

确实是抄，但这个抄不是因为懒/坏/骗，而是要吸Android的开发生态，比如下面这个视频，钊哥特别想给鸿蒙洗地，但其实没洗到点子上，钊哥毕竟是个实在人，最后其实还是说了实话。我觉得没必要拐弯磨脚，就直球对决，把逻辑讲明就行了。

首先，Android的SDK有几大痛点，比如Activity/Fragment的lifecycle特别复杂，没有意义的复杂；XML对layout的不友好，即该解耦合的没解好（对比html+css这种模式）；UI相应背后的异步模型非常简陋等等，都被鸿蒙继承了，虽然有一定的改进；

第二，鸿蒙继承Android SDK的目的，是为了降低Android开发者迁移的开销，估计也有为未来方舟降低一定的复杂度。毕竟比Android好的解决方案多了去了，比如Qt的signal/slot，iOS的GCD。但问题是iOS和Qt的开发资源，并不是鸿蒙的首要目标。

第三，UI开发上，鸿蒙可以用类web的模式，这个是合理的，但未来面对iOS/Android搞基于DSL的Swift UI和Compose，估计也要考虑这部分迁移的问题，未来可能也会有些对应的东西出来。

综上，为了吸收Android的开发生态，做一套这样的SDK，可以理解。

鸿蒙的目的是什么

大家看看所谓“分布式应用”的一些想象，确实还是有些过人之处的，要用现在的Android搞，真要吐血的：

最后，分享一段我很喜欢的电影，枪火，中的一个片段，还挺配当下这个感觉。

如何看待鸿蒙os里全是android痕迹? 的其他答案点击这里

1 2 3 4

如何看待鸿蒙os里全是android痕迹? 第1页

最好别认真看代码，否则真是成了安卓套壳了，这能不兼容安卓才怪了。

2. 当我们在讨论Android时，我们在讨论什么？

2.1 Android的定义

2.2 ”掏空“安卓需要几步？

参考

鸿蒙2.0中有安卓彩蛋吗？

通过简单配置，使用Android API开发鸿蒙APP

相关话题

前一个讨论

下一个讨论

相关的话题