[maven-android-developers] Separate mainfest package and actual source code package name?

[Fredrik Jonson]

Hi all,

I have developed an application that I want to publish with only minor
changes under several different package names on android market. It sounds
like the 'apksources' solution[0] should solve that problem, but my build
fails because R does not exist when the manifest package name does not match
the application's actual class package.

Is there any way to not use the manifest package attribute as the class
hierarchy package name for the generation and overlaying of the R class?

Or maybe I can specify a different androidManifestFile:s. One with the class
package name equal to the manifest package name for the
android:generate-sources and android:dex goals, and a separate one where the
manifest package name is changed for the android:apk goal? Is that possible?

[0] http://code.google.com/p/maven-android-plugin/wiki/ApkSourcesDependency

--
Fredrik Jonson

--
You received this message because you are subscribed to the Google Groups "Maven Android Developers" group.
To post to this group, send email to maven-androi...@googlegroups.com.
To unsubscribe from this group, send email to maven-android-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maven-android-developers?hl=en.

[Manfred Moser (simpligility)]

You could have the source project just not contain a manifest and have
each module that reuses that package contain its own manifest and
whatever customizations needed..

manfred

[Fredrik Jonson]

On 2010-05-19 at 13:48, man...@mosabuam.com wrote:

> You could have the source project just not contain a manifest and have
> each module that reuses that package contain its own manifest and
> whatever customizations needed.

Thanks for your response,

I actually ended up solving it with a specific manifest file for the apk
goal.

In the example below I use the class based package name in the manifest
package attribute for in the AndroidManifest.xml in the directrory
src/main/android/build. And then for the apk goal execution I specify the
android market package name in the AndroidManifest.xml in the
src/main/android/package directory.

I haven't yet uploaded the apps to android market but as far as I can tell
of the resulting apk archives it seems to work. I hope this is as intended
and not just some bug^H^H^Hfeature I happened to stumble into. ;)

<plugin>
<groupId>com.jayway.maven.plugins.android.generation2</groupId>
<artifactId>maven-android-plugin</artifactId>
<version>2.3.3</version>
<configuration>
<!-- actual class package name in this manifest -->
<androidManifestFile>
src/main/android/build/AndroidManifest.xml
</androidManifestFile>
<sdk>
<path>${env.ANDROID_HOME}</path>
<platform>1.6</platform>
</sdk>
<deleteConflictingFiles>true</deleteConflictingFiles>
</configuration>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>apk</goal>
</goals>
<configuration>
<!-- android market package name in this manifest -->
<androidManifestFile>
src/main/android/package/AndroidManifest.xml
</androidManifestFile>
</configuration>
</execution>
</executions>
</plugin>

[Malachi de Ælfweald]

I think I am missing something.  Why is there a mismatch in package names?


Malachi de Ælfweald
http://www.google.com/profiles/malachid

[Manfred Moser]

Cool. Btw. you do not need to specify the path like you did anymore. This
is the automatic default..

manfred

[Fredrik Jonson]

On 2010-05-20 at 6:18, mala...@gmail.com wrote:

> I think I am missing something. Why is there a mismatch in package names?

For marketing reasons. Say you write an app that keep track of opening hours
for shops. Now you want to make it available for several competing shops
using different names in android market. The owners of shop A do not want
its customers to see the opening hours of shop B and vice versa. So your
code is entirely generic, all that differs is a logotype for shop A and B
and the opening hours of course. And neither shop wants their customers to
(easily) tell that you developed the app either.

Now the source code is developed using package com.example.foo, hence for
the generate-sources (and dex?) goal the manifest package name still needs
to be com.example.foo. But when you publish the apps on android market the
manifest package name is used to identify the application for install links,
and on androlib.com it is visible to the user, so in the apk file the
manifest package name for shop A's app needs to be com.A.app and the
manifest package name for B's app com.B.app. Thats why.

[Manfred Moser]

> On 2010-05-20 at 6:18, mala...@gmail.com wrote:
>
>> I think I am missing something. Why is there a mismatch in package
>> names?
>
> For marketing reasons. Say you write an app that keep track of opening
> hours
> for shops. Now you want to make it available for several competing shops
> using different names in android market. The owners of shop A do not want
> its customers to see the opening hours of shop B and vice versa. So your
> code is entirely generic, all that differs is a logotype for shop A and B
> and the opening hours of course. And neither shop wants their customers to
> (easily) tell that you developed the app either.
>
> Now the source code is developed using package com.example.foo, hence for
> the generate-sources (and dex?) goal the manifest package name still needs
> to be com.example.foo. But when you publish the apps on android market the
> manifest package name is used to identify the application for install
> links,
> and on androlib.com it is visible to the user, so in the apk file the
> manifest package name for shop A's app needs to be com.A.app and the
> manifest package name for B's app com.B.app. Thats why.

Very nice... makes sense ..

[Malachi de Ælfweald]

Thanks! That's great information!

Malachi de Ælfweald
http://www.google.com/profiles/malachid

[rofl harrison]

I have had some email correspondence on this matter with Frerik and he
recommended I post our findings here!

Basically using the build plan above works for debug signing, however
when you try to sign for a release (e.g. using a proper keystore + the
jarsigner plugin) the apk won't install because of a
INSTALL_PARSE_FAILED_NO_CERTIFICATES error. Some quick research
suggests this is because the "build" manifest is being signed, then
replaced with the "package" manifest, which is unsigned. This process
is equivalent to editing the manifest in the apk after signing, i.e.
the installer thinks the file been tampered with

Quick work around is to add <sign><debug>false</debug></sign> to the
configuration/s of the plugin and sign the apk later with the
jarsigner in cli.
I expect this is fixable by changing the order of of the signing in my
pom, once I get some time to investigate it more I will post back with
results.

Thanks,
Sam

On May 21, 9:05 am, Malachi de Ælfweald <malac...@gmail.com> wrote:
> Thanks! That's great information!
>

> Malachi de Ælfwealdhttp://www.google.com/profiles/malachid
>
>
>
> On Thu, May 20, 2010 at 2:50 PM, Fredrik Jonson <fred...@jonson.org> wrote:

> > maven-android-deve...@googlegroups.com<maven-android-developers%2Bunsu...@googlegroups.com>
> > .