aosp14上SystemUI相关的调试堆栈乱码无法对应行号，logcat无法输出

背景

在做WMShell相关开发时候，或SystemUI相关模块一些调试时候，如下几类问题：

1、实体手机lineage系统上无法对SystemUI的一些java代码进行断点调试，根本不会进入断点（实际已经运行）
2、SystemUI中打印堆栈时候，不能正常展示出对应详细类名字，是一堆看不懂的hash码

3、发现logcat中无法抓取到SystemUI的Log.v级别的日志

针对android studio的断点调试根本无法运行，且打印堆栈也是出现下面一些hash码一样东西，根本无法知道具体情况
go/retraceme 420c0d65c52ef6f50f90080584eeaa4abe9e0659d00e941c0eb1401615ea21c6
其实这里的1、2问题都是属于同一类问题，问题3属于另一类，所以就只需要分析2类问题既可以，下面针对上面几个问题进行剖析解决。

修改as调试及堆栈显示行号异常

问题分析思路：
首先只是在SystemUI进程里面打印堆栈才会出现堆栈是乱的一堆hash码一样的，但是SystemUI是可以正常运行的，系统进程和其他apk是正常的，说明这个可能这个apk是被优化了，那么控制apk优化一般是在编译的Android.bp里面控制

/ Opt-out config for optimizing the SystemUI target using R8.
// Disabled via `export SYSTEMUI_OPTIMIZE_JAVA=false`, or explicitly in Make via
// `SYSTEMUI_OPTIMIZE_JAVA := false`.
soong_config_module_type {
    name: "systemui_optimized_java_defaults",
    module_type: "java_defaults",
    config_namespace: "ANDROID",
    bool_variables: ["SYSTEMUI_OPTIMIZE_JAVA"],
    properties: ["optimize"],
}

systemui_optimized_java_defaults {
    name: "SystemUI_optimized_defaults",
    soong_config_variables: {
        SYSTEMUI_OPTIMIZE_JAVA: {
            optimize: {
                enabled: true,
                optimize: true,
                shrink: true,
                shrink_resources: true,
                proguard_compatibility: false,
            },
            conditions_default: {
                optimize: {
                    proguard_compatibility: false,
                },
            },
        },
    },
}

上面可以看出来如何想不优化则在编译make前进行export SYSTEMUI_OPTIMIZE_JAVA=false设置
也可以单独编译make SystemUI,然后替换apk既可以

修改后结果如下：

这里堆栈无法显示具体类文件，其实就是因为Android.bp有相关的优化配置配置，只需要去除优化既可以，然后重新make。

Log.v日志无法输出问题修改

问题排查过程：
正常情况下一个普通app直接调用Log.v肯定是可以输出日志的，所以Log.v无法打印，那么第一怀疑是不是有源码中针对systemui进程有单独的过滤拦截。
分析一下源码：
frameworks/base/core/java/android/util/Log.java
发现没看到有任何的拦截就直接调用了println_native，Log源码看着没有拦截。
那么试一下如果直接调用println_native(LOG_ID_MAIN, VERBOSE, tag, msg)方法看看是否可以打印，注意这里的LOG_ID_MAIN，VERBOSE可以直接使用数字：

    /** @hide */ public static final int LOG_ID_MAIN = 0;
     /**
     * Priority constant for the println method; use Log.v.
     */
    public static final int VERBOSE = 2;

添加如下代码验证：

结果发现：
println_native是有打印的，那么这就可以断定其实系统根本没有针对systemui进行拦截Log.v。

那么怀疑点就得回到SystemUI代码，这里也可以对apk进行反编译看看，是不是被编译时候混淆去除了呢？
果然在SystemUI目录下找到下面一个混淆配置文件

把相关的Log.v混淆部分去除掉

再进行编译make运行,一切正常：

更多framework技术干货，请关注下面“千里马学框架”