Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>At the company I work for, we pretty much use the approach given by Eugen to automate the build process of apps that e.g. should simply be branded differently by exchanging certain assets, styles, strings and configurations. We tend to set up the project and build process as follows:</p> <ol> <li>Create the Android project and set it up such that it works for a specific branding. This will make sure that you can still build and run from Eclipse. Assuming that the codebase does not change between differently branded releases, that should be fine.</li> <li>Create an ant build configuration that: <ol> <li>copies any files that are going to be changed to a backup directory</li> <li>modifies the project files according to a configuration file (see below)</li> <li>compiles the project sources and signs it with a release key (if making a release build)</li> <li>copies back the files from step 1, overwriting any changes and returning the project to its original state</li> </ol></li> <li>Create configuration files for every 'branding', or language specific release in your scenario.</li> </ol> <p>Basically these steps will allow you to create branded/partner/language specific builds by simply providing the appropriate configuration with the ant build command. In our case it looks somewhat like this:</p> <pre><code>ant partner-release -Dpartner=stackoverflow </code></pre> <p>where 'stackoverflow' will point to a configuration with the same name. In our case these configuration files are small xml files that contain all the parameters that are to be replaced for that specific build. It could contain strings, but might as well point to other files (e.g. logo images) that should be copied into the assets/resources. For example:</p> <pre><code>&lt;config&gt; &lt;version_name&gt;1.00&lt;/version_name&gt; &lt;version_code&gt;1&lt;/version_code&gt; ... &lt;/config&gt; </code></pre> <p>Some more pointers:</p> <ul> <li>We use <code>xmltask</code> to modify any xml files in the project; e.g. the manifest and resources.</li> <li>Since the aforementioned task is really easy to use, our build configuration files are also set up as xml files, as illustrated above. It's quite human readable and easy and straightforward to change.</li> <li>You can also use <a href="http://ant.apache.org/manual/Tasks/replace.html" rel="nofollow"><code>replace</code></a> and <a href="http://ant.apache.org/manual/Tasks/replaceregexp.html" rel="nofollow"><code>ReplaceRegExp</code></a> tasks to change configuration-dependent variables in almost any file. The latter can be especially convenient to make build-time changes to source code.</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload