❶ android打混淆包以后，BuildConfig.DEBUG还是true不是说，打混淆包以后，这个值会变成false么
混淆不混淆和BuildConfig.DEBUG无关，BuildConfig.DEBUG只取决于你build的方式。平时build都是true，只有通过export（导出）方式时才是false。导出功能在右键点击工程->Android Tools -> Export Signed Application Package。
再找不到的话就看这个问答http://stackoverflow.com/questions/9855834/when-does-adt-set-buildconfig-debug-to-false
建议学android变成多上stackoverflow，很多有用答复。
❷ Android中如何使用代码打开各种类型的文件
在安卓中打开音乐、视频、图片、文档等文件是需要有读取SD卡权限的，如果是6.0以下的系统，则直接在清单文件中声明SD卡读取权限即可；如果是6.0或以上，则需要动态申请权限。
在7.0以下中打开文件时，通过intent调用系统安装得人软件打开文件就好了，但是在android7.0及以上的机子上这么做会报android.os.FileUriExposedException错误，
1）读取SD卡
2）动态申请权限
//设备API大于6.0时，主动申请权限（读取文件的权限）
public static void requestPermission(Activity context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
if (ContextCompat.checkSelfPermission(context, Manifest.permission.WRITE_EXTERNAL_STORAGE)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(context, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE,
Manifest.permission.READ_EXTERNAL_STORAGE}, 0);
}
}
}
3）读取文件
intent = OpenFileUtil.openFile(filePath+"/"+FileName+"."+end);
使用OpenFileUtil这个。链接： https://www.jianshu.com/p/1414101858c1
为了兼容Android7.0，获取文件Uri需要使用到FileProvider。
1）首先是AndroidManifest文件里面注册FileProvider
android:name="android.support.v4.content.FileProvider"
android:authorities="${applicationId}.provider"
android:exported="false"
android:grantUriPermissions="true">
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/provider_paths" /> //需要自己编写xml文件
2）provider_paths.xml文件的编写
// .表示根目录
3）打开文档方式为
intent = new Intent(Intent.ACTION_VIEW);
intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
File txtFile = new File(filePath+"/"+FileName+"."+end);
Uri contentUri = FileProvider.getUriForFile(MyApplication.getContext(), BuildConfig.APPLICATION_ID+".provider", txtFile);
intent.setDataAndType(contentUri, "application/vnd.android.package-archive");
grantUriPermission(context, contentUri, intent);
startActivity(intent);
4）grantUriPermission方法添加权限
private static void grantUriPermission (Context context, Uri fileUri, Intent intent) {
List resInfoList = context.getPackageManager().queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY);
for (ResolveInfo resolveInfo : resInfoList) {
String packageName = resolveInfo.activityInfo.packageName;
context.grantUriPermission(packageName, fileUri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION);
}
}
综合两种情况：
//判断是否是AndroidN以及更高的版本，Build.VERSION_CODES.N是Android 7.0
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
intent = new Intent(Intent.ACTION_VIEW);
intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
File txtFile = new File(filePath+"/"+FileName+"."+end);
Uri contentUri = FileProvider.getUriForFile(MyApplication.getContext(), BuildConfig.APPLICATION_ID+".provider", txtFile);
Log.i("文件地址：",contentUri.toString());
intent.setDataAndType(contentUri, "application/vnd.android.package-archive");
grantUriPermission(MyApplication.getContext(), contentUri, intent);
} else {
//7.0以下的可以打开文件了
intent = OpenFileUtil.openFile(filePath+"/"+FileName+"."+end);
}
MyApplication.getContext().startActivity(intent);
❸ 按照网上的方法,android studio导出的jar只有一个文件BuildConfig
在你要打jar包的mole build文件中，加上一个生成jar包的task。其实即使不添加，在整个工程build时也会生成jar文件的。在build/intermediates/bundles/release/classes.jar可以找到。只是没混淆罢了。
task makeJar(type: proguard.gradle.ProGuardTask, dependsOn: "build") {
// 未混淆的jar
injars 'build/intermediates/bundles/release/classes.jar'
// 混淆后的jar路径
outjars 'build/http.jar'
// 具体需要keep住的类
configuration 'proguard-rules.pro'
}
这个时候，在Termial中就输入./gradlew makeJar就能将classes.jar复制倒http.jar了。这个时候还是没混淆的，因为混淆根本没写。
如果mole中同时也依赖其它libs，那需要在proguard中声明那些libs。比如：#-libraryjars libs\gson-2.2.2.jar，大部分都跟apk混淆类似的，只不过是局限于某个mole而已。
附送一个proguard供大家参考，也是网上找的。最后混淆效果并不是很好，只是简单的将部分变量改成了abcd这样，不过也够了。总不能将方法也混淆，这样外部调用就麻烦了。
❹ 在创建一个新的Android项目中为什么含有BuildConfig.java文件,如何删除
这是新版SDK的新功能，自动生成并且不能删除的。它的具体作用和使用方式你可以参照工程组建的说明文档。
简单来说，就是代码的辅助检查，在整个工程中不断自动检测。
❺ android buildconfig什么时候生成
本文章都只是在AndroidStudio基于Gradle构建项目开发的验证，所以不保证其它开发环境与构建项目方式也是这样
BuildConfig身在何处
了解一个东西前，至少先要知道这东西在哪里吧！而我们今天要了解的这个类又在哪里了，我相信应该还有一些安卓开发人员没见过此类的身影。那么这类在哪里了？
答案：一般情况是在applicationId<应用包名>.BuildConfig；如：我的应用ID为:com.jay.demo，那么此类的全类名就是com.jay.demo.BuildConfig；
但这是一般情况，也就是说我们在创建工程时确定的应用包名，但这里答案准确的来说，此类是和R<resouce>类在同一个包里的，那么R<resouce>类的名路径是怎么确定的了？
答案：很明确，是由AndroidManifest.xml文件中的manifest标签中的package属性指定的包路径
BuildConfig有啥用
我们先从类名来试图理解这个类是做什么的，BuildConfig很明显是由Build与Config组成，Build = 构建，Config = 配置，那么直译过来就是BuildConfig = 构建配置，大致猜到了这个类可能会与一个配置相关的信息
❻ Android反编译（三）— 手动编译
PS: 最近没工作，没工作就没需求，没需求就没什么技术总结的灵感，那就没更新什么。但是两个月不更新了，要是三个月不更新就会出大事，所以这次打算做一件有意思又不难的事。
之前有发文章写过反编译，今天就来试试反编译之正编译，开玩笑的，就是试试手动编译的过程， 平时我们在项目中编译出包都是使用Gradle直接执行assemble任务就能解决，我打算试试手动模拟整个过程。当然我也是第一次这样搞，所以如果有写得不对的地方，还望指出。
众所周知，apk实质上就是一个压缩包。复习一下，我们写个最简单的Demo，然后打包，然解压，注意是解压，不是反编译，意义是不同的。
注意我这个Demo很简单，什么都不引入
然后我们看看整个出包的过程，随便从网上拿张图
然后这里我们用Android SDK给我们提供的工具来完成整个流程，工具在sdk文件夹下的build-tools文件夹下，有什么aapt.exe、dx.bat，用的就是这些
这步应该是整个流程最简单的吧，我感觉，所以从最简单的开始。
我们先看看生成的dex有什么
对比项目，我是一开始最基本的项目，什么都没动，所以只有一个MainActivity.clas，所以这里肯定是要先想办法得到BuildConfig.class和R.class。
输入命令：
aapt p -f -m -J <输出路径> -S <res路径> -I <android.jar路径> -M <Manifest路径>
下一步，我们需要BuildConfig.class
这个BuildConfig.java是由gradle在我们配置好gradle之后自己帮我们生成的，所以我们直接拿来用，然后再javac就得到class文件了
然后我们再编译我们的MainActivity.java并将它们放到同一个文件夹下， MainActivity因为引用了Android.jar和R文件，所以编译时注意点，我为此被动好好的复习了一遍javac，都是泪
最后一步，我们用dx工具就能打出dex文件了
然后执行命令就得到一个Dex文件，看看这个文件里面和上面直接打出的apk中的Dex文件有什么不同：
看图，我们上一步已经生成.dex了，那么我们需要和compiled Resource 还有 Other Resource 一起生成APK。
我们先来生成compiled Resource，也就是resources.arsc
发现之前使用aapt生成R文件的时候没写完整，当时可以加一个-F参数直接生成arsc和Manifest
导出的abc.zip里面就有resources.arsc和AndroidManifest.xml。
因为之前写漏了，所以肯定要重新编一次MainActivity.java和Dex
我们把刚才的dex文件和aapt生成的resources.arsc、AndroidManifest.xml和res放到一个文件夹里面。
PS：res文件夹也是上面aapt的命令生成的
然后我们对比这个文件夹和之前apk解压的文件夹
最后运行
看来是成功了。
再说说遇到的还有两个问题，并说下我解决问题的思路
（1）我把它们都放到一个文件夹之后，我压缩成压缩包，然后改后缀成.apk，然后发现安装不了，我就直接反编译，发现发编译失败，提示包有问题，以我多点玩包的经验，我感觉就是压缩工具出了问题，然后我去下个“好压”（这不是广告啊），然后就能正常反编译了。
（2）但是还是安装不了，再根据我多年的玩包经验，我感觉是签名问题，然后我随便给这个包上一个签名，就能正常安装得到上图的结果了。
总体来说，还真挺好玩的，这整个过程，就是翻车了几次。做完之后感觉非常牛逼，为什么这样说，因为我知道这整个过程，我就可以做到，我不经过gradle来打包，我自己写个python脚本来调用aapt和dx来打包也是能做到的。
当然上面纯属异想天开，因为这是个什么都没有的Demo所以觉得简单，要是一个真实的项目，我感觉肯定要有很多坑，别的先不说，一个项目那么多依赖关系，我这javac要搞死人。
最后如果有不对的地方，希望有大佬能够指出，毕竟能运行也不能证明完全没问题。然后我使用的build-tools是28的，不敢保证其它版本包括以后版本的玩法都一样。
❼ android开发怎么发送不同类型的阿里百川云推送
推送和IM的版本为此时间点的最新版本，两个SDK都是以Mole方式依赖，编译的时候会报下面的错误:
Error:Execution failed for task ':ipark2:'.
> com.android.build.api.transform.TransformException: java.util.zip.ZipException: plicate entry: com/alibaba/sdk/android/BuildConfig.class12
BuildConfig.class冲突了。百搜不得其解，最后经推送的旺旺群里一位哥们提醒，发现推送和IM的SDK的报名重复了，所以会报上面的错误，修改其中一个的包名即可解决。
❽ Android Debug 版本判断及为什么 BuildConfig.DEBUG 始终为 false
android项目编译时自动会在gen文件夹里，生成一个BuildConfig类，如果是调试的话，BuildConfig.DEBUG将自动赋值为true，你在Log的地方加上if(BuildConfig.DEBUG)，就可以了。比较方便，也不用写个类进行管理。
❾ Android Gradle 多维度实例
上一篇文章 Just Enough Gradle for Android 介绍了Gradle的一些基本知识，基本概念，理解这些有助于我们更加合理地使用Gradle。这篇文章聚焦于Gradle在Android项目中的实际使用。之所以叫做多维度实例，是想展示Gradle运用的灵活性，对于同一种需求，尽可能尝试用多种方式去实现。比较各种实现之间的思路、方式及优劣。
Gradle的Android插件默认定义了两种BuildTypes：debug和release。我们往往需要对这两种BuildTypes进行区分。
为了使debug版本和release版本的APP能同时装到手机上，它们需要有不同的applicationId。
BuildType和ProctFlavor都可以设置自己的applicationId、minSdkVersion、targetSdkVersion、versionName等，如果没有设置，则使用defaultConfig中的设置。
如今debug版和release版的APP都装到我们的手机里了，但是它们俩看上去长得一模一样，无论是应用图标还是名称都一样，实在不容易区分。给不同版本的APP起不一样的名字也许是最简单明了的区分方式了。
之所以有不同的BuildType就是为了可以对它们进行差异化设置。Android资源（即res文件下面的内容）的差异化设置非常简单。在与main平级的目录下增加debug文件夹，在相应的资源文件夹下设置app_name即可：
我们甚至可以为不同版本的APP设置不一样的应用图标（以及其它一切资源），步骤跟修改app_name是一样的，把图标放置在相应文件夹里即可。如果仅仅是为了区分debug版和release版的话，确实没必要。不过对于不同的ProctFlavor还是有用的，的确不同的ProctFlavor可能会用不同的应用图标。一般而言，BuildType主要是内部使用，如debug或者测试什么的；而ProctFlavor主要是外部使用，发布不同版本的APP，如免费版和付费版等。
其实，在build.gradle中可以直接定义资源，跟我们在res/values中定义是一样的：
debug和release版的APP，一般需要设置不同的接口地址，方便测试使用。我们可以使用如下的方式实现：
BuildConfig类是项目构建过程中生成的，默认情况下DEBUG只在BuildType为debug的时候为true，其它情况下都为false。当然也可以设置：
我们通过BuildConfig的DEBUG字段去决定使用哪个URL，能不能在BuildConfig中增加字段呢？例如直接增加一个BASE_URL字段，这样岂不是更加直接。当然可以：
利用buildConfigField方法定义新的字段，注意最后一个参数的写法'" http://example.com/api "'，buildConfigField的三个参数都是String类型，最后一个参数String的值会直接拿来赋值给我们定义的字段：
一顿操作之后，我们便可以直接引用我们定义的字段了：
这种方式比较直接，但是如果要修改BASE_URL的值则需要Sync Gradle。究竟使用哪种方式，看你的喜好了。
对于multiproject多工程（包含有多个mole）而言，一个常见的需求就是在不同的Project之间“共享”一些属性。例如，指定统一的compileSdkVersion、buildToolsVersion、appcompat版本等。这可以通过额外属性来实现。
这种方式的确可以，但是并不推荐。因为gradle.properties主要是用来设置Gradle本身的属性的。
这样就可以在所有build.gradle中直接使用额外属性了：
插件对于Gradle而言是极其重要的，除了我们常用的Android Application插件和Android Library插件外，我们也可以自己定义插件。Gradle插件既可以是像Android Application这样的，实现了Plugin接口的插件（主要用来定义了Tasks，在多个Project中复用这些Tasks）；也可以是简单的groovy脚本文件（主要用来在多个Project中共享一些属性、方法等）。根据我们的需求，定义脚本插件即可。
可以在根目录定义versions.gradle文件：
然后在顶层build.gradle中将versions.gradle作为脚本插件，应用到所有Project中：
余下的步骤是一样的，可以在所有build.gradle中直接使用额外属性了。这种方式不同于在RootProject中定义额外属性，versions.gradle被应用在了所有的Project中，相当于在每个Project中都定义了额外属性，只是这些属性都是相同的。并且，这种方式也更加符合Gradle模块化的思想，是比较推荐的方式。
进一步的，我们可以在versions.gralde中定义更多东西：
在mole中的build.gradle中：
我自己对Gradle的使用也比较有限，遇到更多Gradle的使用实例我再补充。