I write simple program to get various information: signal strength, cell info etc... To test I use two phones with the same Android version 2.1 - Sony Ericsson and Samsung Galaxy Spice.
To extract Neighbour Cell Info I use:
telephonyConnectionAdapter.getNeighboringCellInfos()
On SE I am able to get Neighbour Cell info and in adb logcat -b radio I can see:
D/GSM ( 488): [GsmSST] Poll ServiceState done: oldSS=[0 home T-Mobile.pl
T- Mobile.pl 26002 EDGE:2 CSS not supported -1 -1 RoamInd=-1 DefRoamInd=-1
EmergOnly=false] newSS=[0 home T-Mobile.pl T-Mobile.pl 26002 EDGE:2 CSS not
supported -1 -1 RoamInd=-1 DefRoamInd=-1 EmergOnly=false] oldGprs=0 newData=0
oldMaxDataCalls=20 mNewMaxDataCalls=20
oldReasonDataDenied=-1 mNewReasonDataDenied=-1 oldType=EDGE:2 newType=EDGE:2
D/GSM ( 488): [EONS] Reading data from EF_OPL or EF_PNN is not complete.
Suppress operator name display until all EF_OPL/EF_PNN data is read.
D/RILJ ( 488): [8847]> REQUEST_GET_NEIGHBORING_CELL_IDS
D/RILJ ( 488): [8847]< REQUEST_GET_NEIGHBORING_CELL_IDS [b01b59c7#18 [b01b5260#27] [] [b01b63f9#19] [b01b2f4f#17]
but the same application could not extract Neighbour Cell Info on Samsung - the list is empty and adb logcat -b radio looks:
D/GSM ( 1993): Poll ServiceState done: oldSS=[0 home Play Play 26006 (manual)
EDGE CSS not supported -1 -1RoamInd: -1DefRoamInd: -1] newSS=[0 home Play Play
26006 (manual) EDGE CSS not supported -1 -1RoamInd: -1DefRoamInd: -1] oldGprs=0
newGprs=0 oldType=EDGE newType=EDGE D/RILJ ( 1993): [5590]> REQUEST_GET_NEIGHBORING_CELL_IDS
D/RILC ( 1855): [5590]> GET_NEIGHBORING_CELL_IDS
D/RILC ( 1855): [5590]< GET_NEIGHBORING_CELL_IDS fails by E_REQUEST_NOT_SUPPORTED
D/RILJ ( 1993): [5590]< REQUEST_GET_NEIGHBORING_CELL_IDS error: com.android.internal.telephony.CommandException: REQUEST_NOT_SUPPORTED
The is one more important information. When I use magic code *#*#197328640#*#* on Samsung and enter to service menu. There are few visible Neighbour Cells.
Any idea what is going on? Or at least what does this mean?
"com.android.internal.telephony.CommandException: REQUEST_NOT_SUPPORTED"
Each manufacturer implements the low level functionality for their devices as they see fit. In this case, Samsung has decided not to support this feature on this device. This means that you will not be able to get the list of neighboring cells on this device.
Related
Many Android devices with AMOLED screens display all images with oversaturated colors by default. E.g. Samsung Galaxy phones have the "Adaptive" screen mode, which forces windows of all apps to be displayed as if they were rendered in the native screen color space, which is wider than Display-P3.
OTOH, not all such devices support EGL_EXT_gl_colorspace_display_p3, regardless of screen mode, so I can't be sure whether the device my app is running on even has a wide-gamut screen, even less determine whether this mode is the default.
So, how can I actually determine whether current screen mode is sRGB or some wide-gamut mode? I'm targeting one specific device model, Samsung Galaxy A320F/DS (AKA "A3 (2017)"), so platform-specific ways are also OK.
There are several layers where colors can be manipulated.
SurfaceFlinger. This component is common to all Android systems. One can pass a custom color matrix to it (see the source code of the handler of this request) via e.g. the following command executed as the root user:
service call SurfaceFlinger 1015 i32 1 \
f 0 f 0 f 1 f 0 \
f 0 f 1 f 0 f 0 \
f 1 f 0 f 0 f 0 \
f 0 f 0 f 0 f 1
The above example command sets a matrix that will, acting on RGBA vectors, swap red and blue channels. To reset the custom matrix to default (identity) you can simply do
service call SurfaceFlinger 1015 i32 0
You might be able to do all this from a Java/JNI app without root privileges, simply asking for some permission, I didn't research this.
mDNIe, which stands for mobile Digital Natural Image engine. It's a Samsung-specific system that acts on a lower level than SurfaceFlinger. Namely, it affects Always On Display, on which SurfaceFlinger's custom color matrix doesn't have any effect.
Current screen mode can be seen in the /sys/class/mdnie/mdnie/mode file, which appears to have the following mapping of values on Galaxy A320F/DS:
0 — AMOLED cinema (apparently aims at Display-P3),
1 — AMOLED photo (apparently aims at Adobe RGB),
2 — Basic (aims at sRGB),
3 — (don't know its purpose, but the value is accepted if written to mode)
4 — Adaptive display (the widest, apparently native screen color space).
5 — (don't know its purpose, but the value is accepted if written to mode)
Moreover, the colors are also affected by the Cool — Warm slider as well as Advanced options RGB per-channel adjustments. Changes to the former are somehow reflected in mdnie_ldu and sensorRGB files in the same directory, while the latter directly corresponds to whiteRGB file.
Also, Blue light filter feature state is reflected in the night_mode file (it also influences mdnie_ldu and sensorRGB files mentioned above).
Of the files described above, only mode is readable to a non-root user on SM-A320F/DS. On SM-G950FD (AKA "S8") nothing is accessible without root.
According to Android documentation: https://developer.android.com/guide/topics/sensors/sensors_motion.html
linear acceleration = acceleration - acceleration due to gravity .
Which seems to work my 2 phones and LG Watch Urbane W150.
BUT, on my new Huawei Watch 2, linear acceleration still contains acceleration due to gravity. I'm running the same app on all devices, and only on Huawei Watch 2 I see this problem.
The command adb shell dumpsys sensorservice for LG Watch Urban W150 give this as output when the watch is lying on table:
Linear Acceleration: last 10 events
1 (ts=24353.048620089, wall=17:28:40.031) -0.92, -0.15, 0.23,
2 (ts=24353.115270480, wall=17:28:40.086) -0.79, -0.17, 0.33,
3 (ts=24353.181920870, wall=17:28:40.146) -0.75, -0.14, 0.21,
MPU6515 Accelerometer: last 50 events
1 (ts=93043.344428463, wall=12:33:30.392) -8.18, -2.35, 4.83,
2 (ts=93043.352240963, wall=12:33:30.392) -8.20, -2.35, 4.87,
3 (ts=93043.367865963, wall=12:33:30.392) -8.14, -2.35, 4.81,
As you see the x,y and z for LG watch is close to zero which is expected.
However, the same command but for Huawei Watch 2 gives:
huawei Linear Acceleration Sensor: last 10 events
1 (ts=31287.761652539, wall=17:31:07.258) -2.27, 6.58, 7.51,
2 (ts=31287.829730716, wall=17:31:07.325) -2.48, 6.41, 8.10,
3 (ts=31287.891682226, wall=17:31:07.387) -2.55, 6.60, 7.39,
BMI160 3-axis Accelerometer: last 50 events
1 (ts=100179.672482189, wall=12:39:19.258) 9.30, -3.46, 0.83,
2 (ts=100179.682469756, wall=12:39:19.258) 9.32, -3.46, 0.83,
3 (ts=100179.692457323, wall=12:39:19.258) 9.30, -3.47, 0.84,
And you see weird output for the linear acc sensor.
Is it a bug in Huawei Watch 2?
All huawei equipment have this problem, maybe the SOC design issue or the driver's math is wrong.
Tested in huawei p40 mate20 p10, all got high bias result.
When I open a link from a barcode reader that calls an action on my site the controller is called twice and the session data is reset on the second call.
If I open a browser and paste the same URL directly into it, then the controller is only called once. If I follow the same link from an email the controller is only called once.
This is happening in Firefox, Chrome, and Safari on Android and iPhone. Any clues to why opening the browser from a link would force my website to load twice?
Edit: I've tried multiple barcode readers on iPhone and Android with the same result, the page loads twice even if it is stripped down. However, it is not happening in email links as originally stated. The email links went to a different page with a different problem, when directed to the same page as the barcode scan they do not load twice. I have corrected the info above to reflect this.
Edit 2: Here are the logs from my server for an iPad following a link in a barcode scanner. Note that the first two logs are the same except the last digit.
2016-01-29 13:19:34 69.94.136.16 GET /MyPage/ABCDEF - 80 - 24.62.217.163 Mozilla/5.0+(iPad;+CPU+OS+9_2+like+Mac+OS+X)+AppleWebKit/601.1.46+(KHTML,+like+Gecko)+Mobile/13C75 - 200 0 0 93
2016-01-29 13:19:34 69.94.136.16 GET /MyPage/ABCDEF - 80 - 24.62.217.163 Mozilla/5.0+(iPad;+CPU+OS+9_2+like+Mac+OS+X)+AppleWebKit/601.1.46+(KHTML,+like+Gecko)+Mobile/13C75 - 200 0 0 109
2016-01-29 13:19:34 69.94.136.16 GET /Scripts/jquery-2.1.1.min.js - 80 - 24.62.217.163 Mozilla/5.0+(iPad;+CPU+OS+9_2+like+Mac+OS+X)+AppleWebKit/601.1.46+(KHTML,+like+Gecko)+Mobile/13C75 http://example.com/MyPage/ABCDEF 200 0 0 328
Edit 3: Here is a fairly typical version for Android from the logs:
2016-01-29 13:14:28 69.94.136.16 GET /MyPage/ABCDEF - 80 - 77.234.44.145 ZXing+(Android) - 200 0 0 125
2016-01-29 13:14:47 69.94.136.16 GET /MyPage/ABCDEF - 80 - 77.234.44.145 Mozilla/5.0+(Linux;+Android+5.1.1;+VS985+4G+Build/LMY47V)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/47.0.2526.83+Mobile+Safari/537.36 - 200 0 0 109
I found the problem for anyone else who comes here seeking. It turns out the barcode readers are calling GET so they can get the page and show its title to the user (and perhaps they get it for other reasons as well).
So, the page gets called by the reader and by the user when he follows the link. That is why a page with no images or missing links gets loaded twice from a barcode reader.
First check references on your page, maybe they are doing second request - for example if you have css or script reference with empty path. The easiest way to test that is to setup one simple view just with "Helloo" text, and try open that from link or android app.
I have a USB keypad with 0 to 9,*,#,+,-,CALL,CALLEND keys and I am using it with an Android board.
With the default android Generic.kl file, this keypad provides proper output for each key pressed (checked in a TextBox and this application).
Scan code of these are as below as per application mentioned above,
CALL - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:48 keyCode:30
KEYCODE_B
ENDCALL - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:30 keyCode:29
KEYCODE_A
STAR - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:9 keyCode:15
KEYCODE_8
POUND - META_SHIFT_ON | META_SHIFT_RIGHT_ON - scanCode:4 keyCode:10
KEYCODE_3
I need to remap it, and my custom .kl content is as follows,
key 2 1
key 3 2
key 4 3
key 5 4
key 6 5
key 7 6
key 8 7
key 9 8
key 10 9
key 11 0
key 12 VOLUME_DOWN
key 78 VOLUME_UP
key 30 ENDCALL
key 48 CALL
I have put it in /system/usr/keylayout/
Now with this change, when I am checking the scan code with same test application, I am getting scanCode:54 for the ENDCALL button which was previously 30.
I have following questions from this behavior,
What my understanding is of scan codes is that they are hardware specific and it will provide the same scan code every time whatever the software/host is? I mean scan code for keypad will not change? Which is not happening here.
I have also tried with adding file .kcm in /system/usr/keychars/ but with or without it the behaviour is the same. Do I need to use a .kcm file for it?
Yes, afaik scan codes are specific to firmware residing in hardware. i.e for keypad/keyboard devices scan code will be provided by hardware and they will be unique to distinguish keys.
In android, if you don't want to alter character map of your device, you don't need character map file(.kcm). Job of character map file is to map keycode to human readable character. If you don't provide .kcm file for your device it will use Generic.kcm file for character mapping.
You can also refer link 1 & 2 for more information.
I'm struggling with calibration of a touchscreen on Android plataform.
It is an USB Single-Touch Touchscreen from vendor 0dfc and product 0001 as checked with dmesg:
<6>[ 4118.091541] input: USB Touchscreen 0dfc:0001 as /devices/platform/usb20_host/usb2/2-1/2-1.3/2-1.3:1.0/input/input23
I'm pushing the Vendor_0dfc_Product_0001.idc file /data/system/devices/idc/ (following the documentation from android source - IDC
I got the touch device with all requirements for single touch events:
root#android:/ # getevent -il /dev/input/event3
add device 1: /dev/input/event3
bus: 0003
vendor 0dfc
product 0001
version 0202
name: "USB Touchscreen 0dfc:0001"
location: "usb-usb20_host-1.3/input0"
id: ""
version: 1.0.1
events:
KEY (0001): BTN_TOUCH
ABS (0003): ABS_X : value 540, min 0, max 32767, fuzz 0, flat 0, resolution 0
ABS_Y : value 289, min 0, max 32767, fuzz 0, flat 0, resolution 0
input props:
<none>
I also enabled the Pointer Location option from Developer options (Android settings) in order to debug this stage of calibration.
Setup 1
touch.deviceType = touchScreen
With this setup (1) all the gestures on the touchscreen take place at the up-left corner - just a few pixels left/right/up/down no matter the gesture (swipe). All the touchscreen get events. All the gestures are reversed - when swipe left the pointer goes right; when swipe up, the pointer goes down.
Setup 2
touch.deviceType = pointer
touch.gestureMode = pointer
With this setup (2), as expected, it shows a pointer, placed at the position from the last pointer device left (mouse). All the gestures on the touchscreen (no matter the swipe size) keep beaving like setup 1 - move only a few pixels with each swipe event, and with reversed axis.
Setup 3
touch.deviceType = pointer
touch.gestureMode = spots
With this setup (3) the result is the same as setup 2. I just did that to prove that the IDC file is being interpreted correctly.
At this stage, as you can check by now, I have a working IDC file (setup 1) requiring calibration for this touch device.
I tried a lot of combinations from other IDC files (internet samples) and from android source - IDC - ANY OTHER PROPERTY TOOK EFFECT (NOT A SINGLE ONE) - raw.*, output.*, touch.size.*
Does anyone knows how to calibrate properly a touch screen in Android that could guide me in this process?
Same here,
but my calibration app did't do anything.
After a while, reading /system/etc/init.sh i found the following:
mkdir -p /data/misc/tscal
touch /data/misc/tscal/pointercal
chown 1000.1000 /data/misc/tscal /data/misc/tscal/*
chmod 775 /data/misc/tscal
chmod 664 /data/misc/tscal/pointercal
Just run those commands manually, reboot, and start the calibration app