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!
Related
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!
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
can't believe I'm the only one with that issue
maybe an idea for a dev? would be willing to pay for that ;-)
I don't see why this can't be done:
-http://stackoverflow.com/questions/2695746/how-to-get-a-list-of-installed-android-applications-and-pick-one-to-run
-http://developer.android.com/reference/android/content/pm/PackageManager.html
-http://developer.android.com/reference/android/content/Context.html#getApplicationInfo()
I haven't thought through the problem just yet, but its seems to be doable. If you don't find an app soon, I will start working on a script that does it and, if successful, a proper, free software app. I am hoping the available methods won't require something as stupid as launching each app fully. But again, I haven't thought it through. Thanks for the idea btw.
EDIT:
Made a little more effort
https://groups.google.com/forum/?hl=en&fromgroups#!topic/android-developers/dXLACRIizKc
I will work on something this weekend and get back with y'all.
EDIT 2:
So it looks like I would need maxSdkVersion which I don't find in the API. Furthermore, it is strongly suggested that one not use maxSdkVersion when building an app so that doesn't sound all that useful. I have received another, much more complicated suggestion that may do what I want, but I will have to look hard at it. Looks like I'm going nowhere in my effort. Always open to suggestions. More to come later this weekend.
I'm not the sharpest tool in the shed, but I thought this was mostly a straightforward task using the API's exposure to AndroidManifest.xml. As per my previously posted link to an Android Developers discussion on the topic, my approach is dead in the water as far as I can see. I did try to find an answer though to the best of my limited ability. If anyone has or ever solves this problem (I consider it a problem) I would hope they find the this thread.
Thanks for the learning experience. I give up.
Most older apps will work fine on ICS, its pretty backwards compatible. If the app uses legacy menus the button will appear in the old lower left hand corner location instead of the upper right hand corner like apps written for ICS.
i'm no dev so bear with me if i write stupid stuff
one likely but not very promising sounding way might be to use android:targetSdkVersion as "As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's targetSdkVersion, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifying targetSdkVersion to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens)."
question though is how many apps actually use this?
However after having read this re android:maxSdkVersion "Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute." (taking from here) i now don't know how important my op is, but then why do all app devs release new versions "fixing things" for ICS?
One pretty significant example which actually currently will prevent my phone from getting ICS for now is that the subsonic app in the current version produces stuttering when playing audio while downloading (problem description here).
Isn't there any way to instead of searching the phone searching google play/android market instead?
Randi said:
maybe either through API level, or by querying market info
Reason: i want to check on GB before I upgrade to ICS, which apps will not work.
don't know if relevant but it is for SGS II
Thx in advance
repost from here as nobody could really answer my question
Click to expand...
Click to collapse
Here's a list of some working games/apps for ICS
Theoretically an Android app (or a combo of say App Engine and Android) could find your installed apps, seacrh Play for said apps and then scrape the page for relevant information. Doesn't sound to hard, but I didn't think about too hard either. Perhaps I will check out what useful info is on Play and how feasible scraping its markup will be. I will get back at y'all if I do.
Download Link:
http://goo.im/devs/agrabren/cm10/shooter/cm-10-DisarmedToaster-0.1-shooter.zip
GAPPS:http://goo.im/gapps/gapps-jb-20120726-signed.zip
TERMS AND CONDITIONS
0. Definitions.
“This License” refers to version 2 of the GNU General Public License.
“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
A “covered work” means either the unmodified Program or a work based on the Program.
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
Toolchain: GCC ARM version 4.4.3
Kernel Source: https://github.com/agrabren/android_kernel_htc_shooter
This is a Discussion thread for the rom and is only to be used for that purpose.
This ROM Thread is posted with Permission of Agrabren
WORKING:
SOUND
WI-FI
CALLING
DATA
You Tell Me!
Note I AM NOT the creator of this rom. IT IS AGRABREN
He gave me permission to post a discussion thread
I will keep this open until he feels like the build is alpha quality
I will then close this thread
I'm posting a thread as he has not.
Also If you phone explodes or you create a black hole I Take NO RESPONSIBILITY
I'm fine with the thread, at least until the ROM is stable enough to meet my standards to be posted as an alpha. People in the CM9 thread wanted to see it, since I had posted a build for the GSM phones (to test if I had the basic infrastructure working) and they were thrilled. So I posted for CDMA after the last builds came out.
Now everyone, settle down. You're all more than welcome to use this thread to discuss what works, doesn't work, and how to help each other make the most out of it.
This forum is supposed to be about helping each other. Is the ROM in development? Yes. Does it work up to my requirements for alpha quality? No. Why? Because the microphone doesn't work right. If that were fixed, I'd likely switch to developing for CM10 instead of CM9, because the camera won't kill me to get working and everything else is trivial between the two for me to not lose any time or features.
Thread moved to GENERAL - it will stay here as a discussion thread.
Edited OP and thread title to reflect that, also left a couple posts from agrabren so people know he's ok with this thread.
Any and all flames or name calling will get you an immediate infraction and likely a ban if you cross the line too much.
Keep XDA what it shold be, open and a place to learn.
Have a nice day.
im still confused why the dictionary exists in the OP? - why not just link to where that was copied and pasted from? its pretty distracting from the actual OP
Xda is the best...
Sent from my GT-XPERIA S using xda app-developers app
Can't wait to install this once I get home.
Thank you il Duce! I'm excited to see CM10 on the Shooter, and can't wait to see how far Agrabren and others take this rom!!
minieod said:
im still confused why the dictionary exists in the OP? - why not just link to where that was copied and pasted from? its pretty distracting from the actual OP
Click to expand...
Click to collapse
It's the op decision to put what they want there. You'll live.
jasonvanfebr said:
Xda is the best...
Sent from my GT-XPERIA S using xda app-developers app
Click to expand...
Click to collapse
I agree.
I've been running this for a little over 12 hours now. It's very nice and makes me very excited to see where we can see Jellybean in the future.
Not Working:
4G will not enable
3D
Camera
Google Now/Search FCs
Headphones are not detected - sound continues to play through external speaker
Potential battery drain - BetterBatteryStats shows phone as awake 100% of the time, though I had an app running that may have been the cause of it
Watching Youtube can cause a reboot after 20-30 seconds
I also was unable to boot with the stock kernel, and if I had the newer ICS firmware it refused to boot at all with any combination I tried.
It's incredibly fast though, you can definitely feel the Butter in play. I'm very impressed with the ROM and will continue to run it until I go back to the USA, at the very least.
Hi.
I've been out for a bit, glad to see much hasn't changed (sarcasm).
One troll has already been banned from the mess that had to be deleted. Please behave yourselves, I really don't like spending my free time deleting drivel and banning people. The op has permission to post this, it's compliant, just discuss away. Don't be rude to each other.
Thanks and have a pleasant evening
Can't Wait
wwjoshdew said:
Thank you il Duce! I'm excited to see CM10 on the Shooter, and can't wait to see how far Agrabren and others take this rom!!
Click to expand...
Click to collapse
I feel the same way.
I would feel better when an official RUU is available then I would start ROM'ing all crazy lol.
FusionNeo said:
I've been running this for a little over 12 hours now. It's very nice and makes me very excited to see where we can see Jellybean in the future.
Bugs:
4G will not enable
3D
Camera
Google Now/Search FCs
Headphones are not detected - sound continues to play through external speaker
Potential battery drain - BetterBatteryStats shows phone as awake 100% of the time, though I had an app running that may have been the cause of it
I also was unable to boot with the stock kernel, and if I had the newer ICS firmware it refused to boot at all with any combination I tried.
It's incredibly fast though, you can definitely feel the Butter in play. I'm very impressed with the ROM and will continue to run it until I go back to the USA, at the very least.
Click to expand...
Click to collapse
4g is not integrated into this build , neither is camera , neither is 3d , neither is voice search - that is why those are bugs
Love the idea here, just dropped in to see only shooter, not shooteru.
Perhaps a CDMA thread title, or people posting whether they are gsm or cdma.
We all want to ditch sense after all.
scariola said:
Love the idea here, just dropped in to see only shooter, not shooteru.
Perhaps a CDMA thread title, or people posting whether they are gsm or cdma.
We all want to ditch sense after all.
Click to expand...
Click to collapse
you can get a fully functioning cm9 rom (no sense) for gsm in the gsm developers section
minieod said:
4g is not integrated into this build , neither is camera , neither is 3d , neither is voice search - that is why those are bugs
Click to expand...
Click to collapse
Oh I know, I wasn't expecting them to work. I just wanted people to be aware of what isn't working, even if it's things people shouldn't expect to work.
FusionNeo said:
Oh I know, I wasn't expecting them to work. I just wanted people to be aware of what isn't working, even if it's things people shouldn't expect to work.
Click to expand...
Click to collapse
:good: - OP should be updated reflecting a "not working" feature set
Found another bug - attempting to watch Youtube for more than 30 seconds or so causes a reboot. Will update my post to reflect this (in 5 minutes, due to my lack of user permissions). I agree that these bugs should be listed in the OP, to make them easier for people to find as well as remove all the posts like "DOES FOUR GEEZ WORK" from people who only choose to read the OP.
minieod said:
you can get a fully functioning cm9 rom (no sense) for gsm in the gsm developers section
Click to expand...
Click to collapse
yes, a cm9 and cm10 Rom if you know where, the thread hasn't been created for 10 yet.
Was just hoping someone could find out why audio goes out after phone connects call through SIP(Internet calling) ?
Problem with all cm9+ roms, by 3 different gsm devs.
Titanium backup won't restore Facebook.
It's not critical, but it is a problem I've been having. Unchecking Facebook fixes it.
It hung on something else too - had to force close TB a couple times, but I got most of my stuff back.
Over all, very fast, and the phone (the old neglected bit some people actually use to talk with other people verbally, rather than via txt) works well.
I've also had issues downloading paid apps from the market - and TB warned me that my device ID had changed. It offered to change it back, which also crashed TB.
After restoring accounts from TB (and possibly the device ID as well - not sure if that completed or not), the market issues have gone away.
Project Treble provides a great help in getting access to vendor-specific HALs, I'll try to explain how, and how to exploit it.
Presentation of vendor HIDLs
Thanks to Project Treble, all HALs must be defined through HIDL.
Standard AOSP HALs means that a generic AOSP system works with standard AOSP features.
But, vendor HALs are also going through HIDL!
APIs defined through HIDL are stable, versioned, hashed and easy to access.
Just plug the HIDL inside your build system, and you get easy access from your applications to the HAL behind the HIDL!
Also, APIs defined through HIDL are supposed to be clean, and mostly self-documented, so getting the HIDL can help understand how the HAL works.
To understand how easy it is, here is a real world client usage of an HIDL:
Code:
IExtBiometricsFingerprint service = IExtBiometricsFingerprint.getService();
service.sendCmdToHal(NAV_ON);
With the HIDL, enabling gestures on the fingerprint sensor on Huawei devices is a two liners! [1]
Browsing vendor HIDLs
Now, the problem is that HIDLs are part of the source code, not the firmware.
So if the vendor doesn't publish it, there is some additional work to do.
Android build system is capable of generating two client APIs for HALs using HIDL. Either a C++ library, or a java library. Not all firmwares will contain java libraries for all APIs, but C++ is almost always available.
Both languages make it fairly easy to reverse engineer the prototype of the functions, which is almost all of HIDL (c++ is missing function arguments)
So, I made a script to reverse engineer those HALs ( https://github.com/phhusson/treble_experimentations/blob/master/vendor-HAL/reverse-hal.sh ).
It is far from perfect, it can't generate a full-blown HIDL, but it makes discovery much easier!
Here are a few examples of APIs it is giving access to:
- Touch screen gives us access to Glove mode and cover mode
- Display gives us access to functions like setColorTemperature, or updateRgbGamma
- Infrared HAL gives us access to learning capability
- fingerprint sensor gives us access to sendCmdToHal
With the first three examples, we can see things can be easy, but the last one makes things trickier. With the last one, there is still a magic value to give to the sendCmdToHal function.
Anyway, that's still quite an improvement compared to before Treble.
Using vendor HALs
So, let's say we've discovered [email protected]::hwTsSetGloveMode(bool) function, and we want to call it.
As I mentioned in the first section, if we have the HIDL, it's a two liners.
But, we don't have it, so what do we do?
Android build system usually generates HIDL client code for C++ and Java, so we just need to piggy-back to this code to be able to call the functions!
Using vendor HALs from Java
For Java, the idea is fairly simple, we need to copy/paste the code from the original firmware (either from an app or framework), and copy it in our own environment.
It's a bit more complicated to realize, here is how I did it:
- grep -rF <name of the function> system # To find where to find the java symbols
This gave me system/system/framework/oat/arm64/hwServices.vdex
- deodex it
- Retrieve all symbols inside proper folder. In this case, vendor/huawei/hardware/tp
- Create a mock of the java class ( here is an example )
- Create the code to call this (here is an example)
- Build the mock and the caller (here is an example)
- Decompile the result into smali
- Replace the mock code by the actual classes from the original firmware
- Recompile the whole
- Run the resulting app/dex
Things to improve
First problem here, is this code is annoying to automate and put into a build system.
Them, we can only partially reverse-engineer the HIDL, which leads to two problems:
- We need to piggy-back previous firmware's APIs
- Calling C++ is much harder (because ABI behaviour when changing headers is tricky)
The cleanest solution would be to fully reverse-engineer the HIDLs.
Though current reverse engineering is so bad that it doesn't even list all the functions available, so a lot of work is needed.
Conclusion
Project Treble's HALs are fun to play with, look at it!
[1] I'm a bit lying here. This is enough to enable event reporting, but there are some additional changes needed to make sense of those events
Thanks for your great work here OP
BTW, on Honor 9 stock EMUI HwCamera2 can't take a photo ( checked on landscape or portrait mode on the both camera ), but video recording it's working like expected !
Also with your solution, home button it's working in this way : when I press home button it's open search with a "=" into it
surdu_petru said:
BTW, on Honor 9 stock EMUI HwCamera2 can't take a photo ( checked on landscape or portrait mode on the both camera ), but video recording it's working like expected !
Click to expand...
Click to collapse
This is fixed by https://github.com/phhusson/huawei_camera_aosp/commit/177459fdb76f0aa68fa4ffb869b633d9460a2fb0
Also with your solution, home button it's working in this way : when I press home button it's open search with a "=" into it
Click to expand...
Click to collapse
Yeah, that's what my footnote basically says
Huawei is defining the meaning of fingerprint evdev in /vendor/usr/keylayout/fingerprint.kl, but the KEYCODE_FINGERPRINT_* it uses doesn't exist in AOSP.
What I'm planning to do there is a daemon listening exclusively to /dev/input/eventX of fingerprint, and launch commands based on the events.
This could have performance issues (input keyevent KEYCODE_HOME takes half a second), so I might switch to creating an uinput.
phhusson said:
This is fixed by https://github.com/phhusson/huawei_camera_aosp/commit/177459fdb76f0aa68fa4ffb869b633d9460a2fb0
Yeah, that's what my footnote basically says
Huawei is defining the meaning of fingerprint evdev in /vendor/usr/keylayout/fingerprint.kl, but the KEYCODE_FINGERPRINT_* it uses doesn't exist in AOSP.
What I'm planning to do there is a daemon listening exclusively to /dev/input/eventX of fingerprint, and launch commands based on the events.
This could have performance issues (input keyevent KEYCODE_HOME takes half a second), so I might switch to creating an uinput.
Click to expand...
Click to collapse
Thank you very much, and good luck
surdu_petru said:
Thank you very much, and good luck
Click to expand...
Click to collapse
Does your fingerprint sensor mechanically click? Or is it just some capacitive sensor?
phhusson said:
Does your fingerprint sensor mechanically click? Or is it just some capacitive sensor?
Click to expand...
Click to collapse
No, the only one withe the click is into Honor 8 ... I already see it this : "key 28 ENTER" into fingerprint.kl ... maybe here we can defined as virtual or something like this if I'm not wrong, but sure need to be tested
EDIT :
I guess it's used only on Honor 8, as fingerprint.kl is almost the same for all devices
surdu_petru said:
No, the only one withe the click is into Honor 8 ... I already see it this : "key 28 ENTER" into fingerprint.kl ... maybe here we can defined as virtual or something like this if I'm not wrong, but sure need to be tested
EDIT :
I guess it's used only on Honor 8, as fingerprint.kl is almost the same for all devices
Click to expand...
Click to collapse
Well, my Device (Mate 9), which doesn't mechanically click, does trigger click event.
The way I'm doing it doesn't require changing vendor partition. But yes, changing vendor/usr/keylayout/fingerprint.kl would be much easier.
xx
Diggin on "my own"
Good evening out there!
First of all: Thank you very much for all of your afford till now.
I own a honor 9 lite and im investigating right now how oreo and treble works.
So i took your reverse_hal and tried to improve it a little bit (see attachment).
Maybe it can keep things easier?
Does it make sense to read out all classes in the so's?
I've uploaded the script (reverse-hal-grork.sh) and an example-output from vendor.huawei.hardware.biometrics.fingerprint.
Please, have a look at it.
greetings
vsrookie
PS: If there are any ideas to improve just tell. I thought about automatically create JavaClasses? Or Smali? Will it work?
vsrookie said:
Good evening out there!
First of all: Thank you very much for all of your afford till now.
I own a honor 9 lite and im investigating right now how oreo and treble works.
So i took your reverse_hal and tried to improve it a little bit (see attachment).
Maybe it can keep things easier?
Does it make sense to read out all classes in the so's?
I've uploaded the script (reverse-hal-grork.sh) and an example-output from vendor.huawei.hardware.biometrics.fingerprint.
Please, have a look at it.
greetings
vsrookie
PS: If there are any ideas to improve just tell. I thought about automatically create JavaClasses? Or Smali? Will it work?
Click to expand...
Click to collapse
Looks good
Could you make a pull-request to https://github.com/phhusson/treble_experimentations/ ?
The ideal target would be to generate the original .hal file, so that we can generate c++ and java code automatically with hidl-gen.
I don't know how big is the gap to be able to do that though...
Hi.
I dont think that it will be earlier then the weekend.
But i will do.
Also i go on with my investigation at weekend.
Greetings
Vsrookie
This is interesting... Going to see if I could extract something useful from the Nabi SE, as I'm curious if it can be Treble'd.
phhusson said:
Project Treble provides a great help in getting access to vendor-specific HALs, I'll try to explain how, and how to exploit it.
Presentation of vendor HIDLs
Thanks to Project Treble, all HALs must be defined through HIDL.
Standard AOSP HALs means that a generic AOSP system works with standard AOSP features.
But, vendor HALs are also going through HIDL!
APIs defined through HIDL are stable, versioned, hashed and easy to access.
Just plug the HIDL inside your build system, and you get easy access from your applications to the HAL behind the HIDL!
Also, APIs defined through HIDL are supposed to be clean, and mostly self-documented, so getting the HIDL can help understand how the HAL works.
To understand how easy it is, here is a real world client usage of an HIDL:
With the HIDL, enabling gestures on the fingerprint sensor on Huawei devices is a two liners! [1]
Browsing vendor HIDLs
Now, the problem is that HIDLs are part of the source code, not the firmware.
So if the vendor doesn't publish it, there is some additional work to do.
Android build system is capable of generating two client APIs for HALs using HIDL. Either a C++ library, or a java library. Not all firmwares will contain java libraries for all APIs, but C++ is almost always available.
Both languages make it fairly easy to reverse engineer the prototype of the functions, which is almost all of HIDL (c++ is missing function arguments)
So, I made a script to reverse engineer those HALs ( https://github.com/phhusson/treble_experimentations/blob/master/vendor-HAL/reverse-hal.sh ).
It is far from perfect, it can't generate a full-blown HIDL, but it makes discovery much easier!
Here are a few examples of APIs it is giving access to:
- Touch screen gives us access to Glove mode and cover mode
- Display gives us access to functions like setColorTemperature, or updateRgbGamma
- Infrared HAL gives us access to learning capability
- fingerprint sensor gives us access to sendCmdToHal
With the first three examples, we can see things can be easy, but the last one makes things trickier. With the last one, there is still a magic value to give to the sendCmdToHal function.
Anyway, that's still quite an improvement compared to before Treble.
Using vendor HALs
So, let's say we've discovered [email protected]::hwTsSetGloveMode(bool) function, and we want to call it.
As I mentioned in the first section, if we have the HIDL, it's a two liners.
But, we don't have it, so what do we do?
Android build system usually generates HIDL client code for C++ and Java, so we just need to piggy-back to this code to be able to call the functions!
Using vendor HALs from Java
For Java, the idea is fairly simple, we need to copy/paste the code from the original firmware (either from an app or framework), and copy it in our own environment.
It's a bit more complicated to realize, here is how I did it:
- grep -rF <name of the function> system # To find where to find the java symbols
This gave me system/system/framework/oat/arm64/hwServices.vdex
- deodex it
- Retrieve all symbols inside proper folder. In this case, vendor/huawei/hardware/tp
- Create a mock of the java class ( here is an example )
- Create the code to call this (here is an example)
- Build the mock and the caller (here is an example)
- Decompile the result into smali
- Replace the mock code by the actual classes from the original firmware
- Recompile the whole
- Run the resulting app/dex
Things to improve
First problem here, is this code is annoying to automate and put into a build system.
Them, we can only partially reverse-engineer the HIDL, which leads to two problems:
- We need to piggy-back previous firmware's APIs
- Calling C++ is much harder (because ABI behaviour when changing headers is tricky)
The cleanest solution would be to fully reverse-engineer the HIDLs.
Though current reverse engineering is so bad that it doesn't even list all the functions available, so a lot of work is needed.
Conclusion
Project Treble's HALs are fun to play with, look at it!
[1] I'm a bit lying here. This is enough to enable event reporting, but there are some additional changes needed to make sense of those events
Click to expand...
Click to collapse
So my theory is.
Trebel is a wrapper for closed source drivers ?
If so. Knowing the calls to the drivers give you the code to make any driver trebel ...
I'm not a developer but I have knowledge about Linux and how PCs in general work. Is there any book/course that explains how android works on a deeper level? I'm not interested in apps or user UIs, I want to know the deeper levels like how partitioning works, how the OS is loaded, why some bootloaders are locked by default, what a custom recovery is or what is the first thing to load when you power on your phone/tablet (do phones have a BIOS like PCs or anything equivalent?). Thanks in advance.
I'm also interested in this, but I think the answer is it's a bunch of undocumented proprietary baseband processor junk nobody will share for the boot, then the rest is basically a Linux distro made by 1000 monkeys on 1000 typewriters copy/pasting stuff provided by their hardware vendors together, and the components of that also probably have no documentation or incorrect documentation.
Just browsing through directory structures on a rooted phone there's so much unused and inaccessible junk like config files for really old versions of android, random vendor apks that aren't configured, and firmware for other processors strewn all over, sometimes multiple copies of the same structure, that it makes no sense. It looks like a bunch of vendors gave their support libraries to manufacturers with the intent they'd delete the unused parts and copy the used parts in, but the manufacturers don't understand how to do that so they just paste the same full directory structure several different places until it starts working.
If it made any sense, some people would just learn it and rooting new phones wouldn't be hard.
dan2525 said:
I'm not a developer but I have knowledge about Linux and how PCs in general work. Is there any book/course that explains how android works on a deeper level? I'm not interested in apps or user UIs, I want to know the deeper levels like how partitioning works, how the OS is loaded, why some bootloaders are locked by default, what a custom recovery is or what is the first thing to load when you power on your phone/tablet (do phones have a BIOS like PCs or anything equivalent?). Thanks in advance.
Click to expand...
Click to collapse
The rabbit hole goes as deep as you want it to. I have plenty of information to get you started. Happy digging!
*A general overview of the android boot process, thanks to the Lineage OS developers.
*An old, but good read on reverse engineering aboot.
*And a much more recent article on reverse engineering android. It gets very detailed in this one. It also goes into the low level processes of android. Like; What loads the bootloader? That kind of stuff. I think this is what you're after. Hope it helps.
About the bios question. The short answer is, "kind of". They have a very simple and proprietary one that's not easy to access. It also does not function in the same ways that a PC bios does. It's more like a motherboard programmer. It's hard to explain. The last article goes into some of that.
Spaceminer said:
The rabbit hole goes as deep as you want it to. I have plenty of information to get you started. Happy digging!
*A general overview of the android boot process, thanks to the Lineage OS developers.
*An old, but good read on reverse engineering aboot.
*And a much more recent article on reverse engineering android. It gets very detailed in this one. It also goes into the low level processes of android. Like; What loads the bootloader? That kind of stuff. I think this is what you're after. Hope it helps.
About the bios question. The short answer is, "kind of". They have a very simple and proprietary one that's not easy to access. It also does not function in the same ways that a PC bios does. It's more like a motherboard programmer. It's hard to explain. The last article goes into some of that.
Click to expand...
Click to collapse
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
ZHNN said:
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
Click to expand...
Click to collapse
The best way to remove google entirely is to flash a custom ROM or GSI if your device supports it. You really only need to look in system/app and system/priv-app for google stuff. Some phones use stock Google apps for things like the Calendar or MMS. So, to run google-less you may need to replace some system apps as well. Just a warning, even if you already know this. Removing certain apps, even google apps, may cause problems for normal operation. Definitely make a backup before deleting anything in the system.
ZHNN said:
Do you know if there is any tool that lists all the various initscripts and settings in use on a running system? I'd like to remove Google entirely from my phone, but there are so many firmwares and initscripts all over the place that I can't even figure out which ones are actually used to run the system. Half of the settings files, properties, and commands return 0 results or 3-4 useless results when searching for them on the internet.
Click to expand...
Click to collapse
I'm no expert but have been running lineageos 14.1 for some time now. It is a version of android 7.1 in which everything google has been removed. I use it with microG which replaces google play services.
You may wish to look into it instead of re-inventing the wheel.
I use it with a firewall (AFWall +), and Xprivacylua for additional privacy.