ah! I understood the problem was specific for the signature verification.
One thing I can tell you is that the field signature for a signed transaction is an array (to allow multi-signature).
So the method encodeSignedTransaction:
private String encodeSignedTransaction(byte[] sig, byte[] binaryTx) {
should be something like this
private String encodeSignedTransaction(byte[][] sig, byte[] binaryTx) {
ok yes that was the problem. got it working now. thanks! 
is multi-signature already supported? I mean should the SDK provide the possibility to put an array of multiple signatures at this moment of time?
haven’t seen this implemented in other SDKs so far
a few days ago we released the new version aepp-sdk-java v1.0.2.
@noandrea
do we already have some Æ-unit-conversion tools? I would like too add this to the sdk.
we also want to provide a tool to estimate the best fees. can you tell us the best way to do this?
@marco.chain for fee calculation you can check the specs here
what do you mean for unit conversion ?
ahh thanks. didn’t catch that in the specs 
with unit conversion I generally mean how we define the units in æternity. there was some discussion about that in this thread. but it seems like it isn’t defined yet how to name the units.
some call the smallest unit aettos and in the blockexplorer I saw something like picoAE. I would love to have this specified and published by the æternity team 
@noandrea do you know which SDKs already support state channel operations? we started implementing state channel support in our Java SDK and I just want to have a look at other implementatons.
The JS SDK supports state channels GitHub - aeternity/aepp-sdk-js: Javascript SDK for the æternity blockchain
For the unit conversion, there are no specific guidelines afaik.
AE supports Java sdk? Where can I find it?
are you sure that the JS SDK supports state channels? haven’t found the respective code in the repo 
yes, Æternity has a (community developed) Java-SDK. we are actively developing it here:
you can follow the progress of new features here:
if you want to have access to new features in our dev-branch which aren’t released yet you can always use the most recent SNAPSHOT version
Thank you for sharing. Thank you for working hard for the prosperity of the AE community.
@marco.chain super sure! The integration tests are here https://github.com/aeternity/aepp-sdk-js/blob/develop/test/integration/channel.js
@noandrea
we’re currently working on the fee calculation in our JavaSDK, according to the MINERVA hardfork upcoming. Is there any possibility to activate the new fee calculation adaptions to our local test chain?
Additionally, do some example transactions with the new fee calculation exist for validating?
Thanks and greets,
Michel
ok I talked about that with Dimitar on telegram. so in our case (running default settings with network ae_devnet) the new fee structure automatically starts on block height 1.
it’s all fine.
I also talked with him about the best way to implement a calculation for the minimum required fees and came to the following process:
if anybody has a better approach. please tell us
Yes that’s the way to go!
It can be a bit confusing because sometime the docs are not very accurate, here is how the calculation is done in python:
https://github.com/aeternity/aepp-sdk-python/blob/feature/tx_decoding/aeternity/transactions.py#L62
thank you!
you should consider providing an endpoint for googles where people can check validity through api calls 
… I think it would be great to have such an endpoint in the core of aeternity if thats not too expensive
That is a very good idea, but I am afraid that it will be misused and taken as a service provided for transaction verification, and I am not sure about that.
I also thought about that. So maybe it should only be active in debug-mode. I posted this question in the public developer hangout thread