Android not compiling with assembly stripping on (version 1.6.2)

[SeriouslySam]

We updated our Parse to use the latest version, and the Android build is not working anymore. It fails at assembly stripper with the following error about missing iOS library. Which is very curious as it's making Android build. iOS building works
With stripping off, it compiles on android also, but this is not an option for us.

UnityException: Failed assemblies stripper: /Applications/Unity/Unity.app/Contents/Frameworks/Mono/bin/mono "/Applications/Unity/Unity.app/Contents/Frameworks/Tools/UnusedByteCodeStripper/UnusedBytecodeStripper.exe" -l none -c link -a "Assembly-CSharp-firstpass.dll" -a "Assembly-CSharp.dll" -out output -x "/Applications/Unity/Unity.app/Contents/Frameworks/Tools/UnusedByteCodeStripper/link.xml" -d "Temp/StagingArea/Data/Managed" -x "/Applications/Unity/Unity.app/Contents/Frameworks/Tools/UnusedByteCodeStripper/native_link.xml" -x "/Users/removed/perforce/removed/Assets/link.xml" -x "tmplink.xml" current dir : Temp/StagingArea/Data/Managed
 result file exists: False. Timed out: False

stdout:

stderr:

Unhandled Exception: Mono.Linker.ResolutionException: Can not resolve reference: System.Int32 UnityEngine.iOS.NotificationServices::get_localNotificationCount()
  at Mono.Linker.Steps.MarkStep.MarkMethod (Mono.Cecil.MethodReference reference, System.Object markedby) [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.MarkInstruction (Mono.Cecil.Cil.Instruction instruction, Mono.Cecil.MethodDefinition markedby) [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.MarkMethodBody (Mono.Cecil.Cil.MethodBody body) [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.ProcessQueue () [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.Process () [0x00000] in <filename unknown>:0 
  at Mono.Linker.Steps.MarkStep.Process (Mono.Linker.LinkContext context) [0x00000] in <filename unknown>:0 
  at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00000] in <filename unknown>:0 
  at UnusedBytecodeStripper.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

[richardjrossiii]

Thanks for the report. This seems related to our handling of push notifications.

Because UnityEngine.iOS.NotificationServices doesn't actually exist on android, I'm guessing that the assembly stripper doesn't like that, even though it works at runtime.

Note that changing our SDK to use reflection for the push notification APIs will not work, as IL2CPP does not generate reflection stubs for properties.

I'm not sure we as an SDK can provide a workaround, as assembly stripping is not a workflow we support, but feel free to fork/compile your own version of the SDK without push notification support.

[andsee]

Are there any solutions to this? I'm now stuck as to how to use Parse within Unity3D on Android. I've updated to the latest 1.7 and suffer the same issue it won't build with stripping enabled which is a requirement for the app.

I'm not using the notifications, so perhaps the notification side of the SDK could be split int a separate dll?

Or perhaps the sdk needs to be split into two, one for iOS and another for Android. Surely Android should not be trying to link in iOS functions.

[richardjrossiii]

@andsee we have no plans to split the SDK for unity into multiple platforms at this time (it would make deploying our SDK via the Unity Asset Store as we do right now a nightmare), nor do we have plans to split out the notifications portion of the SDK.

My recommendation would be to clone the source code, take out the parts related to notifications (essentially everything related to ParsePush) and recompile the DLL yourself.

I would also consider filing a bug with the Unity team to see if there's anything they can do on their end to support assembly stripping with a cross-platform binary.

[andsee]

Doesn't this issue make the unity android sdk and therefore the unity sdk if you're interested in multi-platform development pointless? You just end up with a nasty surprise when you port to android after iOS that the solution you have doesn't work.

There must be another way around this. I've used over 20 other sdks (which target multiple platforms) within unity without such issues.

It's really gutting as I was loving the Parse solution.

If it's a specific issue with Unity hasn't Parse filled a bug already?

[richardjrossiii]

@andsee You should still be able to compile with assembly stripping off (yes, that does increase application size), and that's our current recommended workaround for this issue.

And actually, the real issue here comes down to an IL2CPP issue. We used to be able to reference the notification libraries by class name using reflection, but IL2CPP stopped generating property info as of version 5.0 for bulit-in libraries, which guts our ability to do this. We did file a bug on that issue, but have not heard back as of right now.

[andsee]

I'm wondering what it is in the parse sdk that requires the additions to the link.xml file, does this stop Unity from stripping the iOS calls away?

Perhaps there's some class that needs to be linked in part which I could call a function on to force the link instead of forcing everything to remain. I hadn't come across link.xml until this SDK.

So some Unity side c# init function that ensures whatever's needed in the parse dll is linked instead of the link.xml approach? I apologies I haven't had the time to read through the sdk to understand the issues and reasons behind link.xml.

[richardjrossiii]

@andsee So the reasons, IIRC for link.xml come down to IL2CPP not allowing construction of generic types that aren't explicitly in the binary.

This means that if we were to say, for example, parse a Dictionary<string, List<ParseObject>> from our server, it would crash with IL2CPP turned on without the link.xml because that specific dictionary type with those type arguments doesn't exist.

Most of the dictionary types we require are in PlatformHooks.Unity.cs, and could be moved into an initializer such as that. YMMV, I have not tested any of that.

[andsee]

Does that mean for Android (not using IL2CPP) I don't need link.xml? Or have the changes made to support IL2CPP on iOS mean't that it is still needed for Android?

Many thanks for your responses by the way, I'm just trying to weigh up the quickest possible solution to attempt (ideally with stripping) as typically deadlines are tight.

[richardjrossiii]

@andsee I'm not 100% sure. I personally have not done much testing with android and unity -- it's never been a platform that has gotten many bug reports.

You could try it out and report it back, as that would probably be quicker than me trying to set up an environment to mirror yours.

Good luck, and let me know how I can help you further.

[richardjrossiii]

This should be fixed as of #169, and will be fixed in the 1.8.0 release.

[jamesbigbit]

Hi

Could you tell me how I get the version with this fix or when 1.8.0 will be out. The SDK download page is still showing 1.7.0 for Unity :-(

Regards

James