I want to change of Bluetooth pairing timeout in AOSP? - android

I want to change Bluetooth pairing timeout but I didn't find the relevant variable in AOSP 10 source tree. I found some answers but they are changing it via ADB shell/script but I don't want to use this method. I need to change relevant places and re-build the source.
Regards

According to the Bluetooth Core Specification the timeout has a fixed value of 30 seconds. So you may not be able to change this value.
See also chapter "Vol 3: Host / Part H: Security Manager Specification / 3 Security Manager Protocol / 3.4 SMP timeout"

Related

How to enable second SPI channel of Raspberry Pi 3 on Android Things?

I'm trying to get second SPI channel spidev1.x by adding the code below into config.txt on Raspberry Pi 3.
dtparam=spi=on
dtoverlay=spi0-hw-cs
dtoverlay=spi1-1cs
So far I get spidev0.x under folder /dev, but not spidev1.x. The code above works on Raspbian. Is there a method to enable second SPI channel for AT?
The issue here divides into two parts:
Enabling the spidev driver in the kernel.
Accessing SPI1 using the SpiDevice APIs provided by Peripheral I/O.
Since you cannot see /dev/spidev1.x in the kernel, both problems are at hand.
For issue #1, there seems to be a link between the usage of UART0 and SPI1 as noted in this RPi forum post. In the latest preview of Android Things (DP2), UART0 is currently shared with the console and routed to the GPIO header pins for use by apps. It's possible that you might have to disable UART0 in order to get SPI1 to work at the kernel level.
However, regarding issue #2, the Peripheral I/O APIs do not currently expose SPI1 in Android Things DP2. So even with the kernel issue resolved there would not be a direct way to access the port from an app. We are working on ways to enable additional ports outside of those pre-defined at build time, but do not have a solution at this time.

Editing Functionality of Host Card Emulation in Android

I'm currently in the process of developing a project for my University course wherein I will be hopefully editing the functionality of the HCE Feature of Android to allow me to set my own UID when emulating a card.
Now, i've downloaded the AOSP source, and built a custom image with no edited code and installed that to my Nexus 7 (This includes downloading and including the Vendor specific hardware drivers), and i'm stuck on the next part.
I physically cannot find the device code that governs the NFC features of Android, and i'm unsure how to go about a) Looking for it, and b) How I should be editing this code.
Is the code for NFC in Android in the base Kernel? and if so how would I edit that before I run "make" again and hope it builds? or is it elsewhere? I've noticed that the files in the Vendor folder i've downloaded and extracted are in a .ncd format, which I don't think is editable.
Any help I can get on this would be greatly appreciated.
Ok ! So i've found a solution to the problem I was having!
On the Nexus 7, when the NFC is turned on, it gets its information from a config file in "/etc/" called "libnfc-brcm-20791b05.conf"
Inside of this file there is a parameter called "NFA_DM_START_UP_CFG"
By default, it looks like this:
NFA_DM_START_UP_CFG={42:CB:01:01:A5:01:01:CA:14:00:00:00:00:0E:C0:D4:01:00:0F:00:00:00:00:C0:C6:2D:00:14:0A:B5:03:01:02:FF:80:01:01:C9:03:03:0F:AB:5B:01:00:B2:04:E8:03:00:00:CF:02:02:08:B1:06:00:20:00:00:00:12:C2:02:01:C8}
To edit the UID that is generated at Emulation, you need to add some bytes to the end of this parameter.
The first byte you add is 0x33 (This means that you are going to manually set the UID)
The second byte that is added is the length of the UID you wish to set (This can be either 4,7 or 10 bytes, so this second byte can be 0x04, 0x07 or 0x0A)
The next bytes are then the ID you wish to set! (NOTE: Depending on how many Bytes you add, you should change the first byte of the array to reflect the new size of the array - it starts at 42, so if you were to add 6 bytes it should change to 48)
For example, if you wished to set a 7 byte ID of 01 02 03 04 05 06 07, the new config line would look like this:
NFA_DM_START_UP_CFG={4B:CB:01:01:A5:01:01:CA:14:00:00:00:00:0E:C0:D4:01:00:0F:00:00:00:00:C0:C6:2D:00:14:0A:B5:03:01:02:FF:80:01:01:C9:03:03:0F:AB:5B:01:00:B2:04:E8:03:00:00:CF:02:02:08:B1:06:00:20:00:00:00:12:C2:02:01:C8:33:07:01:02:03:04:05:06:07}
You can then push this config file to your nexus device using adb:
-> adb root
-> adb remount
-> adb push libnfc-brcm-20791b05.conf /etc/
-> adb reboot
This will reset the Nexus with the new config file in, and upon emulation the UID will now be set to 01 02 03 04 05 06 07
Hope this helps anyone reading my question!
Android's NFC stack is basically split into five parts:
The NFC interface device driver. This is part of the kernel. In a nutshell, this driver simply tunnels data frames (e.g. NCI protocol frames) between a character device file and the NFC controller hardware. You won't have to touch that part for your project.
The low-level interface library written in C (libnfc-nci, or libnfc-nxp for devices with NXP's PN544 NFC controller). This library provides a set of high-level functions to interact with the NFC controller. So it basically translates high-level functionality (e.g. "start polling for technologies X, Y and Z") into NCI commands that are sent to the NFC controller through the kernel driver. This is certainly a place where you will need to add modifications. As it's part of AOSP you can compile it using the normal AOSP build system.
The JNI interface library written in C++ (libnfc_nci_jni). This layer connects the libnfc-nci C library with high-level Java code. If you want to modify the emulated UID from Android apps, this is certainly a place where you will need to add modifications. As it's part of AOSP you can compile it using the normal AOSP build system.
The Android NFC system service written in Java. This service takes control over the whole NFC stack and implements the high-level functionality based on the resources provided by libnfc-nci. If you want to modify the emulated UID from Android apps, this is certainly a place where you will need to add modifications. As it's part of AOSP you can compile it using the normal AOSP build system.
The Android core framework provides an API to the functionality of the NFC system service that can be accessed by Android apps.
With regard to setting/modifying the emulated UID you will certainly want to have a look at these projects that I recently published on GitHub (though they are still work in progress):
https://github.com/mobilesec/swr50-android-external_libnfc-nci
https://github.com/mobilesec/swr50-android-packages_apps_nfcwatch1

Communicate via SPI in Android

Currently I'm looking for a solution to communicate via SPI in Android. I installed the NDK on my system and used the native classes to communicate with the GPIO´s (/sys/class/gpio/gpioxx/value) on my Wandboard. It works fine. So the principle to use the NDK or C code in Android is clear for me. Unfortunately I can't find any SPI devices /dev/… . I only find I²C devices. Can somebody tell me, if android basically offers SPI? And if it is possible, where I can find the device? Can I communicate in the same way like with Linux?
thanks
This is an answer to a very old question but it could still be valuable for someone else
Often by default /dev/spidev0.0 is not enabled. It must be enabled both in the kernel during build time and device tree during runtime.
The first step is to change linux kernel build configuration to enable spidev by adding
CONFIG_SPI_SPIDEV=y
And in the device tree (one of the dts files) add a spidev leaf to the spi device you wish to map to connect to.
This is an example for hikey960 and spi3 on the high-speed connector other boards will be slightly different
&spi3 {
/* On High speed expansion */
label = "HS-SPI1";
status = "okay";
spi-cpol=<0>;
spidev#1 {
spi-max-frequency = <5000000>;
compatible = "rohm,dh2228fv";
pl022,com-mode = <2>;
}
};
You will be able to read and write to the device /dev/spidev0.0 with a simple cat > /dev/spidev0.0 and cat </dev/spidev0.0 but ioctl must be used for more complex options e.g. reconfiguration of speed, change polarity, and full duplex write/read.

