Problems communicating with MOVESENSE using adb - movesense

I have tried to follow the instructions from Movesense on how to do Whiteboard communication using ADB. This does not work as expected.
On a sidenote - I'm just trying to set up a handful of sensors to start some heart rate and movement measurement and store data to the logbook. After 30-40 minutes, I want to stop measurements and fetch the data from each device. My first dream was that I could do this using Whiteboard over BLE (from Matlab, Python, LabVIEW, ...) without having to use ADB or similar solutions. But I guess this was a bit too optimistic.
Setup
Installed the adb tools: OK
Enabled USB debugging on an Android phone: OK
Tested that adb can install apps and handle the phone: OK
Installed sampleapp-debug-1.5.1.apk:
Tried to install using adb: OK
Tried to install by copying the file to the phone and installing it there: OK
I got a message saying that the sample app was not compiled for the current version of Android (I'm using a Samsung S10e running One UI version 4.0 and Android version 12, security fix level 01.02.2022).
Im working on an Intel Mac running Big Sur 11.6.5 with plenty of resources.
What I've tried so far
First of all, I start the app and connect to the MOVESENSE device.
When trying the example commands from Movesense, I get:
Switch on LED:
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":true}'''
Broadcasting: Intent { act=android.intent.action.MOVESENSE flg=0x400000 (has extras) }
Broadcast completed: result=0
Get Info
Get Info does only work if I place curly braces between the quotas. See results below for both variants.
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type get --es path Info --es value ''''''
Exception occurred while executing 'broadcast':
java.lang.IllegalArgumentException: Argument expected after "value"
at com.android.modules.utils.BasicShellCommandHandler.getNextArgRequired(BasicShellCommandHandler.java:295)
at android.content.Intent.parseCommandArgs(Intent.java:8329)
at com.android.server.am.ActivityManagerShellCommand.makeIntent(ActivityManagerShellCommand.java:367)
at com.android.server.am.ActivityManagerShellCommand.runSendBroadcast(ActivityManagerShellCommand.java:788)
at com.android.server.am.ActivityManagerShellCommand.onCommand(ActivityManagerShellCommand.java:214)
at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
at android.os.ShellCommand.exec(ShellCommand.java:38)
at com.android.server.am.ActivityManagerService.onShellCommand(ActivityManagerService.java:10429)
at android.os.Binder.shellCommand(Binder.java:986)
at android.os.Binder.onTransact(Binder.java:860)
at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:6049)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3034)
at android.os.Binder.execTransactInternal(Binder.java:1220)
at android.os.Binder.execTransact(Binder.java:1179)
fjp#fMac-19 sensorsw % adb shell am broadcast -a android.intent.action.MOVESENSE --es type get --es path Info --es value '''{}'''
Broadcasting: Intent { act=android.intent.action.MOVESENSE flg=0x400000 (has extras) }
Broadcast completed: result=0
The suspects
Is my problems due to an old version of the Android app? I could not find anything newer than 1.5.1.
I tried to poke around a bit in the phone using adb shell dumpsys activity services | grep android.intent.action, and got a load of results, I then started to look for MOVESENSE as well using adb shell dumpsys activity services | grep MOVESENSE, and got no hits. I'm on thin ice here, but could it be that there should be an android.intent.action.MOVESENSE in there someplace?

After a lot of trial and error, I have finally found a solution.
The solution
I found aBitbucket directory with a lot of precompiled Android apps.
The file Showcaseapp-debug_adb-bridge-build.apk is the one you want. Here is what you do:
Download Showcaseapp-debug_adb-bridge-build.apk, and place it in your directory of choice.
On your Android device, uninstall the Showcase app if you have installed it already.
Install the app using ADB on your computer: adb install Showcaseapp-debug_adb-bridge-build.apk.
Start the app on your Android device and connect to the Movesense device.
Try a command like:
Switch LED on: adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":true}'''
Switch LED off: adb shell am broadcast -a android.intent.action.MOVESENSE --es type put --es path Component/Led --es value '''{\"isOn\":false}'''
A final note
In a perfect world, Movesense would make wbcmd capable of using theBLE device built into most/all PCs, be it Windows, Linux, or Mac. Or even perfecter (is that a word?), make a variant that used TCP/IP instead of standard in/out.

Related

How to apply SELinux file_contexts change on AOSP device without a full image flash?

