Multiple application elements when integrating Transfuse into legacy app about transfuse

Can I give a hint to transfuse by adding a particular tag or something to the existing manifest and/or application elements?

[johncarl81]

That's one problem with not starting from scratch. Sometimes you need to resolve conflicts with your previous xml. You can add a hint, as you asked, by adding an attribute t:tag="+,n" to your <application> tag. Also, you may have to remove the second application tag added by Transfuse.

Let me know if that works for you.

It looks like that causes it to only keep the transfuse managed activities and to totally remove the legacy activities.

What does +,n mean? is there a list of these tags somewhere or a place in the code base I can get an idea of what I'm looking at?

The manifest that is generated is in the build/ hierarchy.. is that the one I would be manually modifying if we can't get this to work or should it be modifying the Manifest in place in src/main ?

[johncarl81]

That's strange. I just tried it myself with a gradle build with the following Manifest input:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<manifest package="org.gradletransfuse" android:versionCode="1" t:tag="+" xmlns:t="http://androidtransfuse.org"
          xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19"/>
    <application android:name="android.app.Application" t:tag="+,n">
        <activity android:name=".MainActivity2" />
    </application>
</manifest>

and I got the following output:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<manifest android:versionCode="1" package="org.gradletransfuse" t:tag="+" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:t="http://androidtransfuse.org">
    <uses-sdk android:targetSdkVersion="19" android:minSdkVersion="7"/>
    <application android:name="android.app.Application" t:tag="+,n">
        <activity android:name=".MainActivity" t:tag="+,n">
            <intent-filter t:tag="+">
                <action android:name="android.intent.action.MAIN" t:tag="+,n"/>
                <category android:name="android.intent.category.LAUNCHER" t:tag="+,n"/>
            </intent-filter>
        </activity>
        <activity android:name="org.gradletransfuse.MainActivity2"/>
    </application>
</manifest>

You can see MainActivity2 was preserved, (although the default package wasn't removed 😕 ). Is this how yours looks?

the +,n basically tells Transfuse that +: that tag is being managed by Transfuse, and n the name attribute is being managed. There is no end-user documentation around these because these tags are not supposed to be manually tweaked. They are defined, however, in the Manifest parsing JAXB code under org.androidtransfuse.model.manifest.

You should be modifying the AndroidManifest.xml in the src/main directory. By the way, did you setup your gradle build to find the AndroidManifest.xml properly as described here: #53?:

apt {
    arguments {
        androidManifestFile variant.processResources.manifestFile
    }
}

Huh... Something funky is going on, I do not see that behavior and I do have that apt argument set... gradle plugin 0.7.3 and apt 1.2 and gradle 1.9 with the latest snapshot of transfuse... does that match your config?

My manifest is not being changed in-place either it's changing the debug and release manifests under the build hierarchy only.

[johncarl81]

That is more or less the versions I am using. You can check out the example here: https://github.com/johncarl81/transfuse/tree/master/examples/gradle

Can you share your gradle build script?

When I toy with your sample project I do see the manifest in the build/ hierarchy is getting modified in a reasonable way. However, when I install it on the emulator after giving it an icon and a name, nothing shows up in the app list (even though it's there under settings->apps). Which is what happens when there is no "main" activity.

If I manually unzip the apk and look at the binary manifest file, I can see the string referencing my legacy Activity but not the transfuse managed activity... so it's like the binary manifest is being created before transfuse can manipulate it... and that is what ultimately gets into the APK.

I don't yet fully understand the gradle, apt, transfuse lifecycle, yet... but it seems like something is happening out of order here.

I see this in the log (./gradlew installDebug --info):

command: /Users/dan/dev/libs/android-sdk/build-tools/android-4.4/aapt package -f --no-crunch -I /Users/dan/dev/libs/android-sdk/platforms/android-19/android.jar -M /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/manifests/debug/AndroidManifest.xml -S /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/res/all/debug -A /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/assets/debug -m -J /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/source/r/debug -F /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/libs/GradleTransfuse-debug.ap_ --debug-mode --custom-package org.gradletransfuse

before I see this:

Compiling with JDK Java compiler API.
Note: AndroidManifest.xml file found: /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/manifests/debug/AndroidManifest.xml
Note: Transfuse took 1114ms to process
Note: AndroidManifest.xml file found: /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/manifests/debug/AndroidManifest.xml
Note: Transfuse took 37ms to process
Note: AndroidManifest.xml file found: /Users/dan/dev/projects/company/thirdparty/transfuse/examples/gradle/GradleTransfuse/build/manifests/debug/AndroidManifest.xml
Note: Transfuse took 40ms to process

Which seems strange to me... can you clarify what is happening for me?

[johncarl81]

It looks like the Gradle build with the androidManifestFile variant.processResources.manifestFile parameter is not allowing Transfuse to edit the AndroidManifest.xml in place. I reverted a bit this morning and was able to get it working by using the following Gradle setup:

android {
...
    sourceSets.main {
        manifest.srcFile 'AndroidManifest.xml'
    }
}

This requires you to move the AndroidManifest.xml into your root directory (/ rather than /src/main/)

Like here:
https://github.com/johncarl81/transfuse/blob/32b60724a11bb2cf894545288d651981096aae04/examples/gradle/GradleTransfuse/build.gradle

I'll need to look at this issue further, but this should work for the time being. Let me know if this works for you.

That is moving things along... I'll use this pattern for now. Fortunately we don't need multiple manifests right now so this should work for a while. Thanks for all your help!

[rehos]

It looks like the behaviour of the android tools changed. I think we can determine the manifest file location dynamically in the source folder with the following code:

apt {
    arguments {
        androidManifestFile "${project.projectDir.absolutePath}/${android.sourceSets[variant.mergedFlavor.name].manifest}"
    }
}

I didn't had the time yet to test a more complex project structure.

[johncarl81]

@rehos confirmed, this approach works as well.

[johncarl81]

@zump ok to close?

+1

Once I added some flavors to my build I hit some issues... seeing if I can figure them out.

This is way too complex and brittle for what needs to happen here... I am hardcoding the location of our manifest until such time as we need more than one.... then I'll cross this bridge again.

[johncarl81]

Fair enough. This brings up an idea.. How about an option to turn off manifest processing?

I think there are 3 interesting options here..

off - do nothing
rewrite - current behavior
log manifest - write the manifest the current behavior would have created to the log.

[johncarl81]

Good ideas. I would assume this is a command line / build option but this could also be a @TransfuseModule option.

[johncarl81]

Ok, just committed the manifest processor option 113428c

So, if you're having trouble with the manifest generation you can either log it or turn it off like so:

-AtransfuseManifestProcessing=log
-AtransfuseManifestProcessing=off

Hope that helps.