Re gard my topic problem I have some basic questions about PNACL
Does PNACL is supported by all samsung SmartTV?
2.If I use pepper 31 will my application work on older TV's?
And now the main problem
I've compiled application in C (basic helloworld from SDK 5.1 + some additional code of mine), for x86 architecture and it works both in emulator and chrome.
Then I recompiled it for Samsung Smart TV (arm) (I have 2013 series).
Aplication starts on TV, but PNACL module dont dispalay any result, the js onload callback of div containing module is called but nothing else.
Does my tv support PNACL?
2013 and 2014 models support PNACL.
2013 models: only support up to pepper29
2014 models: only support up to pepper33.
I hope this information help you.
As you have the 2013 series, you will need an older version of the pepper SDK (31 wont work).
In this link you can download the pepper 25 SDK
(for windows). Otherwise, you will have to get the SDK source code from Git and rebuild it. The native_client_sdk is part of the chromium project and can be found here.
You can get the older releases of nacl here http://gsdview.appspot.com/nativeclient-mirror/nacl/nacl_sdk/.
Related
I have a Unity project that I'm switching from APKs to AABs (app bundles). Previously, when I was building it as an APK, the Google Play Console told me the APK was 64-bit compliant.
Now that I'm building an aab, I'm getting the warning:
This release is not compliant with the Google Play 64-bit requirement.
The following APKs or App Bundles are available to 64-bit devices, but
they only have 32-bit native code
I have both ARM7 and ARM64 architectures set.
I am excluding x86.
When I open the .aab in an archive viewer, the lib folder has all of
the .so's for both arm64-v8a and armabi-v7a.
I'm using IL2CPP, .NET 4.x
I'm using Unity 2018.3.7f1
My ndk version is 16b
My
Android Studio is up to 3.4.2 and gradle is 3.2
A lot of similar threads here talk about following the "Learn more" links, which I've done. I had already done all of the work to get my app 64-bit compliant before switching to app bundles.
Other threads talk about Android Studio solutions, which I can't use because my automated build process involves building with Unity from command line, so it has to be Unity configurations or bust.
My expectation was the app bundles were supposed to be the hot new way to let Google build better APKs for you, but it seems like it's getting confused on whether or not aabs are actually 64-bit compliant, which seems to defeat the whole purpose.
Is this a Unity problem, does Google have an error in their system with regards to app bundles, or is there some other step I'm missing?
For those who have this problem since yesterday (August 19, 2019):
In Player Settings > Other Settings you must now uncheck the x86 box (It is for the 32-bit Intel architecture).
You will now only have the following warning:
The device types on which your application can be installed will be more restricted.
But, in my case, it drops from 12392 devices to 12385 devices.
Here is the opinion of a Unity member on the issue:
x86 is used by less than 0.4% of all Android devices, so it shouldn't have any real impact.
x86 target will be removed completely in Unity 2019.3.
It looks that there was a bug in the Play Console where this message was displayed even when the AAB was compliant. This should have been fixed last Friday afternoon.
Try again now.
Went to build Holoworld.
Unity3D Compiler not finding UnityEngine.VR.WSA.Input
Running Unity 5.2, now upgrading to 5.3.3f1. (Personal edition)
Installed: Windows 10 SDK, Visual Studio 2015 Update 1
Any ideas?
So this is just a tease?
I think UnityEngine.VR.WSA.Input will be part of the HoloLens SDK, which is not available yet.
You need a special version of Unity for Hololens. It is already public, and it is based on the 5.4.0b10 beta version but it is not the same, so go to the proper page to download it: http://unity3d.com/es/pages/windows/hololens#download
I've developed an Android app which has replaced two previous systems written in J2ME. My boss has the old source code and needs it compiling for Samsung tocco phones. Which sdk/jar file do i need in Eclipse to make the source code compile?
I've had a look on the samsung web site but can't seem to find anything. Also it's not clear which operating system the Tocco phones use.
thanks in advance Matt
You may try installing Samsung SDK 1.2.2 for the Java ME platform:
http://developer.samsung.com/java/tools-sdks/New-Samsung-Java-SDK-1-2-2-release-28th-October-2010
And then taking the steps on how to create a Hello world with it:
http://developer.samsung.com/java/tools-sdks/Developing-HelloWorld-MIDlet-using-Samsung-SDK
I'm using a MacBook Air with bootcamp and Windows 7 Professional installed.
When trying to to launch Samsung TV Apps SDK(IDE) 3.5.2 Windows crashes after few minutes with a bad blue page.
It looks like Samsung TV SDK attempts to write something to my Mac HD and fails operations.
I would like to know if you have the same issue and your work around.
After digging the problem I found out a solution:
I renamed the file
C:\windows\system32\drivers\AppleMNT.sys
to
C:\windows\system32\drivers\AppleMNT.sys.bak
This resolved the issue in my case,
I had also to install “vcredist_x86.exe” from “Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update” as it is also required in SDK 3.5.2
If you have other solutions please let me know.
I have installed android tools and eclipse successfully (making the hello World and hello widget examples) and have run these successfully on the Xperia X10 add-on that I downloaded from the developer site of SE.
However, my phone is running the updated Android 2.1, and any apps that I make will either have to run on 1.6, or will not be able to be tested on the Xperia X10 during development without moving it to my physical phone.
I have contacted Sony and they told me there is no add-on with 2.1 on it. And that is all they would say.
My Question:
Is there anyone out there who has developed for this phone, who knows what to do? Do I somehow run the SE update tool on the virtual phone to upgrade the OS of the image? Or am I missing something much more obvious?
As of April 2011, this is (an estimate of) Android usage share:
That's 3.5% for Android 1.6 and 2.7% for Android 1.5. As time goes by, those percentages will only decrease.
Just develop for 2.1.
Why do you prefer to use the emulator, anyway? Most Android devs (myself included) have found that the emulator is painfully slow, and it's just plain easier to plug in a real phone and test on that.
You can use the adb for getting your phone in debug mode.
Or you can just install your APKs via OTA or via USB in your physical phone.
Or you could just develop on 2.1 knowing that almost everything will work. I don't get the problem, really.