Unable to process transactions signed by the Android app

[vsobotka]

We are using: Android Pera Wallet App v5.4.2 @walletconnect/client 1.8.0 @walletconnect/types 1.8.0 py-algorand-sdk==1.11.0

When using the sendCustomRequest on the frontend, to ask user to sign transaction (method "algo_signTxn"), the response is returned in different format. While on iOS we get back Uint8Array, the Android seems to give us back something else. At first glance it seems like signed integer array, as there are negative numbers and the range seemed to correspond also.

This is the bit we have on FE:

This is where it fails for us on the BE, because numbers out of range for bytearray function are present:

We have had this working for over a year, until roughly two week back. Seems to work fine on iOS, but not when signed by Android App.

[vsobotka]

In our case, we needed to keep the iOS format as is (base64 string) while we needed to modify the Android response (integer array)

if (signedTxns) {
  return signedTxns.map((txn) => {
    if (typeof txn === "string") return txn;
    else return new Uint8Array(txn);
  });
}

Nonetheless, I see this as a bug, when the same app behaves differently on different platforms.

[taylanpince]

Hello, we've investigated this and confirmed that Android and iOS apps always had a different format. We will rectify this in the near future. However I should point out that "this was working for over a year and that it stopped working recently" is false. It's always been implemented this way.

If you use Pera Connect, it handles this difference gracefully behind the scenes.

[JoshOtter]

We ran into the same issue with our app at what sounds like approximately the same time. The Pera app on iOS was returning the base64 string and on Android it had been returning a byte[]. But then suddenly the Android started returning and sbyte[] with negative numbers included, which broke our apps ability to convert it into a byte[], which it needed to be to work with the .NET Algorand SDK. We added some code to check if the signed transaction was coming back as an sbyte[], and if it was we had to convert to byte[] before continuing as normal.

Again, this was a sudden change in behavior, because we hadn't done anything with that part of our code base for a while. We also noticed that when using an older version of the Pera app on Android, it was returning a byte[] like normal, but then we updated the app to the newest version (at that point, anyway), and with that update, the same phone started returning signed transactions as an sbyte[]. I understand that it works differently on Android and iOS, but I think the potential bug is in the fact that it suddenly started returning a different value than it previously had, specifically on Android devices.

[yasin-ce]

Hi, we are using Kotlin ByteArray as the data type since the beginning. Kotlin byte represents an 8-bit signed integer. Until now all the dApps we are integrated to, handled this type of value. But as you mentioned iOS and android data type difference is causing extra hassle. We are unifying them now and we will be sending an encoded base64 value exactly the same as iOS. It's currently in the testing period. We will be releasing it soon and informing you about it. Thank you for your detailed reports.

[yigitguler]

This is fixed.