chuyouyinghe的专栏

大牛：“关于权限各种类型就已经结束了，我用一张图来做下总结吧，如下图：”imagenormal权限，该类型权限对用户隐私或系统安全影响较小，因此在Apk安装后就自动授予了该类型的权限。正因如此一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户没有关系的。dangerous权限，该类型权限是指可能会侵犯用户隐私或设备安全的权限，因此应用在使用这些权限之前必须获得用户的明确授权。一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户有关系的。

本文详细介绍了 APKTool 的使用方法和技术原理。APKTool 主要应用于逆向工程、调试和修改已编译的 APK 文件。文章首先解释了 APK 文件的反编译过程，包括 APK 的解压、DEX 文件的 smali 转换和资源文件的解码。接着，讨论了 APK 的重新打包过程，包括资源的重新编译、smali 文件的 DEX 转换、APK 的打包和签名。

AVF的安全特性为移动设备提供了强大的保护。通过其分层安全方法、机密性、完整性和可用性的维护，以及Hypervisor和客户机OS的安全特性，AVF确保了移动设备在面对日益复杂的威胁时，能够保持安全和可靠。随着技术的不断进步，我们期待AVF能够继续为移动设备的安全性提供更多的创新和改进。

等，换句话说，在 Android 15 上唯一可以读取带有身份验证代码的通知的第三方应用：连接到智能手表的应用、连接到智能眼镜的应用或默认主屏幕启动器应用。而 ASI 主要依赖于安装了 Google 服务，甚至一些深度功能是 Pixel 独有，所以大多数情况下，你的手机里一般是没有 ASI 的，在没有 ASI 的情况下，就会 API 35 的模拟器场景一样，之前对通知进行处理，如果 ASI 检测到通知中包含如身份验证代码，它会告诉系统将其标记为“敏感内容”，并停止将通知发送到不受信任的。

还有就是在选择code reviewer可能需要注意一下，能多选几个就多选几个吧，我选择了一个对appcompat贡献最多的一个老哥，结果到现在都还在pending review状态，期间都打算发邮件去沟通一下了，我看其他的pr都是同时选择了好几个code reviewer，最后还是在issue tracker创建了一个issue，才有好心的Google老哥帮忙review了一下，thank you bro😁。它里面有个create的方法，可以适配不同的系统版本，创建带有weight的Typeface。

允许一个 Activity 作为任务栈的根 Activity 来运行，并且它只会在这个任务栈中有一个实例。不过，与singleTask不同的是，可以在不同的任务栈中创建多个实例。如果启动该 Activity 时设置了或标志，那么每次启动时都会创建新的任务栈。在 Android SDK 中，通过此定义可以看出，可以避免在同一个任务栈中创建多个实例，但允许在不同的任务栈中有多个实例。而singleTask则会限制该 Activity 只存在于一个任务栈中。

android开发中文网站 android developer

目前看来 Android 15 上需要适配的难度不高，毕竟 16K Page Size 应该是明年的事情，而且按照目前情况猜测，更多也支持明年 Google Play 上会开始要求，国内估计还会继续延迟，真正需要在国内启用 16K Page Size 也许会更晚。所以，勇敢的少年，是时候开始吃螃蟹了。Android 15 正式发布到 AOSP ，来了解下新特性和适配需求作者：恋猫de小郭链接：https://juejin.cn/post/7410645914585317403来源：稀土掘金。

本文是一篇入门插件化的文章，主要回答了插件化是什么，有什么难点，又是怎么解决的，其中没有涉及到很多代码，非常适合入门。文中很多的篇幅来自腾讯Bugly团队的，感兴趣可以阅读原文：《Android插件化技术-原理篇》最近团队中的很多代码很多涉及了插件化，之后结合具体的插件化代码和大伙分析一下流程。参考文章：《Android插件化技术-原理篇》《聊聊陈旧的插件化》《【Android 修炼手册】常用技术篇 -- Android 插件化解析》面试官：你对插件化有什么了解？

当垃圾回收算法是 CC（并发复制）的时候，compactiing_gc 是true，从 compacting 这个词加上过去一些垃圾回收算法八股文的学习，我们可以推测，这个代表的应该是是否移动对象，压缩碎片空间的意思。kGcCauseForNativeAlloc: NativeAllocationGcWatermark 超出的时候调用的，这个涉及到native分配的机制，感兴趣的也可以研究一下。返回了本次gc的类型。分别是不执行gc、回收本次分配的对象、回收ZtgoteSpace之外的对象、完整的回收。

