❶ 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的使用實例我再補充。