Thursday, March 31, 2016

Android Build System

Android Build System - Hallo sahabat Google Android Developer Tutorial, Pada Artikel yang anda baca kali ini dengan judul Android Build System, kami telah mempersiapkan artikel ini dengan baik untuk anda baca dan ambil informasi didalamnya. mudah-mudahan isi postingan yang kami tulis ini dapat anda pahami. baiklah, selamat membaca.

Judul : Android Build System
link : Android Build System

Baca juga


Android Build System

source: https://ejf.io/android/build_system/

Tips

  • Use the daemon
    • --daemon or org.gradle.debug = true
  • Give it enough memeory
  • Control the number of threads
  • Use the latest build tools
  • Get an SSD
  • Don’t use timestamps or commit numbers in debug build files
Try:
android {
dexOptions {
dexInProcess = true
}
}
Consider having a development flavor using min SDK 21, as it’s going to be faster.
android.productFlavors {
normal
dev {
minSdkVersion 21
}
}

Testing

Test dependencies

dependencies {
compile ".."
testCompile "junit:junit:4.12"
testCompile "org.mockito:mockito-core:1.9.5"
}

Unit testing

config:
unitTests.all {
jvmArgs "-XX:MaxPermSize=256m"

beforeTest { descriptor ->
logger.lifecycle("Running test: " + descriptor)
}
}

Using a test project

Use a separate project just for the test APK.
In main project:
apply plugin: 'com.android.application'
android {
...
publishNonDefault true
}
In test project:
apply plugin: 'com.android.test'
android {
targetProjectPath ':app'
targetVariant 'debug'

defaultConfig {
minSdkVersion 8
testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner'
}
}
Test code then lives in the main source set of your test project.
Instrumentation tag still needs to be added to the test project manifest, however they’re hoping to be able to remove this step soon:
<manifest ...>
<instrumentation
android:name="android.support.test.runner.AndroidJUnitRunner"
android:targetPackage="com.example.app" />
</manifest>
Running task on test project:
./gradlew :testProject:connectedAndroidTest
One note on all of this is to make sure that you avoid build tools and dependency version conflicts! Main APK and Test APK need to have the same Build Tools version, and same versions for dependencies. This should be common sense (since you want to test the same versions of everything).

Native Support

New plugins

  • com.android.model.application - *.apk
  • com.android.model.library - *.aar
  • com.android.model.native - *.so
In build.gradle:
apply plugin: 'com.android.model.application'
model {
android {
compileSdkVersion = 22
buildToolsVersion = "22.0.1"

ndk.with {
moduleName = "native"
// and other configurations like the following
CFlags.add("-DCUSTOM_DEFINE")
cppFlags.add("-DCUSTOM_DEFINE")
ldFlags.add("-L/custom/lib/path")
ldLibs.add("log")
stl = "stlport_static"
}
}
}

Inter-module dependencies

Inter-module dependencies for native code, using a library project for the native code:
apply plugin: 'com.android.model.application'
model {
android.sources {
main {
jni {
dependencies {
project ":lib"
}
}
}
}
}
Perhaps the lib project with native code is set up like this:
apply plugin: "com.android.model.native"
model {
android {
compileSdkVersion = 21
}
android.ndk {
moduleName = "hello"
}
}

Extending the Android plugin

afterEvaluate

Old way:
project.afterEvaluate {
def task = project.tasks.getByName('transformClassesWithInstantRunForDebug')
// ...
}
  • not part of the official API
  • no guarantee that task names will be stable
  • no guarantee that things won’t be merged or split


Demikianlah Artikel Android Build System

Sekianlah artikel Android Build System kali ini, mudah-mudahan bisa memberi manfaat untuk anda semua. baiklah, sampai jumpa di postingan artikel lainnya.

Anda sekarang membaca artikel Android Build System dengan alamat link https://googleandroiddevelopertutorial.blogspot.com/2016/03/android-build-system.html

Artikel Terkait

Android Build System
4/ 5
Oleh

Berlangganan

Suka dengan artikel di atas? Silakan berlangganan gratis via email