多线程在Android开发中非常重要，通过适当的多线程管理，可以显著提升应用的性能和用户体验。应避免在主线程上执行任何耗时操作，以防止应用响应不及时。选择合适的多线程管理方法和工具（如线程池、Kotlin协程等）是保持代码简洁、高效的关键。一个Android App最少有几个线程？实现多线程的方式有哪些？

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。原文链接：https://blog.youkuaiyun.com/a307326984/article/details/141366635。通过以上方法获取的分辨率与实际的分辨率不一样，获取的屏幕高度是减掉虚拟返回键后的分辨率，那如何获取完整的分辨率呢，方法如下。以上就是获取屏幕密度的全部内容，如有错误，欢迎指正。方法三. 通过WindowManager获取。方法二. 通过Resources获取。

总结而言，getMaximumWindowMetrics()方法用于获取设备屏幕的完整度量信息，而windowManager.getCurrentWindowMetrics()方法用于获取当前窗口的度量信息。Android 11 中引入了 WindowMetrics，可让开发者轻松查询与窗口相关的指标，例如，窗口的位置和大小，以及任何系统边衬区。需要注意的是，这些方法的返回值是WindowMetrics对象，可以通过该对象获取有关窗口的详细度量信息，如窗口大小、位置和可见区域等。

Binder 机制是 Android 特有的一种进程间通信（IPC）方式。

Android 的 Context 大家肯定是不陌生了，它是安卓开发中不可或缺的概念，它允许我们访问系统资源，管理应用程序的生命周期，并与系统交互。实际开发中我们在使用 Toast，使用 Dialog，启动 Activity 与 Service ，加载资源，操作数据库，获取 App 相关的文件路径，创建 View 等操作时，都会涉及到一个 Context 引用。

差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并成一个完整的dex，完整dex加载得到dexFile对象作为参数构建一个Element对象然后整体替换掉旧的dex-Elements数组。随着时代的发展，生活节奏的加快，人们对于互联网的需求日益加深，再加上IT技术的日新月异，导致应用的更新频率越来越快。Hook了ClassLoader.pathList.dexElements[]，将补丁的dex插入到数组的最前端，所以会优先查找到修复的类，从而达到修复的效果。

DecorView的主要角色是作为顶层容器，承载着应用的视图结构。当在应用中使用setContentView方法加载布局时，实际上是将这个布局作为子视图添加到DecorView中。因此，DecorView定义了应用界面的边界，所有的视图都在这个边界内进行绘制和事件分发。下面我们来说一下，DecorView与Window、Activity和ViewRootImpl之间的关系，这能够更好地帮助我们理解应用的视图层次结构。最后，总结一下，整个流程主要可以归纳为四步：在Activity的attach()

Android 的 Context 大家肯定是不陌生了，它是安卓开发中不可或缺的概念，它允许我们访问系统资源，管理应用程序的生命周期，并与系统交互。实际开发中我们在使用 Toast，使用 Dialog，启动 Activity 与 Service ，加载资源，操作数据库，获取 App 相关的文件路径，创建 View 等操作时，都会涉及到一个 Context 引用。

最后，我们来做个总结。在我们修改屏幕的density之后，仅更新Java层的值，并没有更新C++层。所以导致在获取dimension时，C++层用的是旧值去判断，所以导致dimension获取的不对。在我们更新完density之后，需要调用Resource的方法，去更新C++层的屏幕宽度(dp单位)额外补充两句，可能大家在实际开发过程中很少遇到这种问题，原因应该是，系统默认的屏幕宽度和我们修改density之后的屏幕宽度都比指定的values-wxxdp要大，或者要小，所以难以发现这个问题。

本文同样梳理了一下Android 15在线程挂起流程的变更，看来每次升级都要绞尽脑汁想想hook方案，不过找到方案那一刻还是蛮开心的。此次方案不一定最优解，因为这个循环等待操作不知道会不会带来ANR风险，或者影响卡顿率指标等等，但是还是那句话避免Crash优先级更高。同样，其实我们应用如果像拼多多整体流畅度高性能好，其实间接也不需要这种hook，这个只是没办法而为之。Android 15 线程挂起超时崩溃与修复作者：巴黎没有摩天轮。

