Chris Pim

Hi, I've successfully built and tested my app on Android 64 with Rio 10.3.3 and now trying to build the .aab file. The project is configured to build this, but I'm getting an error at Deployment time: [PAClient Error] Error: E6408 java.lang.UnsupportedClassVersionError: com/android/tools/build/bundletool/BundleToolMain : Unsupported major.minor version 52.0 I've always used JDK1.8.0_60 and that's what the paths are in my SDK Manager for Android 32 and 64 targets. The odd thing is that the command Delphi is running is: [PAClient Error] Error: E6408 Unable to execute '"C:\Program Files\Java\jdk1.7.0_25\bin\java.exe" -jar "c:\program files (x86)\embarcadero\studio\20.0\bin\android\bundletool-all-0.10.3.jar" build-bundle --modules="C:\Development\Project\Android64\Release\Project\base.zip" --output="C:\Development\Project\Android64\Release\myShiftPlanner\bin\Project-unsigned.aab" --config="C:\Development\Project\Android64\Release\Project\buildconfig.json"' (Error 1) Where is it determining that it needs to use JDK1.7.0_25? I can't see this anywhere in my Tools > Options? Surely it should be using the one I defined in my SDK Manager? If I manually run the above command but use the 1.8.0_60\bin\java.exe instead, it complains about a missing buildconfig.json file - which is missing from the release folder. It sounds like I may be missing a configuration or something similar? I followed EMBs instructions on the DocWiki to configure my project. Has anyone else had a problem with this or know if there are issues with the bundle tool?

I’ve checked and there’s an extra key in the registry location you mentioned called JDKPath which isn’t published into the IDE. Changing this seems to have fixed the problem and I can now build an aab file! Thanks again Dave

Thanks Dave. Have you ever had problems with it generating the buildconfig.json file? It doesn’t seem to have created one in my release folder so wonder if I need to turn something on in my project config?

Thanks Dave, I’m glad you saw the same. Thanks for reporting it for me too, I’ve voted for it so hopefully it’ll be looking into.

That’s good news. In terms of the banner being in a scroll box, I’m not surprised that it flickers when scrolling as it isn’t really designed to be used like that. I suggest anchoring it to a fixed position on your form if possible. The flicker is because the FireMonkey code has to recalculate the position when it scrolls and force a re-render of the native control. As FireMonkey isn’t responsible for rendering the banner it can’t use double buffering to smooth the flickering as it would with other controls. Sorry but if you need it to be in a scroll area then I’m not aware of a solution, but maybe someone else does?

The TBannerAd component creates a native control. Because of the way FireMonkey renders everything to a canvas, native components will always render on top of FireMonkey components. It’s a side-effect of the way it works. The way I got round this is to hide and show the banner component when in other screens (e.g. tabs of a page control or frames which display as screens depending on your UI architecture), so it doesn’t get it the way when I don’t want it to. I also suggest including a bottom padding to your multi view menus to push the contents above the banner. I hope this helps

That’s a shame but useful to know. Hopefully we won’t need any hacks!

I wondered the same thing but I guess as the NDA exclusion only mentions allowing Android updates from 10.4 beta not iOS, you’d still be better using 10.3.2 for iOS, Windows and Mac builds while they get 10.4 released if you’re already using 10.3 anyway. 10.3.1 is really buggy so if 10.3.2 is more stable then it may be worth upgrading.

Very true, yet I still have hope that EMB get a 10.4 beta out soon so we can have a proper solution rather than a risky hack!

Reassuring words from EMB about it already being underway. Summer is a long season so hopefully the 10.4 beta program will start sooner rather than later!

Has anyone heard any more about this yet? The dreaded 1st August deadline is 3 weeks away after which we won't be able to give our Android users app updates should we need to. If things are running according to the last roadmap at EMB, then they're behind and haven't even released 10.3.2 yet let alone the sorely needed 10.4 which is supposed to contain the Android 64 bit work. I'm getting very worried that we might not be able to support our Android users for 3 months while they get a 10.4 beta out. We have 220,000 of them and the thought of not being able to get even an emergency bug fix to them should we need to terrifies me! Surely EMB must be taking this deadline seriously?

It may seem so, but that’s not true - they just weren’t fixed before the release...

I have strange problem occurring when parsing a JSON string on iOS using the System.JSON library in Berlin. I call TJSONObject.ParseJSONValue() to get a value from the start of a JSON string which has worked fine if I run under Windows. As soon as I run under iOS, the same JSON string causes a null pointer exception. When debugging through, the null pointer is the TJSONObject class itself which is odd as ParseJSONValue() is a class function so don’t know why that would ever happen. I suspect this isn’t really the case and is just what the debugger is interpreting (the iOS debugger in Berlin isn’t great). I suspect the JSON string is too large for the parser as it’s a huge string. My question is whether anyone is aware of a size limit for parsing a JSON string or whether there’s a known issue in the Berlin JSON libraries which might cause this? Unfortunately I can’t provide a sample JSON string as it’s a client’s backup data but hopefully someone will be able to help.

It looks like the issue was due to a nil character at the end of the string I was parsing, rather than a string length issue. Thanks for your help Markus!