Play-games-plugin-for-unity: .meta Files are included in the gpgs-plugin-support-0.9.42 causing build failure.

[Baraphor]

gpgs-plugin-support-0.9.42/res/drawable-nodpi-v4/ic_launcher.png.meta: Error: The file name must end with .xml or .png
gpgs-plugin-support-0.9.42/res/values/values.xml.meta:1:1: Error: Content is not allowed in prolog.
gpgs-plugin-support-0.9.42/res/values-v11/values-v11.xml.meta:1:1: Error: Content is not allowed in prolog.
gpgs-plugin-support-0.9.42/res/values-v14/values-v14.xml.meta:1:1: Error: Content is not allowed in prolog.

I am able to work around this by manually deleting the .meta files in the aar files.

[claywilkinson]

What version of unity are using? Which build system did you select in Build Settings? I just tried with Unity.2017.1.2f1 with both internal and gradle and it worked OK.

[Baraphor]

Unity 2017.2.0f3, Building for Android with Gradle. Unity Cloud Build though.

If I remove the .meta files it will work fine, as far as I am aware the "res" folder can only contain certain file types from here: https://developer.android.com/guide/topics/resources/providing-resources.html

Maybe the recent version started enforcing file types, we did not have this issue before.

[kujo87]

I have this issue as well on Unity 2017.2.0p4 using Gradle locally. There are a bunch of meta files in the res folder it would seem. It is from the gpgs-plugin-support aar file that is pulled from Android Resolve if that helps. The one that comes with the plugin is clean.

[cnymose]

I also suddenly started running into this issue in Unity 2017.2.0p4 after a week of no problems at all.
It seems that during build, these .meta files are generated, and the builder expects no .meta extension and doesn't know what to do, even though the correct files are still located in the folders

[burkard]

I'm having the same issue, with Unity 2017.3.f3 and Google Play Games plugin 0.9.42 ...
The compiler gives me this error:

I tried deleting the ic_launcher.png file, and also deleting the build-cache, but the error comes over and over.

Hope someone find a solution...

[cnymose]

As far as I remember, all I had to do was go into the .aar file (or whatever the extension is, it should say in the log), with an archive application (WinRAR), and clear out all the meta files in that path.

[Baraphor]

Yes,

It is annoying though whenever you need to update the libraries. We ended up writing a tool during the pre build process that will check and delete if needed.

[andrelevi]

Dealing with this issue as well. On 2018.1.1f1 and 0.9.50.

As another temporary fix, using Unity's Internal build system instead of Gradle will avoid the .arr .meta file issues, allowing you to buiild.

[p0w1nd]

I'm having this issue with 2017.4.4f1 and 0.9.50. Just like @kujo87 said - I found .meta files inside com.google.games.gpgs-plugin-support-0.9.50.aar which is weird. I replaced that aar file with another one from my other project and it works.

Anyone know why the non-working aar file has .meta files inside? (I don't know much about Android/Graddle internals).

[Thaina]

As of 0.9.52 it still got this problem

C:\Users\Admin.gradlecachestransforms-1\files-1.1com.google.games.gpgs-plugin-support-0.9.52.aara43a6fe04cff91924afa5151fc959e21\res\drawable-nodpi-v4\ic_launcher.png.meta: Error: The file name must end with .xml or .png

[Thaina]

It seem like the build system of play service resolver for unity will try to create some of its own new .aar file to be included in android build. But then it create folder to be zipped into .aar inside unity project, which leads to unity creating .meta for those files. And the zipping process just include those .meta into .aar which is unsupported by android build tools

This should be avoidable by creating that tmp folder anywhere outside unity asset folder. Or just exclude .meta when zipping back

Currently now I just need to open some .aar that cause the build error to delete those .meta by myself. On windows it could be delete by winrar gui. On macos I do it by writing bash command line

aar=com.google.android.gms.play-services-ads-lite-17.0.0; unzip $aar".aar" -d $aar; cd $aar; rm "../"$aar".aar"; find . -type f -name '*.meta' -delete; zip -r "../"$aar".aar" *; cd ..; rm -rf ./$aar

[Baraphor]

It seem like the build system of play service resolver for unity will try to create some of its own new .aar file to be included in android build. But then it create folder to be zipped into .aar inside unity project, which leads to unity creating .meta for those files. And the zipping process just include those .meta into .aar which is unsupported by android build tools
```

Interesting, I never thought of that, I am going to check if this is still happening, if it is I guess I will file a bug report with the Play Services Resolver.

[Thaina]

@stewartmiles Sorry for bother you but would you have any comment on this case?

[stewartmiles]

Well it's a constant grind against changes in Unity and Android build tools. I've filed https://github.com/googlesamples/unity-jar-resolver/issues/169 to track this as I would assume this is not limited to the GPGS. Anyone have an idea when this started to fail? I would love for us to catch things like this before Unity releases leave beta and before Android SDKs are released.

[legas1]

Hi, in our case we were using Jar Resolver v1.2.62.0 and Unity 2017.3.1p2 when we encountered this problem. However according to previous comment the bug was present before we started using Gradle build system setting.

Since then we use hacky workaround, if someone is interested, here is the code:

```using UnityEngine;
using UnityEditor;
using System.IO;
using ICSharpCode.SharpZipLib.Zip;

public static class MetaFilesCleaner {

[MenuItem("Docebit/Meta files cleaner in AARs")]
public static void MetaFilesClean() {
    foreach (string file in Directory.GetFiles(Application.dataPath + Path.DirectorySeparatorChar + "Plugins" + Path.DirectorySeparatorChar + "Android", "*.aar")) {
        string tempDirectory = file.Replace(".aar", "");
        string tempDirectoryMetaFile = tempDirectory + ".meta";
        FastZip fastZip = new FastZip();

        // Explode AAR
        fastZip.ExtractZip(file, tempDirectory, null);
        File.Delete(file);

        DeleteMetaFilesInDirectory(tempDirectory);

        // Bring back AAR
        fastZip.CreateZip(file, tempDirectory, true, null, null);

        Directory.Delete(tempDirectory, true);
        if (File.Exists(tempDirectoryMetaFile)) {
            File.Delete(tempDirectoryMetaFile);
        }
    }

    Debug.Log("Cleaned AARs.");
}

static void DeleteMetaFilesInDirectory(string path) {
    foreach (string file in Directory.GetFiles(path)) {
        if (File.Exists(file) && file.Contains(".meta")) {
            File.Delete(file);
        }
    }

    foreach (string directory in Directory.GetDirectories(path)) {
        if (Directory.Exists(directory)) {
            DeleteMetaFilesInDirectory(directory);
        }
    }
}

}
```

Yes it can be improved, but we should focus on proper solution.
PS: the code requires SharpZipLib dll and put it in Plugins/Editor folder :)

EDIT: Fixed in newest jar resolver, this issue can be closed.