You don't put it in your strings file! The idea is you make a copy of your project for each carrier, and use an XSLT script to make changes
This makes sense if each carrier's files are mostly the same. If you can separate the files into files that have stuff that is the same for each carrier, that would be simpler. That will generally be possible with string files. I use this technique for layout and manifest files, which can't be split up, and only need a few differences between versions. An alternative to XSLT if the files are mostly different is to have your build script copy the right file for the version you are building. But if it is possible to build a single .apk for all carriers, that will be a lot easier build, test, and release. It will be bigger, which could sometimes be a problem, especially for a small app with a lot of graphics being customized. But definitely look at one app for all as the preferred approach. If you use this technique, I recommend making a copy of your project in your build script rather than modifying it in place. It is more robust, and avoids accidentally checking in a modified copy. My build scripts alway first tag in subversion, and then use that revision number as the version number. I then export from that tag for each version I am building, run the XSLT scripts to make any changes, build each version, and publish. By the way, if you are not using a revision system like subversion, you definitely should be. Even fot a single-person project. As for using ant to build android apps--I recommend that ALL production builds be built with ant. The basic setup is with the android command in the SDK. Please refer to the SDK documentation for details. I'm typing this on my iPhone, so I won't try to locate the link for you but you should be able to locate it. On Oct 27, 2:04 am, "Ganesh Kumar R - ." <[email protected]> wrote: > Hi ., > How can i do this XSL (<xsl:when/> <xsl:otherwise/>) in android string.xml > ? > > Any file or import is required to this da ? Its showing error for me .., > > tnx, > ganesh r > > > > On Wed, Oct 27, 2010 at 12:15 PM, Bob Kerns <[email protected]> wrote: > > Yes, and XSLT can be easily invoked from an ant script. > > > As a sample, here's a script that removes an Admob view from a layout: > > > <?xml version="1.0" encoding="UTF-8"?> > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > > version="1.0" > > xmlns:android="http://schemas.android.com/apk/res/android" > > > <!-- Any parameters you may need to pass to your script should be > > declared like this. --> > > <xsl:param name="BUILDTYPE"/> > > <!-- Rules for anything you may want to modify from the input --> > > <xsl:template match="com.admob.android.ads.AdView"> > > <xsl:choose> > > <xsl:when test="$BUILDTYPE = 'PRO'"> > > <xsl:comment>An innocuous empty replacement for the > > ad.</xsl:comment> > > <RelativeLayout > > android:id="@+id/ad" > > android:layout_width="wrap_content" > > android:layout_height="wrap_content" > > android:background="@color/labelBackground" > > /> > > </xsl:when> > > <xsl:otherwise> > > <!-- Otherwise, just invoke whatever rules would > > otherwise run, > > - normally the default rule below. --> > > <xsl:copy> > > <xsl:apply-templates select="@*|node()"/> > > </xsl:copy> > > </xsl:otherwise> > > </xsl:choose> > > </xsl:template> > > > <!-- Identity transform by default: everything else goes through > > this rule. > > - You will always need this. --> > > <xsl:template match="@*|node()"> > > <xsl:copy> > > <xsl:apply-templates select="@*|node()"/> > > </xsl:copy> > > </xsl:template> > > </xsl:stylesheet> > > > And an ant task to invoke it: > > > <xslt in='${loc.project}/AndroidManifest.xml' > > out='${loc.project.build.PRO<http://loc.project.build.pro/> > > }/AndroidManifest.xml' > > style='configureManifest.xsl' > > force='true'> > > <param name='BUILDTYPE' expression="PRO"/> > > </xslt> > > > On Oct 26, 7:06 pm, Frank Weiss <[email protected]> wrote: > > > Although I'm not sure I understand your problem completely, I can offer > > > another solution: XSLT. Using Xalan's multiple output documents make this > > > relatively easy. > > > > Are you thinking of creating an .apk for each carrier from the same code > > > base? That's another can of worms. However, perhaps using ADT library > > > project you can share the common behavioral code and each .apk project > > only > > > needs to provide the carrier-specifc data and resources. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en

