adding a method to read the model file from an Android Archive

[RLessmann]

Android Archives AAR contians an asset folder, which is
accessible by using the Android Asset Manager.
A reference to the Android Asset manager can be obtained from
the App using Java/Kotlin. Within a JNI call the reference
must be converted into an opaque C pointer.
The NDK Asset Manager functions can then be used to load the
model file from the AAR assets.

[github-actions]

✅ Conformance regression test passed on all tested platforms.

[github-actions]

✅ Conformance regression test passed on all tested platforms.

[gfiumara]

Are we guaranteed to not have a null-terminator anywhere in the model file? Maybe for the current model only? Should we write instead (if we keep this loop)?

Suggested change

	buffer[cnt] = 0; // add terminating '\0'
	ss << buffer;
	ss.write(buffer, cnt);

...or even store to a std::vector<char> instead?

[RLessmann]

We read the forest params as string and the yaml file with the model is a text file. Using the '\0' is safe due it is the text termination and will not occur in the text file.
I checked the reading routine in Android and

• it does not need much time
• the MD5 of the file content can successfully compared with the given hash string.
  Moving this to a vector or messing with the string termination will easily invalidate the hash value.

[gfiumara]

You can have \0 in a text file and in the middle of a string. We might not in the current model, but using operator<< (vs write with a size) will not read all BUFSIZ bytes if a future model did have a \0 inside. My overall question for this is and the two comments for line 154 are why are we reading in chunks and manipulating C-style strings if we don't have to with the API Android gives us?

Changing the storage container won't change the contents and we need to get to a C-style string for the digest function anyway (vector<char>.data()). I know calculateHashString takes a string, but it could just as easily and maybe more appropriately take something else in a refactor.

[gfiumara]

@RLessmann: please ignore my second comment (we have to get to a std::string to pass to OpenCV cv::FileStorage eventually, so the vector solution would duplicate RAM. However, I still find the ss.write to be more appropriate than operator<<. This should not change anything, avoids string conversion on every iteration, and guards us in the future if there is ever a \0 in a file. Would you please make and test this change on device? It should be identical. I believe you can commit the suggestion below and run the branch.

[gfiumara]

Also: can we push this to branch develop instead? I think that might be more appropriate, since the forwarding of different CMake args is needed.

[github-actions]

✅ Conformance regression test passed on all tested platforms.

[github-actions]

✅ Conformance regression test passed on all tested platforms.

[github-actions]

✅ Conformance regression test passed on all tested platforms.

[gfiumara]

Suggested change

	char buffer[BUFSIZ + 1]; // BUFSIZ defined in stdio.h
	int cnt = AAsset_read(asset, buffer, BUFSIZ);
	while (cnt > 0 && cnt <= BUFSIZ) {
	buffer[cnt] = 0; // add terminating '\0'
	ss << buffer;
	char buffer[BUFSIZ];
	int cnt = AAsset_read(asset, buffer, BUFSIZ);
	while (cnt > 0 && cnt <= BUFSIZ) {
	ss.write(buffer, cnt);