简介：基于机器学习实现安卓恶意应用检测的毕业设计源码包，面向计算机相关专业（计科、信息安全、人工智能、物联网等）的在校学生、专业教师与毕业生，适用于毕设、课设、期末大作业或项目实战演练。项目功能经导师指导并验证稳定，可直接运行参考。压缩包共2000个文件，大小约250.6MB：1740个xml作为Android界面与资源定义，237个html为说明或辅助页面，另有Java源码、Markdown文档与properties配置，便于查看项目结构与运行配置。已有163人学习。借助这份源码包可快速理解安卓恶意检测的完整流程与代码组织方式，掌握特征构造、分类模型应用等关键环节；基础较好的读者还能基于源码二次开发，扩展检测功能，是毕业设计起步与课程设计的实用参考。
1. 机器学习检测安卓恶意应用：一份能复现 99% 准确率的毕设源码
做安卓恶意应用检测的毕业设计，最怕两件事：一是论文里写的准确率自己跑不出来，二是特征工程和模型选型讲不清楚，答辩一追问就翻车。这套基于机器学习实现的安卓系统恶意应用检测系统源码，走的是当前课程设计里最主流的路线——静态特征加随机森林。它先把 APK 的权限声明、Intent 过滤器和敏感 API 调用抽成特征向量，再交给机器学习模型判定应用是恶意还是良性，代码完整、功能验证过，准确率能做到 99% 量级。适合正在做毕设、课设或期末大作业的计算机相关专业学生，也适合想入门机器学习在安卓安全方向落地的开发者。下面按原理、特征抽取、模型训练、避坑、落地检测的顺序，把这套项目从头拆一遍。
2. 静态特征提取原理：权限、Intent 与敏感 API 为什么能区分恶意应用
2.1 恶意应用的行为痕迹落在哪些特征上
安卓恶意应用和正常应用的区别，不在界面，而在它申请了什么权限、注册了什么组件、调用了哪些敏感接口。机器学习检测恶意应用，本质上是在特征空间里找一条能分开两类应用的边界，前提是特征选得准。
以最常见的恶意行为举例：偷联系人、发付费短信、开机自启、后台静默下载。这些行为落到安卓系统层面，会变成一串可观测的信号。偷联系人要申请 READ_CONTACTS，发付费短信要走 SmsManager.sendTextMessage，开机自启要注册 RECEIVE_BOOT_COMPLETED 的广播接收器，静默下载通常绕不开 Runtime.exec 或网络相关 API。这些信号组合在一起，就是一个应用的行为画像。
换个角度理解：任何 APK 都有一份二进制 AndroidManifest.xml 声明它想要的权限和组件，还有一份 dex 字节码记录它实际调用的方法。恶意应用为了完成攻击动作，必须在清单里申请对应权限、在代码里调用对应 API，它藏不住。所以静态分析不需要真正运行应用，就能拿到足够有区分度的特征。这也是毕设选静态分析而不是动态沙箱的原因：实现成本低、不需要构造恶意触发场景、每个特征都能讲出行为依据，答辩的时候站得住。
动态检测能抓运行时行为，但要搭模拟器、处理加固和反调试、设计触发条件，工作量完全不是一个量级。这套项目的定位是课程设计级别，静态特征这条路线在"效果可验证、原理可讲清"两点上是最优解。
2.2 特征向量化：二进制编码与特征字典的构建
下一步是把"应用申请了哪些权限"这种集合型信息变成模型能吃的数字。常见做法是二进制编码：预先收集一份覆盖常见权限的字典，每个权限对应特征向量里的一个位置，申请了置 1，没申请置 0。
这里有个关键约束：特征字典必须固定。训练时用什么顺序编码，预测时也要用完全相同的顺序，否则同一个权限在训练阶段是第 5 列、预测阶段变成了第 30 列，模型看到的就是完全不同的向量。
# build_feature_dict.py # 特征字典以文本文件形式放在项目根目录，每行一个权限声明 def load_permission_dict(dict_path="permission_list.txt"): with open(dict_path, "r", encoding="utf-8") as f: permission_list = [line.strip() for line in f if line.strip()] return permission_list PERMISSION_DICT = load_permission_dict() def encode_permissions(apk_permissions): # 把 APK 申请到的权限集合编码成 0/1 向量 vector = [] for perm in PERMISSION_DICT: vector.append(1 if perm in apk_permissions else 0) return vector这段代码逻辑不复杂，但决定了整个特征工程的正确性。字典规模控制在 180 个左右比较合理，太少区分度不够，太多会引入大量全零列，白白增加噪声。encode_permissions返回的向量顺序必须和字典严格一致，后续所有 APK 都用同一个函数编码，这一点写死在注释里。
Intent 过滤器特征也按这个思路编码。恶意应用要开机自启，就会声明 BOOT_COMPLETED 的 intent-filter；要拦截短信，就会注册 SMS_RECEIVED。这两个 action 在恶意样本里的出现频率远高于良性样本，是很有价值的区分特征。项目里通常把 intent 特征和权限特征拼成一条总特征向量，维度在 200 到 400 之间，这个规模对随机森林来说是相当舒服的输入。
2.3 数据集与标签：良性样本、恶意样本怎么对齐
有特征还得有标签。这套项目的训练数据来自公开的安卓恶意样本集，加上收集的良性 APK，标签规则很简单：良性应用标 0，恶意应用标 1。
这里要提醒一句：公开样本集（比如学术圈常用的 Drebin 数据集）能拿到"应用文件名加恶意家族标签"的清单，但 APK 文件本身可能需要单独下载。如果项目里附带的是特征缓存 CSV 而不是原始 APK，训练前先确认 CSV 的列顺序和特征字典一致，千万别拿列名对不上的缓存直接喂给模型。
数据准备环节最容易忽略的是划分方式。特征矩阵构建好之后，必须按分层抽样划分训练集、验证集、测试集，保证恶意样本在三个集合里的比例一致。
# split_dataset.py from sklearn.model_selection import train_test_split # X 是特征矩阵(ndarray)，y 是标签(0/1)，恶意样本占比约 15% X_train, X_temp, y_train, y_temp = train_test_split( X, y, test_size=0.3, stratify=y, random_state=42 ) # 临时集再拆一半，最终比例：训练 70%，验证 15%，测试 15% X_val, X_test, y_val, y_test = train_test_split( X_temp, y_temp, test_size=0.5, stratify=y_temp, random_state=42 ) print(X_train.shape, X_val.shape, X_test.shape)stratify=y按标签比例抽样，避免随机划分把恶意样本全分到训练集，测试集里一个恶意样本都没有。random_state=42固定随机种子，保证每次划分结果一致——这一点在毕设里尤其重要，随机种子不固定的话，同一个脚本两次运行结果都对不上，导师检查可复现性时很难交代。
3. 解析 APK 生成特征矩阵：Androguard 抽取脚本实战
3.1 解析 AndroidManifest.xml：拿到权限与组件声明
特征字典定义好之后，要写解析器从 APK 里抽真实特征。这套项目用的解析库是 Androguard，它是安卓逆向领域最常用的 Python 库，能直接读二进制的 AndroidManifest.xml 和 dex 字节码，不需要先把 APK 反编译成 smali。
# manifest_features.py from androguard.core.bytecodes.apk import APK apk = APK("sample.apk") print("包名:", apk.get_package()) print("权限:", apk.get_permissions()) print("主 Activity:", apk.get_main_activity()) # 统计 Activity 数量，作为补充数值特征 print("Activity 数量:", len(apk.get_activities()))运行这段脚本，一个 APK 的权限列表就拿到了。get_permissions()返回的是完整权限字符串，比如android.permission.SEND_SMS，正好可以直接和特征字典匹配。get_activities()统计组件数量，恶意应用为了隐藏行为有时会声明比正常应用更多的 Activity 和 Service，这个数量本身也可以作为一个数值特征。
拿到权限列表后，直接调上一章的encode_permissions编码。实际批量抽取时，先写一个"APK 路径映射权限向量"的函数，后面所有样本都走同一个入口，避免每个脚本各写一套逻辑。
3.2 抽取敏感 API 调用：从 Dalvik 字节码里找线索
权限特征反映的是"应用声明了什么"，但声明和实际调用可能不一致，有些恶意应用会申请一堆权限做掩护。所以还要从 dex 字节码里找真实调用关系，判断它到底有没有碰敏感 API。
# api_call_features.py from androguard.misc import AnalyzeAPK # 敏感 API 按类分组：短信、执行命令、读取设备信息 SENSITIVE_API = { "Landroid/telephony/SmsManager;": ["sendTextMessage"], "Ljava/lang/Runtime;": ["exec"], "Landroid/telephony/TelephonyManager;": ["getDeviceId"], } def extract_api_features(apk_path): a, d_list, dx = AnalyzeAPK(apk_path) feature_vector = [] for api_class, method_names in SENSITIVE_API.items(): found = 0 class_analysis = dx.get_class_analysis(api_class) if class_analysis is not None: for method in class_analysis.get_methods(): if method.get_name() in method_names: # 只要存在来自应用代码的调用引用，就视为命中 if any(ref for _, ref, _ in method.get_xref_from()): found = 1 break feature_vector.append(found) return feature_vectorAnalyzeAPK是 androguard 4.x 的统一入口，一次返回 APK 对象、dex 列表和分析器。dx.get_class_analysis拿到框架类在分析器里的表示，get_xref_from()返回所有调用这个方法的代码位置，只要有来自应用自身的引用，就说明它真的调用了敏感 API。这个方案比粗暴的字符串匹配可靠，字符串匹配会把注释里提到或常量里包含的情况误判成调用。
敏感 API 黑名单的选择直接影响检测效果。建议把维度控制在 30 到 60 个之间，覆盖短信、电话、设备信息、网络、文件操作、shell 执行这几个类别，每类挑最典型的几个方法。太少抓不住恶意行为，太多会误伤正常应用——正常应用也会调getNetworkInfo判断网络状态。
3.3 合并特征并输出 CSV：训练前的最后一步
权限特征、Intent 特征、敏感 API 特征分别抽完后，拼成一条完整特征向量，连同标签写入 CSV。这一步看似简单，却是整个流程里最容易出错的地方。
# build_dataset.py import csv import os def extract_all_features(apk_path): # 按固定顺序拼接三类特征，顺序必须和训练脚本一致 perms = encode_permissions(parse_permissions(apk_path)) intents = encode_intents(parse_intent_filters(apk_path)) apis = extract_api_features(apk_path) return perms + intents + apis def build_csv(apk_dir, label_file, output_path): labels = load_label_map(label_file) # {apk文件名: 0/1} feature_names = load_feature_names() # 与特征向量顺序对应的列名 with open(output_path, "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(feature_names + ["label"]) for apk_name, label in labels.items(): apk_path = os.path.join(apk_dir, apk_name) try: vector = extract_all_features(apk_path) writer.writerow(vector + [label]) except Exception as e: # 单个 APK 解析失败不能中断整个流程，记录后跳过 print(f"[跳过] {apk_name}: {e}") continueload_feature_names()返回的列名列表必须和extract_all_features的拼接顺序一一对应，否则 CSV 打开后列名和数值对不上，模型训练看不出问题，直到分析特征重要性时才发现错位。外层 try-except 是批量抽取的必备习惯，真实 APK 集合里总有几个损坏文件，一个失败就中断的话，几百个样本要重跑好几轮。
注意：特征拼接顺序一旦定下来就不要改。中途增删特征必须重新生成整个 CSV，不能只改部分样本的维度，否则训练时维度对不上或列错位，排查起来极费时间。
4. 模型训练与调参：随机森林如何逼近 99% 准确率
4.1 选型理由：为什么是随机森林而不是深度学习
特征矩阵构建完成，进入模型环节。这套项目选的是随机森林，在我看来这是课程设计场景下的最优解，三个理由。
第一，特征形态匹配。前面构建的特征向量是 200 到 400 维的高维稀疏 0/1 向量，这种表格型数据正是树模型的强项。随机森林对特征做列采样、对样本做行采样，天然能处理特征之间的交互关系，不需要像 SVM 那样纠结核函数。第二，不容易过拟合。单棵决策树深了必过拟合，随机森林通过随机采样和多树投票把方差压下来。恶意检测场景特征有限、样本量不大，深度学习在这个规模下很容易在训练集刷高分、在测试集原形毕露。第三，可解释性好。随机森林自带feature_importances_，能直接输出哪些特征对判定贡献最大，答辩时拿出"SEND_SMS 权限是最重要特征"这种结论，比丢一个黑盒神经网络有说服力。
不是说 XGBoost 不行，它在同类问题上表现接近，但超参数更多、调参成本更高。毕设追求的是可靠复现，随机森林用默认参数就能有不错的基线，再配交叉验证和网格搜索，99% 量级的准确率是能跑出来的。准确率能逼近 99%，靠的从来不是模型玄学，而是特征工程、数据质量和验证方式一起撑起来的。
4.2 五折交叉验证与网格搜索：参数怎么设
训练脚本的核心是交叉验证加参数搜索。交叉验证让评估不依赖某一次数据划分，网格搜索在指定参数组合里找最佳配置。
# train_model.py from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import GridSearchCV from sklearn.metrics import classification_report, confusion_matrix # 基础模型：200 棵树，树深限制 16，叶子最少 2 个样本 rf = RandomForestClassifier( n_estimators=200, max_depth=16, min_samples_leaf=2, random_state=42, n_jobs=-1, ) # 参数网格：树的数量、深度、叶子最小样本数 param_grid = { "n_estimators": [100, 200, 300], "max_depth": [10, 16, 20], "min_samples_leaf": [1, 2, 4], } grid = GridSearchCV( rf, param_grid, cv=5, # 五折交叉验证 scoring="f1", # 用 F1 做评分而不是准确率 n_jobs=-1, ) grid.fit(X_train, y_train) print("最优参数:", grid.best_params_) print("交叉验证 F1:", grid.best_score_)scoring="f1"是有意为之。恶意样本在数据集中占少数，拿 accuracy 做评分，模型只要全判良性就能拿高分，完全没有区分能力。F1 同时兼顾精确率和召回率，更真实地反映模型对恶意样本的识别能力。n_jobs=-1让所有参数组合并行跑，200 棵树加五折交叉验证在这个数据规模下几分钟出结果。
树的数量 100 到 300 是合理区间，超过 300 准确率提升很有限，训练时间却线性增长。max_depth限制树深，防止单棵树记住噪声；min_samples_leaf强制叶子节点最少包含的样本数，这两个是控制过拟合的主要旋钮。换成自己的数据集时，优先调这两个参数，n_estimators基本不用动。
4.3 读评估报告：准确率、召回率、F1 与混淆矩阵
训练完成后用测试集做最终评估。测试集必须是从头到尾没参与训练和调参的那部分数据，否则评估结果没有参考价值。
# evaluate.py from sklearn.metrics import classification_report, confusion_matrix best_model = grid.best_estimator_ y_pred = best_model.predict(X_test) print(classification_report( y_test, y_pred, target_names=["benign(良性)", "malicious(恶意)"], )) print("混淆矩阵:") print(confusion_matrix(y_test, y_pred))围绕 99% 准确率，更该看的是混淆矩阵左下角——真实恶意被误判成良性的数量。下面这张表是评估报告里最值得关注的四个指标，答辩时照着讲不会乱。
| 指标 | 含义 | 在恶意检测场景的解读 |
|---|---|---|
| Accuracy | 全部样本里判对的比例 | 容易被样本不平衡拉高，不能单独看 |
| Precision | 判为恶意的样本里真恶意的比例 | 误报率低则精确率高，误报增加人工复核成本 |
| Recall | 真实恶意样本里被查出来的比例 | 漏掉一个恶意应用的代价远大于误报 |
| F1 | 精确率与召回率的调和平均 | 类别不平衡时的主要优化目标 |
拿到一份检测项目，我第一件事就是跑混淆矩阵。如果准确率 99% 但恶意样本那行召回率只有 60%，说明模型基本在装样子；反过来，两类样本的精确率和召回率都在 95% 以上，这个 99% 才可信。这也是下一章要展开的：准确率高不等于模型好。
5. 避坑指南：路径中文、样本不平衡与特征泄漏的排查记录
下面四条是这份项目最容易翻车的点，也是我跑这类机器学习检测项目攒下的血泪经验。每条按现象、原因、解决的顺序记录，照着排查能省大量时间。
5.1 解压路径带中文导致解析崩溃
现象：项目解压后直接运行，报UnicodeDecodeError或FileNotFoundError，Androguard 解析 APK 时抛出莫名的编码异常。
原因：Windows 下解压路径带了中文目录名，部分 Python 库在读取二进制文件时对中文路径处理不友好。APK 解析过程中要调用底层 zip 处理逻辑，路径编码不一致就会在读文件阶段直接崩溃。项目的说明文件里也明确写了：项目路径不能用中文。
解决：解压后先把目录重命名为纯英文路径，比如android-malware-detector，再配置虚拟环境运行。项目里所有涉及路径的配置项（数据集目录、输出目录）改成基于根目录的相对路径，不要写死带中文的绝对路径。把那以后我每个新项目解压后的第一件事就是看路径，这一步省掉的排查时间远超预期。
5.2 特征泄漏让 99% 准确率成为假象
现象：训练集交叉验证分数极高，测试集分数也很高，但拿几个新下载的 APK 一测，预测结果一塌糊涂。
原因：最典型的特征是泄漏——数据集去重不彻底，同一个应用的不同版本或渠道包同时出现在训练集和测试集里；或者把"来源是否安全"这类元信息当成了特征。模型其实是在背答案，不是学规律。
解决：构建数据集时按包名去重，同一包名只保留一个样本。检查特征列里有没有直接指向标签的列，有就删掉。划分顺序必须是：先打乱，按包名去重，再做分层划分，这个顺序不能反。我一般会在train_test_split之前打印一行X.shape和重复包名数量，一眼就能看出数据是否干净。
5.3 样本不平衡：恶意样本太少，模型全猜良性
现象：整体准确率 95% 以上，但分类报告里恶意类的召回率不到 50%，近一半恶意应用漏掉。
原因：数据集里良性样本远多于恶意样本，比如良性一万个、恶意一千个。模型只要全预测良性，准确率已经 90% 往上，它自然学会了偷懒。
解决：三个手段按优先级用。第一，训练时给随机森林加class_weight="balanced"，让少数类样本的误判代价更高；第二，评估和网格搜索评分用 F1 而不是 accuracy；第三，恶意样本实在少时，考虑用 SMOTE 对训练集过采样，但要记住 SMOTE 只能用在训练集，绝对不碰测试集，否则等同于泄漏。
5.4 Androguard 版本冲突：3.x 和 4.x 接口不兼容
现象：from androguard.core.bytecodes.apk import APK能导入，但AnalyzeAPK找不到；或者同样的解析代码在别人电脑上能跑，自己电脑上报错。
原因：Androguard 3.x 和 4.x 的 API 差异很大，3.x 里的一些方法在 4.x 被移除或改名。直接pip install androguard默认装最新版，很容易把项目锁定的旧版本覆盖掉。
解决：先看项目里的requirements.txt，按里面的版本装。建议用虚拟环境隔离，执行下面的命令再装依赖。
python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install -r requirements.txt没有 requirements.txt 的话，装 androguard 4.x 配 Python 3.8 以上环境是目前兼容性最好的组合。别在系统全局环境直接装，毕设周期里依赖环境被弄坏，排查起来非常浪费时间。
6. 把模型落成检测工具：单 APK 预测与二次开发方向
6.1 封装单 APK 检测脚本
训练完的模型不能只在训练脚本里活着。把最优模型用 joblib 持久化保存，再写一个独立预测入口，就能对任意 APK 做实时判定。
# predict.py import joblib from build_features import extract_all_features model = joblib.load("malware_detector_rf.pkl") apk_path = input("输入 APK 路径: ") features = extract_all_features(apk_path) mal_prob = model.predict_proba([features])[0][1] label = "恶意" if mal_prob >= 0.5 else "良性" print(f"判定结果: {label}，恶意概率 {mal_prob:.2%}")predict_proba比predict有用，它输出置信度而不是只给 0/1 结论。0.5 的阈值可以按场景调：想抓得狠就降到 0.3，代价是误报变多；安全场景里漏报代价远大于误报，我一般会在 0.3、0.4、0.5 三档阈值下各跑一遍测试集混淆矩阵，再定默认值。
6.2 二次开发方向：特征重要性与家族分类
feature_importances_按从大到小排序，挑前二十个特征画条形图，能直观看到 SEND_SMS、RECEIVE_BOOT_COMPLETED 这些特征对判定的贡献。这张图放进论文的"特征分析"章节，比任何文字描述都有说服力，也是答辩时展示工作量的关键素材。
再进一步，把二分类改成恶意家族多分类，标签从 0/1 换成 OpFake、DroidKungFu 这类家族编号。模型层面只需把 RandomForestClassifier 的类别数从 2 改成 N，评估用 classification_report 逐个家族看效果，代码改动量不大，但项目深度立刻上一个台阶。
从拿到这份源码到现在，我养成了一个习惯：任何机器学习检测项目到手，先跑路径检查、特征完整性检查、交叉验证、混淆矩阵这四步，四项全过才敢说项目能复现。这套源码解压后按英文路径重命名、装好依赖就能跑通全流程，照着上面的顺序一个个脚本调，踩坑的概率会小很多。希望帮到你。
本文还有配套的精品资源，点击获取
