I am trying to create a test automation for my mobile app and I need to be able to simulate various accelerometer readings which would happen while the user is using the app.
I originally thought using ADB with and android emulator would work. However the command that is documented to work does not.
$ ./adb shell sensor set acceleration 1:1:1
/system/bin/sh: sensor: inaccessible or not found
Is there a specific software version or emulator or hardware which i need to use to enable the above command?
Can I do similar type tests with an iphone?
you are using the wrong command, sensor set accelerometer is an emulator console command for which you have to use ./adb emu sensor set acceleration 1:1:1 command.
This will help you understand, https://helpmanual.io/help/adb/
Related
I am currently trying to create a React Native app that lets me connect to my OBD2 device and read data about my car from it. However, I am struggling to figure out the "reading data" step. I am able to connect to the device and see characteristics and services, but cannot read data from the characteristic. I've seen articles on running a set of commands to initialize the OBD, but I have no clue what I am doing wrong. These articles have said things such as:
Set the command protocol to AUTO by running AT SP 0. By running AT DP, you should get AUTO.
Convert the commands to base64.
Use the "\r" return carriage at the end.
Write to the characteristic and read the resulting value.
Could anyone with experience on this issue explain how I can use an ordinary BLE app to send a command (via write) and receive a command following (via read). I understand how to code the read/write, but not entirely sure how to implement this specifically with OBD2 devices.
Thank you for your time.
I will be asking a very subjective question, but it is important as I am looking to recover from failure to effectively use BlueZ programatically.
Basically I envision an IoT edge device that runs on a miniature computer (Ex: Raspberry pi or Intel Compute Stick). The device would then run AlpineLinux OS and interact with Cloud.
Since it is IoT environment, it is needless to mention the importance of Bluetooth BLE over ISM band. Hence the central importance of being able to customize and work with BlueZ.
I am looking to do several things with BlueZ BLE including but not limited to
Advertising
Pairing
Characteristic
Broadcast
Secure transport of data etc...
Since I will be needing full control over data, for data-processing and interacting with cloud (Edge AI or Data-science on Cloud) I am looking at three ways of using BlueZ:
Make DBus API calls to BlueZ Methods.
Modify BlueZ codebase and make install a custom bin.
(So that callback handlers can be registered and wealth of other bluez
methods can be invoked)
Invoke BlueZ using command line utils like hcitool/bluetoothctl inside a program using system() calls.
No 1 is where I have failed. It is exorbitant amount of effort to construct and export DBus objects and then to invoke BlueZ methods. Plus there is no guarantee that you will be able to take care of all BLE issues.
No 2 looks very promising and I want to fully explore how feasible it is to modify the BlueZ code to my needs.
No 3 is the least desirable option, but I want to have it as a fallback option nevertheless.
Given my problem statement, what is the most viable strategy forward? I am asking this aloud so that I do not make more missteps and cost myself time and efforts.
Your best strategy is to start with the second way (which you already found promising) as this is a viable solution and many developers go about this method in order to create their BlueZ programs. Here is what I would do:-
Write all the functionality of the system in some sort of flowchart or state machine. This helps you visualise your whole system and what needs to be done to reach your end goal.
Try to perform all the above functionality manually using bluetoothctl and btmgmt. This includes advertising, pairing, etc. I recommend steering away from legacy commands such as hcitool and hciconfig as these have been deprecated and have a very different code structure.
When stumbling upon something that is not the default in bluetoothctl/btmgmt or you want to tweak the functionality, update the source to do so.
Finally, once you manually get the system to perform the functionality that you need (it doesn't have to be all, it can just be a subset of the functions), you can move to automating the whole process. This involves modifying the source for bluetoothctl/btmgmt commands so that instead of manual intervention, everything would be event-driven.
This is a bonus, but if you can create automated tests using python or some other scripting language, then this would ensure that your system is robust and that previous functionality doesn't break when adding new ones.
By the end of this process, you'll have a much better understanding of the internals of bluetoothctl/btmgmt and D-BUS APIs that you might be able to completely detach your code from the original bluetoothctl/btmgmt or create the program from scratch.
You probably already know this, but when modifying the tools, this is the starting point for the source code:-
bluetoothctl - client/main.c
btmgmt - tools/btmgmt.c
For more references on using bluetoothctl commands and btmgmt, please see the links below:-
BlueZ D-Bus C or C++ Sample
Bluetoothctl set passkey
https://stackoverflow.com/a/51876272/2215147
Bluez Programming
Linux command line howto accept pairing for bluetooth device without pin
https://stackoverflow.com/a/52982329/2215147
Bluetooth Low Energy in C - using Bluez to create a GATT server
I hope this helps.
I have installed pocl.
make check shows all 145 tests passed.
The build shows that
--******** Enabled features:
......
-- OCL_DRIVERS (Drivers built): basic pthreads
......
But clinfo command shows only pthreads as the only device for the pocl platform. Is there a way to enable the basic device?
I want to add a custom opencl device to pocl. Understanding basic device implementation in pocl seems to be a good starting point.
According to the pocl documentation, the basic device hast to be enabled explicitly by setting the environment variable POCL_DEVICES to basic:
POCL_DEVICES is a space separated list of the device instances to be
enabled. This environment variable is used for the following devices:
- basic A minimalistic example device driver for executing
kernels on the host CPU. No multithreading.
So you should be able to use the device by calling POCL_DEVICES="basic" clinfo.
I have a MinSeg, which is built upon an Arduino Mega 2650.
I am connecting to the Arduino board using Simulink (in External mode), and
I am attempting to continuously log data on the Arduino Mega.
Problem:
When I start a run and later end the simulation,
the To Workspace block has only saved the last made sample.
Guidelines are provided here; however, they seem convoluted.
Is there no way to just continuously log data?
This guy also had the same problem,
but said he fixed it with an earlier version.
I feel like some setting has changed;
I can't imagine why things would have become more difficult.
I had the same problem and I fixed it by changing MATLAB release from 2015b to 2017b.
I'm currently working on an experimental Android Kernel (Research). I'actually trying to find some ways to preserve battery charge by implementing a kind of power management tool on the kernel level. I'm working on the msm-hammerahead kernel (used by the nexus 5 running Android 5.0).
I'm trying to figure out if there exists a way to switch between network types (2G,3G,Wifi) at runtime. I know that there exist the possibility to switch the default network type within the build.prop file(ro.telephony.default_network).
Does anybody know if it is even possible to achive this?
The android kernel is not the place to look for network switching. build.prop is also useless for this because it just contain the default boot values.
Switching network interfaces is a very bad idea, because the android framework need to be synchronized with the lower linux layer state.
I would suggest checking the ConnectivityManager.java in the android framework to understand better how the network switching works.