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!
I've been following threads on here for a few months, and now I think I want to try to learn more about how Android actually works. I'm familiar with IDEs and coding in general(not my strong point), so I think I could pick up some things pretty quickly. Where would you guys recommend I look for learning to code/tweak Android code*?
I kind of want to be able to say I'm running my own cooked up version of Android.
*please ignore this redundant word choice, please.
rougegoat,
There is a fork in the road right at your starting point, strangely enough. You could choose to study Android application development, or you could choose to look at ROM "development". They are almost worlds apart in both nomenclature, toolsets, and skills; and because of the breadth of skills that are needed in both domains, I have no doubt that there are people that are simultaneously geniuses in one of those areas of expertise, and a numb-skull in the other: that's how far apart they are.
The former is all about Java, Android API's, the "SDK", and an IDE such as Eclipse, and emulators and the device bridge; the latter has a distinct "Unix jock" nature to it: Android "NDK", (or CodeSourcery) toolchains, gcc, make, command-line and shell scripting, understanding dynamic linking and execution environments, and use of configuration management tools (git and repo).
When "code" comes up in the former, it's Java; in the latter, ANSI C (or any other native-compiler language, but C is most typical). In the latter case, if you are building source trees from public repositories, (say Cyanogen or AOSP) initially you won't spend any time at all with C - you'll be spending 95% of your time struggling with with the build environment(s) and trying to wrap your head around the mysteries of "git" and "repo" - and also deciphering Unix shell scripts (typically written in the "Bourne" or "Bash" shell dialect) when things go wrong or are poorly documented. And yes, they will go wrong; effectively diagnosing what happened when things go wrong requires solid Unix/Linux skills.
Your question as posed suggests that you are more interested in the OS/ROM side of things than App development; if that is the case I would suggest you:
-brush up or learn from scratch basic Unix/Linux skill sets (they map over to Android almost 1-to-1).
-If you are a Windows user, download VirtualBox, and create a VM with Ubuntu (8.0.4 or 10x); use developer.android.com as a reference for dependencies and setup. Make sure the virtual disk is plenty big: at least 30-40 Gb. Don't attempt to set up a native development enviroment in Windows/cygwin. ( Windows is a great place for the Android SDK and Android App development, but decidedly not for native code development for Android "ROMs"** ).
-Install both the CodeSourcery and the Android "NDK" (Native Development Kit) in your Linux VM, and try and build a smallish, but multi-file C source-code project that uses Makefiles using both of those toolchains. (Sounds easy, right? Wait till you try anything involving the standard I/O library with the NDK).
-Get your simple project code to run correctly on a real phone device.
- Then, download and build an HTC kernel from their (standalone) source tree - try and do it with both toolchains (CodeSourcery and Android NDK) - simply for the experience of setting up the environments correctly.
- Then, learn the basics of dealing with repo, download an Android source tree and compile it - using both toolchains (CodeSourcery and Android NDK)
- After succeeding with the above, try pulling code from someone else's "git" repository and merging it into an Android build tree - and getting it to build correctly.
The above looks like a pretty short list - but it represents many, many hours of effort. Good luck.
bftb0
** There might be folks that take issue with that statement about ROM-building and Windows. They might tell you, "just download so-and-so's kitchen, and start building ROMs", it works fine under Windows." There's nothing wrong with that, especially because it can be satisfying seeing something of your creation actually running on a phone in a short period of time - but you probably won't learn very much, and when things go wrong, you'll be stumped about how to go about fixing things. The difference between a "chef" and a "developer" is that the former merely assembles together pre-built executable programs and libraries - whereas the latter understands not only how to go about building those things when the sources are available, but also has the opportunity to change them.
Lucky for me that I'm a Slackware guy. I'd much rather learn the system then just have a pretty GUI that does it all for me. That's half the fun of it.
Thanks for the advice, I'll have to try that whole bit out and see where it gets me. A weekend project awaits!
Making "Stock" Custom ROMs Defunct (XposedFramework) - Tweaks for any ROM Version
Introduction
Recently it has dismayed me how, across the Android Community, people seem to feel that it's necessary to run a "Custom ROM" in order to get improvements and changes to your ROM. Of course, some of you know it's possible to modify the APK files directly to change things, but these changes need to be done every time your base ROM is updated. Once Samsung starts leaking out updates to 4.2 like a sieve, you guys will be all over them, needing to update your patches and tweaks every time.
Anyway, seeing this displeases me, as it encourages people to see "Custom ROMs" as a commodity, and something you consume. In essence, users were getting their "fix" of tweaks from their "chef", but not learning how to do it themselves, nor realising their beloved chef isn't doing anything magical. In fact, their chef is likely decompiling the applications, and using baksmali/apktool to take apart the app, hard-code in their changes, then rebuild it. This method has worked well for 3 years, but it's been in need of an update for some time.
The Enlightenment
Then I saw this thread by rovo89. That man deserves a beer for every Android user there is, for his work on the Xposed Framework! His and Tungstwenty's work on this has made it possible to modify the core Android system, without doing any actual modifying of applications.
OK... Why are you telling me this?
This invention seems to have pretty much gone unnoticed by the world. The reasons this is vastly superior to any other way of making modifications to apps and the system are:
Your modifications are not tied into a single version of the APK or app or framework. If the ROM is updated, the patch should still work perfectly on the new version of the app (this doesn't necessarily apply across major updates like 4.1 to 4.2, but should be fine across 4.1.0 to 4.1.2 style changes).
You are not actually modifying any files on the phone! If something goes wrong, you can just disable the support for the framework, and the tweaks will do nothing. As such, it's easier to get a working phone if something dies - in fact there is a ZIP placed on your SD for this very purpose. Just flash it in CWM and it will disable the framework.
As no actual files are being modified, it doesn't matter if your ROM is odexed, deodexed, or a bit of both (ie. certain apps deodexed, but frameworks odexed). With this, there is no reason to run a deodexed ROM, since you can change pretty much everything you want to without touching the raw files. So leave them as odex files and you'll not have any problems. Bear in mind we deodex to allow easier customisation, odexed is actually slightly faster, and removes the majority of the dexopt process on first boot.
No application signatures are modified, as the apps are not touched, so if you were to use this to modify an app like Maps or Gmail, you won't get issues when trying to update to a new version of the app via the market.
The only way this can succeed is for you to try it. I usually run a "custom ROM" on my phone. For the first time ever, I've been using a stock ROM for a significant period of time. On the Note2 in particular, Samsung is really getting good at this. But they're not perfect. And as such, I started to look at using this to perfect their work.
When you run a custom ROM, look at what you're getting, and ask yourself why it doesn't use this method. I've only made one little modification so far, but it's one that annoys me hugely! The blooming SMS -> MMS conversion when you try to write any form of prose in a text message. I cannot stand the limitation of SMS to 160 characters, so the ability to chain together messages is a godsend to me. Unfortunately though, Google and Samsung seem to like to restrict you to 3 SMS messages worth of text before converting to an MMS message. Which is wonderful, except when you have totally unlimited SMS, but pay for MMS. As such, I was finding my ability to communicate in my usual verbose way somewhat hindered by the messaging app.
Alas that is no longer an issue. If you want to get started, here's how.
OK... How do I use this?
Download and install the APK file from this post - http://forum.xda-developers.com/showthread.php?t=1574401. I have tested it on the N7100, it works fine. Run it, install the framework, grant it root (yes, this requires root!), and reboot. I have mirrored the APK below just in case of issues.
Download and install the APK modification you want from http://www.villainrom.co.uk/forum/microdownloads/
When you get a notification about enabling the modification (after the APK is installed), tap that notification, and enable the plugin by ticking the box.
Reboot your phone
Go test your modification
If you have any issues with this, please paste the contents of /data/xposed/debug.log on a pastebin site or in
Code:
tags.
[SIZE="5"][B]How can I make my own modifications like this?[/B][/SIZE]
Will post this a bit later, along with the source of this plugin.
[SIZE="5"][B]References[/B][/SIZE]
[url]http://forum.xda-developers.com/showthread.php?t=1574401[/url]
[url=http://forum.xda-developers.com/member.php?u=4322181]Tungstwenty[/url]
[url=http://forum.xda-developers.com/member.php?u=4419114]Robo89[/url]
[SIZE="5"][B]Sources[/B][/SIZE]
You can find the sources for Xposed Framework at [url]https://github.com/rovo89[/url]
You can find the sources for all Xposed modifications I have made so far on Github:
[url=https://github.com/pulser/xposedSMStoMMS]Disable SMS -> MMS Conversion[/url]
[url=https://github.com/pulser/xposedDisableBatteryFullAlert]Disable 100% Battery Notification[/url]
[url=https://github.com/pulser/xposedEnableCallRecording]Enable Call Recording[/url]
[url=https://github.com/pulser/xposedScrollingLauncherWallpaper]Enable scrolling wallpaper in stock launcher[/url]
[url=https://github.com/pulser/xposedEmailTextColour]Make text in email app message list clearer to read (lighter) on the black background[/url]
Install the Xposed Framework from this thread: http://forum.xda-developers.com/showthread.php?t=1574401
Modifications
OK so a few people suggested an addon repository... I have got one sorted
Downloads
http://www.villainrom.co.uk/forum/microdownloads/
I've added some of mine so far, but I won't add other people's - they can add them themselves, and maintain them
This system is vastly superior to a stickied forum thread, as you can update your own modification (as a developer), and as a user, receive notifications if a modification is updated.
Developers
Register for an account (Free, easy, no spam etc)
Go to http://www.villainrom.co.uk/forum/account/join-user-groups
Tick the option for Xposed Uploader, and hit Save. A request will be sent to me for your application. I'll approve it when I see it (should be quite fast, it gives me a popup)
Head back to http://www.villainrom.co.uk/forum/microdownloads/ and click the Upload button at the top right.
Use a general title that describes what your modification does. Put in a version string too. I tend to use the format 1.0, 1.1, 1.2 etc, but this is up to you. You can add Alpha or Beta or other designations if you wish.
For author, pop in your name or username. And enter a brief description of what the modification does (which will appear in the index)
Click Categories/Agreements, and select which category the modification falls under. If you think there's a category which should be added, let me know.
Under Full Description, you can enter a detailed description of your modification. Finally, under File Options, use File to Upload to select your APK file. You can optionally add an Image to Upload. The Use File URL should be set to no, and the File URL box left blank.
Users
There is no need to register an account to download files from the repository. If you wish to receive notifications of updates, you can register an account - just hit the red "Log in or Sign up" button - you can use a Twitter or Google account if you want, or just make a plain account. It makes no difference.
Head across to http://www.villainrom.co.uk/forum/microdownloads/ and have a look at the modifications you want.
Click watch file (at the bottom right) if you want notifications about updates to a modification
Click Report to report a modification for being malicious or problematic.
Click "add comment" to discuss or comment on the modification, or leave a "review" or feedback
Click on the stars under (0 votes) to leave a star rating on the modification, which will help generate most popular lists on the main page.
Click to see licence details of mine:
Feel free to use these as you wish, for non-commercial purposes. You may share these for personal use. Note that distribution in any kind of "package" or "custom ROM" is not personal use. Sending a friend a copy is personal use, feel free to do that and share the love.
Feel free to make changes to the source code of the modifications if you think you can improve them, provided you make your changes available in a similar manner. If you fix a bug or error, please send a pull request.
If you wish to use these commercially, please contact me. This includes in any "distribution package", be it a ROM, app, store, marketplace or other package. That's not in the spirit of this project, so get in touch with me and we'll discuss it.
Tl;dr:
End users, have fun, use these, enjoy them, share them, tweak them, just be sure to share your source changes and/or send a pull request if you improve something!
"Custom ROM" Developers, and anyone wanting to try to use these for commercial purposes: Don't. These are to encourage people to learn about these changes, so contact me if you want to do something else with them. Commercial use, including distribution in "Custom ROMs" is not permitted.
How to make your own such modification
This information is NOT complete. This example only uses 1 of about 10 different types of modification. I have spoken to rovo89 and he has said it would probably be possible to document this further. This example covers ONE usage case - I am going to override an entire method.
1. Create a new empty Android project in Eclipse.
2. Within the "application" section of your AndroidManifest.xml, add the following metadata:
Code:
<meta-data android:name="xposedmodule" android:value="true"/>
<meta-data android:name="xposedminversion" android:value="2.0rc1.*" />
3. Within the assets folder of the project, add a plain text file, "xposed_init". Within this, I have put
Code:
uk.co.villainrom.pulser.allowlongsms.AllowLongSMS
uk.co.villainrom.pulser.allowlongsms is the PACKAGE name of my Java package. AllowLongSMS is my class name. The purpose of this is to tell the Xposed Framework what to run.
4. Within AllowLongSMS.java (ie. the class name, with .java on the end), I put the following code:
PHP:
package uk.co.villainrom.pulser.allowlongsms; //this sets the package for our project, this is the first part of the value in xposed_init file in assets.
import de.robv.android.xposed.IXposedHookLoadPackage;
import de.robv.android.xposed.XC_MethodHook;
import de.robv.android.xposed.XC_MethodReplacement;
import de.robv.android.xposed.XposedBridge;
import de.robv.android.xposed.XposedHelpers;
import de.robv.android.xposed.callbacks.XC_LoadPackage.LoadPackageParam;
//above includes all the required parts of the xposed framework that we need here
public class AllowLongSMS implements IXposedHookLoadPackage { //here we declare the class AllowLongSMS. We say it implements IXposedHookLoadPackage, as we want to make use of the hook-in on package load. Other options are available here for working with native libs etc, and resources, but I'm not using these right now.
public static final String MY_PACKAGE_NAME = AllowLongSMS.class.getPackage()
.getName(); //this doesn't do anything, I just left it here for if I needed to write logs and wanted to have the package name easily accessible.
public static final String TAG = "PulserMmsTweak"; //same here, this doesn't do anything.
@Override //we are going to override the method handleLoadPackage, if it exists further up the hierarchy
public void handleLoadPackage(LoadPackageParam lpparam) throws Throwable {
//this method is called every time a package is loaded. We have a parameter that we're going to call lpparam, that is passed in, that relates to what package was loaded
if (lpparam.packageName.equals("com.android.mms")) { //if the package that has just been loaded is called "com.android.mms" then
ClassLoader classLoader = lpparam.classLoader; //create a classloader object that we can now use
XC_MethodReplacement methodreplacer = new XC_MethodReplacement() { //create a method replacer object, as we are going to REPLACE an entire method within the mms app.
protected Object replaceHookedMethod( //we make an object here, that passes in the parameters of what to actually change
XC_MethodHook.MethodHookParam paramAnonymousMethodHookParam)
throws Throwable {
return Integer.valueOf(255);
/* THIS IS THE IMPORTANT LINE
* This line returns the value 255. Why this happens won't make sense yet, but THIS is where you put your "new method" code.
*
*/
}
};
XposedHelpers.findAndHookMethod("com.android.mms.MmsConfig", //here we say that we want to find and hook into the method "getSMSToMmsTextThreshold" which is part of the class com.android.mms.MmsConfig. We then say that we're passing this to methodreplacer, which we defined earlier
classLoader, "getSmsToMmsTextThreshold", methodreplacer);
}
//if the package wasn't com.android.mms, do nothing.
}
}
Awesome work mate. Wish I had a Note 2 to check this on.
EDIT: Wait.. I can use this on any device! Rock on. Thanks!
Wow this is great post. While reading this it makes me learn something like what is going on in background.
Sent from my GT-N7100 using Tapatalk 2
Thanks for continuing that amazing project pulser!!
I think i'm going to create some small apks for some stuff very soon (and release them of course).
Cool stuff as always pulser, keep it up
simone201 said:
Thanks for continuing that amazing project pulser!!
I think i'm going to create some small apks for some stuff very soon (and release them of course).
Cool stuff as always pulser, keep it up
Click to expand...
Click to collapse
The original guys are not gone, was talking to them recently
There's scarce documentation so far on this, but I will see what else I can do with it... I might make post 2 a repository of these APKs for now...
chaitanya87 said:
Wow this is great post. While reading this it makes me learn something like what is going on in background.
Sent from my GT-N7100 using Tapatalk 2
Click to expand...
Click to collapse
That's the intention Glad it worked! This is about learning, and not just "using".
Sure, you can download the APK and use it, but that's no better than just downloading some zipkang ROM that claims it does everything including making your morning coffee... This is about taking a look at HOW it works too That way people can make their own tweaks and share them!
pulser_g2 said:
The original guys are not gone, was talking to them recently
There's scarce documentation so far on this, but I will see what else I can do with it... I might make post 2 a repository of these APKs for now...
Click to expand...
Click to collapse
A small repo for APKs would be really cool and useful for users....
tell me if i can contribute in some ways (i'm an app dev mainly also)
simone201 said:
A small repo for APKs would be really cool and useful for users....
tell me if i can contribute in some ways (i'm an app dev mainly also)
Click to expand...
Click to collapse
I will work something out (I can easily make a repository if this kicks off, so people can upload them and they appear).
TBH right now it's more a case of thinking up some ideas. For now, I can add anything people send into the second post (though I think it would be reasonable that we request source for all such modifications, just given the sheer ability to modify anything that this has...)
I can't think of enough things to tweak, we just need to work out WHAT people will like to modify, and implement it
I'll be a good example and put mine onto git shortly
My own notepad of things I need...
http://forum.xda-developers.com/showthread.php?t=1965801
http://forum.xda-developers.com/showthread.php?t=1924905
call record:
http://forum.xda-developers.com/showthread.php?t=1938808
http://forum.xda-developers.com/showthread.php?t=1871525
Hey folks,
I'm happy to see some new interest on Xposed.
I've been using it since rovo89 came up with this brilliant idea, and have to admit I was kind of sad to see not many saw its great potential.
Personally, I'm using a couple of hacks for my individual use, but if the community starts to be interested in the HOWs rather than merely nagging about the apks I guess I can try to make an effort to clean and share the code.
Please do ask away stuff, I'm eager to seeing this being used to its full potential
For now, please check the Tweakbox sources. While the code itself might no longer 100% apply to the most recent S2 stock roms, it's still a nice example of how the hacks can be done.
this sounds great! like an universal (almost!) patching system. I hope more chef will write mods for this. man...wish i had taken some lessons in coding.
for a start, how about some of the often repeated annoyance in stock samsung that drives many to use custom roms just to get these functions:-
1) disable the scrolling quick setting panel when you open notification
2) 15 toggles as implement by guys like Wanam.
3) call recording (ok we got this already)
4) 4 way reboot menu
5) some kind of user definable custom battery graphics.
sunwee said:
this sounds great! like an universal (almost!) patching system. I hope more chef will write mods for this. man...wish i had taken some lessons in coding.
for a start, how about some of the often repeated annoyance in stock samsung that drives many to use custom roms just to get these functions:-
1) disable the scrolling quick setting panel when you open notification
2) 15 toggles as implement by guys like Wanam.
3) call recording (ok we got this already)
4) 4 way reboot menu
5) some kind of user definable custom battery graphics.
Click to expand...
Click to collapse
Yeah this is pretty universal. I'd even remove the word "almost" tbh...
For 1, do you mean to disable the scroll animation so that it shows the leftmost icon (wifi) first?
2 is possible, I know samsung has done it on 4.2, is the custom implementation better?
3 is done like you said.
4 should be more than possible.
5 is definitely possible, at least via flashing the modification for the battery style you want...
Thank for the ideas
i flash custom rom just because i need below few things
1.Call-Record. (done)
2.15 toggle, or maybe add NFC, S Beam, Multiwindow, Smart Stay as well
3.Louder Volume Speaker.
4.CRT Lock and Unlock Screen.
5.4 Way Reboot.
6.Unlimited Multi-Window
thanks for the good work and sharing.
Hi. So glad to see that this amazing framework didn't "die"
I would have one question about the mods...
Ok its likely that for the same device they work on different bases of the rom like DLJ5, ELK4 am I right?
But does a mod that was made for lets say the Note 2 work on a SGS3 or must it be adapted?
Thanks !
DirkStorck said:
Hi. So glad to see that this amazing framework didn't "die"
I would have one question about the mods...
Ok its likely that for the same device they work on different bases of the rom like DLJ5, ELK4 am I right?
But does a mod that was made for lets say the Note 2 work on a SGS3 or must it be adapted?
Thanks !
Click to expand...
Click to collapse
If it's touchwiz then it should work - samsung seems to have unified a lot of it.
Jerdog used the SMS to mms patch fine on his s3.
It really just depends on the modification itself tbh...
If I would like to start writing my own mods is there somewhere a guide how to debugg the mod I write?
Thanks!
one more
can you add:
*:laugh:skip music track with volume button
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!