Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-7474] Android: Support selecting what ABI to target when using V8 runtime.

GitHub Issuen/a
TypeNew Feature
PriorityHigh
StatusClosed
ResolutionFixed
Resolution Date2012-12-21T05:43:49.000+0000
Affected Version/sRelease 2.0.2, Release 3.0.0, Release 1.8.3
Fix Version/sRelease 2.1.3, Release 3.0.0, Sprint 2012-18 Core
ComponentsAndroid
LabelsSupportTeam, core, module_build, qe-review, qe-testadded
ReporterJosh Roesslein
AssigneeBill Dawson
Created2012-01-30T14:45:13.000+0000
Updated2013-01-03T16:00:57.000+0000

Description

Allow developer to specify in tiapp.xml which ABI to support when using V8 runtime. Currently we always bundle both ABI versions of the native library. If the developer only wishes to support one ABI version to cut down size of the APK they may choose to do so. http://developer.appcelerator.com/question/131313/why-are-both-rhino-and-v8-bundled-in-the-apk

Attachments

FileDateSize
log2.2.0CI.txt2012-08-29T11:01:50.000+00001084

Comments

  1. Bill Dawson 2012-08-28

    Testing Notes

    Not specifying an ABI

    * Create a new app. * Build and launch it on a device. Make sure it runs. (This step just tests that the most common use case -- not specifying an ABI -- is not broken.) * Also go down to the command line, navigate to your project's build/android/bin folder, and run unzip -l app.apk. In the output, make sure you see libraries for both armeabi and armeabi-v7a. Like in this sample output:
           11716  08-29-12 01:13   lib/armeabi/libtiverify.so
         5532236  08-29-12 00:20   lib/armeabi/libkroll-v8.so
          393604  08-29-12 00:20   lib/armeabi/libstlport_shared.so
           11768  08-29-12 01:13   lib/armeabi-v7a/libtiverify.so
         5510044  08-29-12 00:20   lib/armeabi-v7a/libkroll-v8.so
          393496  08-29-12 00:20   lib/armeabi-v7a/libstlport_shared.so
       

    Specifying one ABI

    * Edit the tiapp.xml and add the element to the section and make it look like this:
       <android xmlns:android="http://schemas.android.com/apk/res/android">
       	<abi>armeabi</abi>
       </android>
       
    * Build and launch the app on device. Make sure it runs. * Also go down to the command line, navigate to your project's build/android/bin folder, and run unzip -l app.apk. In the output, make sure you see libraries for *only* armeabi, *not* armeabi-v7a. Like in this sample output:
           11716  08-29-12 01:13   lib/armeabi/libtiverify.so
         5532236  08-29-12 00:20   lib/armeabi/libkroll-v8.so
          393604  08-29-12 00:20   lib/armeabi/libstlport_shared.so
       

    Specifying "all"

    * We also support explicitly specifying "all", which is the same as removing the element altogether. But test it by replacing "armeabi" with "all" in tiapp.xml's element. * Build and run the app, make sure it works. * Go down to the command line and again run unzip -l app.apk and make sure you see libs for both armeabi and armeabi-v7a, like in the first test above.

    Specifying multiple ABIs, comma-separated.

    * We also support comma-separated list of ABIs to package libs for. So replace "all" with "armeabi,armeabi-v7a" (no space). * Build and run, make sure it works. * Go down to the command line and again run unzip -l app.apk and make sure you see libs for both armeabi and armeabi-v7a, like in the first test above.
  2. Bill Dawson 2012-08-28

    PR ready https://github.com/appcelerator/titanium_mobile/pull/2848/
  3. Josh Roesslein 2012-08-28

    Is extending the android manifest really the only option for specifying the ABIs? I think it might be better if we use a property tag. Example:
           <property name="ti.android.abi">armabi, armabi-v7a</property>
       
  4. Bill Dawson 2012-08-29

    I'm not putting it in the manifest section, but in the section (not in other words.) I know the section has a tendency to look like the manifest because we pre-supply the android xml namespace for convenience in case someone _does_ put in the manifest section. But its purpose is not solely to house the manifest. For example, another build-time setting is in there (). tags become runtime SharedPreferences and should only be used if the values are needed at runtime, which is why we support the optional "type" attribute for them. We may not be 100% consistent about using them only when values are needed at runtime, but it certainly _should_ be that way.
  5. Josh Roesslein 2012-08-29

    Bill, okay that seems logical. Yeah I did confuse the tag as being part of Android's manifest schema.
  6. Josh Roesslein 2012-08-29

    Mauro, please use file attachments for logs so the comments section doesn't explode in length. A quick look of the log only seems to show a HTTPClient socket error (possible connection issue?).
  7. Bill Dawson 2012-08-31

    2_1_X cherry-pick PR ready. *Do not merge until 2.1.2 is released and build/titanium_version.py shows 2.1.3.* https://github.com/appcelerator/titanium_mobile/pull/2859
  8. Tamila Smolich 2012-09-05

    Verified ability to specify in tiapp.xml which ABI to support when using V8 runtime. Now developers can specify one ABI (armeabi or armeabi-v7a) or all ABIs. New feature was verified using Bill's test steps by building the app and packaging as well. Note: If the app was built for device with spicifying "all" ABIs, you'll find in /build/android/bin/app.apk\ Folder/lib not only "armeabi" and "armeabi-v7a", but also "x86". I discussed with Josh and this is expected behavior. Verified on: Titanium Studio, build: 2.1.2.201208301612 Titanium SDK, build: 2.1.3.v20120904163110 OS: Mac OS X Lion 10.7.4

JSON Source