[Mobile] Clearly document endianness requirements for OnnxTensor.createTensor

[sapphire-arches]

Describe the issue

The obvious way to build an input tensor can lead to unexpected results. onnxruntime should document that it requires native byte order in FloatBuffers, and (optionally) throw an IllegalArgumentException when provided with a buffer in non-native byte order.

To reproduce

val input = ByteBuffer.allocateDirect(tensorSize * 4).asFloatBuffer()
// Fill input using input.put
OnnxTensor.createTensor(env, input, longArrayOf(tensorSize))

This code snippet will result in lots of NaNs downstream because ByteBuffer defaults to enforced-BigEndian mode. Instead, you need to call .order(ByteOrder.nativeOrder()) to ensure floats are stored in native byte order.

Urgency

Trivial to work around, but very annoying to debug.

Platform

Android

OS Version

n/a

ONNX Runtime Installation

Released Package

Compiler Version (if 'Built from Source')

No response

Package Name (if 'Released Package')

onnxruntime-android

ONNX Runtime Version or Commit ID

1.23.1

ONNX Runtime API

Java/Kotlin

Architecture

ARM64

Execution Provider

Default CPU

Execution Provider Library Version

No response

[Craigacp]

It is documented on all the createTensor methods which accept buffers that the buffer should be in native order - e.g., https://onnxruntime.ai/docs/api/java/ai/onnxruntime/OnnxTensor.html#createTensor(ai.onnxruntime.OrtEnvironment,java.nio.ByteBuffer,long%5B%5D).

[sapphire-arches]

Oh, I just can't read apparently. Still, since it's completely invalid, it would be nice if these APIs threw exceptions when the byte order is not the same as the native order.

[Craigacp]

I can have a look into it, though in the case of supplying byte or smaller data then it's not required that it's in native order so the check will be a little involved.