Simulate Slow Internet Connection on a REAL device? [duplicate]

This question already has answers here:
Simulate low bandwidth in android
(11 answers)
Closed 8 years ago.
I need to test my application in conditions where even 2G Internet connectivity isn't at its full coverage (i.e. 2 bars instead of 4, 2G).
I prefer conducting these tests over WiFi.
Is there a way (programmatically or otherwise) to tell the Android OS on the real device to slow down or throttle Internet connection 56 Kbit/s?
Note: I know how to do this on the emulator. I'm looking for a way to do this on a real device.
Is this possible?
In one of your comments you mentioned that you have a DD-WRT router, which is really a tiny Linux box. So you may be able to get a way with the tc command:
tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit allot 1500 prio 5 bounded isolated
tc filter add dev $DEV parent 1: protocol ip prio 16 u32 match ip dst 195.96.96.97 flowid 1:1
It kind of depends on what you have on the upstream side. If you're transmitting some kind of test load, write a driver at the upstream end that does, in fact, slow itself down -- although sleep() is a bad choice. What you'll be writing is essentially a fairly hard real-time program if you hope to get anything resembling a real workload.
(When I say "a driver" btw , I don't mean necessarily a device driver, just some kind of driver program.)
But are you really trying to simulate a slow connection, or a degraded and noisy connection that has a low effective data rate?

Android - Bluetooth - Limit Scan range

I am currently making an Android utility related to Bluetooth, and I need to change the device discovery range of my device..
Is there a way for me to do so? I am currently looking into using the TPL to do this, but I am not so sure..
Either an Android application or changes in the kernel are possible.
Thank you very much.. :)
You seem to be on the right track. To reduce the range you would need to reduce the Tx power while searching and this should be possible through the HCI command hci_write_inquiry_transmit_power_level (external/bluetooth/bluez/lib/bluetooth/hci_lib.h)
You need to figure out how this is done in Bluez (if it is being used) and then extend it to use in your application.

Categories

Resources