The sourcePlay call in NativeAudioSource.play is removed, since
setCurrentTime will always do that itself. Additionally, within
setCurrentTime, sourcePlay was happening before setting the byte
offset for non-streamed sounds.
This appears to fix the problem of sounds playing the first part
multiple times, described here:
https://community.openfl.org/t/sounds-play-twice-on-ios/12163
This change places the focus on the one known use case, while clearing
up potential confusion caused by similar-sounding classes that function
totally differently.
Previously, they could access `${app.file}` and `${config.android}`, but
not `${project.platformType}` or `${config.android.target-sdk-version}`.
Now they can!
I don't know if we want to phase out `${projectDirectory}`, but it's now
an option.
This is recommended as a best practice, though AFAIK this only matters
for projects that are going to be imported by other projects.
For instance, you used to be able to include `:deps:extension-api` by
including any extension that depended on it. Now, every project that
wants to use `extension-api` has to include it directly. (Which is fine
because in practice, they all already do so.)
vorbisFile.timeTell() returns the current decoding offset in seconds,
and it's updated each time vorisFile.read() is called. Since data is
buffered by calling vorbisFile.read() multiple times, the associated
time values also need to be preserved in order to get the correct time
offset.
Without this change, getCurrentTime() will return some time in the
future relative to the amount of buffered data.
It isn't always safe to assume `./` is the app directory, and removing
that assumption opens up options.
Requires at least Haxe 3.4, but I don't think Lime supports 3.3 anyway.
https://developer.android.com/studio/projects/configure-agp-ndk#agp_version_41
The documentation tells you to be careful about this, since you're
putting local-only information into a file that gets uploaded to version
control, but Lime doesn't really need to worry about that.
Granted, Lime DID use local.properties, but that's no longer practical.
I can't think of any practical reasons for an Android extension to compile an ndll. All of Android's system functions require Java, not C++, and you can get the speed of C++ just by writing Haxe code.
I surveyed several Android extensions on lib.haxe.org, and not one of them used ndlls when targeting Android.