View绘制可以说是Android开发的必备技能，但是关于View绘制的的知识点也有些繁杂。如果我们从头开始阅读源码，往往千头万绪，抓不住要领。目前当我们写页面时，布局都是写在XML布局从XML到显示到屏幕上，都发生了什么，可以分为哪几个部分?我们将整个显示流程分解为以下几个部分代码是怎么从XML转换成View的?View是怎么添加到页面上的?在内存中View到底是怎么绘制的?View绘制完成后是怎么显示到屏幕上的?从XML到View显示到屏幕上主要涉及到以下知识点Activity。

在Android 官方开发者网站的参考手册中，有一段关于这个方法的说明，算是简单的介绍了一下同步屏障[1]LooperLooper大体意思就是：在View绘制时，会在Looper中使用同步屏障，来确保在view下一帧绘制完之前其他同步消息都暂不处理。这里重点看第三段，这段第一句话说的很清楚：异步消息不受同步屏障限制。得，看完这个，感觉更迷茫了。不过既然说了是在Looper中会用到同步屏障，那么就看看Looper中在哪里用到了。

阅读到这里，我们总结几个有用的结论：• Android Bitmap 内存占用和图片的尺寸，质量强相关，日常治理大图的时候要对这些参数适当做降级方案。• Android8以下图片分配在 Java 堆内，容易 OOM，可以通过一些 hook 方案把内存移到堆外。并且虽然 Bitmap 有自己兜底的内存释放机制，但是主动及时调用 recycle也不是坏事。

用于监控应用的 Java 内存泄漏问题，它的核心原理：周期性查询Java堆内存、线程数、文件描述符数等资源占用情况，当连续多次超过设定阈值或突发性连续快速突破高阈值时，触发镜像采集镜像采集采用虚拟机supend->fork虚拟机进程->虚拟机resume->dump内存镜像的策略，将传统Dump冻结进程20s的时间缩减至20ms以内基于shark执行镜像解析，并针对shark做了一系列调整用于提升性能，在手机设备测即可执行离线内存泄露判定与引用链查找，生成分析报告。

要研究内存泄漏框架，KOOM是个不可忽略的优秀开源框架，由快手开源。这将是一个系列的文章。这篇文章作为开篇，来看看KOOM框架的demo是怎么制造Java层面的leak的。下面通过官方给出的Demo代码作为入口，来分析和学习这个开源框架。初始化。

APM，全称是Application Performance Management，也就是应用性能管理，这与我们平时写的业务可能并不相关，但是却承载着App线上稳定的责任。当一款App发布到线上之后，不同的用户有不同场景，一旦App出现了问题，为了避免黑盒，找不到头绪，就需要APM出马了。对于App的性能，像CPU、流量、电量、内存、crash、ANR，这些都会是监控的点，尤其是当App发生崩溃的时候，需要回捞到当前用户的日志加以分析，找到此问题崩溃的堆栈，完成修复。

Add a fast dumper with HeapDumper API

本文简单的介绍了 Android 系统权限收紧的介绍，并且对于如何写入文件方面做了几种适配案的探讨。再次强调，本文只针对文件的写入，对于文件的读取是不适用的，那是另外的事情，对于多媒体图片视频等文件的写入和读取又是另另外的事了，万不可混为一谈。对于文件的写入其实除了以上的方案还可以用 MANAGE_DOCUMENTS 的权限，但是但是个人强烈不推荐使用 android.permission.MANAGE_DOCUMENTS 这样的危险权限方案。

目录1. 前台服务（Foreground Service）2. 双进程守护3. 使用系统广播拉活5. 白名单6. 第三方推送服务7. 静态广播监听8. 合理利用Activity9. 使用AlarmManager定时唤醒10. 合理设置进程优先级11. 使用sticky广播12. 使用WorkManager13. 合理使用WakeLock14. 合理使用SyncAdapter15. 使用AccountManager16. 适配Doze模式和App Standby。

广播会发送到广播队列中不同集合。其中广播队列有三种类型，分别对应优先级从高到底：前台、后台、长广播队列类型。而广播又分三种：黏性广播、无序广播、有序广播。无序广播和有序广播的处理主要要发送广播的时候，而黏性广播则在广播接收者注册时候被处理。一个应用程序允许注册最大的广播接收者是1000个。广播之间的传递也要经历各种权限检查，所以广播不适合在应用间用于频繁的交互。值得一看的Android广播分析好文作者：新小梦链接：https://juejin.cn/post/7322156751818522661。

有部分同学只要是上传或者下载，只要用到了文件，不管三七二十一写个 FileProvider 再说。不是每一种情况都需要使用 FileProvider 的，啥？你问行不行？有没有毛病？这... 写了确实可以，没毛病！但是这没有必要啊。如果不需要FileProvider就不需要定义啊，如果定义了重复的 FileProvider，还会导致清单文件合并失败，需要处理冲突，从而引出又一个问题，解决 FileProvider 的冲突问题，当然这不是本文的重点，网上也有解决方案。

