There is a 100 device limit in Android for the maximum number of paired Bluetooth devices. This causes problems for my App used for reading the meter status.
Solutions
Multiple solutions to the problem looks possible.
* Solutions that replace the Bluetooth lib library all require some form of rooting the device.
* Use AOSP and GSI to update system image of device.
* Manufacturers use different solutions for partitioning etc. of phones so it’s very hard to create a portable solution even when using GSI.
* Replace only the Bluetooth library
Replacing only the lib may be more general, but it also requires rooting and installation of TWRP.
* Use the ndk to patch/replace the pairing code or try to integrate the App deeper in the stack
There is an interesting old paten for “Centralized Bluetooth Device Pairing”
* Patch of Bluetooth library
The idea is to just change BTM_SEC_MAX_DEVICE_RECORDS variable. If we can change or override this variable outside in some configuration file and do not build source is more desirable.
If we can just build and replace component which allow it to keep more then 100 paired Bluetooth device is ideal
The below code seems to be culprit
According to the Bluetooth implementation, if there are more than 100 device records the allocation will fail. The responsible BTM_SEC_MAX_DEVICE_RECORDS is defined in bt_target.h:
/* The number of security records for peer devices. */
#ifndef BTM_SEC_MAX_DEVICE_RECORDS
#define BTM_SEC_MAX_DEVICE_RECORDS 100
#endif
This is then used inside btm_dev.c, specifically in BTM_SecAddDevice which returns false after 100 pairings:
/* There is no device record, allocate one.
* If we can not find an empty spot for this one, let it fail. */
for (i = 0; i < BTM_SEC_MAX_DEVICE_RECORDS; i++)
Query
* If I update the #define BTM_SEC_MAX_DEVICE_RECORDS from 100 to lets say 1000, do I need to build the complete GIS image and install.
* Or, can I only update the BT library?
* Or, any other methods?
Related
On a rooted Nook Tablet, you can access a FAT partition at mount point /rom. Under the "devconf" directory is a configuration file titled "OperatingMode". Right now it contains the value "Normal" (no trailing CR or LF). The Nook Color did not have this file.
One area of experimentation is to rename that file (to save it), and then create a replacement one with various values, rebooting each time; eg:
mount -o remount,rw /rom /rom
cd /rom/devconf
mv OperatingMode OperatingMode.org
echo -n "Debug" > OperatingMode (the "-n" option suppresses the writing of a LF)
Other values to try are "Test", "Admin", "Update", "Factory", etc. Who know if any values will affect rooting, checking for signing, etc.
WARNING: I have no idea if doing any of this will brick your device. Experiment at your own peril.
EDIT: Please don't ask me what various values will do. Read the above. I don't know. That's why I posted this as an experiment for others to try if they wish.
Have you tried this? Any idea why it would do?
Perhaps try "Debug"?
I found this, maybe it's something related.
I wonder if that's a file which might reflect what boot mode the device is in - that is, the range of values can be set using variations on the reboot command. Some devices write files at boot time, or rewrite them, to create known states at each boot. (The yp-g70 recreates its LED configuration, badly, on every boot.)
The "OEM reboot codes" section of http://tjworld.net/wiki/Android/HTC/Vision/BootProcess#FastBootRestart
discusses a number of reboot flags that can be passed via ADB. Depending on what flag is passed, they put the device in different modes.
It might be interesting to try passing commands via adb reboot options and see if the file content is changed - but you'd need to be able to interrupt the boot process *and* have a viable ADB shell or other way to pull data from the device to do that. I don't know of a way to do that, but it might be possible -- I think I've seen NTs booting Clockwork now, and at least some CWR boot modes have ADB support, or used to.
Various commands issued to rebooted to bootloader phnes have been used to help unlock bootloaders, eg,
http://www.androidcentral.com/how-unlock-galaxy-nexus-bootloader is a discussion of this on the Galaxy
I may not understand that and I may be wrong.
I just searched through the source. I'd say this is likely for the Nook app or something.
Code:
[email protected]:~/Desktop/nook_tablet_1-4_Source$ grep -r "OperatingMode" ./
./kernel/android-2.6.35/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3xxx.c:| Function Name : int i_APCI3XXX_AnalogInputConfigOperatingMode |
./kernel/android-2.6.35/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3xxx.c:static int i_APCI3XXX_AnalogInputConfigOperatingMode(struct comedi_device *dev,
./kernel/android-2.6.35/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3xxx.c: i_APCI3XXX_AnalogInputConfigOperatingMode(dev,
Code:
[email protected]:~/Desktop/nook_tablet_1-4_Source$ grep -r "Operating Mode" ./
./kernel/android-2.6.35/drivers/staging/rt2860/rtmp_def.h:/* 802.11n Operating Mode Definition. 0-3 also used in ASICUPdateProtect switch case */
./kernel/android-2.6.35/drivers/net/stmmac/dwmac100.h:#define MAC_CONTROL_OM 0x00200000 /* Loopback Operating Mode */
./kernel/android-2.6.35/drivers/net/tulip/dmfe.c: /* Operating Mode Check */
./kernel/android-2.6.35/drivers/net/tulip/de4x5.h:#define OMR_OM 0x00000c00 /* Operating Mode */
./kernel/android-2.6.35/drivers/net/tulip/de4x5.c: s32 csr6; /* Saved Operating Mode Reg. */
./kernel/android-2.6.35/drivers/net/wan/lmc/lmc_var.h:#define TULIP_CMD_OPERMODE 0x00000C00L /* (RW) Operating Mode */
./kernel/android-2.6.35/arch/blackfin/mach-bf548/include/mach/defBF54x_base.h:#define CNTMODE 0x700 /* Counter Operating Mode */
./kernel/android-2.6.35/arch/blackfin/mach-bf548/include/mach/defBF54x_base.h:#define XFR_TYPE 0xc /* Operating Mode */
./kernel/android-2.6.35/arch/blackfin/mach-bf518/include/mach/defBF516.h:#define EMAC_OPMODE 0xFFC03000 /* Operating Mode Register */
./kernel/android-2.6.35/arch/blackfin/mach-bf518/include/mach/defBF51x_base.h:#define CNTMODE 0x700 /* Counter Operating Mode */
./kernel/android-2.6.35/arch/blackfin/mach-bf527/include/mach/defBF527.h:#define EMAC_OPMODE 0xFFC03000 /* Operating Mode Register */
./kernel/android-2.6.35/arch/blackfin/mach-bf527/include/mach/defBF52x_base.h:#define CNTMODE 0x700 /* Counter Operating Mode */
./kernel/android-2.6.35/arch/blackfin/mach-bf537/include/mach/defBF537.h:#define EMAC_OPMODE 0xFFC03000 /* Operating Mode Register */
./kernel/android-2.6.35/arch/arm/mach-at91/include/mach/at91rm9200_mc.h:#define AT91_BFC_BFCOM (3 << 0) /* Burst Flash Controller Operating Mode */
./kernel/android-2.6.35/Documentation/power/regulator/consumer.txt:5. Regulator Operating Mode Control & Status (dynamic drivers)
grep: warning: ./android/alsa-lib/include/alsa: recursive directory loop
./u-boot/include/asm-mips/inca-ip.h:/***SCC Control Register (Operating Mode)***/
./u-boot/include/asm-mips/inca-ip.h:/***SCC Control Register (Operating Mode)***/
./u-boot/board/tqm8xx/tqm8xx.c: * | +----------- Operating Mode = Standard
./u-boot/board/LEOX/elpt860/elpt860.c: * | +----------- Operating Mode = Standard
Did anyone get http://labs.teague.com/projects/ChordedKeyboard/ working on A10.1IT G8?
we have multitouch but with just up to 2 points.
So u can't play a piano with more then 2 fingers at the same time...
I didn't try the app.
I've heard rumours that this is a software limitiation, not hardware.
BTW, the site I mentioned is not an app, it's a web page.
sciurius said:
I've heard rumours that this is a software limitiation, not hardware.
Click to expand...
Click to collapse
As far as I could understand, it's a "software limitation", but the problem is that to eliminate this limitation, a new touchscreen driver must be written. Honestly, I think that even if all needed specs and sources for it are available (I doubt it), there're not many people around able to write device drivers, and even less are interested in developing this particular driver...
A bit of info about A101g8 is here: http://forum.xda-developers.com/showpost.php?p=21095289&postcount=60
In GPL'ed 2.6.29-omap1 gen8 kernel touchscreen driver is called "hanvon" (probably, after Hanvon-10, a Chinese tablet), and also a generic dualtouch driver for Pixcir is included in the latest mainline kernels.
oh if it software realtes we schold be able to fine some info in the datasheets of the controller - lets have a look
Thanks to schollbert we know:
Touchscreen subsystem
• Pixcir capacitiv touchscreen unit (TR16C0 controller, USB interface)
• Ti USB hub
EDIT:
hmm the "datasheet" schollbert had is a brouchure - in chineese...
but its telling 2-10 fingers... if i got it right
As far as I could understand, the touchscreen driver (hanvon.c) in GPL'ed 2.6.29-omap1 has some implementation of the "multitouch protocol A" (i.e. the old one, superseded by "protocol B" in recent mainline kernels). At least, it issues necessary ABS events.
The device itself maps to /dev/input/event3 and /dev/input/event4, but event4 seems not working.
The problem is that tslib driver (at least, its older versions) refuses to work with hanvon, because hanvon doesn't issue all necessary events out of the box (namely, it lacks ABS_PRESSURE). On some forum I found someone with similar problem and, strangely, but only a little dirty fix was needed to make hanvon and tslib friends:
Code:
--- hid-hanvon.c.old 2012-01-04 21:17:34.000000000 +0400
+++ hid-hanvon.c 2012-03-10 19:30:59.822992148 +0400
@@ -110,6 +110,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
input_event(td->dev, EV_KEY, BTN_TOUCH, 0);
+ input_event(td->dev, EV_ABS, ABS_PRESSURE, 0); // little dirty fix for tslib
input_sync(td->dev);
#endif
@@ -171,6 +172,7 @@
/* touchscreen emulation */
hid_map_usage(hi, usage, bit, max,
EV_KEY, BTN_TOUCH);
+ input_set_abs_params(hi->input, ABS_PRESSURE, 0, 1, 0, 0); // little dirty fix for tslib
return 1;
case HID_DG_TIPSWITCH:
@@ -238,6 +240,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
// issue button press
input_event(input, EV_KEY, BTN_TOUCH, 1);
+ input_event(input, EV_ABS, ABS_PRESSURE, 1); // little dirty fix for tslib
#endif
// next time, we'll only rearm timer and
// issue position update if ts emulation.
@@ -297,6 +300,7 @@
#ifdef CONFIG_HID_HANVON_10_MONO_TSP_EMULATION
// issue button release
input_event(input, EV_KEY, BTN_TOUCH, 0);
+ input_event(input, EV_ABS, ABS_PRESSURE, 0); // little dirty fix for tslib
input_sync(input);
#endif
// start debouncer.
This patch reports support of ABS_PRESSURE, and also issues this event together with BTN_TOUCH in TSP emulation mode (not sure if it's needed, though).
I'm not sure how real "multitouch" and "dualtouch" must look like, but now when I start ts_test and press two fingers in Draw mode -- it successfully draws a line between them...
In theory, it seems possible to port multitouch support from recent mainline kernels to 2.6.29-omap1, but practically it requires very good coding skills and some time.
Found this on Huawei's webpage: http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDcwODE=
open source_wlan.tar_S7_Android2.2
Would be nice if someone has the time to look at this.
The binary file that shipped with my Huawei firmware has version 4.218.248.17
Edit:
Tested and working. Forgot to update text here.
Mirrored the file for convenience for everyone who wants this. The first link actually was wrong, so I changed it.
Put this in an Android tree (such as /hardware/broadcom), do breakfast/lunch after envsetup, and perform 'make dhdko' with the kernel files present at /kernel. This is for Froyo. To build for Gingerbread, LOCAL_MODULE_TAGS cannot be equal to 'user', so you need to change Android.mk to say 'optional' instead. That's if you want to use Android.mk to build. If you are not building the whole tree, remember to make a folder /lib/modules/, or dhd.ko will not copy from the product obj folder properly.
Not sure how this will build for ICS/Jellybean, but at least now we have the source code that actually builds a proper module.
Kernel objects need to be in the right place. I did something to the effect of:
make -C kernel O=/sources/aosp/out/target/product/s7/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE=arm-eabi-
Built module works fine and is the same version shipped with Android 2.2 (4.218.248.17).
The driver is actually eerily similar to the bcm4329 kernel 3.4 bcm4329 driver. So much so i figured out what caused the sdio timeout.
Offending code causing emulate domain manager error om 2.6.35 when removed, sdio timeout when added:
dhd_linux.c:
Code:
static int
dhd_watchdog_thread(void *data)
{
dhd_info_t *dhd = (dhd_info_t *)data;
/* This thread doesn't need any user-level access,
* so get rid of all our resources
*/
#ifdef DHD_SCHED
if (dhd_watchdog_prio > 0) {
struct sched_param param;
param.sched_priority = (dhd_watchdog_prio < MAX_RT_PRIO)?
dhd_watchdog_prio:(MAX_RT_PRIO-1);
setScheduler(current, SCHED_FIFO, ¶m);
}
#endif /* DHD_SCHED */
DAEMONIZE("dhd_watchdog");
/* Run until signal received */
while (1) {
if (down_interruptible (&dhd->watchdog_sem) == 0) {
offender---------> dhd_os_sdlock(&dhd->pub);
if (dhd->pub.dongle_reset == FALSE) {
For kernels : http://threader.zapto.org/experimental/s7/wifi/bcm4329-30-09-13.tar.bz2
Hi and first thank you for reading my question!
I have a device, which gives me an output of essentially just a RS232 serial signal (1200 baud, 8 databits, no parity bits, one stop bit). This output comes in to my android phone via the 3.5mm audio jack.
I want to store every data bit into a variable, display or calculate something and when the next bits come in, it should override the variable.
I know exactly what to do with it after I thave the databits in variables but I have no idea on how to do the basic input / stream / read from audio jack thing...
More informations about my signal The payload is transmitted in 9 byte packets:
Code:
1: command byte as ASCII character ('I','A','S','L','R','C' or ' ')
2-6: time in ASCII chars (2:34:56)
7: checksum (64 + sum of time digits)
8: CR (carriage return, ASCII code 0x0D)
9: LF (line feed, ASCII code 0x0A)
I also think I have to store the input into a buffer and then read the signals from the buffer... But how do I write serial input from audio jack into a buffer?
Maybe something like this will work:
Code:
try
{
int N = AudioRecord.getMinBufferSize(8000,AudioFormat.CHANNEL_IN_MONO,AudioFormat.ENCODING_PCM_16BIT);
recorder = new AudioRecord(AudioSource.MIC, 1200, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, N*10);
track = new AudioTrack(AudioManager.STREAM_MUSIC, 1200,
AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, N*10, AudioTrack.MODE_STREAM);
recorder.startRecording();
track.play();
/*
* Loops until something outside of this thread stops it.
* Reads the data from the recorder and writes it to the audio track for playback.
*/
while(!stopped)
{
Log.i("Map", "Writing new data to buffer");
short[] buffer = buffers[ix++ % buffers.length];
N = recorder.read(buffer,0,buffer.length);
track.write(buffer, 0, buffer.length);
}
}
catch(Throwable x)
{
Log.w("Audio", "Error reading voice audio", x);
}
/*
* Frees the thread's resources after the loop completes so that it can be run again
*/
finally
{
recorder.stop();
recorder.release();
track.stop();
track.release();
}
}
Please help me, thank you!
Basically, there has been an app ported to Android that allows even unrooted(stock) devices to deliver a bootrom exploit to the Nintendo Switch via USB-OTG and a USB cable (or C-to-C). USB 3.0 (xHCI) devices have no issues and deliver the exploit just fine. Apparently it is not even a USB 2.0 problem but rather how the EHCI performs, as certain USB 2.0 phones actually have the xHCI controller and can run the exploit just fine. What happens is that although it can detect the connected Switch in Tegra Recovery Mode, it just doesn't do anything and gives an error in the logs, "SUMBITURB failed".
On Linux desktop systems it is similar, but the exploit can still work with a kernel patch provided by a hacking group that discovered the exploit in the first place:
Code:
--- linux-4.14.27/drivers/usb/host/ehci-hcd.c.old 2018-04-17 18:00:00.000000000 +0000
+++ linux-4.14.27/drivers/usb/host/ehci-hcd.c 2018-04-17 18:00:00.000000000 +0000
@@ -873,14 +873,6 @@
INIT_LIST_HEAD (&qtd_list);
switch (usb_pipetype (urb->pipe)) {
- case PIPE_CONTROL:
- /* qh_completions() code doesn't handle all the fault cases
- * in multi-TD control transfers. Even 1KB is rare anyway.
- */
- if (urb->transfer_buffer_length > (16 * 1024))
- return -EMSGSIZE;
- /* FALLTHROUGH */
- /* case PIPE_BULK: */
default:
if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))
return -ENOMEM;
The author of the Android port had also written a Python "hotpatch" script for desktop Linux systems:
Code:
#!/usr/bin/env python3
import os
"""
Cursed Code.
This code literally patches your kernel memory, proceed at your own risk.
Tested on Ubuntu 17.10 and Arch, x86_64. Should work on other distros, maybe even other architectures!
Run fusee-launcher.py with the "--override-checks" argument.
If you'd rather patch your drivers properly:
https://github.com/fail0verflow/shofel2/blob/master/linux-ehci-enable-large-ctl-xfers.patch
"""
ksyms = {
line[2]: int(line[0], 16)
for line in
map(lambda l: l.strip().split(),
open("/proc/kallsyms", "r").readlines())}
print(hex(ksyms["ehci_urb_enqueue"]))
patch_c = """
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/pgtable.h>
static u32 ORIG_MAX = 16*1024;
static u32 NEW_MAX = 0x1000000;
/* borrowed from MUSL because I'm lazy AF */
static char *fourbyte_memmem(const unsigned char *h, size_t k, const unsigned char *n)
{
uint32_t nw = n[0]<<24 | n[1]<<16 | n[2]<<8 | n[3];
uint32_t hw = h[0]<<24 | h[1]<<16 | h[2]<<8 | h[3];
for (h+=3, k-=3; k; k--, hw = hw<<8 | *++h)
if (hw == nw) return (char *)h-3;
return 0;
}
static pte_t* (*lookup_addr)(unsigned long, unsigned int*) = (void *) PLACE2;
static void set_addr_rw(unsigned long addr) {
unsigned int level;
pte_t *pte = lookup_addr(addr, &level);
set_pte_atomic(pte, pte_mkwrite(*pte));
}
int init_module(void) {
void * ehci_urb_enqueue_start = (void *) PLACEHOLDER;
u32 * patch_addr;
printk(KERN_INFO "Patch module loaded\\n");
patch_addr = (u32 *) fourbyte_memmem(ehci_urb_enqueue_start, 0x400, (void *)&ORIG_MAX);
if (patch_addr == NULL) {
printk(KERN_INFO "Failed to find patch site :(\\n");
return -1;
}
printk(KERN_INFO "patch_addr: 0x%px\\n", patch_addr);
set_addr_rw((unsigned long)patch_addr);
*patch_addr = NEW_MAX;
printk(KERN_INFO "Patching done!\\n");
return -1;
}
""".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2", hex(ksyms["lookup_address"]))
makefile = """
obj-m += patch.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
"""
with open("patch.c", "w") as patchfile:
patchfile.write(patch_c)
with open("Makefile", "w") as mf:
mf.write(makefile)
os.system("make")
print("About to insert patch module, 'Operation not permitted' means it probably worked, check dmesg output.")
os.system("insmod patch.ko")
I tried to see if running it in Termux would do anything but I got the following error:
Code:
0x0
Traceback (most recent call last):
File "ehci_patch.py", line 70, in <module>
" " ".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2" hex(ksyms["lookup_address"]))
KeyError: 'lookup_address'
I know that script isn't meant for use on Android anyway but maybe it can lead to a solution. The author of it does not know how to go about it at this time either, but believes an entire recompile of the kernel would be necessary. I am hoping that something like a systemless Magisk module would be the easiest solution for users but do not know if that is possible. I am only guessing it might be possible to create a Magisk module because of audio drivers like VIPER4Android. If indeed a custom kernel is needed, does anyone know how to go about it? It could be difficult to implement for everyone because not everyone has a device where the source to the kernel is available, etc. I am willing, however, to test anything on my tablet which is USB 2.0 and gives the error in the app. Any advice for how to go about this will be greatly appreciated.
I feel ya man, i need this stuff too. NXLoader doesn't work on my Galaxy Grand Prime (G530T) and i really need it to Dx