Hello,
I would like to develop an application that makes use of the accelerometer sensor on an Android smartphone.
My app needs a measurement range of +-4g. I looked for accelerometer hardware specifications for various models and found that Nexus One mounts BMA150 by Bosch Sensortec, which supports three ranges (+-2g/+-4g/+-8g).
While browsing Android source code from Nexus One, looking for bma150 driver, I read this issue:
code.google.com/p/android/issues/detail?id=8143
I wish to modify the bma150 driver to set a default range of +-4g and then write a Java app to get and use data from the sensor. By the way, as far as I understand, the driver is actually not implemented at all. Or it is just not exported to the Java API? However, if it is not implemented at all, how can the OS change the screen orientation when the user rotates the device? And if it is not exported to the Java API, what would actually happen when an app tries to read data from the sensor?
Thank you for your help,
Nhexus
Using the accelerometer is pretty easy from the SDK, just google for "android accelerometer" you'll get loads of examples, like:
http://stuffthathappens.com/blog/2009/03/15/android-accelerometer/
Note the "onAccuracyChanged" method, I think the ranges/accuracy depend on the magnitude of the forces currently applied.
Hope that helps.
Thanks for the answer. I'd already had a look at the Sensor API in Android.
I was trying to understand a bit more about the driver that actually stands behind the Java API. I thought that the measurement range could be set via software (maybe via i2c communication with the device) and that it is not dynamically adapted.
However, I'm not an expert in the Android Open Source Project, so I don't clearly understand the source code structure and design. Maybe someone with an in-depth knowledge of HAL and drivers could give me some hints.
Thank you again for you help!
Hi Everybody,
I have a Toshiba AT270 (7.7", Android 4.0.3) and I want to develop a very simple application to determine the distance of users finger from the screen (a couple of mm's or 1 cm at top). In short terms ; I want to be able to read the capacitive reading of each touch-cell as numerical value not as binary like user pressed-or-not. In theory this should be possible but I don't know if the API has such a feature or not. I can dive deeper than API if one suggests a hacky workaround for reading this.
I wanted to have experienced users opinions before starting to read some docs and API.
Peace
y.
Yeah, it is possible. But seems you are trying to achieve it with Mono Droid. I exactly don't know if it supports the feature or you will have to do a bind. Btw I prefer you to search on Google and as you can see not many users wandering here, though only few interested in mono Droid.
Sorry for being ot and not helping.
Good luck
Sent from my SonyX8 using Tapatalk 2
This was released today but there does not appear to be much info on whether this is already in the wild. It would be almost undetectable.
Apparently it is possible to use statistical analysis of the size of the surfaceflinger off-screen buffer to predict with 90% accuracy what another app is doing. All an attacker needs is an application that runs in the background, and does not require any special permissions. Once it determines that a user is entering his password, for example, it can bring to the foreground an identical looking password dialog and capture the login data. Since the user expects this behavior, they may never notice.
So far all I could find is the actual paper:
cs.ucr.edu/~zhiyunq/pub/sec14_android_activity_inference.pdf
And some videos of a proof of concept have been posted:
f2bbs.com/thread/2234
The question is: has this been seen in the wild? Seems like a very serious threat without an obvious fix...
I own a JFLTEVZW i545, but I understand that this affects other variants as well.
I'm not a developer, but in the last 4 weeks or so, I've been trying to learn more about android, linux, and kernels. Hopefully what I've come up with can be attempted by someone with a more advanced skill set, because although I've had what appears to be success in attempted fixes, I really don't know if I'm implementing the changes appropriately because I don't see the appropriate fix. I'm also wasting many, MANY hours (200-300?) learning, tinkering, and waiting on compiling because I'm not skilled enough to make a quick change that I want, or to implement that change easily, without a complete recompile (which costs me 2 hours each time). Someone who is more knowledgeable with kernels and building/compiling from source could probably do everything I'm doing in 1%, or less, of the time that I'm doing it.
Core issue:
The magnetometer's X and Z axes are off 180degrees. This has been a consistent issue since early/mid 2014 builds in both CM11 and CM12, as well as CM12.1 (as of a few days ago when I last tested). This causes problems with navigation and multiple user apps.
Ways to experience the issue:
If you aren't familiar with this bug, or if you're of the opinion that the compass doesn't have any problems, fire up google sky and you'll see that things are wonky when the phone flips around crazily and none of the constellations, planets, or moon are where they should be via the augmented reality. This app is NOT incompatible--the data it's being fed is erroneous.
Alternatively, you can use Physics Toolbox Sensor Suite to view the true raw data (other sensor apps are either adulterated or show false or useless data). With this, the sections I've found most worth looking at are the Linear Accelerometer, Magnetometer, and Orientation, and you can compare the data to an OEM phone if you have another one handy.
For the magnetometer, I've found that the absolute best way to calibrate it is by performing a figure-8 movement in three-dimensional space, rather than two-dimensional as shown in some apps and videos, or by the method mentioned in GPS Status & Toolbox. See this video for an example. I perform a larger figure-8 and do it multiple times--once can work, but a few times really settles it down.
What aren't contributing factors:
Calibration
Hardware malfunction (many others have confirmed)
App malfunction
Magnetometer driver source code (note: the code itself in the files I've looked at are the same as Samsung's source, but the way in which it's implemented may not be)
Please keep in mind that because I'm very new to this, I don't have instant intuitive feedback to know how to confirm these things in the contributing factors or possible solutions. I really need to pass the reigns on this one to someone much more advanced than myself, who will see this post and churn out the fix in a half hour.
Possible contributing factors (could be more than this):
Driver implementation. The source in /kernel/samsung/jf/drivers/sensors/ is new, and OEM, but I don't see it compiling.
Driver implementation. I'm having difficulty knowing which source files from Samsung need to be dropped in to try and compile a kernel without CM modifications which pertain to the sensors. I also have significant difficulty knowing if it succeeded, correctly, rather than something in CM taking over and undoing my changes. This is the case for one particular thing, so I have no idea how to confirm the things that I can't readily see.
Sensor(s) orientation configuration(s).
Possible solutions:
Should /kernel/samsung/jf/drivers/sensors/ actually be compiling? I don't think it is (because I don't see the folder), or even know if it's necessary for our phones, but Samsung has it in their source and I cannot successfully compile Samsung source to try and compare. I also don't know if it gets merged in with other files somewhere else.
Dropping in all OEM necessary files and compiling, without CM interrupting. I don't understand linux and the filesystem enough to know what happens when, and I've resorted to using shred/srm to try and truly delete files, but I still struggle with understanding what's going on. I also don't know what encompasses a swap like this. I don't know if replacing sensorhub is all that needs to be done or if there are 3 other files in completely different directories that are critical, and must overwrite the CM modifications for things to compile appropriately.
Setting sensor orientation correctly with CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=0, CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=0, CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=0 being different values than zero.
I've tried the first two and had intermittent success. Sometimes things compile, sometimes they don't. But I also don't know if what I'm changing even matters. I've been checking file hashes to see when things change, but it's becoming tedious and someone who knows all of the linux commands and knows how the source gets compiled would know without having to check.
My favorite possible solution is the third. This is in the .config file which is made by the make menuconfig process, which I believe is influenced by various defcofig files. I've tried changing the .config directly, but CM undoes that. I've tried adding those lines to the defconfig files, but CM either undoes or ignores that. I've tried compiling a kernel outside of compiling CM as a whole and am hitting roadblocks with my lack of experience and knowledge. I've successfully compiled kernels, but I don't even know if my changes are sticking. I've taken what I though may have been an appropriately compiled kernel (Image and zImage) by modifying the .config and then manually doing a make zImage, but even dropping those in to compile with CM, chmod 555, chown/chgrp root and CM somehow manages to overwrite the renamed zImage-->kernel file, but it would actually leave them alone when I did all that nonsense to the Image and zImage in their normal output spot, /arch/arm/boot/kernel/ I believe.
The third possible solution sets how the sensors are physically placed within the phone. If the readings are off by right-angles, it seems that a coding change for one or more of these would be appropriate:
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=0
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=0
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=0
I've had no success in making this happen, but as I said, someone who is a genuine programmer would be able to make these things happen and compile and test quickly...rather than me spend an entire day trying 20 different ways to see if I can get something to stick, and then not even being able to confirm if what I changed, actually made its way into the final compiled files.
Hopefully someone is willing to take a stab at this, because I'm apparently the equivalent of an elderly person having their first encounter with a computer when it comes to this stuff. It seems so simple, but I'm not the one to make it happen, and I feel like this may be the route to take. Thanks, y'all!
EDIT: I've tried other methods to make this work that I didn't list, I just can't remember everything and my mind is breaking down after going at this for about 13 hours straight today.
I suppose you own a Verizon phone, the unique with Compass issue. I'm currently helping jfltevzw guys to find a fix, and still nothing real even after some tries...
Already tried to change magnetometer physical angle (the correct value must be 3 or 5 according to board-jf_vzw), but if you think: even in CM10.2 the MAGNETOMETER_POSITION was 0
I'm going to try some other things...
Sorry, yes, I own a JFLTEVZW
What are your thoughts on the new "sensors" source folder and it seemingly not being compiled/built? The \Kernel\drivers\sensors\geomagnetic\Kconfig has a completely separate orientation reference of INPUT_YAS_MAGNETOMETER_POSITION:
Code:
#
# Copyright (c) 2010 Yamaha Corporation
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
# USA.
#
config INPUT_YAS_MAGNETOMETER
tristate "YAS Geomagnetic Sensor"
depends on I2C
config YAS_MAG_DRIVER_YAS532
tristate "YAS Geomagnetic Sensor - yas532"
depends on I2C
help
Say Y here if you want support for the yas532 sensor
device.
To compile this driver as a module, choose M here: the
module will be called yas532.
config INPUT_YAS_MAGNETOMETER_POSITION
int "YAS Geomagnetic Sensor Mounting Position on Board"
depends on INPUT_YAS_MAGNETOMETER
default "0"
help
Chip mounting position (pin 1).
0: top, upper-left
1: top, upper-right
2: top, lower-right
3: top, lower-left
4: bottom, upper-left
5: bottom, upper-right
6: bottom, lower-right
7: bottom, lower-left
This is one of the points where I get stuck, because even if I can forcefully input a different number and reference, I don't know how to reverse engineer and get the pseudo-code (or how to read it) to confirm that what I input actually made it into the kernel. I want to confirm one of two things:
1) The change made it into the kernel successfully, and there is proof of that, yet the magnetometer data is not fixed, or
2) The change cannot be confirmed that it made it into the kernel successfully, with proof, so things such as this are still viable options.
Side note:
Samsung is also using this driver setup for their new "wear" devices. Both sensors and sensorhub source folders, for the same YAS532 (YAS532B is the same chip from my research, it's akin to calling the phone the s4 or galaxy s4). This source code change was made without any hardware change to our phones, so that why I wonder if something is awry and something completely unexpected and seemingly unrelated, on first glance, is expecting the sensors source folder to be compiled, but it isn't.
jfltevzw compass now works on CM
Feel free to donate to invisiblek as part of the bounty
Heh, I saw that commit and was tinkering around before sunrise today--very excited!
Hi there everyone -
I am running an AOSP / CM12.1 / Lollipop 5.1 ROM (Fusion) with KT Kernel. IT's a Sprint variant and I, too have the Compass / magnetometer bug. North points south / east points west. Maddening. Everything else in the ROM is Really wonderful, but without the compass / GPS / Maps, it's a deal breaker for me.
My last ROM - GPE on this forum had NO issues with the compass, so I am assuming that it is either the Kernel, or the ROM, or some odd combo.
If anyone else has any other info, please let me know? Thanks in advance!
Hello XDA, i believe this is my first time writing in XDA forums so apologize for any wrongdoings and if it had been posted before
https://imgur.com/gallery/OvbYFhP
I just seen this Thread on Twitter where there's an image that that can make devices crashes if you set it as a wallpaper or a lock-screen, the original user said particularly samsung device, as it will make the phone go into safe mode and required the phone to reset the data. Here's the original image link directed to google drive of the image:
https://drive.google.com/file/d/11rxzYvPcIOh_8GvS4XSC3YtbW3CecE-O/view?usp=drivesdk
Seen people actually did it and it did crashes their phone, most of them are Samsung and Pixel phones, but not all of them crashes too.
I don't know the technical terms and just curious how this could happen and is it a bug for certain devices or just Android Pie in general? (seen some people said it crashes Android Pie phone only). Is it related to the steganography of a code written behind the image?
For other contexts, here's another person crash log after they did it https://imgur.com/gallery/TSvmenT
So just wondering, what's happening here in the image?
Original tweet: https://twitter.com/UniverseIce/status/1266943909499826176?s=19
Obviously only devices with Android 10 are affected by it.
The exact reason for this can only be guessed at so far, but it is most likely due to the color space of the image. "As the quality of digital photos has improved, smartphones need to examine what the image 'color space' is to find out how to display it correctly," says an analysis by Ken Munro and Dave Lodge of security firm Pen Test Partners. "This way, a phone, for example, knows what exact shade of green it should display," the British "Guardian" quotes.
However, images may contain more color information than some devices can handle. This may cause the system to crash. "The software developers probably hadn't considered that this could happen," the experts said.
Huawei devices are not affected.