Few cents about my commits

iOS13 PostFix #1: Generic class arguments and @Block parameters


iOS13 bindings are complete but CocoaTouch related issues keep arriving, part of them about compiler not able to compile one or other class.
Most of these issues can be detected just by compiling entire CocoaTouch library as simple smock test to find out outstanding issues. This can be done by force linking its class path with template like this:


This post start series of fixes discovered during compilation of CocoaTouch library.

PostFix #1: Generic class arguments and @Block parameters

Other postfixes:

  • /to be added/

fix414: run/debug on ios13 device


History: errors when deploying to ios13 #414
Fix: PR416

Root case

libmobiledevice when locking services has to perform SSL handshake if required.
in iOS13 debugerserver started requiring this as well by including EnableServiceSSL in response:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

The weird thing is that after SSL handshake debug server service switches back to plain text communication over same underlayer socket. There was a try-fix in libmobiledevice to close SSL connection but it didn’t work. Root case of it is that it was trying close SSL connection by calling SSL_shutdown which sends close_notify shutdown to underlaying socket. But debugserver expects clear text GDP protocol communication and close_notify aren’t expected which causes gdp protocol error.
This issue was also discussed on libimobiledevice repo: issue789

The fix

iOS 13 bindings


iOS 13

bindings have arrived as PR406.
iOS13 introduces bunch of new frameworks:

  • ImageCaptureCore
  • VisionKit
  • SoundAnalysis
  • QuickLookThumbnailing
  • PencilKit
  • MetricKit
  • CryptoTokenKit
  • CoreHaptics
  • BackgroundTasks
  • LinkPresentaion

Beside new ones also missing in previous binding cycle frameworks were added:

  • (new from ios 10) Speech
  • (new from ios 9.3) HealthKitUI
  • (new from ios 11) DeviceCheck
  • (new from ios 10) CallKit
  • (new from ios 11.3) BusinessChat

Beside new framework there was massive API from iOS13. Also this PR delivers lot of fixes to existing bindings as well as generic classes received template parameters (with enhanced version of bro-gen).

Known issues

  • ios13 changed few previously existing classes were common api were moved to new super class introduced in ios13. As result running on pre-ios12 will cause crash due native class not found. This to be fixed in RoboVM obj-c runtime itself;
  • several existing API naming were changed (to improve namings). this might break existing code;

AltPods: pods updated + new bindings(Facebook)


AltPods were update to v1.3.0-SNAPSHOTS. Changes include:

New pod

Updated pod

Unchanged pod

Other changes

All pods now have proper dependency setup:

  • references to other pods;
  • references for required framework thorugh META-INF/robovm.xml (no need to specify frameworks in host application)

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.3.0-SNAPSHOTS version.
Source code @github

Updates are not fullty tested, please open issue if bug found.

NB: AltPods – are robopods kept at my personal standalone repo. This is done to prevent main robopods repo from turning into code graveyard. As these pods have low interest of community and low chances to be updated.

Ios13: Fixing broken launch on simulator target


With Xcode 11 RoboVm can’t deploy to simulator anymore. It fails with:

simlauncher[70781:19762861] *** Terminating app due to uncaught exception ‘NSInvalidArgumentException’, reason: ‘+[DVTSimulatorApplication simulatorApplicationForDevice:]: unrecognized selector sent to class 0x1077a3590’

simlauncher was borrowed from MOE project and internaly build around tonns of hacks, and its hard to keep maintain it this way.
Meanwhile Apple provides simctl tool allong with Xcode and its functionality quite enough for RoboVm needs.

PR402 deliver migration to simctl and introduces following changes:

  • rmeoves simlauncher;
  • boots simulator if required with simctl boot;
  • deploys application with simctl install;
  • and launches it with simctl launch.

It works for me with Xcode11 and also has to be backward compatible.

Workaround for AndroidStudio/Fix242/Maintaince


This post continue series of Android facet related posts and delivers a workaround for issue #242 Unable to start RoboVM iOS in IntelliJ due to NullPointerException.
Fix is delivered as PR401.

Root cause

It happens as long as project gets Android module (which attaches AndroidFacet) to all modules and Idea loses compilation control as Android plugin takes over it. RoboVM Idea plugin registers as compilation step to process compiled java class files into native objects. Buts as this not happens as Android plugin respects not more than gradle rules (e.g. ignores Idea’s compilations steps) native parts is not get generated and plugin crashes with NPE. Also it will not work if build and run is configured to be done with gradle and not with Idea. Its being controlled by these options:

The fix

RoboVM updated to run on JDK12 host


Changes propose as PR400

As Java8 is end of support and requires additional registration to be downloaded its time to support recent versions of Java. Switching to it is not simple case as it requires complex set of changes to sources, tests and dependencies.

Code and unit tests update

First thing that was failing when trying to run on JDK12 are compiler’s tests. Followings were the issues:

Fix #399: ArrayIndexOutOfBounds inside soot


Its investigation in context of issue #399. Soot was crashing on big class files with exception:

java.lang.ArrayIndexOutOfBoundsException: -29458 at soot.coffi.CFG.processCPEntry(CFG.java:2652)

Investigation shown following byte code that Soot was trying to parse:

Code: stack=4, locals=0, args_size=0 0: ldc2_w #36078 // double 0.017453292519943295d

Easy check in hex presentation (-29458=0xFFFF8CEE and 36078=0x8CEE) shows that its classical signed/unsigned misstake.
Root case was in Instruction_intindex where argument (the index) was read as singed short which was ok till the value fit positive boundary of short, but turned into negative value once overflows. This class is super class for following set of Java bytecode which were affected as well (corresponding to JVM spec):

  • anewarray
  • checkcast
  • getfield
  • getstatic
  • instanceof
  • invokedynamic
  • invokeinterface
  • invokenonvirtual
  • invokestatic
  • invokevirtual
  • ldc2
  • ldc2w
  • multianewarray
  • new
  • putfield
  • putstatic

Fix is trivial: read value as unsigned short

NP: this bug was hidding from very beginning and was just waiting big enough class file to detonate.

bugfix #357, #387: CGBitmapContext.create crashes


History CGBitmapContext.create fails on real device for big sizes #387
Fix PR394

Root case

CGBitmapContext.create(byte[] ... ) method implemented as bellow:

BytePtr ptr = new BytePtr();
return create(ptr.as(IntPtr.class), width, height, bitsPerComponent, bytesPerRow, space, bitmapInfo, releaseCallback);

interested moments here:

  • new BytePtr(); allocate struct that contains one byte (size of struct is one byte);
  • ptr.set(data) just mem copies data over this one byte struct and corrupts all memory after it;

The fix

bro-gen: fixes + argument tuples


Another set of bro-gen updates it get during everyday usage. Whats new:

  • arguments tuple
  • better support for @Deprecated annotation
  • fixed visibility of default constructor