apk

工具介绍： apktool: ：把APK反编译，生成程序的源代码和图片、XML配置、语言资源等文件。 官方地址： https://ibotpeaches.github.io/Apktool/ dex2jar：将apk反编译成java源码（classes.dex转化成jar文件） 官方地址： https://github.com/pxb1988/dex2jar jd-gui：查看APK中classes.dex转化成出的jar文件，即源码文件 官方地址： http://jd.benow.ca/ https://github.com/java-decompiler/jd-gui 一、反编译APK得到源代码、图片、XML配置、语言资源等文件 apktool工具及待反编译的apk见下图 apktool.bat中的内容： @echo off set PATH=%CD%;%PATH%; java -jar "%~dp0\apktool.jar" %1 %2 %3 %4 %5 %6 %7 %8 %9 将APK放在和apktool同一目录下，命令行进入该目录，执行如下命令： apktool d zhinanzhen.apk 输出参见下图 生成文件目录见下图： 二、反编译APK得到Java源代码 将要反编译的APK后缀名改为.rar或则 .zip，并解压得到其中的classes.dex文件

一、需要工具 apktool：反编译APK文件，得到classes.dex文件，同时也能获取到资源文件以及布局文件。 dex2jar：将反编译后的classes.dex文件转化为.jar文件。 jd-gui：用于将.jar文件转换成java代码。 二、apktool安装： 下载地址： https://ibotpeaches.github.io/Apktool/install/ ，看页面说明安装。 apktool d -s xxx.apk //编译apk 三、dex2jar安装： 源码下载地址： https://github.com/pxb1988/dex2jar 。 这里做个说明：很多地方可以下载，如： https://sourceforge.net/projects/dex2jar/files/ ， 但是这些使用的时候会报错，像一下这样的： dex2jar classes.dex -> ./classes-dex2jar.jar Detail Error Information in Fil 看错误日志说的是： java.lang.RuntimeException: can not merge I and Z 具体原因看： https://www.jianshu.com/p/0306cb947d7a 现在是需要下载源码，编译修复好的源码拿到工具。（ 别人修复了

alpine Linux简介 1.Alpine Linux是一个轻型Linux发行版，它不同于通常的Linux发行版，Alpine采用了musl libc 和 BusyBox以减少系统的体积和运行时的资源消耗。 2.Alpine Linux提供了自己的包管理工具：apk(注意：ubuntu中是apt-get)，我们可以通过https://pkgs.alpinelinux.org/packages 查询包信息 3.Alpine Docker镜像继承了Alpine Linux发行版的这些优势，相比于其他Linux Docker镜像，它的体积非常小 对比常用的、没有压缩过的基础镜像（查看当前的:latest标签）： Alpine - 4.8MB Ubuntu - 124.8 MB Debian - 125.1MB Centos - 196MB 4.建议使用Alpine Linux 3.10.0版本，这也是 v3.10 稳定系列的首个版本 alpine:3.10 基于alpine使用Dockerfile创建jdk8镜像 1.下载镜像 docker pull alpine:latest 2.创建Dockerfile并编辑Dockerfile（在你有jdk jar包中的文件夹内创建，如果有Dockerfile了直接把里面的内容删掉重新编辑即可，不会影响上次镜像的使用 ） vim

打包的具体操作，可以参照官网，只是官网没有那么细 1、修改AndroidManifest.xml 2、构建配置 可以跳过 3、构建签名 4、创建 key.properties 5、配置混淆 6、修改builg配置build.gradle 7、打包 --------------------------------------------------分割线-------------------------------------------------------------------- 1、修改AndroidManifest.xml 路径： <app dir> /android/app/src/main/AndroidManifest.xml 3、构建签名 使用keytool， 可以直接在Android Studio 的terminal里面操作 口令： keytool -genkey -v -keystore G:/keys/test.keystore -keyalg RSA -keysize 2048 -validity 10000 -alias key 区分开来的字段需要注意，存储路径 和 别名， 路径里面的文件自己创建。 输入口令之后，开始填写一些信息，名字，公司....到了 【否】 这里写y，继续，没有报错的话签名就构建ok了，notepad++打开一坨乱码

开篇： “对于软件开发人员来说，保护代码安全也是比较重要的因素之一，不过目前来说Google Android平台选择了Java Dalvik VM的方式使其程序很容易破解和被修改，首先APK文件其实就是一个MIME为ZIP的压缩包，我们修改ZIP后缀名方式可以看到内部的文件结构，类似Sun JavaMe的Jar压缩格式一样，不过比较去别的是Android上的二进制代码被编译成为Dex的字节码，所有的Java文件最终会编译进该文件中去，作为托管代码既然虚拟机可以识别，那么我们就可以很轻松的反编译。所有的类调用、涉及到的方法都在里面体现到，至于逻辑的执行可以通过实时调试的方法来查看，当然这需要借助一些我们自己编写的跟踪程序。Google最然在Android Market上设置了权限保护app-private文件夹的安全，但是最终我们使用修改定值的系统仍然可以获取到需要的文件。" from: http://www.cnblogs.com/huyipeng/archive/2010/07/25/1784679.html 搞过几天android的朋友都知道，将apk文件解压后有两部分文件需要处理，一种是xml文件，另一种一个dex文件（.dex），我们可以从.dex文件中得到.class，利用后者再得到大家垂涎已久的java文件。 下面分别针对这三种格式的文件进行反编译处理； 1

1、自动化打包方案 　1）友盟多渠道多渠道打包 2）gradle productFlavors系统的条件编译 3）美团打包 4）APK文件注释写入渠道号 2、各打包方案简介 1)友盟多渠道多渠道打包(window 绿色版，gradle版本 现在过时) 原理：拆包分解apk,修改AndroidManifest.xml二进制文件后，再重新打包 耗时：较短（多渠道打包时，避免了多次dex过程，aapt过程） 渠道号保存方式：保存在AndroidManifest.xml 文 件 meta 数据中 不足：较难保证AndroidManifest.xml二进制修改正确，可能会出现兼容性问题；多渠道apk 命名不能预定，需要额外处理重命名apk文件。 2）.gradle productFlavors系统的条件编译 　　 原理： 每个渠道包，都走完整个打包（appt、混淆、dex，签名）流程 耗时：长（跟渠道包量成正比） 渠道号保存方式：保存在AndroidManifest.xml 文 件 meta 数据中 3)美团方案 原理：在APK文件的META-INF目里增加渠道文件 耗时：快（多个渠道包，只有一次完整打包流程） 渠道号保存方式：mtchannel_yybcpd文件名中 4)APK文件注释写入渠道号 原理：Android 使用的apk包的压缩方式是zip,与zip有相同的文件结构，正确写入

ADB的概念 adb的全称为Android Debug Bridge，是起到调试桥的作用。通过adb，我们可以在ecplise中方便的通过DDMS来调试Android程序，其实他就是一个debug工具。但它的工作当时比较特殊，采用监听socket TCP 5554等端口的方式让IDE和Qemu通讯，默认情况下adb会daemon相关的网络端口，所以当我们运行ecplise的时候adb的进程就会自动运行 ADB的作用 借助adb工具，我们可以管理设备或手机模拟器的状态。还可以进行很多手机操作，比如安装软件、系统升级、运行shell命令等等。 ADB的特点 1).运行设备的shell(命令行) 2).管理模拟器或设备的端口映射 3).计算机和设备之间上传/下载文件 4).将apk软件安装至模拟器或android设备 5).ADB是一个 客户端-服务器端 程序, 其中客户端是你用来操作的电脑, 服务器端是android设备. ADB操作命令 1. 查看在线设备 　　 adb devices 这个命令是查看当前连接的设备, 连接到计算机的android设备或者模拟器将会列出显示 其中标红的表示设备的状态，其有三个状态： 　　Devices:这个状态表示设备或者模拟器已经连接到adb服务器上。 　　Offline:这个状态表明设备或者模拟器没有连接adb服务去或者没有响应。 　　No

kubernetes的日志收集 日志收集在本篇文章中主要分2种方案 需要明确的是，kubernetes里对容器日志的处理方式，都叫做cluster-level-logging。 对于一个容器来说，当应用日志输出到stdout和stderr之后，容器项目在默认情况下就会把这些日志输出到宿主机上的一个JSON文件里。这样就能通过kubectl logs查看到日志了。 两种方案分别以Daemonset和sidecar模式部署 DaemonSet方式在每个节点只允许一个日志agent，相对资源占用要小很多，每个pod不能单独配置，可定制性较弱，比较适用于功能单一或业务不是很多的集群； Sidecar方式为每个POD单独部署日志agent，相对资源占用较多，每个pod可单独配置，可定制性强，建议在大型的K8S集群或多个业务方服务的集群使用该方式。 第一种 　　在Node上部署logging-agent，将日志文件发送到后端保存起来。 　　实际上这种模式的核心就是将logging-agent以Daemonset的方式运行在节点上，然后将宿主机上的容器日志挂载进去，最后由logging-agent把日志发送出去。 　　这种工作模式最大的有点，在于一个节点只需要部署一个agent，并且不会对应用和pod有任何的入侵。 　　在这里，我们通过fluentd作为logging