We shouldn't be recommending OpenSLES any more, and we don't need Oboe
samples because Oboe's own samples are much more thorough than ours will
ever be.
This expands the docs and comments in the native-activity sample to be
something closer to a proper guide. There isn't a very clear flow to it
since the documentation is necessarily spread out into multiple files,
and sometimes the order of the code requires explaining things out of
order, but it's better than nothing.
If we wanted to turn this into an actual guide that could be written in
a clear order without duplicating code snippets into the docs, which
would surely be quickly out of date, we could use something like sphinx
(possibly through readthedocs) to generate something closer to a
literate code sample.
License text, setup instructions, and support info do not need to be
duplicated into every README, since they're already in the top-level
README. They were originally in each sample because the samples used to
each be separate Android Studio projects with different requirements
that could be checkout out independently in Android Studio. This is no
longer the case.
Most of the docs also included text along the lines of "This sample uses
the new Android Studio with CMake support", which hasn't been new since
2015, so doesn't really need to be said.
The prerequisites were mostly not true. Android Studio is not required
for any of this. Cloning the repo and running `./gradlew build` is
sufficient to build all the samples. They also were not being kept
up-to-date at all, since they mostly said "Android Studio 2.2 or newer",
which was definitely not true. I'm not what the oldest version of
Android Studio that will work here is, but I don't actually test
anything but the latest so claiming anything otherwise is just
misleading.
I haven't pruned or edited any of the real content of the docs. I'm sure
there are plenty of edits to be made there and a lot of expansion to do,
but those changes will be less mechanical and will happen separately.
These should all just move to GameActivity, but that's a slightly more
involved migration. This is an easy first step to clean up the existing
callers.
I'm ignoring the deeper questions of why some of these seemingly
important arguments are unused because this whole directory is destined
for the scrap heap, but until I've actually finished writing that new
merged graphics sample, this will stick around.
These don't demonstrate any NDK behavior, just AGP behavior. The
dependency management they show is also shown elsewhere since we rely on
these features for sharing code between samples anyway.
It's a little bit strange to do this in a sample that's intentionally
doing bad things, but not *these* wrong things, so it's still helpful to
move the sample to `add_app_library` so we can apply consistent
behaviors throughout the repo.
This is just another OpenGL sample, and a very old one at that. It
wasn't even originally written for Android, but was ported from asm to
OpenGL for desktop and now this is the Android port (though it still
includes the win32 code!). It's also not doing anything useful that the
other GL samples aren't.
It's not perfect because any stale links people follow that link to
anything but this README will still be a 404, but it's at least
something people can find if they walk up the dead link to the top of
the sample's directory.
We don't need OpenGL just to do a color fill. Save that for the OpenGL
samples. Replace that with a trivial AHardwareBuffer based color fill.
I've altered the old animation which didn't really work the way I think
it was intended to. It looks like someone had intended for the
accelerometer to alter the color, but it actually only animated between
black and bright green. I've removed the sensor code as superfluous
anyway, so just do something simpler: switch from red, to green, to blue
every second. I kept some amount of animation rather than just clearing
a solid color because if we only draw once and have no update cycle then
choreographer and most of the event handling code also becomes useless,
and without that the sample no longer bears any resemblance to a real
app.
https://github.com/android/ndk-samples/issues/1139
This API is deprecated in favor of TFLite:
https://developer.android.com/ndk/guides/neuralnetworks/migration-guide.
TFLite has their own docs and samples, and isn't an NDK API anyway so we
don't need to replace these samples with TFLite samples. Just delete the
thing we're recommending against so people don't get confused into
following bad advice.
This is essentially an OpenMAX AL duplicate for native-codec. OpenMAX AL
isn't deprecated, but it's not recommended either. I'm removing the
sample because new code should prefer to use the NDK Media Codec APIs as
shown in the native-codec sample.
