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

New pod

• Facebook: core, login, share, place, audience v5.5.0

Updated pod

• AppLovinSDK v6.9.1
• BranchMetrics v0.28.1
• Firebase v6.8.1
• HelpShift v7.6.2
• Lottie v3.1.2
• OneSignal v2.11.0

Unchanged pod

• SAMKeychain v1.5.3
• Pollfish v5.0.0
• Charts v3.3.1

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.

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.

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

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:

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.

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();
ptr.set(data);
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

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

  arguments_tuple

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

New pods

• AppLovinSDK v6.7.1
• Pollfish v5.0.0

Updated pod

• BranchMetrics v0.27.1
• Charts v3.3.0
• Firebase v6.3.0
• HelpShift v7.5.3
• Lottie v3.1.1
• OneSignal v2.10.0

Unchanged pod

• SAMKeychain v1.5.3

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

Updates are not tested yet, 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.

Packed C structures were not supported what caused and issue #374. Adding support for them seemed as a quick win but it had own pitfalls. As part of quick win following was done:

(code was delivered as PR 378)

Added @Packed(align param) annotation to mark structures to be packed:

To mark structure as packed it is enough just annotate it with @Packed.
Following C structure:

#pragma pack(push, 2)
struct PascalString { short length; long long v;};
#pragma pack(pop)

is to be bind into following Java one:

@Packed(2)
public class PascalString extends Struct<PascalString> {
    @StructMember(0) public native short length();
    @StructMember(0) public native PascalString length(short length);
    @StructMember(1) public native long v();
    @StructMember(1) public native PascalString v(long v);
}

Bro compiler generates proper LLVM IR packed Java structures:

Once Issue #373 (Wrong data type of MIDINotificationMessageID enum) was opened it is clear that cocoa-touch had to be revised for enum marshalers case.
This issue wasn’t exposed till #373 and was around for years but anyway it is just metter of time till someone finds another one.

What’s wrong

Marshalers are compilation time annotations that specifies RoboVM compiler the way how to convert native/objc object to java side and back. In case of enums it is usualy specifies size of integer used by enum type in native/objc (e.g. signed/unsigned char/short/int/long).
Using wrong size/sign integer type marshalers leads to data loss (when wrong value read from memory) and potentionaly memory corruption on write attempt.

• using enum type as member of structure (#373)
• accessing enum type value by pointer

Why it was in general working