Gradle והפלאגין של Android ל-Gradle מספקים דרך גמישה לכתוב, ליצור ולארז את האפליקציה או הספרייה של Android. בדף הזה ריכזנו כמה טיפים והגדרות שימושיים שיעזרו לכם להפיק את המקסימום מכל גרסה מוצרית. במאמר אופטימיזציה של מהירות ה-build מוסבר איך אפשר לזרז את תהליך ה-build.
אם אתם משתמשים חדשים ב-Gradle, כדאי לעיין במאמר הגדרת ה-build כדי ללמוד את העקרונות הבסיסיים. אפשר גם לעיין במסמכי העזרה של ה-DSL של הפלאגין ל-Android כדי לקבל מידע נוסף על המאפיינים שבהם נעשה שימוש בדף הזה.
ניהול פרויקטים ומקורות
ריכזנו כאן כמה הגדרות לניהול המודולים של הפרויקט והמקורות שלהם. למידע נוסף על יצירה וניהול של פרויקטים ומודולים, קראו את הסקירה הכללית על פרויקטים.
שינוי ההגדרות של קבוצת מקורות ברירת המחדל
אפשר להשתמש בבלוק
sourceSets
בקובץ build.gradle
ברמת המודול כדי לשנות את המיקום שבו Gradle מחפש קבצים לכל רכיב של קבוצת מקורות.
Groovy
android { ... sourceSets { // Encapsulates configurations for the main source set. main { // Changes the directory for Java sources. The default directory is // 'src/main/java'. java.srcDirs = ['other/java'] // When you list multiple directories, Gradle uses all of them to collect // sources. You should avoid specifying a directory which is a parent to one // or more other directories you specify. res.srcDirs = ['other/res1', 'other/res2'] // For each source set, you can specify only one Android manifest. // The following points Gradle to a different manifest for this source set. manifest.srcFile 'other/AndroidManifest.xml' ... } // Create additional blocks to configure other source sets. androidTest { // If all the files for a source set are located under a single root // directory, you can specify that directory using the setRoot property. // When gathering sources for the source set, Gradle looks only in locations // relative to the root directory you specify. For example, after applying // the configuration below for the androidTest source set, Gradle looks for // Java sources only in the src/tests/java/ directory. setRoot 'src/tests' ... } } } ...
Kotlin
android { ... sourceSets { // Encapsulates configurations for the main source set. getByName("main") { // Changes the directory for Java sources. The default directory is // 'src/main/java'. java.setSrcDirs("other/java") // When you list multiple directories, Gradle uses all of them to collect // sources. You should avoid specifying a directory which is a parent to one // or more other directories you specify. res.setSrcDirs("other/res1", "other/res2") // For each source set, you can specify only one Android manifest. // The following points Gradle to a different manifest for this source set. manifest.srcFile("other/AndroidManifest.xml") ... } // Create additional blocks to configure other source sets. androidTest { // If all the files for a source set are located under a single root // directory, you can specify that directory using the setRoot property. // When gathering sources for the source set, Gradle looks only in locations // relative to the root directory you specify. For example, after applying // the configuration below for the androidTest source set, Gradle looks for // Java sources only in the src/tests/java/ directory. setRoot("src/tests") ... } } } ...
ניהול ספריות ויחסי תלות
ב-Gradle יש מנגנון חזק לניהול יחסי התלות, בין שמדובר בספריות מרוחקות ובין שמדובר במודולים מקומיים של ספריות.
טירגוט גרסאות build ספציפיות באמצעות הגדרות של יחסי תלות
אם רוצים להגדיר תלות רק לקבוצת מקורות של וריאנט build ספציפי או לקבוצת מקורות לבדיקה ספציפית, צריך להשתמש באותיות רישיות בשם של הגדרת התלות ולהוסיף לו את השם של הווריאנט build או של קבוצת מקורות הבדיקה.
Groovy
android {...} // Creates Gradle dependency configurations to use in the dependencies block. configurations { // For variants that combine a product flavor and build type, you need to // intitialize a placeholder for its dependency configuration. freeDebugRuntimeOnly{} ... } dependencies { // Adds an implementation dependency only to the "free" product flavor. freeImplementation 'com.google.firebase:firebase-ads:21.5.1' // Adds a runtimeOnly dependency only to the "freeDebug" build variant. freeDebugRuntimeOnly fileTree(dir: 'libs', include: ['*.jar']) // Adds a remote binary dependency only for local tests. testImplementation 'junit:junit:4.12' // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.6.1' }
Kotlin
android {...} dependencies { // Use ""() notation for custom flavors and build types // Adds an implementation dependency only to the "free" product flavor. "freeImplementation"("com.google.firebase:firebase-ads:21.5.1") // Adds a runtimeOnly dependency only to the "freeDebug" build variant. "freeDebugRuntimeOnly"(fileTree("dir" to "libs", "include" to "*.jar")) // Adds a remote binary dependency only for local tests. testImplementation("junit:junit:4.12") // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation("com.android.support.test.espresso:espresso-core:3.6.1") }
יצירת גרסאות שונות של האפליקציה
אפשר להשתמש ב-Gradle ובפלאגין של Android כדי ליצור גרסאות שונות של האפליקציה מתוך מודול יחיד, על ידי הגדרת וריאנטים של גרסאות build.
הגדרת קודי גרסאות דינמיים
כברירת מחדל, כש-Gradle יוצר חבילות APK לפרויקט, לכל אחת מהן יש את אותם פרטי גרסה, כפי שצוינו בקובץ build.gradle
ברמת המודול.
חנות Google Play לא מאפשרת להעלות כמה קובצי APK של אותה אפליקציה עם אותם פרטי גרסה, לכן עליכם לוודא שלכל קובץ APK יש versionCode ייחודי משלו לפני ההעלאה לחנות Play.
אפשר לעשות זאת באמצעות לוגיקה מותאמת אישית ל-build שמקצה קוד גרסתה שונה לכל קובץ APK בזמן ה-build. לדוגמה, כשיוצרים קובצי APK נפרדים לכל ABI, המערכת נותנת להם גרסאות באופן אוטומטי באופן הבא:
Groovy
android { ... defaultConfig { ... versionCode 4 } splits { ... } } // Map for the version code that gives each ABI a value. ext.abiCodes = ['armeabi-v7a':1, mips:2, x86:3] // For per-density APKs, create a similar map like this: // ext.densityCodes = ['hdpi': 1, 'xhdpi': 2, 'xxhdpi': 3, 'xxxhdpi': 4] import com.android.build.OutputFile // For each APK output variant, override versionCode with a combination of // ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode // is equal to defaultConfig.versionCode. If you configure product flavors that // define their own versionCode, variant.versionCode uses that value instead. android.applicationVariants.all { variant -> // Assigns a different version code for each output APK // other than the universal APK. variant.outputs.each { output -> // Stores the value of ext.abiCodes that is associated with the ABI for this variant. def baseAbiVersionCode = // Determines the ABI for this variant and returns the mapped value. project.ext.abiCodes.get(output.getFilter(OutputFile.ABI)) // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes, // the following code does not override the version code for universal APKs. // However, because we want universal APKs to have the lowest version code, // this outcome is desirable. if (baseAbiVersionCode != null) { // Assigns the new version code to versionCodeOverride, which changes the version code // for only the output APK, not for the variant itself. Skipping this step simply // causes Gradle to use the value of variant.versionCode for the APK. output.versionCodeOverride = baseAbiVersionCode * 1000 + variant.versionCode } } }
Kotlin
android { ... defaultConfig { ... versionCode = 4 } splits { ... } } // Map for the version code that gives each ABI a value. val abiCodes = mapOf("armeabi-v7a" to 1, "mips" to 2, "x86" to 3) // For per-density APKs, create a similar map like this: // val densityCodes = mapOf("hdpi" to 1, "xhdpi" to 2, "xxhdpi" to 3, "xxxhdpi" to 4) import com.android.build.api.variant.FilterConfiguration.FilterType.* // For each APK output variant, override versionCode with a combination of // abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode // is equal to defaultConfig.versionCode. If you configure product flavors that // define their own versionCode, variant.versionCode uses that value instead. androidComponents { onVariants { variant -> // Assigns a different version code for each output APK // other than the universal APK. variant.outputs.forEach { output -> val name = output.filters.find { it.filterType == ABI }?.identifier // Stores the value of abiCodes that is associated with the ABI for this variant. val baseAbiCode = abiCodes[name] // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes, // the following code does not override the version code for universal APKs. // However, because we want universal APKs to have the lowest version code, // this outcome is desirable. if (baseAbiCode != null) { // Assigns the new version code to output.versionCode, which changes the version code // for only the output APK, not for the variant itself. output.versionCode.set(baseAbiCode * 1000 + (output.versionCode.get() ?: 0)) } } } }
שילוב של כמה גרסאות של מוצרים
במקרים מסוימים, יכול להיות שתרצו לשלב הגדרות אישיות מכמה גרסאות של המוצר. כדי לעשות זאת, הפלאגין של Android ל-Gradle מאפשר ליצור קבוצות של טעמי מוצרים, שנקראים מאפייני טעמים.
בדוגמת הקוד הבאה נעשה שימוש במאפיין
flavorDimensions
כדי ליצור מאפיין 'mode' של טעמים כדי לקבץ את טעמי המוצר 'full' ו-'demo', ומאפיין 'api' של טעמים כדי לקבץ את הגדרות הטעם של המוצרים לפי רמת ה-API. לאחר מכן, Gradle משלבת בין טעמי המוצרים מהמאפיין 'mode' לבין טעמי המוצרים מהמאפיין 'api'.
Groovy
android { ... buildTypes { debug {...} release {...} } // Specifies the flavor dimensions you want to use. The order in which you // list each dimension determines its priority, from highest to lowest, // when Gradle merges variant sources and configurations. You must assign // each product flavor you configure to one of the flavor dimensions. flavorDimensions "api", "mode" productFlavors { demo { // Assigns this product flavor to the "mode" flavor dimension. dimension "mode" ... } full { dimension "mode" ... } // Configurations in the "api" product flavors override those in "mode" // flavors and the defaultConfig block. Gradle determines the priority // between flavor dimensions based on the order in which they appear next // to the flavorDimensions property above--the first dimension has a higher // priority than the second, and so on. minApi24 { dimension "api" minSdkVersion '24' // To ensure the target device receives the version of the app with // the highest compatible API level, assign version codes in increasing // value with API level. To learn more about assigning version codes to // support app updates and uploading to Google Play, read Multiple APK Support versionCode 30000 + android.defaultConfig.versionCode versionNameSuffix "-minApi24" ... } minApi23 { dimension "api" minSdkVersion '23' versionCode 20000 + android.defaultConfig.versionCode versionNameSuffix "-minApi23" ... } minApi21 { dimension "api" minSdkVersion '21' versionCode 10000 + android.defaultConfig.versionCode versionNameSuffix "-minApi21" ... } } } ...
Kotlin
android { ... buildTypes { getByName("debug") {...} getByName("release") {...} } // Specifies the flavor dimensions you want to use. The order in which you // list each dimension determines its priority, from highest to lowest, // when Gradle merges variant sources and configurations. You must assign // each product flavor you configure to one of the flavor dimensions. flavorDimensions += listOf("api", "mode") productFlavors { create("demo") { // Assigns this product flavor to the "mode" flavor dimension. dimension = "mode" ... } create("full") { dimension = "mode" ... } // Configurations in the "api" product flavors override those in "mode" // flavors and the defaultConfig block. Gradle determines the priority // between flavor dimensions based on the order in which they appear next // to the flavorDimensions property above--the first dimension has a higher // priority than the second, and so on. create("minApi24") { dimension = "api" minSdkVersion(24) // To ensure the target device receives the version of the app with // the highest compatible API level, assign version codes in increasing // value with API level. To learn more about assigning version codes to // support app updates and uploading to Google Play, read Multiple APK Support versionCode = 30000 + android.defaultConfig.versionCode versionNameSuffix = "-minApi24" ... } create("minApi23") { dimension = "api" minSdkVersion(23) versionCode = 20000 + android.defaultConfig.versionCode versionNameSuffix = "-minApi23" ... } create("minApi21") { dimension = "api" minSdkVersion(21) versionCode = 10000 + android.defaultConfig.versionCode versionNameSuffix = "-minApi21" ... } } } ...
סינון וריאנטים
אתם יכולים לסנן וריאנטים של build שאתם לא רוצים באמצעות הבלוק
variantFilter
בקובץ build.gradle
של המודול. קוד לדוגמה שמורה ל-Gradle לא ליצור וריאנטים שמשלבים בין טעמי המוצר 'minApi21' ו-'demo':
Groovy
android { ... buildTypes {...} flavorDimensions "api", "mode" productFlavors { demo {...} full {...} minApi24 {...} minApi23 {...} minApi21 {...} } variantFilter { variant -> def names = variant.flavors*.name // To check for a certain build type, use variant.buildType.name == "<buildType>" if (names.contains("minApi21") && names.contains("demo")) { // Gradle ignores any variants that satisfy the conditions above. setIgnore(true) } } } ...
Kotlin
android { ... buildTypes {...} flavorDimensions "api", "mode" productFlavors { create("demo") {...} create("full") {...} create("minApi24") {...} create("minApi23") {...} create("minApi21") {...} } } androidComponents { beforeVariants { variantBuilder -> // To check for a certain build type, use variantBuilder.buildType == "<buildType>" if (variantBuilder.productFlavors.containsAll(listOf("api" to "minApi21", "mode" to "demo"))) { // Gradle ignores any variants that satisfy the conditions above. variantBuilder.enabled = false } } } ...
בדיקת האפליקציה
מידע נוסף על הפעלת בדיקות יחידה מקומיות ומשולבות זמין במאמר בדיקת האפליקציה.
הגדרת אפשרויות איתור שגיאות
אפשר להגדיר אפשרויות מסוימות של איתור שגיאות באמצעות הבלוק
lintOptions
בקובץ build.gradle
ברמת המודול. למידע נוסף על שימוש ב-Lint בפרויקט Android, תוכלו לקרוא את המאמר שיפור הקוד באמצעות Lint.
Groovy
android { ... lintOptions { // Turns off checks for the issue IDs you specify. disable 'TypographyFractions','TypographyQuotes' // Turns on checks for the issue IDs you specify. These checks are in // addition to the default lint checks. enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // To enable checks for only a subset of issue IDs and ignore all others, // list the issue IDs with the 'check' property instead. This property overrides // any issue IDs you enable or disable using the properties above. checkOnly 'NewApi', 'InlinedApi' // If set to true, turns off analysis progress reporting by lint. quiet true // if set to true (default), stops the build if errors are found. abortOnError false // if true, only report errors. ignoreWarnings true } } ...
Kotlin
android { ... lintOptions { // Turns off checks for the issue IDs you specify. disable("TypographyFractions") disable("TypographyQuotes") // Turns on checks for the issue IDs you specify. These checks are in // addition to the default lint checks. enable("RtlHardcoded") enable("RtlCompat") enable("RtlEnabled") // To enable checks for only a subset of issue IDs and ignore all others, // list the issue IDs with the 'check' property instead. This property overrides // any issue IDs you enable or disable using the properties above. checkOnly("NewApi", "InlinedApi") // If set to true, turns off analysis progress reporting by lint. quiet = true // if set to true (default), stops the build if errors are found. abortOnError = false // if true, only report errors. ignoreWarnings = true } } ...
הגדרת הגדרות המניפסט של המדידה
כש-Gradle יוצר את קובץ ה-APK לבדיקה, הוא יוצר באופן אוטומטי את הקובץ AndroidManifest.xml
ומגדיר אותו באמצעות הצומת <instrumentation>
. אפשר לשנות חלק מההגדרות של הצומת הזה על ידי יצירת קובץ מניפסט נוסף בקבוצת מקורות הבדיקה או על ידי הגדרת קובץ build.gradle
ברמת המודול, כפי שמתואר בדוגמת הקוד הבאה.
Groovy
android { ... // Each product flavor you configure can override properties in the // defaultConfig block. To learn more, go to Configure Product Flavors. defaultConfig { ... // Specifies the application ID for the test APK. testApplicationId "com.test.foo" // Specifies the fully-qualified class name of the test instrumentation runner. testInstrumentationRunner "android.test.InstrumentationTestRunner" // If set to 'true', enables the instrumentation class to start and stop profiling. // If set to false (default), profiling occurs the entire time the instrumentation // class is running. testHandleProfiling true // If set to 'true', indicates that the Android system should run the instrumentation // class as a functional test. The default value is 'false' testFunctionalTest true } } ...
Kotlin
android { ... // Each product flavor you configure can override properties in the // defaultConfig block. To learn more, go to Configure Product Flavors. defaultConfig { ... // Specifies the application ID for the test APK. testApplicationId = "com.test.foo" // Specifies the fully-qualified class name of the test instrumentation runner. testInstrumentationRunner = "android.test.InstrumentationTestRunner" // If set to 'true', enables the instrumentation class to start and stop profiling. // If set to false (default), profiling occurs the entire time the instrumentation // class is running. testHandleProfiling = true // If set to 'true', indicates that the Android system should run the instrumentation // class as a functional test. The default value is 'false' testFunctionalTest = true } } ...
שינוי סוג ה-build לבדיקה
כברירת מחדל, כל הבדיקות פועלות מול סוג ה-build לניפוי באגים. אפשר לשנות את זה לסוג build אחר באמצעות המאפיין testBuildType
בקובץ build.gradle
ברמת המודול. לדוגמה, אם רוצים להריץ את הבדיקות לגרסה של סוג ה-build 'staging', עורכים את הקובץ לפי קטע הקוד הבא.
Groovy
android { ... testBuildType "staging" }
Kotlin
android { ... testBuildType "staging" }
הגדרת אפשרויות הבדיקה ב-Gradle
כדי לציין אפשרויות שמשנות את האופן שבו Gradle מפעיל את כל הבדיקות, מגדירים את הבלוק
testOptions
בקובץ build.gradle
ברמת המודול.
Groovy
android { ... // Encapsulates options for running tests. testOptions { // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports // in the path_to_your_project/module_name/build/outputs/reports/ directory. // '$rootDir' sets the path relative to the root directory of the current project. reportDir "$rootDir/test-reports" // Changes the directory where Gradle saves test results. By default, Gradle saves test results // in the path_to_your_project/module_name/build/outputs/test-results/ directory. // '$rootDir' sets the path relative to the root directory of the current project. resultsDir "$rootDir/test-results" } }
Kotlin
android { ... // Encapsulates options for running tests. testOptions { // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports // in the path_to_your_project/module_name/build/outputs/reports/ directory. // '$rootDir' sets the path relative to the root directory of the current project. reportDir "$rootDir/test-reports" // Changes the directory where Gradle saves test results. By default, Gradle saves test results // in the path_to_your_project/module_name/build/outputs/test-results/ directory. // '$rootDir' sets the path relative to the root directory of the current project. resultsDir "$rootDir/test-results" } }
כדי לציין אפשרויות רק לבדיקות יחידה מקומיות, מגדירים את הבלוק
testOptions.unitTests
.
Groovy
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { // By default, local unit tests throw an exception any time the code you are testing tries to access // Android platform APIs (unless you mock Android dependencies yourself or with a testing // framework like Mockito). However, you can enable the following property so that the test // returns either null or zero when accessing platform APIs, rather than throwing an exception. returnDefaultValues true // Encapsulates options for controlling how Gradle executes local unit tests. For a list // of all the options you can specify, read Gradle's reference documentation. all { // Sets JVM argument(s) for the test JVM(s). jvmArgs '-XX:MaxPermSize=256m' // You can also check the task name to apply options to only the tests you specify. if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } } } } }
Kotlin
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { // By default, local unit tests throw an exception any time the code you are testing tries to access // Android platform APIs (unless you mock Android dependencies yourself or with a testing // framework like Mockito). However, you can enable the following property so that the test // returns either null or zero when accessing platform APIs, rather than throwing an exception. returnDefaultValues true // Encapsulates options for controlling how Gradle executes local unit tests. For a list // of all the options you can specify, read Gradle's reference documentation. all { // Sets JVM argument(s) for the test JVM(s). jvmArgs '-XX:MaxPermSize=256m' // You can also check the task name to apply options to only the tests you specify. if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } } } } }
אופטימיזציה של ה-build
בקטע הזה מפורטות כמה הגדרות שיעזרו לכם לזרז את ה-build המלא וה-build המצטבר. מידע נוסף זמין במאמר אופטימיזציה של מהירות ה-build.
צמצום הקוד
Android Studio משתמש ב-R8, שמשתמש בקובצי הכללים של ProGuard כדי לצמצם את הקוד. בפרויקטים חדשים, Android Studio משתמשת בקובץ הגדרות ברירת מחדל (proguard-android.txt
) מ-tools/proguard/folder
של Android SDK. כדי לצמצם את הקוד עוד יותר, אפשר לנסות את הקובץ proguard-android-optimize.txt
שנמצא באותו מיקום.
Groovy
android { buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } ... } ...
Kotlin
android { buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } ... } ...
כדי להוסיף כללים ספציפיים לכל וריאנט build, מגדירים מאפיין
proguardFiles
נוסף לכל גרסת build. לדוגמה, בדוגמה הבאה מתווסף הערך flavor2-rules.pro
ל-"flavor2". עכשיו גרסה המהדורה של flavor2 משתמשת בכל שלושת קובצי הכללים, כי גם אלה מבלוק המהדורה חלים.
Groovy
android { ... buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } productFlavors { flavor1 { ... } flavor2 { proguardFile 'flavor2-rules.pro' } } } ...
Kotlin
android { ... buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } productFlavors { flavor1 { ... } flavor2 { proguardFile 'flavor2-rules.pro' } } } ...
פרסום האפליקציה
מידע נוסף על פרסום האפליקציה ב-Google Play זמין במאמר פרסום האפליקציה.
חתום על האפליקציה שלך
ב-Android Studio יש דרך פשוטה להגדיר חתימה לגרסאות build לפריסה דרך ממשק המשתמש, אבל אפשר גם להגדיר את הבלוק
signingConfigs
באופן ידני בקובץ build.gradle
של המודול:
Groovy
android { ... defaultConfig { ... } // Encapsulates signing configurations. signingConfigs { // Creates a signing configuration called "release". release { // Specifies the path to your keystore file. storeFile file("my-release-key.jks") // Specifies the password for your keystore. storePassword "password" // Specifies the identifying name for your key. keyAlias "my-alias" // Specifies the password for your key. keyPassword "password" } } buildTypes { release { // Adds the "release" signing configuration to the release build type. signingConfig signingConfigs.release ... } } } ...
Kotlin
android { ... defaultConfig { ... } // Encapsulates signing configurations. signingConfigs { // Creates a signing configuration called "release". release { // Specifies the path to your keystore file. storeFile file("my-release-key.jks") // Specifies the password for your keystore. storePassword "password" // Specifies the identifying name for your key. keyAlias "my-alias" // Specifies the password for your key. keyPassword "password" } } buildTypes { release { // Adds the "release" signing configuration to the release build type. signingConfig signingConfigs.release ... } } } ...
הסרת פרטי החתימה הפרטיים מהפרויקט
כברירת מחדל, הגדרות החתימה מתועדות בטקסט פשוט בקובץ build.gradle
של המודול. אם אתם עובדים עם צוות או בפרויקט בקוד פתוח, תוכלו להעביר את המידע הרגיש הזה מקבצי ה-build באופן הבא.
- יוצרים קובץ בשם
keystore.properties
בתיקיית השורש של הפרויקט ומוסיפים את הפרטים הבאים:storePassword=myStorePassword keyPassword=myKeyPassword keyAlias=myKeyAlias storeFile=myStoreFileLocation
- בקובץ
build.gradle
, מעמיסים את הקובץkeystore.properties
באופן הבא (הפעולה הזו צריכה להתבצע לפני הבלוק android):Groovy
// Creates a variable called keystorePropertiesFile, and initializes it to the // keystore.properties file. def keystorePropertiesFile = rootProject.file("keystore.properties") // Initializes a new Properties() object called keystoreProperties. def keystoreProperties = new Properties() // Loads the keystore.properties file into the keystoreProperties object. keystoreProperties.load(new FileInputStream(keystorePropertiesFile)) android { ... } ...
Kotlin
// Creates a variable called keystorePropertiesFile, and initializes it to the // keystore.properties file. def keystorePropertiesFile = rootProject.file("keystore.properties") // Initializes a new Properties() object called keystoreProperties. def keystoreProperties = new Properties() // Loads the keystore.properties file into the keystoreProperties object. keystoreProperties.load(new FileInputStream(keystorePropertiesFile)) android { ... } ...
- מזינים את פרטי החתימה שמאוחסנים באובייקט
keystoreProperties
:Groovy
android { signingConfigs { config { keyAlias keystoreProperties['keyAlias'] keyPassword keystoreProperties['keyPassword'] storeFile file(keystoreProperties['storeFile']) storePassword keystoreProperties['storePassword'] } } ... } ...
Kotlin
android { signingConfigs { config { keyAlias keystoreProperties['keyAlias'] keyPassword keystoreProperties['keyPassword'] storeFile file(keystoreProperties['storeFile']) storePassword keystoreProperties['storePassword'] } } ... } ...
- לוחצים על סנכרון עכשיו בסרגל ההתראות.
מידע נוסף על חתימת אפליקציות זמין במאמר חתימה על האפליקציה.
פיתוח אפליקציות פשוט יותר
הטיפים הבאים יעזרו לכם לפתח אפליקציות ל-Android בקלות רבה יותר.
שיתוף שדות מותאמים אישית וערכים של משאבים עם הקוד של האפליקציה
בזמן ה-build, Gradle יוצר את המחלקה BuildConfig
כדי שקוד האפליקציה יוכל לבדוק מידע על ה-build הנוכחי. אפשר גם להוסיף שדות מותאמים אישית לכיתה BuildConfig
מקובץ התצורה של ה-build ב-Gradle באמצעות השיטה buildConfigField()
, ולגשת לערכים האלה בקוד של זמן הריצה של האפליקציה. באופן דומה, אפשר להוסיף ערכים של משאבי אפליקציה באמצעות resValue()
.
Groovy
android { ... buildTypes { release { // These values are defined only for the release build, which // is typically used for full builds and continuous builds. buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"") resValue("string", "build_time", "${minutesSinceEpoch}") ... } debug { // Use static values for incremental builds to ensure that // resource files and BuildConfig aren't rebuilt with each run. // If these rebuild dynamically, they can interfere with // Apply Changes as well as Gradle UP-TO-DATE checks. buildConfigField("String", "BUILD_TIME", "\"0\"") resValue("string", "build_time", "0") } } } ...
Kotlin
android { ... buildTypes { release { // These values are defined only for the release build, which // is typically used for full builds and continuous builds. buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"") resValue("string", "build_time", "${minutesSinceEpoch}") ... } debug { // Use static values for incremental builds to ensure that // resource files and BuildConfig aren't rebuilt with each run. // If these rebuild dynamically, they can interfere with // Apply Changes as well as Gradle UP-TO-DATE checks. buildConfigField("String", "BUILD_TIME", "\"0\"") resValue("string", "build_time", "0") } } } ...
בקוד האפליקציה, אפשר לגשת למאפיינים באופן הבא:
Kotlin
... Log.i(TAG, BuildConfig.BUILD_TIME) Log.i(TAG, getString(R.string.build_time))
Java
... Log.i(TAG, BuildConfig.BUILD_TIME); Log.i(TAG, getString(R.string.build_time));
שיתוף מאפיינים עם המניפסט
במקרים מסוימים, יכול להיות שתצטרכו להצהיר על אותו מאפיין גם במניפסט וגם בקוד (לדוגמה, כשמצהירים על רשויות ל-FileProvider
). במקום לעדכן את אותו מאפיין במספר מיקומים כדי לשקף שינוי, אפשר להגדיר מאפיין יחיד בקובץ build.gradle
של המודול כדי שהוא יהיה זמין גם למניפסט וגם לקוד, כפי שמתואר בדוגמה הבאה. למידע נוסף, אפשר לקרוא את המאמר החדרת משתני build למניפסט.
Groovy
android { // For settings specific to a product flavor, configure these properties // for each flavor in the productFlavors block. defaultConfig { // Creates a property for the FileProvider authority. def filesAuthorityValue = applicationId + ".files" // Creates a placeholder property to use in the manifest. manifestPlaceholders = [filesAuthority: filesAuthorityValue] // Adds a new field for the authority to the BuildConfig class. buildConfigField("String", "FILES_AUTHORITY", "\"${filesAuthorityValue}\"") } ... } ...
Kotlin
android { // For settings specific to a product flavor, configure these properties // for each flavor in the productFlavors block. defaultConfig { // Creates a property for the FileProvider authority. val filesAuthorityValue = applicationId + ".files" // Creates a placeholder property to use in the manifest. manifestPlaceholders["filesAuthority"] = filesAuthorityValue // Adds a new field for the authority to the BuildConfig class. buildConfigField("String", "FILES_AUTHORITY", "\"${filesAuthorityValue}\"") } ... } ...
במניפסט, ניגשים ל-placeholder באופן הבא:
<manifest> ... <application> ... <provider android:name="android.support.v4.content.FileProvider" android:authorities="${filesAuthority}" android:exported="false" android:grantUriPermissions="true"> ... </provider> </application> </manifest>
הגישה לשדה FILES_AUTHORITY
בקוד של האפליקציה נראית בערך כך:
Kotlin
... val contentUri: Uri = FileProvider.getUriForFile(context, BuildConfig.FILES_AUTHORITY, myFile)
Java
... Uri contentUri = FileProvider.getUriForFile(getContext(), BuildConfig.FILES_AUTHORITY, myFile);