Synced with Android 4.4.3

[Niklas Therning]

Hi,

Earlier today I pushed an update which syncs the runtime class library with the latest Android release (4.4.3). The old runtime classes were based on a very old Android version (4.1.1). Apart from bug fixes this new Android version also comes with a few new features such as fork-join support and 64-bit support (as far as I can see at least). It should now be considerably easier to add 64-bit target support to RoboVM.

A few things worth noting after this upgrade:

If you use URLConnection objects using the http: or https: protocols you will have to add a

  <forceLinkClasses>

    <pattern>com.android.okhttp.HttpHandler</pattern> <!-- for http -->

    <pattern>com.android.okhttp.HttpsHandler</pattern> <!-- for https -->

  </forceLinkClasses>

section to your robovm.xml.

Also the JSSEProvider has been moved to another package. If you use security related stuff in your app and you previously force linked classes in org.apache.harmony.xnet.provider.jsse you should now force link classes in the com.android.org.conscrypt package instead.

Please let me know if you run into any problems after this update.

/Niklas

[Kirill Prazdnikov]

Hi, thanks for the update. 

Is it worth to merge with 4.4.4 at some point later ? 

[Niklas Therning]

Do you know what has changed in 4.4.4? Anything worth upgrading for?

On Mon, Jun 30, 2014 at 11:07 AM, Kirill Prazdnikov <pki...@gmail.com> wrote:

Hi, thanks for the update. 

Is it worth to merge with 4.4.4 at some point later ? 

--
You received this message because you are subscribed to the Google Groups "RoboVM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robovm+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mario Zechner]

Great stuff. If been trying to update libGDX to use 0.0.14, but i have trouble getting SSL/Https to work. Here's the fixed up imports: https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-iosrobovm/robovm.xml#L20

We have a little test that uses URLConnection internally to fetch an image from a URL over https (https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests/src/com/badlogic/gdx/tests/DownloadTest.java). This test now fails with an NPE. I tried getting the full stacktrace, but that info isn't available. Will investigate further.

[Mario Zechner]

Boiled it down to a simple app and played around with it a little: https://gist.github.com/badlogic/78b81f71183a2f46acf8

Hard to tell what's going on. Line 13 seems to throw an NPE without a stacktrace in case we try to get the input stream for a https resource. Works fine without ssl. Any pointers where i could look to resolve this?

[Niklas Therning]

The missing stack traces for NPEs (and also SOEs) have been fixed now: https://github.com/robovm/robovm/issues/381

And here's a robovm.xml file which will force link enough classes to make https work properly:

<config>

  <forceLinkClasses>

    <!-- For http: support in URLConnection -->

    <pattern>com.android.okhttp.HttpHandler</pattern>

    <!-- For https: support in URLConnection -->

    <pattern>com.android.okhttp.HttpsHandler</pattern>

    <!-- OpenSSL is preferred over BouncyCastle. This pulls in full OpenSSL support. -->

    <pattern>com.android.org.conscrypt.**</pattern>

    <!-- We still need KeyStore.BKS and CertPathValidator.PKIX from BouncyCastle -->

    <pattern>com.android.org.bouncycastle.jce.provider.BouncyCastleProvider</pattern>

    <pattern>com.android.org.bouncycastle.jcajce.provider.keystore.BC$Mappings</pattern>

    <pattern>com.android.org.bouncycastle.jcajce.provider.keystore.bc.BcKeyStoreSpi</pattern>

    <pattern>com.android.org.bouncycastle.jcajce.provider.keystore.bc.BcKeyStoreSpi$Std</pattern>

    <pattern>com.android.org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi</pattern>

    <!-- Use AndroidDigestFactoryOpenSSL as AndroidDigestFactory implementation -->

    <pattern>com.android.org.bouncycastle.crypto.digests.AndroidDigestFactoryOpenSSL</pattern>

  </forceLinkClasses>

</config>

[Mario Zechner]

Awesome, thanks! By what process did you figure out these force links?

[Niklas Therning]

Figuring out why the NPE was thrown was a bit hard. It was due to the default KeyStore (BKS) implementation not being linked in. Fixing the empty stack traces bug helped. :-)

After that I got pretty ok messages in the exceptions thrown complaining about MD5 not being available and similar. From then it's just a matter of finding which java.security.Provider implementation (see security.properties) provides the missing algorithm and force link it in. Many algorithms are provided by many of the providers and as you can see in security.properties the OpenSSLProvider is the provider with the highest priority so I figured that we might as well pull in everything in OpenSSL and then just enough from BouncyCastle.

[Niklas Therning]

Should add that you need to go through the code of each provider to figure out what it provides. This is rather tedious. It should be possible to auto-generate a table of providers, algorithms and implementing classes which would help quite a lot.