By exporting it as a string resource, you gain the flexibility to use it either as a resource or as a Java string. The problem is, there is no associated XML string, so using it in layouts, menus, preferences, and other strings is not straightforward. There is another approach that recommends putting these fields in BuildConfig, which makes it available to your code as a generated Java source file, BuildConfig.java. module/app.gradle: android res/values/strings.xml: Feedback about App %1$s Hello! Send feedback Why not BuildConfig? The versionName is a straightforward string concatenation of the three components. Then have Gradle compute the versionCode from these three components as a place-value-based number. module/app.gradle: def versionMajor = 2 def versionMinor = 4 def versionPatch = 1 Compute values for versionCode and versionName. This is the one place you’d update the numbers for every version you release. Start off with defining individual components of the version number-major version, minor version and patch level-as separate Gradle variables. Define individual components of the version number. Here’s how you can specify everything in exactly one place and use it everywhere needed. An app’s versionName is usually shown within the app in the About screen, and in other places, such as when sending a bug report. Gradle, which is now Android Studio’s default and recommended build system, can help you automate many tasks that other developers might be doing manually.Īs you know, every Android app must declare an app’s versionCode (a monotonically increasing integer for each version of the app), and versionName (a text description which can really be anything, but is usually a human-readable version string of the form x.y.z (major version, minor version, patch level). Update: I posted a new article which uses the setup from this article to inform your users whenever an app is updated with new features.
0 kommentar(er)