这次梳理了常见Android9之后的反射hide api的方案，通过这次学习，梳理了场景的方案的方向和思路。一方面我们需要做到理解Android限制我们调用hide api的原理，在真正需要这个方案的时候更好的做出选择，另一方面，我们也应该认识到Google设置这个规则的目的，那就是不到万不得已的时候不要随意去反射hide api，以免给app带来稳定性和安全性的问题。• 《一种绕过Android P对非SDK接口限制的简单方法》• 《另一种绕过 Android P以上非公开API限制的办法》

在做一个项目中，遇到下面这样一个问题。项目主界面是TabActivity，每个子tab 都是一个acitivity。有个子tab中，点击注销用户，要退回到项目主界面默认的tab，相当于按返回键。解决办法如下：在这个子tab中写下面方法。版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。原文链接：https://blog.youkuaiyun.com/u010213003/article/details/8979828/

本文介绍了在Android中模拟发送键值的方法，并提供了一个示例应用。Android提供了一个名为Instrumentation的类，它允许我们在应用程序中模拟用户的操作。simulateKeyEvent方法中，我们创建了一个新的线程，在该线程中使用Instrumentation类的sendKeyDownUpSync方法来模拟发送回车键事件。在上述代码中，我们首先在onCreate方法中获取到模拟发送键值的按钮，并为其设置一个点击事件监听器。下面我们来创建一个示例应用，演示如何模拟发送键值。

这次梳理了常见Android9之后的反射hide api的方案，通过这次学习，梳理了场景的方案的方向和思路。一方面我们需要做到理解Android限制我们调用hide api的原理，在真正需要这个方案的时候更好的做出选择，另一方面，我们也应该认识到Google设置这个规则的目的，那就是不到万不得已的时候不要随意去反射hide api，以免给app带来稳定性和安全性的问题。• 《一种绕过Android P对非SDK接口限制的简单方法》• 《另一种绕过 Android P以上非公开API限制的办法》

更该语言之后调用方法更改APP的更改语言配置的方法，该方法是全局变化，然后再发送广告，每个Activity都动态注册了广告，监听到语言更换的广播之后，调用recreate方法，则每个存活的Activity都会重启一下更换成了设置的语言。之前的设置语言代码，都是保存设置的语言在手机本地，在application启动时读取保存的语言设置进行设置，一旦手动更改设置了，后续再去获取语言都是获取到设置了之后的，所以需要在启动程序application初始化中，先获取系统语言保存后再把app设置为显示其他语言。

关于 Resource.getx() 相关的底层实现到这里就分析结束了。本篇中，我们以Kotlin+[裁枝剪叶]的方式，提供一个较清晰的脉络，以供更好的读懂应用层源码设计，关于更细节的原生实现，并不是本篇所关注的。所谓一眼入森，而不在林，正是如此。现在让我们反推上去：.xml结尾的，ColorDrawable 或者 非ColorDrawable;非.xml结尾的，即为 BitmapDrawable。那他们又是怎么判断得出的呢？

mReferrer很容易通过重写context的getBasePackageName()被伪造，在使用时一定要小心。通过ActivityManageService获取的Uid是无法被伪造的，可以考虑使用Uid来转换PackageName。作者：vivo互联网技术链接：https://juejin.cn/post/7030977861691375629来源：稀土掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

但是在Activity中，我们是无法touch到Binder线程的。如果这个值是SystemServer中填充的，然后发送到App中的，那么可以认为无法伪造，但是如果这个值依赖于调用者的传入，那么很可能可以被伪造。可以看到，我们调用startActivity的时候，并没有传入callingPackage参数，但是当调到ActivityManagerService的startActivityAsUser方法的时候，却出现了callingPackage参数，所以，肯定是调用流程中间的某一步，加入了这个参数。

了解完这个过程之后，我们依次回答一下上面的问题。多个客户端都去 bind 同一个 service，那么 service 返回的是同一个 stub 对象，还是多个 stub 对象无论有多少客户端绑定到同一个 Service，Service 通常返回的是同一个 Stub 对象的引用，所有客户端共享同一个 Service 的 Stub 对象。这种设计使得 Service 能够有效地管理和维护所有的客户端连接，同时避免了无谓的资源开销与复杂度。