How to set up and run the sample app as an Android Studio project. Linux (Android Studio version 0.8.11 beta) ===== (1) Launch Android Studio. (2) Choose "Import project". - Navigate to the location of the sample soure code. You should be looking at a directory named "sample" containing a file named "AndroidManifest.xml". - Pick a new destination for it. (3) Copy in the '.jar' files. (a) Directly under the "app" directory of your project, create a "libs" directory. Use a shell command if you like, or use "File|New|Directory" from the menu. But note that you only get "Directory" as an option if you are in "Project" view, not "Android" view. "Project" models the local machine's filesystem, but Android is a virtual layout of files corresponding to the deployed hierarchy. That is to say, do step (b) before step (a) if you're inclined. (b) Toggle the view from "Android" to "Project" in the selection list above the file hierarchy. Otherwise you won't see "libs". (c) Copy 'cronet.jar' and 'cronet_stub.jar' to "libs". [Also note that it is possible to leave the '.jar' files in their original locations, though this seems to be somewhat discouraged by convention] (4) Inform the IDE about the '.jar' files. (a) Select both files at once. (b) Bring up the context menu and choose "Add as Library". (d) Confirm "OK" at the "Add to module" dialog. [Note: the keyboard shortcut and/or main menu selection for these steps seems to be missing from Android Studio. If you prefer, the advice under problem #2 in "Troubleshooting" below will perform the same thing without reliance on menu selections] (5) Copy in the '.so' file. (a) Under "app/src/main" create a directory named "jniLibs" (b) Copy armeabi and ameabi-v7a into jniLibs, which should contain only subdirectories, not directly a '.so' file (c) The IDE will automatically know about these. (6) Click "Run". Troubleshooting: If you have vast swaths of red text (errors) in the edit window for CronetSampleActivity, you should confirm that the requisite jar files are present in 'build.gradle'. There are at least 2 files which are named 'build.gradle'. Check them both. You should observe the following lines [see footnote 1] dependencies { compile file('libs/cronet.jar') compile file('libs/cronet_stub.jar') } If absent, the lines may be added by hand to the gradle file which corresponds to the module named "app", and not the project s a whole. You might have to press a "Sync" button in the IDE which tells it to re-scan the 'build.gradle' files. (II) If the project builds but doesn't run, verify that the '.so' files are present in your Android package (which is just a jar file in disguise): % jar tf build/outputs/apk/app-debug.apk AndroidManifest.xml res/layout/cronet_sample_activity.xml resource.arsc classes.dex lib/armeabi/libcronet.so lib/armeabi-v7/libcronet.so META-INF etc If the '.so' files are not present, it is likely that Android Studio misinterpreted the containing folder as "ordinary" source code, which, due to lack of any special directive pertaining to it, failed to be copied to the apk. One thing to check for is the spelling of "jniLibs" - it must literally be that, with a capital "L" or it won't work. This is a bit of magic that allows users without the NDK (Native Development Kit) to deploy '.so' files. [With the NDK, things are different because in that case you have to produce the '.so' files, and create build rules to do so, so the setup is naturally more flexible to begin with.] As a visual cue that the folder has been recognized as special, its icon should match that of the "res" (resources) folder which resembles a tabbed manila folder with some extra cross-hatches on the front, and not the icon of the "java" folder. The marking on the icon signifies that its contents land on the the target device. But to keep things interesting, the icon is distinct visually only in "Android" view, not "Project" view. MacOS (Android Studio version 1.0.1) ===== (0) You might or might not have to set a magic environment variable as follows [see footnote 3]: export STUDIO_JDK=/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk (1) Launch Android Studio, which can be achieved from the command line with % open '/Applications/Android Studio.app' (2) Choose "Import Non-Android Studio Project" (a) Navigate to the path containing "sample" (b) Pick a place to put it, and choose "Finish" (3) If you are comfortable using shell commands to create directories, you may proceed to step (3) for Linux above. Otherwise, if you prefer to create directories from the UI, proceed with the following steps. (4) Choose "File -> New -> Folder -> Assets Folder". Check "Change Folder Location" and delete the entire pathname that was there. Change it to 'libs' which is conventional for pre-built jar files. (5) Copy and paste the two pre-built '.jar' files into 'assets'. When you do this, it will say that the destination is "app/libs". This is right. If you prefer to see the file hierarchy as it really exists, you can change the dropdown above the tree view from "android view" to "project view". Or just keep in mind that assets = libs at this level of the hierarchy. (6) Select both jar files that you added (Shift+click). and pull up the menu for them (Ctrl+click). Select "Add as library" (7) Choose "File -> New -> Folder -> JNI Folder". Choose "Change Folder Location" and change the name to "src/main/jniLibs" [see footnote 2] ---- Footnotes: [1] "compile file" as used in a dependency line means to package the named jars into the apk, and not to make those files. The opposite of this is "provided file" which assumes that the jars exist on the device already (in whatever the standard location is for systemwide jar files), and not that a file has been externally provided to Android Studio. [2] The menu option to add JNI files assumes that you have the NDK (Native Development Kit) installed and want to produce files into the named directory. This is triggered by an automatic rule that tries to look for C++ source code and the NDK based on the existence of "src/main/jni". Changing this directory to "src/main/jniLibs" is magical in a different way: it informs Android Studio that you will place precompiled binaries into that directory. [3] This has to do with differences between the JDK that the studio runs in as distinct from the JDK that the studio understands to be present on the target machine. There is discussion of the issue in https://code.google.com/p/android/issues/detail?id=82378 Additional notes: Ideally the two .jar files and one .so file could be delivered as one .aar (Android Archive) file, but Android Studio will try to pull aar files from a Maven repository without some workarounds that are about as much trouble as adding in three separate files. See https://code.google.com/p/android/issues/detail?id=55863 Additionally, it is unclear how to automate the creation of a '.aar' file outside of Android Studio and Gradle. If the entire workflow were controlled by Gradle, it would be one thing; but presently the cronet jars are produced as artifacts of the Chromium build which uses Ninja.