Related
Presently we're running a little short on kernel exploits, with the following being the only one that looks remotely plausible:
http://xorl.wordpress.com/2010/01/14/cve-2009-4141-linux-kernel-fasync-locked-file-use-after-free/
Big hold-up? For all that we have a trigger, we don't have an exploit. I believe it's up to us at this point to make that happen.
If I'm reading it right, it looks like the bug initially rears its head right here:
Code:
void __kill_fasync(struct fasync_struct *fa, int sig, int band)
{
while (fa) {
struct fown_struct * fown;
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
[B]fown = &fa->fa_file->f_owner;[/B]
/* Don't send SIGURG to processes which have not set a
queued signum: SIGURG has its own default signalling
mechanism. */
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
fa = fa->fa_next;
}
}
... as fa_file now points to invalid memory (having been free'd earlier). The f_owner member gets shot out to send_sigio, which look like this:
Code:
void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
struct pid *pid;
int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
if (type == PIDTYPE_MAX) {
group = 0;
type = PIDTYPE_PID;
}
[B]pid = fown->pid;[/B]
if (!pid)
goto out_unlock_fown;
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, group);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
out_unlock_fown:
read_unlock(&fown->lock);
}
... in which we see the f_owner member being dereferenced. Also it gets pushed through several other functions which may be exploitable.
There are several questions to be answered before we can start attacking this:
Can we resolve the address of the fa_file data structure so we can overwrite the f_owner value?
Can we do anything with it once we've done that? (Presumably we can set it to zero to cause a null-pointer dereference, but we're mmap_min_addr = 32768 on the most recent versions, so unless we can flag the mmap region to grow down and apply memory pressure to reach page 0 this will do us no good.)
Failing the plan above: are any of the functions that f_owner gets pushed into vulnerable? I evaluated this over the weekend, but without the help of a trained kernel dev I'm not going to get very far.
While I studied a lot of this in uni, I'll admit I'm green when it comes to actually writing these exploits. I'm hoping that this will get the creative juices flowing, and perhaps provide a more comprehensive resource in case any hard-core kernel hackers want to take a look at what we're doing or give us pointers (harhar) in the right direction.
Thanks, guys. Great work up to this point.
In the original POC if you change /bin/true to /system/bin/sh you can get a new shell to open just not as root. So I'm guessing that their needs to be more added to the POC to make it a full exploit.
Right, the fork()'s in the PoC exist only to cause the file descriptor's fasync_struct to be erroneously killed, not start a root session. The root session would need to be started (presumably) by the kernel doing something to our maliciously crafted fown_struct.
The tough part is figuring out exactly where and what that fown_struct needs to be.
Well I definetly agree with you that this seems to be our best best bet I am some what of a newbie when it comes to linux allthough i am learning as i go. Do you know of any good sites to read up on kernel hacking?
Sorry Guys just got the word that this one is dead for us.....
Here is the explantion i got.
some_person said:
Nope, the bug didn't exist in 2.6.27. That's why they say >= 2.6.28 are vulnerable.
As far as how the bug works, there are 2 other issues. 1) our kernel probably wasn't compiled with AT_RANDOM 2) we don't have an elf executable.
The exploit you found does not give us root access, it crashes the system. Basically, you open the "random number generator" file, lock it, and close it... but the lock release when you close it. Then you have to call an elf executable because that generates a random number (running an elf executable) provided the kernel was compiled AT_RANDOM. you continue to call that executable (and generating random numbers) until the the lock is released on the "random number generator" file... then it's your program's turn... the kernel tries to send your program notification that the file is available, but your program has moved on. BLAM the kernel stops (or "oops").
Click to expand...
Click to collapse
Sorry to dredge up an old thread:
This exploit *will* work. According to Zanfur, the hole is in our kernel. We need to use it without AT_RANDOM (which I dont know how to do).
http://sourceware.org/ml/libc-alpha/2008-10/msg00016.html
I am pretty sure we do have elf executables, here is proof:
% file m6
m6: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If our kernel is susceptible to this bug then it should work, as long as there is a way to do it without at random.
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
jballz0682 said:
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
Click to expand...
Click to collapse
This won't get us root. Even zanfur said it. Moving on....
Framework43 said:
This won't get us root. Even zanfur said it. Moving on....
Click to expand...
Click to collapse
To clarify, even if we get AT_RANDOM functionality working, we can't use this to exploit our kernel. All we can do with this is get data from a file that was recently closed. The point of this exploit is to send a signal to a process, but there are no processes we could send a signal to that would give us root.
Our kernel seems practically invulnerable, it appears that almost all exploits are patched
Just updated to ADT 8.0.0 for Gingerbread goodness, and now it won't compile a project that compiled perfectly well on the previous version with the following error:
Code:
[2010-12-06 20:55:23 - Dex Loader] Unable to execute dex: null
[2010-12-06 20:55:23 - DummyAndroidProject] Conversion to Dalvik format failed: Unable to execute dex: null
I've narrowed this down to the fact that my Android project references a pure Java Eclipse project I have in the same workspace, which is a platform-neutral library I wrote myself. I confirmed by creating a blank Java project with an empty class, and a blank Android project that referenced the Java project as a library. This triggered the above dex error.
Has anyone else encountered this? I'm sure I'm not the only one who references external projects in this way?
I got the exact same problem. Have you found a solution?
Nothing yet. Going to report it as a bug and see of this behaviour is intentional. I certainly hope not.
As a workaround, manually including the library as a .jar should work...
Ok, now got it logged as bug 13000 (!) right here.
My current workaround is to link the source of my Java project to my Android project (right click Android project, 'Build Path' > 'Link Source')
FYI, Google have just pushed out AT 8.0.1 that fixes this bug. Hooray!
Hi everybody,
It's my first post on XDA, because I always got my answer on the differents topics I found.
I'm actually working on monitoring network. I use the firmware provide by these brillant guys :
http bcmon blogspot ie/.
I want to developp an native code to write a easy airodump-ng like, to monitoring the traffic close to my device.
I need to use radiotap headers to do what I want, and of course a monitoring access to my wireless card.
So I reverse the bcmon.apk provided by bcmon team, to look how they lauch airodump-ng in a term. I noticed they use LD_SHARED=`pwd`/libs LD_PRELOAD=`pwd`/fakedriver.so.
My first problems : my toolchain (provided by NDK) don't have radiotap header access, and I really don't know how to add these last one to it.
My second problems : how to compile my code with the LD_SHARED/ LD_PRELOAD libraries used by bcmon drivers to ensure I'll be able to execute my code with the monitor mode activated. I think that I will have to add the libs contained on /data/data/com.bcmon.bcmon/files/libs
on these of my toolchains, but I really don't know.
I read a lot papers to understand how linking works in C, but I'm probably still missing something.
I really don't know how to improve my toolchain, and I'm quite anoyed because I haven't progressed in my work for days...
Any help will be really appreciated.
Thanks a Million
Ant.
I found a solution few weeks ago.
I had linking erros.
I reserved the .apk provided by bcmon guys.
For those that want to develop using monitoring functionnalities, there is the way to do :
LD_PRELOAD=/data/data/com.bcmon.bcmon/files/libs/libfake_driver.so LD_LIBRARY_PATH=/data/data/com.bcmon.bcmon/files/libs ./yourprog
If you want to comiple your code using some of their libraries, for example pcap libraries I have done the fellowing stuffs :
1- found radiotap headers, and pcap headers on github likes websites.
2- try to cross compile with the headers
3- Correct the erros (like typedef missing ...)
4- Build your make file adding name of the libraries :
GCC={your toolchain}
FLAGS={your flags}
LIBS=libfake_driver.so \
libpacap.so.1
OBJ = {your obj}
output :
$(GCC) $(OBJ) -c {yoursrcfile) -o {output} $(FLAGS) $(LIBS)
Hope it 'll help.
Ant.
Hello I am trying to port the beloved OmniRom to my device which is a KLTE (Samsung Galaxy S5) I have successfully built the ROM from source using kernel and device configs from CM and of course some fixes and cherry picking. The issue I have now is that the ROM will not boot.
I stays at my carrier logo (Samsung) so it does not even let me cat-log. I tried to install the ROM and then restored a backup of Cyanogenmods system directory. It boots to android but all apps forceclose. I did this to see if it was an issue with the boot image and since it can boot to a different system partition I don't believe its a boot.img issue or kernel issue for that matter. Or is it?
Any help getting this to boot would be appreciated. I can provide build logs and my device repo if needed.
gigoo25 said:
Hello I am trying to port the beloved OmniRom to my device which is a KLTE (Samsung Galaxy S5) I have successfully built the ROM from source using kernel and device configs from CM and of course some fixes and cherry picking. The issue I have now is that the ROM will not boot.
I stays at my carrier logo (Samsung) so it does not even let me cat-log. I tried to install the ROM and then restored a backup of Cyanogenmods system directory. It boots to android but all apps forceclose. I did this to see if it was an issue with the boot image and since it can boot to a different system partition I don't believe its a boot.img issue or kernel issue for that matter. Or is it?
Any help getting this to boot would be appreciated. I can provide build logs and my device repo if needed.
Click to expand...
Click to collapse
MSM8974 is our first CAF chipset we're working on supporting.
I'd suggest looking at the Oppo find7/msm8974-common repos as nearly all initial CAF 8974 work is being done on the Find7.
you need android-5.1-caf branches for frameworks/av and frameworks/native for a CAF device until I finish the merge effort
Entropy512 said:
MSM8974 is our first CAF chipset we're working on supporting.
I'd suggest looking at the Oppo find7/msm8974-common repos as nearly all initial CAF 8974 work is being done on the Find7.
you need android-5.1-caf branches for frameworks/av and frameworks/native for a CAF device until I finish the merge effort
Click to expand...
Click to collapse
Thank you! That explains a lot. Maybe you can help me again? I keep coming across building with legacy opposed to CAF and to change it in the configs... What configs are they talking about?
Sent from my SM-G900T using XDA Free mobile app
gigoo25 said:
Thank you! That explains a lot. Maybe you can help me again? I keep coming across building with legacy opposed to CAF and to change it in the configs... What configs are they talking about?
Sent from my SM-G900T using XDA Free mobile app
Click to expand...
Click to collapse
You mean AOSP HALs? It's pretty rare for a CAF device to work with vanilla AOSP HALs.
It's the various QCOM_blah_VARIANT flags - 8974s are caf-bfam
Entropy512 said:
You mean AOSP HALs? It's pretty rare for a CAF device to work with vanilla AOSP HALs.
It's the various QCOM_blah_VARIANT flags - 8974s are caf-bfam
Click to expand...
Click to collapse
Updated my repo to 5.1 source but still getting errors. Here is the device configs that I am using. I am getting the same errors throughout.
First error was
Code:
frameworks/base/core/jni/android_view_Surface.cpp:206:14: error: 'class android::Surface' has no member named 'setDirtyRect'
surface->setDirtyRect(&rect);
Which I solved by cherry-picking THIS
Next I get an error that msmcal-hwdep.h is not found not sure how to fix this yet...
I recreated my devices config from scratch and uploaded it to git... Maybe you can take a look when you have some free time? It would mean alot! https://github.com/Gigoo25/android_device_samsung_klte
gigoo25 said:
Updated my repo to 5.1 source but still getting errors. Here is the device configs that I am using. I am getting the same errors throughout.
First error was
Code:
frameworks/base/core/jni/android_view_Surface.cpp:206:14: error: 'class android::Surface' has no member named 'setDirtyRect'
surface->setDirtyRect(&rect);
Which I solved by cherry-picking THIS
Next I get an error that msmcal-hwdep.h is not found not sure how to fix this yet...
I recreated my devices config from scratch and uploaded it to git... Maybe you can take a look when you have some free time? It would mean alot! https://github.com/Gigoo25/android_device_samsung_klte
Click to expand...
Click to collapse
msmcal_hwdep - look at the stiff in your kernel source under include/ - all of that header-y stuff in some of the Kconfigs
You shouldn't be cherrypicking that, I'm not sure why Max even put that up. Until I finish the CAF av/native merge, anyone declaring QCOM_HARDWARE should be using the android-5.1-caf branches of av and native
Entropy512 said:
msmcal_hwdep - look at the stiff in your kernel source under include/ - all of that header-y stuff in some of the Kconfigs
You shouldn't be cherrypicking that, I'm not sure why Max even put that up. Until I finish the CAF av/native merge, anyone declaring QCOM_HARDWARE should be using the android-5.1-caf branches of av and native
Click to expand...
Click to collapse
Awesome! alright will look into that
Sent from my SM-G900T using XDA Free mobile app
Entropy512 said:
msmcal_hwdep - look at the stiff in your kernel source under include/ - all of that header-y stuff in some of the Kconfigs
You shouldn't be cherrypicking that, I'm not sure why Max even put that up. Until I finish the CAF av/native merge, anyone declaring QCOM_HARDWARE should be using the android-5.1-caf branches of av and native
Click to expand...
Click to collapse
Having issues compiling the camera I get the error
Code:
device/samsung/klte/camera/CameraWrapper.cpp: In function 'char* camera_fixup_setparams(int, const char*)':
device/samsung/klte/camera/CameraWrapper.cpp:161:20: error: 'KEY_DIS' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_DIS, android::CameraParameters::DIS_DISABLE);
^
device/samsung/klte/camera/CameraWrapper.cpp:161:56: error: 'DIS_DISABLE' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_DIS, android::CameraParameters::DIS_DISABLE);
^
device/samsung/klte/camera/CameraWrapper.cpp:162:20: error: 'KEY_ZSL' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_OFF);
^
device/samsung/klte/camera/CameraWrapper.cpp:162:56: error: 'ZSL_OFF' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_OFF);
^
device/samsung/klte/camera/CameraWrapper.cpp:164:20: error: 'KEY_ZSL' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_ON);
^
device/samsung/klte/camera/CameraWrapper.cpp:164:56: error: 'ZSL_ON' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_ON);
^
make: *** [/home/rob/android/omni51/out/target/product/klte/obj/SHARED_LIBRARIES/camera.msm8974_intermediates/CameraWrapper.o] Error 1
make: *** Waiting for unfinished jobs...
Is this a framework issue?
gigoo25 said:
Having issues compiling the camera I get the error
Code:
device/samsung/klte/camera/CameraWrapper.cpp: In function 'char* camera_fixup_setparams(int, const char*)':
device/samsung/klte/camera/CameraWrapper.cpp:161:20: error: 'KEY_DIS' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_DIS, android::CameraParameters::DIS_DISABLE);
^
device/samsung/klte/camera/CameraWrapper.cpp:161:56: error: 'DIS_DISABLE' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_DIS, android::CameraParameters::DIS_DISABLE);
^
device/samsung/klte/camera/CameraWrapper.cpp:162:20: error: 'KEY_ZSL' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_OFF);
^
device/samsung/klte/camera/CameraWrapper.cpp:162:56: error: 'ZSL_OFF' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_OFF);
^
device/samsung/klte/camera/CameraWrapper.cpp:164:20: error: 'KEY_ZSL' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_ON);
^
device/samsung/klte/camera/CameraWrapper.cpp:164:56: error: 'ZSL_ON' is not a member of 'android::CameraParameters'
params.set(android::CameraParameters::KEY_ZSL, android::CameraParameters::ZSL_ON);
^
make: *** [/home/rob/android/omni51/out/target/product/klte/obj/SHARED_LIBRARIES/camera.msm8974_intermediates/CameraWrapper.o] Error 1
make: *** Waiting for unfinished jobs...
Is this a framework issue?
Click to expand...
Click to collapse
Looks like maybe some missing Samsung patches
Entropy512 said:
Looks like maybe some missing Samsung patches
Click to expand...
Click to collapse
I appreciate all the help you have been giving me in trying to port Omni to the KLTE! I could not have done it without you!
I ended up having a booting and working build when I removed the camera and RIL
RIL gives me an error of
Code:
frameworks/opt/telephony/../../../device/samsung/klte/ril/telephony/java/com/android/internal/telephony/KlteRIL.java:282: error: no suitable constructor found for SignalStrength(int,int,int,int,int,int,int,int,int,int,int,int,int,boolean)
return new SignalStrength(gsmSignalStrength, gsmBitErrorRate, cdmaDbm, cdmaEcio, evdoDbm,
^
constructor SignalStrength.SignalStrength(Parcel) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(SignalStrength) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(int,int,int,int,int,int,int,boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(int,int,int,int,int,int,int,int,int,int,int,int,boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength() is not applicable
(actual and formal argument lists differ in length)
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
It should be a frameworks/opt/telephony issue correct? Except it doesn't display the full file path?
gigoo25 said:
I appreciate all the help you have been giving me in trying to port Omni to the KLTE! I could not have done it without you!
I ended up having a booting and working build when I removed the camera and RIL
RIL gives me an error of
Code:
frameworks/opt/telephony/../../../device/samsung/klte/ril/telephony/java/com/android/internal/telephony/KlteRIL.java:282: error: no suitable constructor found for SignalStrength(int,int,int,int,int,int,int,int,int,int,int,int,int,boolean)
return new SignalStrength(gsmSignalStrength, gsmBitErrorRate, cdmaDbm, cdmaEcio, evdoDbm,
^
constructor SignalStrength.SignalStrength(Parcel) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(SignalStrength) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(int,int,int,int,int,int,int,boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(int,int,int,int,int,int,int,int,int,int,int,int,boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength(boolean) is not applicable
(actual and formal argument lists differ in length)
constructor SignalStrength.SignalStrength() is not applicable
(actual and formal argument lists differ in length)
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
It should be a frameworks/opt/telephony issue correct? Except it doesn't display the full file path?
Click to expand...
Click to collapse
It looks like the KLTE actually specifies its own RIL subclass (interesting trick, I've never seen that before) and that subclass is depending on something in frameworks/opt/tel that Omni doesn't have.
Either find the missing patch in f/opt/tel or figure out how to adapt KlteRIL.java
Entropy512 said:
It looks like the KLTE actually specifies its own RIL subclass (interesting trick, I've never seen that before) and that subclass is depending on something in frameworks/opt/tel that Omni doesn't have.
Either find the missing patch in f/opt/tel or figure out how to adapt KlteRIL.java
Click to expand...
Click to collapse
I seem to have gotten everything working fine besides the camera. The app and libraries compile fine but when the rom boots I cannot see it in the app drawer. When I try to launch it through the lockscreen it just force closes. Not sure what could be causing the problem? All the permissions seem to be checking out, and messing with the BoardConfiv and Device make files has not seemed to help. Any suggestions on how to fix this? Could it be a framework issue?
gigoo25 said:
I seem to have gotten everything working fine besides the camera. The app and libraries compile fine but when the rom boots I cannot see it in the app drawer. When I try to launch it through the lockscreen it just force closes. Not sure what could be causing the problem? All the permissions seem to be checking out, and messing with the BoardConfiv and Device make files has not seemed to help. Any suggestions on how to fix this? Could it be a framework issue?
Click to expand...
Click to collapse
Look through the logcat for camera errors, especially any errors about missing libraries.
Not appearing in app drawer indicates that Android doesn't think there is a camera present. There are 2349734297320 different things that could cause this - missing camera HAL dependency, kernel/HAL mismatch, many other things.
Entropy512 said:
Look through the logcat for camera errors, especially any errors about missing libraries.
Not appearing in app drawer indicates that Android doesn't think there is a camera present. There are 2349734297320 different things that could cause this - missing camera HAL dependency, kernel/HAL mismatch, many other things.
Click to expand...
Click to collapse
Here is what I found in the logcat
Code:
--------- beginning of crash
[ 06-01 20:08:07.366 3437: 3437 E/AndroidRuntime ]
FATAL EXCEPTION: main
Process: com.android.camera2, PID: 3437
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.camera2/com.android.camera.CameraActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.android.camera.util.PhotoSphereHelper$PanoramaViewHelper.onStart()' on a null object reference
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2325)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2387)
at android.app.ActivityThread.access$800(ActivityThread.java:151)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1303)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.android.camera.util.PhotoSphereHelper$PanoramaViewHelper.onStart()' on a null object reference
at com.android.camera.CameraActivity.onStartTasks(CameraActivity.java:1885)
at com.android.camera.util.QuickActivity.onStart(QuickActivity.java:111)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1236)
at android.app.Activity.performStart(Activity.java:6006)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2288)
... 10 more
gigoo25 said:
Here is what I found in the logcat
Code:
--------- beginning of crash
[ 06-01 20:08:07.366 3437: 3437 E/AndroidRuntime ]
FATAL EXCEPTION: main
Process: com.android.camera2, PID: 3437
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.camera2/com.android.camera.CameraActivity}: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.android.camera.util.PhotoSphereHelper$PanoramaViewHelper.onStart()' on a null object reference
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2325)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2387)
at android.app.ActivityThread.access$800(ActivityThread.java:151)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1303)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:135)
at android.app.ActivityThread.main(ActivityThread.java:5254)
at java.lang.reflect.Method.invoke(Native Method)
at java.lang.reflect.Method.invoke(Method.java:372)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void com.android.camera.util.PhotoSphereHelper$PanoramaViewHelper.onStart()' on a null object reference
at com.android.camera.CameraActivity.onStartTasks(CameraActivity.java:1885)
at com.android.camera.util.QuickActivity.onStart(QuickActivity.java:111)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1236)
at android.app.Activity.performStart(Activity.java:6006)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2288)
... 10 more
Click to expand...
Click to collapse
Pretty much - if you can't figure out what is wrong from reading a logcat, most likely, you can't figure out what parts of the logcat are relevant and which are not.
That excerpt basically tells me nothing.
I assume that was from trying to forcefully start the camera with no camera actually present as far as Android was concerned. That's a symptom, not the root cause of the problem. Based on what you've described, the root cause of the problem will likely be visible even if no attempt is made to use the camera.
Entropy512 said:
Pretty much - if you can't figure out what is wrong from reading a logcat, most likely, you can't figure out what parts of the logcat are relevant and which are not.
That excerpt basically tells me nothing.
I assume that was from trying to forcefully start the camera with no camera actually present as far as Android was concerned. That's a symptom, not the root cause of the problem. Based on what you've described, the root cause of the problem will likely be visible even if no attempt is made to use the camera.
Click to expand...
Click to collapse
I've been messing around with the device configurations and logcats. I I think I have found the culprit for my camera not working. It shows that it loads the module but then fails to open it? Is this a CameraWrapper issue? Still trying to fix the camera so I can use this as a daily build but I have limited experience as a developer.
EDIT: Also the camera shows up on first boot but then disappears and says that the application is not installed. I'm trying to logcat it but not sure how to do that on the first boot without allowing my PC
EDIT2: From the looks of it searching the web it seems to be an issue with frameworks/av/camera/CameraParameters.cpp & frameworks/av/camera/include/CameraParameters.h
Code:
I/CameraService( 381): CameraService started (pid=381)
I/CameraService( 381): Loaded "MSM8974 Camera Wrapper" camera module
I/CameraWrapper( 381): camera_get_number_of_cameras
I/CameraWrapper( 381): check_vendor_module
I/PackageManager( 741): /system/priv-app/MmsService changed; collecting certs
I/PackageManager( 741): /system/priv-app/OmniSwitch changed; collecting certs
E/HAL ( 381): load: module=/system/lib/hw/camera.vendor.msm8974.so
E/HAL ( 381): dlopen failed: cannot locate symbol "_ZN7android16CameraParameters25KEY_DYNAMIC_RANGE_CONTROLE" referenced by "camera.vendor.msm8974.so"...
E/CameraWrapper( 381): failed to open vendor camera module
gigoo25 said:
I've been messing around with the device configurations and logcats. I I think I have found the culprit for my camera not working. It shows that it loads the module but then fails to open it? Is this a CameraWrapper issue? Still trying to fix the camera so I can use this as a daily build but I have limited experience as a developer.
EDIT: Also the camera shows up on first boot but then disappears and says that the application is not installed. I'm trying to logcat it but not sure how to do that on the first boot without allowing my PC
EDIT2: From the looks of it searching the web it seems to be an issue with frameworks/av/camera/CameraParameters.cpp & frameworks/av/camera/include/CameraParameters.h
Code:
I/CameraService( 381): CameraService started (pid=381)
I/CameraService( 381): Loaded "MSM8974 Camera Wrapper" camera module
I/CameraWrapper( 381): camera_get_number_of_cameras
I/CameraWrapper( 381): check_vendor_module
I/PackageManager( 741): /system/priv-app/MmsService changed; collecting certs
I/PackageManager( 741): /system/priv-app/OmniSwitch changed; collecting certs
E/HAL ( 381): load: module=/system/lib/hw/camera.vendor.msm8974.so
E/HAL ( 381): dlopen failed: cannot locate symbol "_ZN7android16CameraParameters25KEY_DYNAMIC_RANGE_CONTROLE" referenced by "camera.vendor.msm8974.so"...
E/CameraWrapper( 381): failed to open vendor camera module
Click to expand...
Click to collapse
Looks like a patch for CameraParameters needed by your device is missing since no one has tried to bring that device up before, or hasn't tried bringing it up with 5.x
Since it's a Qualcomm-based device and likely using CAF repos, you'll probably have to patch frameworks/av-caf and not frameworks/av - see https://lists.omnirom.org/pipermail/maintainers/2015-June/000101.html for details (we need to add this info to the wiki...)
Entropy512 said:
Looks like a patch for CameraParameters needed by your device is missing since no one has tried to bring that device up before, or hasn't tried bringing it up with 5.x
Since it's a Qualcomm-based device and likely using CAF repos, you'll probably have to patch frameworks/av-caf and not frameworks/av - see https://lists.omnirom.org/pipermail/maintainers/2015-June/000101.html for details (we need to add this info to the wiki...)
Click to expand...
Click to collapse
So I would have to split av into two folders then applying I believe THIS patch to av-caf in order to compile it properly?
Also does native-caf branch still have to be merged before compiling?
gigoo25 said:
So I would have to split av into two folders then applying I believe THIS patch to av-caf in order to compile it properly?
Also does native-caf branch still have to be merged before compiling?
Click to expand...
Click to collapse
Well, the splitting of av is already done. Native is already merged with ifdefs (it didn't require nearly as much ifdefing as av, so we have a "unified" CAF+AOSP native). The only thing that is needed for device maintainers is adding av-caf to omni.dependencies - see the maintainers list post I linked to, or look at the Oppo find7 history.
So once you're pulling in av-caf via omni.dependencies, you should be able to apply that patch to av-caf and then submit it to Gerrit for review.
You might want to start idling in IRC, #omni is where most device maintainers are (in fact, all maintainers for supported devices idle their routinely, it's now a requirement for maintainers to routinely idle in IRC so they can see what's going on/people can ping them with questions.)
Entropy512 said:
Well, the splitting of av is already done. Native is already merged with ifdefs (it didn't require nearly as much ifdefing as av, so we have a "unified" CAF+AOSP native). The only thing that is needed for device maintainers is adding av-caf to omni.dependencies - see the maintainers list post I linked to, or look at the Oppo find7 history.
So once you're pulling in av-caf via omni.dependencies, you should be able to apply that patch to av-caf and then submit it to Gerrit for review.
You might want to start idling in IRC, #omni is where most device maintainers are (in fact, all maintainers for supported devices idle their routinely, it's now a requirement for maintainers to routinely idle in IRC so they can see what's going on/people can ping them with questions.)
Click to expand...
Click to collapse
Turns out I might of fixed the problem. Instead of messing with frameworks/av I can just override it with a file inside include/camera? Looking back at the Cyanogenmod repo for my device THIS is present while in my source it is not.
Compiling now. Will post results after.
Hello,
I am interested in trying to port sumire to Lineage 16.0, the problem is I couldn't find any guide that seemed to help me get started.
In IRC someone told me I had to:
1. Fork the cm-14.1 branch to lineage-16.0, change the required config files, and build in a 16.0 build env.
2. Wait for it to error out, fix error, repeat. Eventually once it builds, attempt booting, check logs to see why it isn't booting, fix error, repeat.
But as you can see, its not much.
I have been taking a look into the first commits for sumire on cm-14.1, https://github.com/LineageOS/androi...mmit/7be9d2e5edf6f7ea1f399febbeee9d9fbdc122e1
But I do not know if its the best way to learn.
Where could I find some guides?
Best regards
algui91 said:
Hello,
I am interested in trying to port sumire to Lineage 16.0, the problem is I couldn't find any guide that seemed to help me get started.
In IRC someone told me I had to:
1. Fork the cm-14.1 branch to lineage-16.0, change the required config files, and build in a 16.0 build env.
2. Wait for it to error out, fix error, repeat. Eventually once it builds, attempt booting, check logs to see why it isn't booting, fix error, repeat.
But as you can see, its not much.
I have been taking a look into the first commits for sumire on cm-14.1, https://github.com/LineageOS/androi...mmit/7be9d2e5edf6f7ea1f399febbeee9d9fbdc122e1
But I do not know if its the best way to learn.
Where could I find some guides?
Best regards
Click to expand...
Click to collapse
It's not really a guide, but the guy in this thread tried to port LOS 15 to the Z5, so it's probably the best place to start. He ran into issues with the camera so take a look at the last few pages too see what's going on. The people in that thread are willing to help.
https://forum.xda-developers.com/z5...erimental-lineageos-15-1-z5c-suzuran-t3894617
Devo7v said:
It's not really a guide, but the guy in this thread tried to port LOS 15 to the Z5, so it's probably the best place to start. He ran into issues with the camera so take a look at the last few pages too see what's going on. The people in that thread are willing to help.
https://forum.xda-developers.com/z5...erimental-lineageos-15-1-z5c-suzuran-t3894617
Click to expand...
Click to collapse
Thanks, although its not for the same device (Mine is sumire) it may be helpful.
I have also found this guide, it seems interesting:
https://fat-tire.github.io/porting-intro.html
algui91 said:
Thanks, although its not for the same device (Mine is sumire) it may be helpful.
I have also found this guide, it seems interesting:
https://fat-tire.github.io/porting-intro.html
Click to expand...
Click to collapse
Is there any progress at porting LOS 16?
BrazzerHead said:
Is there any progress at porting LOS 16?
Click to expand...
Click to collapse
I'm still on it. Advancing slowly as I am a newbie on this and only have a few hours/week to do it.
I will keep you updated
I have successfully come to execute brunch sumire, but I am having problems with open jdk-9:
Code:
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: JAVAC does not match between Make and Soong:
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: Make : /home/hkr/.gentoo/java-config-2/current-user-vm/bin/javac
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: Soong: prebuilts/jdk/jdk9/linux-x86/bin/javac
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:1044: error: Soong variable check failed.
I have copied the prebuild version of java that comes with android into my own local version in gentoo, but still getting the same error.
Any ideas?
I have set up android_device_sony_sumire from sony-msm8994 in the included .repo/local_manifest. Setting ROOMSERVICE_BRANCHES=cm-14 as it functions as a fallback branch was suggested in the console output while i was getting familiar and this is a helpful feature worth noting.
There is an incompatibility in https://github.com/sony-msm8994/android_device_sony_sumire and kitakami-common, the lineage.dependencies file needs to be moved or it will try and download dependencies for the sumire files from the LineageOS Github (http://github.com/LineageOS). Next there are two easy defines, SND_AUDIOCODEC_ALAC and SND_AUDIOCODEC_APE to deal with before an untimely error because of a typo present in the Xperia kernel, content_interprtation_type instead of content_interpretation_type.
Code:
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9377:60: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
if (s3d_frame_packing_payload->content_interprtation_type == 1)
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
out/target/product/sumire/obj/KERNEL_OBJ/usr/include/media/msm_vidc.h:109:15: note: 'content_interpretation_type' declared here
unsigned int content_interpretation_type;
^
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9379:65: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
else if (s3d_frame_packing_payload->content_interprtation_type == 2)
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
out/target/product/sumire/obj/KERNEL_OBJ/usr/include/media/msm_vidc.h:109:15: note: 'content_interpretation_type' declared here
unsigned int content_interpretation_type;
^
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9394:89: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
s3d_frame_packing_payload->fpa_type, s3d_frame_packing_payload->content_interprtation_type, stereo_output_mode);
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
It compiled, but gives a black boot screen both from early boot, a kernel issue, adb seems to be communicating, I'm meddling with the boot image atm so i will know more later (Later: The updated mdss code broke for our case somewhere. I will also need to work on the local_manifest) (Later: New Manifest attached) . Last I tested the kernel a few moons ago it worked on the Z1, so issue this was a surprise... I will also import the changes from the sony-msm8994 project, who is doing a great job, i see quite a lot of work to the sdcardfs code.
threader said:
It compiled, but gives a black boot screen both from early boot, a kernel issue, adb seems to be communicating, I'm meddling with the boot image atm so i will know more later (Later: The updated mdss code broke for our case somewhere. I will also need to work on the local_manifest) (Later: New Manifest attached) . Last I tested the kernel a few moons ago it worked on the Z1, so issue this was a surprise... I will also import the changes from the sony-msm8994 project, who is doing a great job, i see quite a lot of work to the sdcardfs code.
Click to expand...
Click to collapse
How did you managed to compile it? I am finding a lot of problems, for example, in system/core/init/util.h
Code:
#include <android-base/chrono_utils.h>
#include <selinux/label.h>
were not found, so I had to comment them out, but I do not know if this its going to be the best approach...
@algui91
Im about to test what built tonight. I suspect i need to port the binder from sony-msm8994 though, it lookst tasty anyway. But does your build by any chance warn against building with a pre compiled kernel? I guess or simply some headers might have new names maybe or some feature needs to be introduced into the kernel.
The .repo/local_manifest/oss.xml contains some qcom opensource projects, to compile for 16.1 change opensource-location from revision=o-mr to p-mr. Also add https://github.com/sonyxperiadev/transpower/commits/android-8.1.0_r35, for 15.1 or probably master for 16.1, i missed that yesterday.
threader said:
@algui91
Im about to test what built tonight. I suspect i need to port the binder from sony-msm8994 though, it lookst tasty anyway. But does your build by any chance warn against building with a pre compiled kernel? I guess or simply some headers might have new names maybe or some feature needs to be introduced into the kernel.
The .repo/local_manifest/oss.xml contains some qcom opensource projects, to compile for 16.1 change opensource-location from revision=o-mr to p-mr. Also add https://github.com/sonyxperiadev/transpower/commits/android-8.1.0_r35, for 15.1 or probably master for 16.1, i missed that yesterday.
Click to expand...
Click to collapse
Hello,
Thanks for your quick reply, How did your test went? this are the only warnings I get when running brunch sumire:
Code:
build/make/core/combo/TARGET_linux-arm.mk:43: warning: cortex-a53.a57 is armv8-a.
build/make/core/combo/TARGET_linux-arm.mk:45: warning: TARGET_2ND_ARCH_VARIANT, armv7-a-neon, ignored! Use armv8-a instead.
Trying dependencies-only mode on a non-existing device tree?
I applied the required binder changes from sony-msm8994 for AOSP 8.1 and it turns out it results in a locked kernel that fails to even boot, so i'm looking that problem now. So for instant results instead of my Z1 to Z5 kernel, use https://github.com/sony-msm8994/android_kernel_sony_msm8994 in , .repo/local_manifests/LA.BR.1.3.3_rb2.14.xml , you need to comment out common-headers common-kernel, also i see i commented out my kernel, a good place to add sony-msm8994, i realize my project to update the unified kernel is riddled with mines., and we really need 15.1 and 16.1 yesterday.
I've come around to testing the whole Sony-msm8994 project that's up on Z5c, Lineage 15.1 is up with wifi, location, nfc available at least, so is the usb otg switch, not working is fingerprint and gsm services, camera.
Spotted this in logcat.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
TARGET_CPU_VARIANT in device/sony/kitakami-common/BoardConfigCommon.mk is set to generic, it's supposed to be TARGET_CPU_VARIANT := cortex-a53
threader said:
I've come around to testing the whole Sony-msm8994 project that's up on Z5c, Lineage 15.1 is up with wifi, location, nfc available at least, so is the usb otg switch, not working is fingerprint and gsm services, camera.
Spotted this in logcat.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
TARGET_CPU_VARIANT in device/sony/kitakami-common/BoardConfigCommon.mk is set to generic, it's supposed to be TARGET_CPU_VARIANT := cortex-a53
Click to expand...
Click to collapse
Have the same problem, spotted the same Fatal message, Did the change in TARGET_CPU_VARIANT solved the problem?
Best
I've got a problem with librmnetctl, vendor/qcom/opensource/dataservices, not building, netmgrd is complaining about that missing now, I'm trying the version on Xperiadev, but now I've messed up the build i built earlier and need to rebuild all of it...
threader said:
I've got a problem with librmnetctl, vendor/qcom/opensource/dataservices, not building, netmgrd is complaining about that missing now, I'm trying the version on Xperiadev, but now I've messed up the build i built earlier and need to rebuild all of it...
Click to expand...
Click to collapse
I am trying to detect where the error
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
comes from.
I am guessing its some makefile which has a SHARED_LIBRARY link to _ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj missing, but do not know where to find it. I've searched on the LineageOS repos without luck.
algui91 said:
I am trying to detect where the error
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
Click to expand...
Click to collapse
It seems to be called from protobuf, maybe a missing link to it somewhere?
threader said:
It seems to be called from protobuf, maybe a missing link to it somewhere?
Click to expand...
Click to collapse
It seems so, the question is where that 'Somewhere' is. . Will keep searching.
algui91 said:
It seems so, the question is where that 'Somewhere' is. . Will keep searching.
Click to expand...
Click to collapse
I see its in prebuilt compiler also.
But maybe?
Code:
external/protobuf/src/google/protobuf/io/coded_stream.cc :
Los 14.1
bool CodedInputStream::ReadVarint32Fallback(uint32* value) {
if (BufferSize() >= kMaxVarintBytes ||
// Optimization: We're also safe if the buffer is non-empty and it ends
// with a byte that would terminate a varint.
(buffer_end_ > buffer_ && !(buffer_end_[-1] & 0x80))) {
const uint8* end = ReadVarint32FromArray(buffer_, value);
if (end == NULL) return false;
buffer_ = end;
return true;
} else {
// Really slow case: we will incur the cost of an extra function call here,
// but moving this out of line reduces the size of this function, which
// improves the common case. In micro benchmarks, this is worth about 10-15%
return ReadVarint32Slow(value);
}
}
Los.15.1
int64 CodedInputStream::ReadVarint32Fallback(uint32 first_byte_or_zero) {
if (BufferSize() >= kMaxVarintBytes ||
// Optimization: We're also safe if the buffer is non-empty and it ends
// with a byte that would terminate a varint.
(buffer_end_ > buffer_ && !(buffer_end_[-1] & 0x80))) {
GOOGLE_DCHECK_NE(first_byte_or_zero, 0)
<< "Caller should provide us with *buffer_ when buffer is non-empty";
uint32 temp;
::std::pair<bool, const uint8*> p =
ReadVarint32FromArray(first_byte_or_zero, buffer_, &temp);
if (!p.first) return -1;
buffer_ = p.second;
return temp;
} else {
// Really slow case: we will incur the cost of an extra function call here,
// but moving this out of line reduces the size of this function, which
// improves the common case. In micro benchmarks, this is worth about 10-15%
uint32 temp;
return ReadVarint32Slow(&temp) ? static_cast<int64>(temp) : -1;
}
}
The function ReadVarint32Fallback is used in the following libraries :
vendor/sony/kitakami-common/proprietary/vendor/lib64/libsettings.so
vendor/sony/kitakami-common/proprietary/vendor/lib64/libcneapiclient.so
vendor/sony/kitakami-common/proprietary/vendor/lib/libsettings.so
vendor/sony/kitakami-common/proprietary/vendor/lib/libcneapiclient.so
vendor/sony/kitakami-common/proprietary/vendor/lib/mediadrm/libwvdrmengine.so
So i rolled back the functions required by the libraries in external/protobuf/src/google/protobuf/io/coded_stream.h, external/protobuf/src/google/protobuf/io/coded_stream.cc, attached a patch to get a bit farther .
I get the following error now.
Code:
520 F DEBUG : Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf8internal14WireFormatLite10ReadStringEPNS0_2io16CodedInputStreamEPNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEE" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
I think the correct thing to do now is call ReadStringEPNS0_2io16CodedInputStreamEPNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEE