Android Studio 2.2 启用代码混淆

在新版本的 Android Studio中开启混淆的方法如下:

具体解释一下 minifyEnabled用来影响是不是开启混淆, shrinkResources只有在 minifyEnabledtrue的情况下,才能有效,用来去除无效的资源文件。 proguard-android-optimize.txtAndroid SDK-> tools\proguard目录下, Google已经写好默认的混淆模板文件,其中的 proguard-android.txt默认没有配置代码优化,而 proguard-android-optimize.txt默认配置了代码优化,至于我们自己工程下面的 proguard-rules.pro文件,只要配置我们自定义的额外配置即可,其他的用默认配置即可。

顺便讲一下代码混淆的好处:

1.代码安全,不易理解,增加破解难度。

2.减小APK的体积,减少内存开销。

3.缩减类名,方法名的长度,减少CPU开销。

参考链接


Android Studio 混淆代码时提示 “Warning:org.apache.commons.httpclient.util.URIUtil: can't find referenced class org.apache.commons.codec.net.URLCodec”

Android混淆代码时提示" Warning:org.apache.commons.httpclient.util.URIUtil: can't find referenced class org.apache.commons.codec.net.URLCodec"
解决方法是 proguard-rules.pro中增加如下语句:

其他类似的警告信息,可以参考以上的方法,逐行添加即可。

参考链接


ProGuard error can't find superclass or interface org.apache.http.entity

Android Studio升级到2.2正式版本后,在Windows命令行中执行“gradlew build”时,报告错误“Unsupported major.minor version 52.0”

Android Studio升级到 2.2正式版本后,在 Android Studio中编译一切正常。但是在 Windows命令行中执行“ gradlew build”时,报告如下错误:

这个原因,目前本人遇到的原因是,机器上同时安装了 jdk1.7.0_80jdk1.8.0_73两个版本的 JDK,而环境变量中的 JAVA_HOME指向的是 jdk1.7.0_80

解决方法就是修改 JAVA_HOME指向 jdk1.8.0_73即可。

注意,修改完成环境变量后,需要重启一下 Android Studio,以及 Windows命令行窗口。否则环境变量不生效。

Android Studio编译出的APK中一直包含android:debuggable="true"

最近遇到一个比较奇葩的事情,就是编译出来的 APKAndroidManifest.xml中的 application标签中一直包含 android:debuggable="true"。不管是 release版本,还是 debug版本,不管如何设置,最终生成的文件中的调试选项一直是处于开启状态。

一时间竟然有些无从下手的感觉。首先确认我们自己的配置文件是没有问题的,那么这个现象一定是引入了某个 aar中引入的 AndroidManifest.xml中存在这个 android:debuggable="true",导致 Android Studio在最终合并 AndroidManifest.xml文件的时候,把这个选项给合并进来了。

那么我们既然已经知道引入的地方,因此就只需要针对这种情况进行剖析即可了。

执行 gradlew build之后,我们在 app\build\intermediates\exploded-aar目录下面可以找到我们引入的全部的依赖的 aar。我们只需要逐个分析引入的 aar包的 AndroidManifest.xml文件即可。

那么比较奇葩,是奇葩在哪里呢? 正常情况下,我们引入一个 aar包,需要在 build.gradle中声明如下:

但是我们从真正的配置选项中看到的却是

按照一般的理解,我们如果没有设置 @aar,那么 Android Studio应该去下载对应的 jar包才对。但是我们从实际的编译过程中看到, Android Studio在没有指定 @aar的情况下,依旧默认去服务器上先尝试下载对应的 aar,只有当 aar找不到的时候才会去下载对应的 jar包。而恰好,我们服务器上面两者都是存在的。于是出现了乌龙事件,本来只是需要下载 jar包,结果却引入了一个莫名的 aar包。而这个 aar的开发同学又没有考虑到这种情况,以为用户只会用他提供的 jar包。
解决方法还是比较简单的,就是明确告知 Android Studio,我们需要的是 jar包,也就是增加 @jar。如下:

相关参考链接


Android Studio: Why is Release Build debuggable?

Android Studio 2.1.3配置Robolectric-3.0,Powermock-1.6.5单元测试环境

Android Studio提供了比较方便的单元测试,但是由于 Android系统的限制( ClassloaderGoogle自己实现的, Powermock无法修改底层的 bytecode),目前 Powermock还没办法直接在设备上执行测试,但是我们代码中难免存在一些静态对象,需要测试的时候,只能求助于 PowermockRobolectric的组合。
具体的配置如下:
1.首先在需要测试的项目的 build.gradle中声明需要使用 PowermockRobolectric

2.定义测试基类,在基类中声明一些必备的设置
AbsRobolectricPowerMockTest.java

3.定义真正的测试子类
DeckardActivityTest.java

注意,参考链接中的内容不可完全相信,按照参考链接中的配置( Robolectric-3.1.2+ PowerMock-1.6.5),一般会遇到如下问题(看上去很怪异,其实是由于不同的 classloader同时加载了相同的类,导致尽管类名是相同的,但是依旧无法进行类型转换):

参考链接


Gradle本站镜像

使用 Android Studio开发,最痛苦的其中一项是 Maven下载数据缓慢,目前已经可以根据在Ubuntu 14.04 系统中的Apache Tomcat上部署Apache Archiva 2.2.1来使用本站的代理服务器的方式进行提速了。另一个痛苦的事情就是下载 Gradle工具包的速度异常缓慢了,不仅慢,而且还容易失败。
目前本网站已经提供了 Gradle工具包的下载代理,具体的操作就是把 services.gradle.org进行域名污染,指向本站的 IP地址 121.199.27.227
Windows下的解决方法为修改 C:\Windows\System32\drivers\etc下的 hosts文件,里面增加如下内容:

接着修改 Android Studio项目下的 gradle\wrapper\gradle-wrapper.properties文件,把其中的

修改为:

注意,上面的修改其实主要是把 HTTPS修改成了 HTTP,原因在于 HTTPS无法进行域名污染。

当然,另外一个比较简单的修改方式为,只要修改 distributionUrl为本站地址,更加省事:

目前本站提供的 Gradle工具包版本如下:

Android Studio 2.1.2 在引用AAR的时候排除armeabi-v7a目录下的.so文件

Android Studio 2.1.2在引用 AAR的时候,如果 AAR中包含 armeabi-v7a版本的 .so文件,而我们自带的 .so又仅仅包含 armeabi版本的,会导致我们的APK在运行的时候崩溃,报告找不到 .so文件,另外就是会增大我们最后的 APK的大小,因此我们需要排除 armeabi-v7a目录下的 .so文件.
操作方法如下:

这个方法的本质是通过强制指定 abi的方式来要求 Android Studio排除其他系统版本的 .so文件。

同样道理,可以用来在 32位的 APK中排除 64位的 .so文件,减少 APK大小。

参考链接


How to use 32-bit native libaries on 64-bit Android device

Android Studio 2.1.2版本计算代码覆盖率

Android Studio 2.1.2版本已经集成了 JaCoCo用来进行代码覆盖的计算,严格上来说,这个功能并不是 Android Studio实现的,而是 IntelliJ IDEA早就实现的功能。

全部需要做的仅仅是在 build.gradle中增加 testCoverageEnabled = true即可,如下图:

testCoverageEnabled

然后,在命令行中执行

即可在每个子项目的 build\reports\coverage\debug\下面会生成代码覆盖率的统计文件。点击 index.html即可查看代码覆盖情况,目前看到的情况是,貌似只能统计到 test目录下覆盖到的代码,而无法统计 androidTest目录下的测试代码的覆盖情况。

参考链接


Android注解支持(Support Annotations)

注解支持(Support Annotations)

Android Support Library19.1版本开始引入了一个新的注解库,它包含很多有用的元注解,你能用它们修饰你的代码,帮助你发现 bugSupport Library自己本身也用到了这些注解,所以作为 Support Library的用户, Android Studio已经基于这些注解校验了你的代码并且标注其中潜在的问题。 Support Library 22.2版本又新增了13个新的注解以供使用。

使用注解库

注解默认是没有包含的;他们被包装成一个独立的库。( support library现在由一些更小的库组成: v4-support, appcompat, gridlayout, mediarouter等等)

(如果你正在使用 appcompat库,那么你已经可以使用这些注解了,因为 appcomat它自己也依赖它。)

添加使用注解最简单的方式就是打开 Project Structure对话框。首先在左边选中 module,然后在右边选中 Dependencies标签页,点击面板底部的 +按钮,选择 Library Dependency,假设你已经把 Android Support Repository安装到你的 SDK中了,那么注解库将会出现在列表中,你只需点击选中它即可(这里是列表中的第一个):
150820193163761

点击 OK完成 Project Structure的编辑。这会修改你的 build.gradle文件,当然你也可以手动编辑它:

对于 Android ApplicationAndroid Library这两个类型的 module(你应用了 com.android.application或者 com.android.library插件的)来说,你需要做的已经都做好了。如果你想只在 Java Module使用这些注解,那么你就明确的包含 SDK仓库了,因为 Support Libraries不能从 jcenter获得( Android Gradle插件会自动的包含这些依赖,但是 Java插件却没有。)

执行注解

当你用 Android StudioIntelliJ IDEA的时候,如果给标注了这些注解的方法传递错误类型的参数,那么 IDE就会实时标记出来。

Gradle插件 1.3.0-beta1版本开始,并且安装了 Android M Preview平台工具的情况下,通过命令行调用 gradlelint任务就可以执行这些检查。如果你想把标记问题作为持续集成的一部分,那么这种方式是非常有用的。说明:这并不包含 Nullness注解。本文中所介绍的其他注解都可以通过 lint执行检查。

Nullness Annotations

@Nullable注解能被用来标注给定的参数或者返回值可以为 null
类似的, @NonNull注解能被用来标注给定的参数或者返回值不能为 null

如果一个本地变量的值为 null(比如因为过早的代码检查它是否为 null),而你又把它作为参数传递给了一个方法,并且该方法的参数又被 @NonNull标注,那么 IDE会提醒你,你有一个潜在的崩溃问题。
v4 support library中的 FragmentActivity的示例代码:

(如果你执行 Analyze -> Infer Nullity...,或者你在键入时把 @NonNull替换成了 @NotNull,那么IDE可能会提供附加的 IntelliJ注解。参考底部的“ IntelliJ Annotations”段落了解更多)

注意 @NonNull@Nullable并不是对立的:还有第三种可能:未指定。当你没有指定 @NonNull或者 @Nullable的时候,工具就不能确定,所以这个 API也就不起作用。

最初,我们在 findViewById方法上标注 @Nullable,从技术上说,这是正确的: findViewById可以返回 null。但是如 果你知道你在做什么的时候(如果你传递给他一个存在的 id)他是不会返回 null的。当我们使用 @Nullable注解它的时候,就意味着源代码编辑器中会有大量的代码出现高亮警告。如果你已经意识到每次使用该方法都应该明确的进行 null检查,那么就只能用 @Nullable标注返回值。有个经验规则: 看现有的“好的代码”(比如审查产品代码),看看这些 API是怎么被使用的。如果该代码为 null检查结果,你应该为方法注解 @Nullable

资源类型注解

Android的资源值通常都是使用整型传递。这意味着获取一个 drawable使用的参数,也能很容易的传递给一个获取 string的方法;因为他们都是 int类型,编译器很难区分。

资源类型注解可以在这种情况下提供类型检查。比如一个被 @StringRes住进诶的 int类型参数,如果传递一个不是 R.string类型的引用将会被 IDE标注:
150820193163762
ActionBar为例:

有很多不同资源类型的注解:如下的每一个 Android资源类型:
@StringRes, @DrawableRes, @ColorRes, @InterpolatorRes,等等。一般情况下,如果有一个 foo类型的资源,那么它的相应的资源类型注解就是 FooRes.

除此之外,还有一个名为 @AnyRes特殊的资源类型注解。它被用来标注一个未知的特殊类型的资源,但是它必须是一个资源类型。比如在框架中,它被用在 Resources#getResourceName(@AnyRes int resId)上,使用的时候,你可以这样 getResources().getResourceName(R.drawable.icon)用,也可以 getResources().getResourceName(R.string.app_name)这样用,但是却不能这样 getResources().getResourceName(42)用。

请注意,如果你的 API支持多个资源类型,你可以使用多个注解来标注你的参数。

IntDef/StringDef: 类型定义注解

整型除了可以作为资源的引用之外,也可以用作“枚举”类型使用。

@IntDef和” typedef”作用非常类似,你可以创建另外一个注解,然后用 @IntDef指定一个你期望的整型常量值列表,最后你就可以用这个定义好的注解修饰你的 API了。

appcompat库里的一个例子:

