To follow up on Tim?s email I have the following proposal which will allow the Android API to be delivered sooner with minimal impact the the existing API while choosing for the time being to remove support for the BLE / GATT CA Adapter that has been recently added. This is necessary because the Android specific CA changes were not fully communicated in advance and the implementation pushes more responsibility for understanding the CA to the application developer. There were two features that have been exposed in the CA Android source code (delivered in the samples directory) which users are expected to compile with their application and were committed without license headers.
1. Specific use of the Java API to determine the status of network interfaces on the device, we propose that this functionality be reimplemented as using Native NDK features and that it stay in the C layer. 2. The BLE features that were merged expose a lot of functionality to the user and the proper integration of this into the Android API as was done for other APIs will take several weeks and then will require testing. Therefore we believe the best approach is to remove support from the Android API for the OIC GATT profile so that we can get the Android API into developers hands soon. Please consider this proposal, suggest alternatives or let us know if the preferred approach is to merge the code into the Android API. If this is the case there will need to be more active communication about the intended functionality before we can begin the several week task of moving the BLE code into the Android API. Best Regards, Bernie From: <Kourt>, Tim A <tim.a.kourt at intel.com<mailto:[email protected]>> Date: Wednesday, April 15, 2015 at 2:49 PM To: "jn.ashok at samsung.com<mailto:jn.ashok at samsung.com>" <jn.ashok at samsung.com<mailto:jn.ashok at samsung.com>> Cc: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: Re: [dev] runtime issue: merged master/CA built for Android Hi Ashok, Please provide a step-by-step guide on how to enable an android app for CA. Unfortunately, the sample app <iotivity>/resource/csdk/connectivity/samples/android/sample_service/ isn?t buildable as the function signatures do not seem to match the APIs exposed by the CA on master branch. FYI: The runtime issue outlined previously is caused by the g_jvm not being set while the following lines are executed: void CACreateWiFiJNIInterfaceObject(jobject context) { JNIEnv* env; if ((*g_jvm)->GetEnv(g_jvm, (void**) &env, JNI_VERSION_1_6) != JNI_OK) I guess, this should help you to trace the problem. I wonder if a phone call may help us to sort things out? Thank you, Tim From: Naga Ashok Babu Jampani [mailto:[email protected]] Sent: Wednesday, April 15, 2015 3:23 AM To: Kourt, Tim A; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: RE: [dev] runtime issue: merged master/CA built for Android Hi Tim, Please find my comments inline. Hope this gives a clear picture about how CA interacts with Android APIs. Please share us the location where we can keep our Java files so that you can create the JAR/AAR files based on your requirements Best Regards, Ashok JN ------- Original Message ------- Sender : Kourt, Tim A<tim.a.kourt at intel.com<mailto:tim.a.kourt at intel.com>> Date : Apr 15, 2015 12:52 (GMT+09:00) Title : RE: [dev] runtime issue: merged master/CA built for Android <!--[if mso 9]--> Hi Ashok, Thank you for your reply. We have found your sample application inside of <iotivity>/resource/csdk/connectivity/samples/android/sample_service/ If I read it correctly, the current implementation of the connectivity abstraction for Android assumes that an application developer will provide an implementation of the native interfaces which are required by the CA to function on Android. Is this correct? [Ashok] Not really. CA has to invoke Android interfaces like BroadcastReceivers, and Callbacks for Bluetooth, WiFi, and BT. Currently JNI layer expects Context to invoke android/Java APIs . Except this Context, Application does not have to provide/implement any other functionalities If this is the case, I was wondering if you have considered moving the desired implementations into the Android API library (.aar file)? If this was the intent, how long do you think it may take? [Ashok] If Android API branch takes a decision regarding how to provide the context to the below layers, for accessing Android APIs, that will be helpful and everyone can follow that. This will remove the only dependency with the application. Best regards, Tim From: Naga Ashok Babu Jampani [mailto:[email protected]] Sent: Monday, April 13, 2015 10:59 PM To: Kourt, Tim A; iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] runtime issue: merged master/CA built for Android Hi Tim, CAInitialize intern will call CAWiFiInitialize. This will try to create the instance of cawifiinterface Android Java object from the JNI. This interface implements the Broadcast receiver to receive WiFi Connection Status and update the status to JNI Layer. CA intern will update the network status through the callback The current crash is caused as it cannot locate the wifiinterface in the JNI layer. These Java files are placed at samples/android/sample_service/src/com.iotivity.jar. Please bundle the necessary Jar file with the Application based on the Transport (WIFI/BLE/EDR) and the problem will be resolved. Please let us know if you have other issues. Best Regards, Ashok ------- Original Message ------- Sender : Kourt, Tim A<tim.a.kourt at intel.com<mailto:tim.a.kourt at intel.com>> Date : Apr 14, 2015 11:25 (GMT+09:00) Title : [dev] runtime issue: merged master/CA built for Android Hi All, Please take a look at the log file below. We are seeing a crash inside of CACreateWiFiJNIInterfaceObject function. The codebase is built with TARGET_TRANSPORT=WIFI. It seems like CAWiFiJniInit is never called. Are we missing anything? Thanks, Tim 04-13 20:28:09.452 28532-28550/? I/CA? initialize adapters.. 04-13 20:28:09.452 28532-28550/? I/WIFI_ADAP? IN 04-13 20:28:09.452 28532-28550/? I/WIFI_MONITOR? IN 04-13 20:28:09.452 28532-28550/? I/WIFI_MONITOR? [WIFICore] CACreateWiFiJNIInterfaceObject 04-13 20:28:09.452 28532-28570/? I/UTHREADPOOL? Calling routine with data as parameter 04-13 20:28:09.452 28532-28550/? A/libc? Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 28550 (ationTestRunner) 04-13 20:28:09.452 28532-28570/? I/CA? retransmission main thread start.. 04-13 20:28:09.452 28532-28570/? I/CA? wait..there is no retransmission data. 04-13 20:28:09.557 2668-2668/? I/DEBUG? *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 04-13 20:28:09.557 2668-2668/? I/DEBUG? Build fingerprint: 'cloudfone/cloudpad/one7_0_4_coho:5.0/LRX21Q/COHOL00475:user/release-keys' 04-13 20:28:09.557 2668-2668/? I/DEBUG? Revision: '0' 04-13 20:28:09.557 2668-2668/? I/DEBUG? ABI: 'x86' 04-13 20:28:09.557 2668-2668/? I/DEBUG? pid: 28532, tid: 28550, name: ationTestRunner >>> org.iotivity.base.test <<< 04-13 20:28:09.558 2668-2668/? I/DEBUG? signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 04-13 20:28:09.575 2668-2668/? I/DEBUG? eax 00000000 ebx e4afaef8 ecx e43ff03c edx fd4c8d27 04-13 20:28:09.575 2668-2668/? I/DEBUG? esi e4af635b edi 00000000 04-13 20:28:09.575 2668-2668/? I/DEBUG? xcs 00000023 xds 0000002b xes 0000002b xfs 0000006f xss 0000002b 04-13 20:28:09.575 2668-2668/? I/DEBUG? eip e4af208a ebp e43ff058 esp e43ff01c flags 00210282 04-13 20:28:09.575 2668-2668/? I/DEBUG? backtrace: 04-13 20:28:09.575 2668-2668/? I/DEBUG? #00 pc 0000d08a /data/app/org.iotivity.base.test-1/lib/x86/libconnectivity_abstraction.so (CAWiFiInitializeNetworkMonitor+126) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #01 pc 0000b671 /data/app/org.iotivity.base.test-1/lib/x86/libconnectivity_abstraction.so (CAInitializeWIFI+161) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #02 pc 00005b61 /data/app/org.iotivity.base.test-1/lib/x86/libconnectivity_abstraction.so (CAInitializeAdapters+83) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #03 pc 000074ca /data/app/org.iotivity.base.test-1/lib/x86/libconnectivity_abstraction.so (CAInitializeMessageHandler+380) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #04 pc 00005393 /data/app/org.iotivity.base.test-1/lib/x86/libconnectivity_abstraction.so (CAInitialize+44) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #05 pc 0000852a /data/app/org.iotivity.base.test-1/lib/x86/liboctbstack.so (OCInit+65) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #06 pc 0005e399 /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::InProcServerWrapper::InProcServerWrapper(std::weak_ptr<std::recursive_mutex>, OC::PlatformConfig)+205) 04-13 20:28:09.575 2668-2668/? I/DEBUG? #07 pc 000435a4 /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<OC::InProcServerWrapper, std::allocator<OC::InProcServerWrapper>, std::weak_ptr<std::recursive_mutex>&, OC::PlatformConfig&>(std::_Sp_make_shared_tag, OC::InProcServerWrapper*, std::allocator<OC::InProcServerWrapper> const&, std::weak_ptr<std::recursive_mutex>&&&, OC::PlatformConfig&&&)+130) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #08 pc 00043668 /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::WrapperFactory::CreateServerWrapper(std::weak_ptr<std::recursive_mutex>, OC::PlatformConfig)+70) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #09 pc 00042630 /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::OCPlatform_impl::init(OC::PlatformConfig const&)+348) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #10 pc 0004334b /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::OCPlatform_impl::OCPlatform_impl(OC::PlatformConfig const&)+215) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #11 pc 000433ef /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::OCPlatform_impl::Instance()+71) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #12 pc 00040897 /data/app/org.iotivity.base.test-1/lib/x86/liboc.so (OC::OCPlatform::registerResource(void*&, std::string&, std::string const&, std::string const&, std::function<OCEntityHandlerResult (std::shared_ptr<OC::OCResourceRequest>)>, unsigned char)+79) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #13 pc 00036a59 /data/app/org.iotivity.base.test-1/lib/x86/libocstack-jni.so (Java_org_iotivity_base_OcPlatform_registerResource1+489) 04-13 20:28:09.576 2668-2668/? I/DEBUG? #14 pc 000036aa /data/dalvik-cache/x86/data at [email protected] at [email protected]<mailto:/data/dalvik-cache/x86/data at [email protected] at [email protected]> 04-13 20:28:09.773 2668-2668/? I/DEBUG? Tombstone written to: /data/tombstones/tombstone_09 04-13 20:28:09.773 2966-2987/? I/BootReceiver? Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE) 04-13 20:28:09.775 2966-3998/? E/SharedPreferencesImpl? Couldn't create directory for SharedPreferences file shared_prefs/log_files.xml 04-13 20:28:09.776 2966-28571/? W/ActivityManager? Error in app org.iotivity.base.test running instrumentation ComponentInfo{org.iotivity.base.test/android.test.InstrumentationTestRunner}: 04-13 20:28:09.776 2966-28571/? W/ActivityManager? Native crash 04-13 20:28:09.776 2966-28571/? W/ActivityManager? Native crash: Segmentation fault [cid:image001.gif at 01D07784.E49C95C0] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=d083a0c0528fae52162dfa8bb199af05aec715840e3a98dbc4ef17c09022d240677b9b1a87f031eb09060032c89b30e00407d1a278fe738d3298a32fe7c0f484cf878f9a26ce15a0] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150416/c51acf2d/attachment.gif>