I am modifying SELinux policies for a hardware device running Android 9.
Currently my process is like this:
Run the device as userdebug but with SELinux set to enforcing
Make changes to .te files and/or file_contexts
Build the policies using mmm system/sepolicy
Push the policies on the device using the following script:
adb root
adb wait-for-device
adb remount
adb wait-for-device
adb push out/target/product/<PRODUCT_NAME>/vendor/etc/selinux /vendor/etc/
adb push out/target/product/<PRODUCT_NAME>/system/etc/selinux /system/etc/
adb shell sync; sync; sync;
adb reboot
Test and go back to step 1 if needed.
This process seems to work fine when modifications involve .te files. But when I modify the file_contexts, this doesn't work, and labels I changed are not applied on the device.
For now, I have to do a full make and flash when I modify file_contexts, which is very time consuming...
So is there a way to apply file_contexts changes without a full make/flash ?
Check if there is product/etc/selinux or odm/etc/selinux in the ${ANDROID_PRODUCT_OUT}.
If they exist, you have to push them into the device too.
The file_contexts is only applied if the file or directory is created via init.rc or after running the restorecon command.
If the file or directory is created by adb shell or any other process runtime, the selinux context will inherit its parent.

Buildroot and Qemu

I'm using buildroot to compile a minimalistic linux with a 4.19-rt kernel. It is supposed to run on a raspberry pi 3b (arm processor). Additionally I want to run it on a x86_64 linux computer and found qemu as an emulation solution for that.
Building linux and kernel and running it on the raspi works. It boots, I can login and use it.
To test qemu I followed this instruction [1]. A recent raspbian with 4.19 kernel is booting fine so qemu seems to be installed correctly.
sudo qemu-system-arm -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster -hda 2019-09-26-raspbian-buster-lite.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -dtb qemu-rpi-kernel/versatile-pb.dtb
Bringing 1. and 2. together fails. When I try to emulate any self build linux, qemu only shows a black screen and one CPU is using 100%.
I used the same sdcard.img that works on the real hardware. I also tried to recompile the whole system with a normal 4.19 kernel (without real time). And I tried to build a versatile system (make qemu_arm_versatile_defconfig && make). None of it works.
Command to start the emulation:
sudo qemu-system-arm -kernel zImage -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio
My main problem is, that there is absolutly no useful output. The command outputs the following
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `lm4549.out'
and opens a window for the graphics output (that does not show anything). The message also appears when emulating raspbian so it does not seem to be the reason.
When I run qemu with the prebuild raspbian but without the -dtb argument, I get a message like "Error: invalid dtb and unrecognized/unsupported machine ID". I would at least expect something like this with my self build code. But because there is no output I'm out of ideas what even to google for.
Does someone maybe have an idea what I'm doing wrong or how I get qemu to provide me any useful information on what went wrong?
[1] https://blog.agchapman.com/using-qemu-to-emulate-a-raspberry-pi/
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful.
In particular, the QEMU 'versatilepb' machine is completely different to the Raspberry Pi. Any working set of instructions that use that machine type are really running a kernel built to work with the versatilepb board and a raspi userspace/filesystem on top of that. You're trying to build a kernel that has support for only the raspi on a machine that isn't a raspi, which won't work.
It is possible to build a kernel that works on more than one piece of Arm hardware, if you compile in the support for both board types (all the device drivers for both, etc). If you want to go down that path, I would suggest looking at the differences between the kernel config for the kernel that works and your one, and add plausible looking missing things until you find out what is actually required.
Your attempt to boot on QEMU directly from sdcard.img will not work, because QEMU's versatilepb board model does not support direct boot from sdcard (this would require us to run some kind of BIOS/firmware image in the guest, which we don't have). For versatilepb you need to supply directly to QEMU the kernel, possibly an initrd, and definitely the correct dtb for the versatilepb.
You might instead try looking at QEMU's "raspi2" and "raspi3" board models, which really do model the hardware of Raspberry Pis. The disadvantages however are that these models are missing some features and are not very actively developed, so often newer kernels don't boot on them, and also since there is no USB controller model there is no way to get networking. (This is why most blog posts etc suggest using the 'versatilepb' -- userspace doesn't often really care about exactly what hardware it's running on, so unless you're trying to do kernel development you can just run a versatilepb kernel and take advantage of the features like networking that that QEMU model has.)
Advanced Linux Sound Architecture (ALSA) tries to open audio interface device . you must provide audio device in qemu . Because the kernel is compiled with ALSA audio driver and you have compiled sdl library in Buildroot.

kernel module insertion issue

We are running the latest raspibian on the raspberry pi board and have a kernel driver for a USB peripheral which is added externally (sudo insmod driverx.ko) after boot-up by connecting to the hardware using ssh (its a headless system).
The problem is as follows:
If the device is already connected to the system upon power-up then running sudo insmod driverx.ko leads to the terminal getting stuck (no response, Ctrl+C doesn't work). Running lsmod by starting another ssh session shows that the module is in use even though there is no code running that will use it.
If I plug the USB device after the system boots up then sudo insmod driverx.ko works normally, (the terminal is still active). Running lsmod subsequently shows that that module is loaded but not in use by anyone. I can then run my user code and everything is fine. Upon running my user code lsmod shows the kernel module is in use and the number of users is 1.
In our system the USB device will always be plugged in. The kernel version and the driver version are the same.
I can fill in more details but do not wish to bias or make this query un-readble.
Please advise on what could the problem be.
Thank you for your time and help.
Possibility is that, the device is already attached into some other driver during startup. If it’s the case, the device credential of your specific device has to be removed from the startup driver.
Check the USB device list before to insert your driver.

Read Battery Percentage of iPhone via WLAN

I found an app that shows the battery percentage of my iPhone in the menu bar (iBetterCharge). The iPhone is not connected via USB or Bluetooth (it is only connected to the same network as my Macbook).
My question is: How can I get this information? The device shows up in IOReg, but only because I connected my phone via Bluetooth once.
This can be done by using the unix application "libimobiledevice". I'm not sure that it works with all versions of iOS.
//install it:
brew install libimobiledevice
//list all device
idevice_id --list // list available device UDIDs. Normally, we have to plug the device at least once to get its UUID.
//get the current syslog of device that we want to check
idevicesyslog -u <device udid>
//do some text search to get the battery info
//or running ideviceinfo (I don't know if it works wirelessly)
//run 'ideviceinfo --help' to see how it works
ideviceinfo -u <device udid> --domain com.apple.mobile.battery
More read at:
https://www.theiphonewiki.com/wiki/MobileDevice_Library

LIRC irsend: could not connect to socket irsend: No such file or directory

I am trying to configure LIRC to work with my Raspberry 2B and a circuit I build with a transistor and a IR transmitter as explained in this tutorial
After the installation of LIRC, I followed all the steps and I added these two lines in /etc/modules
lirc_dev
lirc_rpi gpio_out_pin=36
Then I typed this in /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
After rebooting, I added the configuration of my Samsung remote (BN59-00516A) to /etc/lirc/lircd.conf
Then I restarted LIRC again but when I run a command to send a IR frequency
irsend SEND_ONCE Samsung_BN59-00865A KEY_POWER
it complains with the following error:
irsend: could not connect to socket
irsend: No such file or directory
I am guessing this is a problem with my device socket, because in the hardware.conf file I set
DEVICE = "/dev/lirc0"
(just because the tutorial states it), but lirc0 file isn't within the folder.
I couldn't find any other question related to this problem and google didn't help me much either. Does anyone have any hint on this?
After googling a lot, I found out an update is needed to have everything working properly. In my case I did:
apt-get update, apt-get upgrade, rpi-update
Also, as pointed out in this other tutorial, depending on the Raspberry firmware, you might need to add this to /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=XX,gpio_out_pin=YY
Substitute X and Y for whatever pins you're using!
I had a similar problem and I solved it with this command:
sudo lircd --device /dev/lirc0
If you set the value of LIRCD_ARGS in /etc/lirc/hardware.conf to "--device /dev/lirc0", it should start lircd appropriately, when /etc/init.d/lirc is started at boot.
you need to run lircd. It will create two files (lircd and lircd.pid) at /var/run/lirc/:
lircd
I got the same error messages. But had all configurations done. The restart of the lirc daemon solved this issue by typing
$ sudo /etc/init.d/lirc restart
I think is useful to say that the gpio_in_pin=XX,gpio_out_pin=YY part of the /etc/modules can be double checked with
dmesg | grep lirc
which results in something like
[ 3.437499] lirc_dev: IR Remote Control driver registered, major 244
[ 5.472916] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.621156] lirc_rpi: auto-detected active high receiver on GPIO pin 22
[ 6.622515] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.622528] lirc_rpi: driver registered!
for /etc/modules containing
lirc_dev
lirc_rpi gpio_in_pin=23 gpio_out_pin=22