上面非注解的部分是现有的 API。我们创建了一个新的注解( NavigationMode)并且用 @IntDef标注它,通过 @IntDef我们为返回值或者参数指定了可用的常量值。我们还添加了 @Retention(RetentionPolicy.SOURCE)告诉编译器这个新定义的注解不需要被记录在生成的 .class文件中(译者注:源代码级别的,生成 class文件的时候这个注解就被编译器自动去掉了)。

使用这个注解后,如果你传递的参数或者返回值不在指定的常量值中的话, IDE将会标记出这种情况。
150820193163768

你也可以指定一个整型是一个标记性质的类型;这样客户端代码就通过|,&等操作符同时传递多个常量了:

最后,还有一个字符串版本的注解,就是 @StringDef,它和 @IntDef的作用基本上是一样,所不同的是它是针对字符串的。该注解一般不常用,但是有的时候非常有用,比如在限定向 Activity#getSystemService方法传递的参数范围的时候。

要了解关于类型注解的更多详细信息,请参考
https://developer.android.com/tools/debugging/annotations.html#enum-annotations

线程注解: @UiThread, @WorkerThread, …

( Support library 22.2及其之后版本支持.)

如果你的方法只能在指定的线程类型中被调用,那么你就可以使用以下4个注解来标注它:

  • @UiThread
  • @MainThread
  • @WorkerThread
  • @BinderThread

如果一个类中的所有方法都有相同的线程需求,那么你可以注解类本身。比如 android.view.View,就被用 @UiThread标注。

关于线程注解使用的一个很好的例子就是 AsyncTask

如果你在重写的 doInBackground方法里尝试调用 onProgressUpdate方法或者 View的任何方法, IDE工具就会马上把它标记为一个错误:
150820193163766

@UiThread还是 @MainThread?

在进程里只有一个主线程。这个就是 @MainThread。同时这个线程也是一个 @UiThread。比如 Activity的主要窗口就运行在这个线程上。然而它也有能力为应用创建其他线程。这很少见,一般具备这样功能的都是系统进程。通常是把和生命周期有关的用 @MainThread标注,和 View层级结构相关的用 @UiThread标注。但是由于 @MainThread本质上是一个 @UiThread,而大部分情况下 @UiThread又是一个 @MainThread,所以工具( lint , Android Studio,等等)可以把他们互换,所以你能在一个可以调用 @MainThread方法的地方也能调用 @UiThread方法,反之亦然。

RGB颜色整型

当你的 API期望一个颜色资源的时候,可以用 @ColorRes标注,但是当你有一个相反的使用场景时,这种用法就不可用了,因为你并不是期望一个颜色资源 id,而是一个真实的 RGB或者 ARGB的颜色值。

在这种情况下,你可以使用 @ColorInt注解,表示你期望的是一个代表颜色的整数值:

有了这个,当你传递一个颜色 id而不是颜色值的时候, lint就会标记出这段不正确的代码:
150820193163767

值约束: @Size, @IntRange, @FloatRange

如果你的参数是一个 float或者 double类型,并且一定要在某个范围内,你可以使用 @FloatRange注解:

如果有人使用该 API的时候传递一个 0-255的值,比如尝试调用 setAlpha(128),那么工具就会捕获这一问题:

1508201931637610

(你也可以指定是否包括起始值。)

同样的,如果你的参数是一个 int或者 long类型,你可以使用 @IntRange注解约束其值在一个特定的范围内:

把这些注解应用到参数上是非常有用的,因为用户很有可能会提供错误范围的参数,比如上面的 setAlpha例子,有的 API&lt;c/ode&gt;是采用<code>0-255的方式,而有的是采用 0-1float值的方式。

最后,对于数据、集合以及字符串,你可以用 @Size注解参数来限定集合的大小(当参数是字符串的时候,可以限定字符串的长度)。

