0

[edit] "Simple" question, long complicated details follow:

Q: What are the steps and project layout requirements in Android Studio to develop and maintain an distributeable SDK that is itself not OSS?

Details:

A similar question was asked a while back in Develop an sdk in android, but it was a good while back and didn't seem to get an answer. There's lots of good info at How do I add a project to the Android Studio, but it doesn't seem to address my specific situation. Which is:

  1. A large body of legacy C/C++ code that has it's own legacy build system, which happens to be cross-compiler friendly
  2. A working JNI configuration of glue, which when combined with the above, results in
  3. Our "SDK", which presents as an .aar file; it is not open source, and thus the end user/developer cannot (re)build the SDK
  4. A Sample Application, which we will distribute with source and can be used as a functional example of how to use our SDK

We started all of this in the days of Eclipse, before there was an Android Studio. Then and today the build process has a bunch of manual steps; we are currently using Android Studio 2.1.2. The goals are:

  • Generate a black-box SDK suitable for depolyment to end user developers along with the sample code
  • In house, be able to debug both the SDK and sample code with a minimum of fuss

The current manual steps look like this:

  1. Build the legacy code, generating a .a that currently is ARM specific (still need to add x86 and someday maybe mips support, if anyone is using that...)
  2. Run ndk-build (we currently hard code the use of NDK r9d) that knows where to find the .a from step 1 and results in a .so suitable for JNI
  3. Copy the .so to the SDK Android Studio project's src/main/jniLibs/armeabi
  4. Do a "Build:Rebuild Project", generating a .aar file
  5. Copy the .aar to the Sample code project's libname-debug/ directory
  6. Do a "Build:Rebuild Project" and/or "Build:Build APK" and debug on our various devices as necessary

I accept that I may be stuck with manually doing step 1 forever - that's the price of "legacy" - and perhaps step 2. But it would be really nice to be able to improve steps 3-6. In so doing, I want any deliverable Gradle files to work for our in-house developers who can see inside the SDK as well as our end-user developers who cannot see inside the SDK.

TIA for any pointers to SO topics I missed.

Community
  • 1
  • 1
UncleOp
  • 25
  • 6
  • 1
    don't you think you've asked too many questions under a single question. it may lead to write a long answer which is probably the violation of SO policy. please correct me if i'm wrong. – surajs1n Jun 22 '16 at 05:14
  • 1
    I agree with @psyco, please narrow your question. – Ishay Peled Jun 22 '16 at 06:40
  • Thanks for the feedback. This is very likely a process question, and as such may indeed lead to a "long answer". Hopefully the edits clarify and focus it a bit. – UncleOp Jun 22 '16 at 14:31

0 Answers0