Error message:
Error: Source path "<haxe folder>/lib/lime/2,0,0-alpha,8/ndll/Android/liblime-v7.so" does not exist
lime 2.0.0-alpha.8
openfl 2.1.5
Are you using -Dnext? This should only be available for “legacy” Lime at the moment. While we are still developing the Lime 2 API, currently it is only for desktop platforms, but soon it could be brought to mobile again
A confirmation please? Right now I can’t build to Android. I removed and installed lime and openfl again both in windows and linux. Still missing. Trying out lime rebuild android or openfl rebuild android did nothing.
EDIT: Just read your post Josh, sorry, right now I just use OpenFL like usual, so no, I don’t have -Dnext. Do you mean I have to add -Dnext?
So could you tell me how to proceed with this. I’ve checked my project.xml, there is no -Dnext. And I need to build to mobile (right now occasionally to show the team about my progress, but eventually we will release on mobile). Could you let me know the last openfl/lime version combo where mobile platform is still available?
Okay, what happens if you use lime test android -Dnative, same thing?
Yup
What if you force lime test android -Dlime-legacy?
Okay, I tested lime build instead of lime test, and it works. So -Dlime-legacy it is. Thank you.
Does this occur only with one project, or does this occur for even something simple, like one of the OpenFL samples?
I’d love to hunt down why that flag was not set. On the OpenFL side, it should have:
<set name="lime-legacy" value="1" if="native || legacy || lime_legacy" unless="openfl-next" />
Then that should populate down into where it includes Lime. What does your project file look like? Is it possible it included Lime before it included OpenFL?
You’re absolutely right, I did include lime explicitely and before OpenFL. It has something to do with sublime-haxe-bundle choke on OpenFL completion if I didn’t.
`
So a question, if I want to keep the project file like the one that I have. How could I set -Dlime-legacy so that I don’t have to explicitly use it from the command line like openfl build android -debug -Dlime-legacy ? Right now using <haxeflag /> and your <set name=... /> lime inside the project file, will not trigger the lime-legacy.
Try <set name="lime-legacy" /> before <haxelib name="lime" /> though be aware that you cannot actually use the Lime API in “legacy”, only the OpenFL API
I had a similar thing happening last week and had an emotional twitter meltdown . LOL
In my case I realized I could not compile anymore with any projects created with earlier versions of Lime.
So I created a new project, reinjected my library paths manually, imported all my classes and then could compile to all targets.
Quite tedious but I’m confident this will be fixed in a near future.
This is happening to me with the HerokuShaders example and it isn’t fixed by either “test” “build” or “-Dlime-legacy” for android. Runs ok on windows.
“-Dlime-legacy” throws out:
“Export/android/haxe/ApplicationMain.hx:3: characters 7-16 : Class not found : lime.Lime”
any idea why the created example is throwing this ?
Should I just have to go to an earlier version of lime lib in order for the HerokuShaders to compile to android ?
There are two copies of the “HerokuShaders” sample.
There is an OpenFL version, which should use OpenGLView. This version should be compatible with either OpenFL “next” (which uses the new Lime API) or OpenFL “v2” on native (which uses the Lime “legacy” binary, and bypasses the new Lime API)
On the Lime side, we have a “HerokuShaders” sample which works with the new Lime API. Lime 2 does not currently support Android, we had some OpenFL renderer work that we wanted to do first before adding mobile support again. The Lime “legacy” binaries do support Android, but that’s incompatible with the Lime version of the sample.
So depending on your needs, maybe you can try the OpenFL version of the sample, or we look at adding Android support into Lime 2 again
EDIT: the second time around I tried to compile, neko didn’t crash and it actually went all the way to the phone. 
It works, the openfl-examples 2.1.0 HerokuShaders example worked. Sorry for jumping the gun, never had neko crash mid compile, thought I wasn’t able to find the correct version.
It works, the openfl-examples 2.1.0 HerokuShaders example worked. Sorry for jumping the gun, never had neko crash mid compile, thought I wasn’t able to find the correct version.So the copy that gets created with lime doesn’t compile, so where is the other copy that does, can I generate it with the “create” command ?
I tried a version that comes in openfl-examples 2.1.0 from haxelib but that made neko crash mid compile and threw a :
"
D:\Work\haxe_test2\HerokuShaders>C:/Development/Android NDK/toolchains/arm-linux-androidea
bi-4.4.3/prebuilt/windows/bin/…/lib/gcc/arm-linux-androideabi/4.4.3/…/…/…/…/arm-linux
-androideabi/bin/ld.exe: Warning: C:\Development\Android NDK/platforms/android-9/arch-arm/
usr/lib/crtbegin_so.o: Unknown EABI object attribute 44
"
so I guess it isn’t that one. 
BTW, amazing stuff being able to use sandbox examples like this, I can learn a lot from the shaders.
Ok, that works up to the moment it tries to change shader, then it just goes black screen and stays that way until the phone sleeps. I’m confused, this used to work, I think I remmber it changing cycling through the shaders on android.
[quote=“Franky, post:17, topic:69”]
Ok, that works up to the moment it tries to change shader, then it just goes black screen and stays that way until the phone sleeps. I’m confused, this used to work, I think I remmber it changing cycling through the shaders on android.[/quote]
That’s the same way on the neko target, that’s not android related.
Which HerokuShaders is doing this, the OpenFL one?