举几个例子

  • 集合不能为空: @Size(min=1)
  • 字符串最大只能有23个字符: @Size(max=23)
  • 数组只能有2个元素: @Size(2)
  • 数组的大小必须是 2的倍数 (例如图形 API中获取位置的 x/y坐标数组: @Size(multiple=2)

150820193163765

权限注解: @RequiresPermission

如果你的方法的调用需要调用者有特定的权限,你可以使用 @RequiresPermission注解:

如果你至少需要权限集合中的一个,你可以使用 anyOf属性:

如果你同时需要多个权限,你可以用 allOf属性:

对于 intents的权限,可以直接在定义的 intent常量字符串字段上标注权限需求(他们通常都已经被 @SdkConstant注解标注过了):

对于 content providers的权限,你可能需要单独的标注读和写的权限访问,所以可以用 @Read或者 @Write标注每一个权限需求:

150820193163763

方法重写: @CallSuper

如果你的 API允许使用者重写你的方法,但是呢,你又需要你自己的方法(父方法)在重写的时候也被调用,这时候你可以使用 @CallSuper标注:

用了这个后,当重写的方法没有调用父方法时,工具就会给予标记提示:

150820193163764

( Android Studio 1.3 Preview 1lint检查有个关于这个注解的 bug,这个 bug就是即使是对的重写也会报错,这个 bug已经在 Preview 2版本修改,可以通过 canary channel更新到 Preview 2版本。)

返回值: @CheckResult

如果你的方法返回一个值,你期望调用者用这个值做些事情,那么你可以使用 @CheckResult注解标注这个方法。

你并不需要微每个非空方法都进行标注。它主要的目的是帮助哪些容易被混淆,难以被理解的API的使用者。

比如,可能很多开发者都对 String.trim()一知半解,认为调用了这个方法,就可以让字符串改变以去掉空白字符。如果这个方法被 @CheckResult标注,工具就会对那些没有使用 trim()返回结果的调用者发出警告。

Android中, Context#checkPermission这个方法已经被 @CheckResult标注了:

这是非常重要的,因为有些使用 context.checkPermission的开发者认为他们已经执行了一个权限 —-但其实这个方法仅仅只做了检查并且反馈一个是否成功的值而已。如果开发者使用了这个方法,但是又不用其返回值,那么这个开发者真正想调用的可能是这个 Context#enforcePermission方法,而不是 checkPermission

150820193163769

@VisibleForTesting

你可以把这个注解标注到类、方法或者字段上,以便你在测试的时候可以使用他们。

@Keep

我们还在注解库里添加了 @Keep注解,但是 Gradle插件还支持(尽管已经在进行中)。被这个注解标注的类和方法在混淆的时候将不会被混淆。

在你自己的库中使用注解

如果你在你自己的库中使用了这些注解,并且是通过 Gradle构建生成 aar包,那么在构建的时候 Android Gradle插件会提取注解信息放在 AAR文件中供引用你的库的客户端使用。在 AAR文件中你可以看到一个名为 annotations.zip的文件,这 个文件记录的就是注解信息,使用的是 IntelliJ的扩展注解 XML格式。这是必须的,因为 .class文件不能包含足够的要处理以上 @IntDef注解的信息;注意我们只需记录该常量的一个引用,而不是它的值。当且仅当你的工程依赖注解库的时候, Android Gradle插件会把提取注解的任务作为构建的一部分执行它。(说明:只有源保留注解被放置在 .aar文件中; class级别的会被放在 classes.jar里。)

IntelliJ注解

IntelliJAndroid Studio就是基于它开发的, IntelliJ有一套它自己的注解; IntDef分析其实重用的是 MagicConstant分析的代码, IntelliJ null分析其实用的是一组配置好的 null注解。如果你执行 Analyze -> Infer Nullity,它会试图找出所有的 null约束并添加他们。这个检查有时会插入 IntelliJ注解。你可以通过搜索,替换为 Android注解库的 注解,或者你也可以直接用 IntelliJ注解。在 build.gradle里或者通过 Project Structure对话框的 Dependencies面板都可以添加如下依赖:

参考链接


Android注解支持(Support Annotations)

Android Studio中的productFlavors指定默认编译执行的任务

Android Studio中指定了 productFlavors如下:

整个的 build.gradle里面的内容如下:

但是这个时候我们点击 Android Studio的调试按钮的时候,不知道究竟是使用哪个 Flavors来编译,比如在 Android Studio 1.5的时候,是按照从上到下的顺序处理的,默认是使用排在第一个的 Daily,而到了 Android Studio 2.1 Preview 5版本,却变成了按照字母排序,结果变成了默认编译 Advance

网上搜索了一下,找到如下解决方法:

选择" Build Variant",然后在出现的窗口中选择其中一个选项作为默认的编译,运行选项即可。

BuildVariantSel