Languages

Menu
Sites
Language
Unable to publish C# Tizen .NET Wearable TPK to Seller Portal

I am trying to publish my Tizen Wearable .NET app to the Samsung Seller portal.

I am using Visual Studio 2017, Tizen plugin up-to-date, and can run my app successfully in release mode on both emulator and real device (Gear Sport) using my author and distributor certificates. My app is targeting Tizen 4.0.

The Samsung Seller portal needs the release binary but doesn't give much instruction, so I assume to get this I'm rebuilding the solution in release mode with the certificate profile setup correctly. The result TPK file is in the bin/Release folder.

Inspecting the TPK binary archive I see all my built DLLs, resources, manifest, etc.

Once I upload this binary to the Samsung Seller portal and submit it for review, it fails the automated pre-review due to the following error:

[Defect] Application was built by x86 compiler. X86 means app run on Tizen emulator, not real target.

[Expected Result] Please configure Architecture to arm when you build app. Project properties -> C/C++ build -> Tizen settings and you can check architecture of your app filename.

e.g. org.example.app-1.0.0-arm.tpk e.g. org.exapmple.ap-1.0.0-x86.tpk

[Reference] In generally, Platform architecture automatically selected based on the test environment. If test device connected by USB, Tizen IDE selected arm architecture automatically but if emulator connected to sdb, Tizen IDE selected arm architecture automatically.

The instructions here are useless as I'm using Visual Studio and C# .NET, not Tizen Studio or C++.

Attached to the rejection is a file named gear_core_architecture.txt whose contents are simply:

Intel 80386[libSkiaSharp.so]

Is this problematic file? If I inspect the release binary TPK archive I find the libSkiaSharp.so file inside the bin/runtimes/linux-x86/native and bin/runtimes/tizen-armel/native folder. I am not using SkiaSharp in my app at all, but my nuget packages might be (Tizen.NET, Xamarin, etc.). Looking at the Tizen-CSharp samples project, the SkiaSharp project sample also includes these libraries in their TPK as well.

I have looked everywhere in Visual Studio and cannot change the platform type for any solution or project to arm. Right now it only builds for Any CPU, x86, or x64. I've added the C++ compilers for ARM and ARM64 to Visual Studio from the individual components but no change. Manually creating an ARM build configuration won't let me.

I have also posted this question on Stackoverflow here:

https://stackoverflow.com/questions/58150747/how-to-build-tizen-c-sharp-net-wearable-tpk-for-arm-platform-and-publish-to-sam

List

Responses

6 Replies
Tizen .NET

Hi,

Regarding rejection in "automated pre-review" phase, I have no idea because the file name of the generated tpk doesn't include x86 or arm for Tizen .NET apps.

Could you share Content ID of your application with us? With Content ID(CID), we can contact Galaxy Store team and check the reason for the rejection and get the guide. (You can also contact them ​and inquire about it. http://help.content.samsung.com/csseller)

About "libSkiaSharp.so " , I'm wondering which template you use for your wearable app and the version of Tizen extension(Visual Studio Tools for Tizen). 

FYI, the latest version of "visual studio tools for Tizen" extension is 2.6.0.0.

I think it shouldn't be included unless we intentionally add it.

If you don't mind sharing the project file of your app, please send it to tizen.net@samsung.com email account.

We can check it with more information.

Thanks.

 

 

 

 

Cord Rehn

Thank you for responding!!

The Content ID is 000004454662.

I am unsure which template I would have used for the Wearable project, but I followed the official Samsung Tizen guide 6 months or so ago to get started using the wizard.  My project is specifically for Wearable, not TV or anything else.  My TIzen for Visual Studio plugin version is 2.6.0.0, the latest version.  I do know the TPK file generated by Visual Studio does not have an x86 or arm suffix in the filename, it's just the package then version number.

Do I need to send my solution to that email, that seems pretty extreme for diagnosing the issue I would hope the content ID is good enough?  I would try reproducing the issue in a small sample project but the issue is in the publishing process and I don't want a sample binary published.  Very odd considering the binary created works on my physical device so I can't imagine it's a problem with my solution but the publish process analyzing my TPK inaccurately?  I suppose if I must I can send the solution but I'd rather avoid sending the code as it's closed-source and my own you see.

Tizen .NET

Hi,

I've inquired of the parson in charge about your issue with your Content ID.

I'll share it with you as soon as I get the answer.

About unintentional addition of library(libskiasharp.so), I requested the project file (xxx.csproj), not your whole source code.

As far as I know, there's no wearable app template to include skiasharp nuget package. Please check out your project file.

Anyway, we can wait for an answer from Galaxy Store team.

 

 

Tizen .NET

Hi,

Could you check if there is no dependency on Skiasharp indirectly in the package you refer to?

Thanks.

Tizen .NET

The current Galaxy Store's policy does not allow libraries for x86 to be included in app tpk.

You can temporarily solve this issue by adding RuntimeIdentifer in project file as follows:

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>tizen40</TargetFramework>
    <RuntimeIdentifier>tizen-armel</RuntimeIdentifier>
  </PropertyGroup>

We'll try to resolve the issue after internal discussion.

Thanks.

 

Cord Rehn

Excellent I tried your fix now and confirmed the TPK generated does not contain the linux-x86 runtime any more.  I am still seeing libSkiaSharp.so in the TPK but I suppose that's expected?

It looks like the package, assemblyref://Xamarin.FFImageLoading.Svg.Forms (2.4.11.982), is including SkiaSharp.  I am not using SVGs just yet so should be able to safely remove this package, but is this even a problem now assuming the project is now built for armel correctly?