Related
I've been hankering to start porting a game I've been working on(originally was going to be for Zune HD but they haven't released the damn 3D SDK. Video of it running in windows is available on youtube, where my username is marcusmaximus04) to android but was hesitant due to the lack of OpenGL ES2.0 support in the Android SDK. However, looking through the file system on my nexus one, I spotted the file libGLESv2.so, which appears to be the shared object file for exactly this!
Obviously, I still can't use the normal SDK to use this, but in theory, one could use the NDK to use OpenGL ES 2.0 features(shaders, etc) through that shared object file.
The purpose of this post is three-fold. One I want to know if anyone has any background with using OpenGL through the NDK or knows of any tutorials for doing so(I'm not entirely sure how that would work...). Two, I wanted to bring this to the attention of all the devs out there who might be holding off from using ES 2.0 features. And three, I wanted to let everyone else know that such a thing is possible, just 'cause it's exciting.
At any rate, even if I can't find any tutorials I'll probably start plugging away at getting this to work and this should make for an exciting couple weeks/months.
Since we have this pretty well working(even on non-rooted phones) I'll post a sample apk. It doesn't look like much, but it does prove that we're using OpenGL ES 2.0(this will only work on the Nexus One). I'll also post the libGLESv2_adreno.so shared library in the same zip file. Enjoy .
From http://developer.android.com/guide/topics/graphics/opengl.html:
note that though Android does include some basic support for OpenGL ES 1.1, the support is not complete, and should not be relied upon at this time.
Click to expand...
Click to collapse
so official 2.0 support might be a bit off :/
kozm0naut said:
From http://developer.android.com/guide/topics/graphics/opengl.html:
so official 2.0 support might be a bit off :/
Click to expand...
Click to collapse
Possibly, but it does still support it in the NDK(really, this hardcore graphics stuff should be done in the NDK anyway). Even there it's not really official, but they aren't likely to change the API calls since those are already set in stone by khronos.
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
robert-qfh said:
Hi Marcus,
to get started, grab the OpenGL ES 2.0 headers from www DOT khronos.org/registry/gles/ and copy the library file from your phone to the NDK installation dir (build/platforms/android-4/arch-arm/usr/lib/). Next you might inspect the libGLESv2.so with objdump to see what functions it provides:
build/prebuilt/linux-x86/arm-eabi-4.2.1/bin/arm-eabi-objdump -t libGLESv2.so
It should have the 2.0 functions like glCompileShader(), glCreateProgram(), etc.
Finally, add the following line to the Android.mk file in the jni/ directory of your Android project:
LOCAL_LDLIBS += -Lbuild/platforms/android-4/arch-arm/usr/lib -lGLESv2
If you're lucky, that should allow you to compile and link OpenGL ES 2.0 code. I cannot try this right now but will as soon as I get my Nexus One on monday
I haven't done any OpenGL ES coding with the NDK, but it should be straightforward if you've written OpenGL (ES) code before. This might be of use: code DOT google.com/p/glesquake/
Click to expand...
Click to collapse
Alright! Thanks for the help. I've done a lot of opengl work before and a little bit of opengl es when i had my g1 but haven't ever used the ndk, so that'll get me started.
EDIT: Sweet, I've dumped the list of functions available and it looks like all the appropriate shader functions are there. I'm attaching the full list output from my computer. I actually had to use arm-eabi-strings, since the objs one showed no objects. Regardless, it's looking good on the OpenGL ES2.0 front, and I've already looked into running opengl code from the NDK which is perfectly possible and ok.
ANOTHER EDIT: Haven't quite gotten it to build yet, but I got it to load gl2.h without any complaints. Now I just have a crapload of errors because the sample project I was using(from the ndk samples, san-angeles) was written for OpenGL ES 1.0 and all the things now done in shaders no longer exist(GL_LIGHTING, GL_MATERIAL, etc). Regardless, I'm considering this a success so far, since all that is expected.
YET ANOTHER EDIT: It runs! I'm not displaying anything yet(so it's not really a good test), but I got the shared library to build using OpenGL ES 2.0 and it runs on my phone. Gonna implement a simple program to display a triangle or something just to prove it works and will provide source code/binaries here(also, if anyone has a Droid or knows someone who does, it'd be great if we could test out to make sure this works on the Droid as well)
I just wanted to drop in and say I'm very interested in what y'all are doing I'm of very good at coding. All I know is Java but ill definantly be following yall and keep up the good work
Decided to post a reply, rather than just adding to that one post.
Well, I encountered a fairly large roadblock:
Code:
E/libEGL ( 3366): called unimplemented OpenGL ES API
That's what I see now every time I call one of the functions dealing with ES 2.0. I'm hoping there's another library I can use that'll make that go away, but we might not be as easy as I thought to do this.
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
robert-qfh said:
That's bad news indeed. I was hoping that everything is in place and Google just didn't release a new NDK with ES 2.0 support yet, but if the libGLESv20.so is merely a stub, we're pretty much out of luck. I'd probably disassemble the file to see if there's actually some code besides "return unimplemented" in there, but even if there was, I'd have no idea on how to continue...
I'm wondering how they render the fancy rain drop effect on the wallpaper. Looks like a perfect fit for a 2.0 fragment shader, however there are a lot of other ways to create that effect.
Click to expand...
Click to collapse
Well I managed to view the assembly code, but can't get it into any form that I can/want to read(I know how to read assembly but unless you spend hours with it, it's damn near impossible to decode anything. Plus, I haven't looked at ARM assembly before). Know of a good program to convert it into C?
At any rate, I'll attach the disassembler dump(ran it using arm-eabi-objdump with flags -DS). From looking at it briefly, all the implemented functions look like they might be stubs since they're pretty bare bones and have almost all the same instructions(with a slight modification to one single instruction). But it's hard to tell with assembly. Let me know if you can make anything of it. I had to attach the file in a .zip by the way because it was too big.
SUCCESS!!!! So, it looks like those functions were stubs. Google seems to have done it intentionally for whatever reason. They took the .so that actually worked(libGLESv2_adreno200.so) and shoved it under /system/lib/egl, which the ndk doesn't seem able to access(gives you a runtime error if you linked against it). However, If you just copy that file to /system/lib (yes, this requires root unfortunately) then you can use it. I successfully drew a triangle using shaders .
I'll try to get it to attach that xxx_adreno200.so file to the .apk so it can be used without messing around with such things(and work without root). If I can, then I'll throw it on here so everyone can see. Right now it's just a triangle, but tomorrow: the world.
EDIT: Alright, I attached the .apk(it's in the zip file, xda still doesn't allow posting .apks). I tried to attach the libGLESv2_adreno200.so library to it, so it wouldn't require moving the local one but it just wouldn't accept it. So, at least for the mean time, if you want to actually run that app without having it crash you'll have to do an adb remount and then the following in the terminal(or adb shell) as root:
Code:
cd /system/lib/egl
cp libGLESv2_adreno200.so ../
Once you do that, when you run the app it should display a yellowish triangle on a blue background(it was from the second tutorial from the OpenGL ES 2.0 sdk for PowerVX). Like I said, it's not much right now, but it is using custom shaders to display that triangle.
ANOTHER EDIT: I decided to change the test program a little. All I changed was the fragment and vertex shaders, which I made to change the color of the pixels based on where they are on the triangle. This should show(to those of you who know OpenGL) that it really is using custom shaders, since it's one triangle and it's clearly not using fixed-function pipeline shading .
Awesome work on reverse-engineering this! Keep us posted.
Indeed, keep at it Marcus! Very interested to see how this progresses.
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
robert-qfh said:
Well done, Marcus! I'm glad you found that working library.
You should be able to embed the library search path in your own library by using the rpath directive while linking your program. See "man ld" for more information. You need to get the NDK to call the compiler like this:
gcc ... -Wl,-rpath=/system/lib/egl
That should allow you to use that library without copying it around, and therefore make it work on non-root phones as well.
I guess all you need to do is add the directive to the LOCAL_LDLIBS variable in Android.mk, or maybe it has LOCAL_LDFLAGS, which would be more appropriate.
Click to expand...
Click to collapse
Ya, I tried adding it to LOCAL_LDLIBS, but that just seemed to make it use that path for the local library on my computer when building it. It still failed to find that library on my phone when I ran it. I'll try poking around a little more since that would obviously be ideal.
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
robert-qfh said:
Alright. Are you sure you used rpath and not rpath-link?
BTW, there's a libGLESv2.so in the 2.1 emulator image. Did you try using that? I wonder if the emulator supports ES 2.0...
Click to expand...
Click to collapse
I didn't touch either actually, just changed the name of the library and the path it had. I haven't done a lot of make files beyond the most basic operations so a little study might be necessary.
Haven't tried the emulator image one, but the one from the phone just had those stubs. It would be really strange if the emulator had the actual functionality and the phone didn't.
I think you're right that if there's hope then it lies in the makefile, so I'll keep looking into that.
EDIT: Just tried adding --rpath=/system/lib/egl everywhere I could possibly think of and all with no change.
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
[email protected] said:
Hmm I can't try this yet, but it looks like it uses the property java.library.path to determine where to look for shared libraries. Maybe I can have it look in /system/lib/egl too?
Ack, tried it, didn't do anything. Still can't find that library.
So ya, I'm giving up on this front for now. Google obviously has some of this ready but doesn't want us using it for now, so I'll just wait for them to give us access unless I get some new info. In the meantime, I'll continue the work I've already started on porting that game from the video I linked to. At least we now have the tools to test this stuff.
Click to expand...
Click to collapse
thats depressing i was checking this thread like 10 times a day waiting for new info to popup lol call me obsessed but i respect your work
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
robert-qfh said:
Yet another idea to try. On Linux you can specify the library search path using the environment variable LD_LIBRARY_PATH, e.g. if you run a program like this
LD_LIBRARY_PATH=/some/path /path/to/program
then the linker will search that path for libraries.
Maybe it's possible to set that variable from within the Java code, but before the JNI library is loaded:
static {
// Set environment variable LD_LIBRARY_PATH
System.loadLibrary("your_jni_lib");
}
Finally another idea, so we cannot link our library to the OpenGL ES library. But we could probably dlopen() it from within the JNI library and grab all the function pointers using dlsym(). I will get my Nexus One in a few hours, and ES 2.0 will be one of the first things I'm going to look into
EDIT: Marcus, would you mind posting the source code of your ES 2.0 triangle demo application? Basically all I need is the gl....() stuff. I haven't done too much Shader stuff so far, so that would save me a lot of time.
Click to expand...
Click to collapse
Sure. I'll post it when I get home from work tonight. I don't have anything proprietary in there yet.
For the setting of the environment variable, from my understanding that's basically what System.SetProperty("java.library.path"... is supposed to do. But it still couldn't find the library and didn't seem to have any effect.
The dlopen bit might work. I was thinking of trying that but haven't had any time. I'm not really too sure on how these shared libraries are used, whether once they're open any other program can find and use them or whether the path to them has to be given explicitly at link time for the program that wants to use them and just generally having one loaded won't help.
EDIT: By the way, @pr0cl1v1ty: Don't worry, I'm not going to stop digging into ES 2.0 entirely. I'm just not going to be pushing as much for getting it to work on non-rooted phones. I've got bigger fish to fry.
Ok, I have applied the market fix. Even went as far as editing the build line. While my market has expanded, I still can't bring up torque by Ian Hawkins. If I use the web service it shows but says it is not compatible with my device /gtablet/. I even copied the APk from my phone over to my tablet, while it does load it crashes within seconds. Can anyone help me?
I have searched the forum to no avail.
What rom are You using?
rom
I'm using the factory version
Hmm.. haven't ever seen it run on that. I have only seen it running on cm7 and vegan 5.1.
Have you looked into editing your build.prop file to expand market?
I edited the build prop with the mahimahi edit from the forum.
This should be the free apk
http://megaupload.com/?d=B07WAF8Y
I definitely wanted to purchase the app to show support for the developer. But all things considered, I will check out that link. I just wish the andriod market would work properly on my device. The market just recognizes my gtablet as "phone" and constantly says the apps I look at aren't compatible. Seems like my money isn't good enough for Google.
Hi *,
I'm very new to forum and hardware hacking. I'm also new to android dev (I have done some WP7 development).
I want to write application about radio conditions (RSCP, EcNo) and also wanna to decode ASN.1 messages to get some 3GPP layer 3 messages (RRC). To do that, I suppose that low level access is required.
So, is there any tutorials, guides etc. on how to do that for android devices (I know about android telephony class) or WP7/WP8 devices.
I also know that that is not possible on every device due manufacture restrictions.
I'm interested in Galaxy S(2/3), Nokia Lumia, Nexus, etc (device doesn't need to have qualcom chipset, all i wanna to do that).
I also know that some of companies like ASCOM are working together with chip suppliers for that kind of applications.
So, is it possible to do on market smartphones...
Thanks in advance for answers
Cheers!
TK
It's troublesome thing.
Every modern mobile solution does split into AP (Application Processor) and BP/CP/Modem (Baseband/Call Processor), sometimes these are integrated into one SoC (QC chips) or are splitted into 2 SoCs (like Exynos AP+QC/Infineon CP), on AP there's working ARMLinux with Android platform.
Platform does communicate with RIL HAL (proprietary lib), RIL does communicate with modem through some dedicated HW interface using kernel driver, nowaday its common shared-memory topology with abit of control through UART/GPIOs before RAM-share is set up (modem bootup, assuming AP does startup first, which is case in 2xSoC topology, on QC SoCs modem does startup first and does perform bootup of AP submodules).
The problem is - BP OS is closed source. In best case (rather unlikely) low-level transmission params might being received by RIL from AP but not being passed to platform, then you probably would need to patch RIL binary to expose these values to platform. If these transmission params aren't being transmitted from CP to AP, the easiest (and the ugliest) way to do is trying to find network structures inside of modem OS and pooling them from AP (assuming you've got direct access to all of CP memory). More advanced way would be integrating additional data into BP-RIL interface (modifying both RIL and modem binaries), what then narrows down to "best case".
If you aren't familiar with ARM assembly - analysing modem binary is pretty big task, prepare for at least few weeks of intense reversing.
This is a very interesting question!
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
But then again, I don't think anyone have tried hard enough either. I have tried to a limited extent in my research of the Intel XMM6260 and trying to use some of the Android internal telephony API. Others have managed by hacking the AT command line interpreter, directly in the modem image of some limited versions of the 2xSoC's (like those of Intel/Infineon) used for jailbreaking <4S iPhones. These modem images are "only" 10 MB, whereas the Qualcomm modems "images" consists of 50-60 files and have a size up to 60 MB!! Although we should be able to find the AT command Processor (ATcP) in those...
As I see it today, we only have these options how to get these parameters in the Android eco-system.
1) We believe that the modem AT command interpreter/processor have the capability to provide radio parameters to the outside world. But this direct access often seem to be crippled:
a) by denying local or external terminal (UART) serial-access.
b) by being filtered by the RIL daemons and accompanying RIL libraries
c) by being complicated due to using modified IPC (shared memory) communication, rather than regular serial devices. However, by putting the device into "download/debug" mode, sometimes these devices re-appear!
(This is what ODIN, QPST and other programs does, see (4).)
2) We know that the Android internal phone API can use the following calls to get particular modem "stuff" (including sending AT commands): RIL_OEM_HOOK_RAW and RIL_OEM_HOOK_STR
The problem is that no one seem to know how to use it, nor how it depends on the hardware...
3) We know that the Service Mode's (settings/menu) are displaying many of these parameters, so that the phone OS certainly can get have access to these. So another option is to hack and understand how this is done by the service mode menu and the underlying modem software. This is where reverse engineering would come to its right!
4) We also know that many of the OEM phone debug/repair software, like QPST and QDART (Qualcomm) and "CDMA work-shop" etc. have full access to these variables as well...
Actually, if you're on a Qualcomm based device and can put it into QXDM mode, you can have all radio data to be output to the QXDM (3.12.754) software and possibly interface API. Thus... if we can understand the handshake and protocol they use we should eventually be able to make an app that can fetch this data as well...
Thx for your answers!
It looks like I need many hours to investigate and learn! Sound like fun, hope it will be...
I hope that soon I'll post something new on this thread about question.
Thx and hear ya!
Little update: Regarding radio conditions, here is telephony API http://developer.android.com/reference/android/telephony/package-summary.html and here is Signal strength class http://developer.android.com/reference/android/telephony/SignalStrength.html!
So I have these information (at least I hope so, because I don't have device for testing and I don't have dev environment set yet).
Also, regarding WP7 Samsung devices: there is samsung app called Diagnosis, where you can access root/debug screen in Test Mode... I was looking little into that app (I have unlocked Samsung Omnia W device), and there are very interesting informations, like list of neighbour cells with CellID and signal strength and many others (Handover test, antenna/ADC, RRC state, Tx Channel, Tx Power, EcIo, RSCP, L1 (looking now it's PCH_Sleep value ??), etc)
I need that kind of information + need to find way for decode L3 messages like RRC and RLC. From L3 you can find many other information (RAB establishment, IRAT handover, all 3GPP information element for GSM/WCDMA/LTE and so on!)...
hi *,
What about Gobi platform and GOBI dev?
BR
TheKrigla said:
hi *,
What about Gobi platform and GOBI dev?
BR
Click to expand...
Click to collapse
Hi, i was just looking for GOBI, too.
But they only show 4 Devices, with the Gobi-Modem inside:
qualcomm.com/gobi/products/finder?type=Smartphones
But there are buid in a few UMTS/USB-Sticks, Mobile Hotspots, a Router and some Notebooks (SubNotebooks),
Not bad, if you can use it as an external device, like the mobile router.
So it looks like a very special solution.
Did somebody check the HTC, Motorola or Samsung SDK ?
I am also trying to get low network info, and it looks like AT commands that exist (at least on my Samsung S3) do not provide this information. So I think emulating what QXDM does is the secret sauce... but that's hard
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
E:V:A said:
You can probably find what you need in the "QMI" related documents from THIS post... Let us know how it goes!
Click to expand...
Click to collapse
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Chipset access
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
enigma99a said:
I quite don't fully understand how QMI works. The SDK appears (C++) to run on Windows. Is it possible run QMI directly on android? Also one post said that really low level information like Signaling can only be through the diag port. Perhaps there is a way to emulate QXDM on the android and connect to it to grab this info
Click to expand...
Click to collapse
mknair said:
I am wondering how tools like qualpoc from SwissQual work. They seem to have access to every damn thing happening in the android phone. Do they have any special API access from Qualcomm ?
Click to expand...
Click to collapse
Thanks.
http://www.swissqual.com/
Probably nothing special. What is special, is that they have full access to all their documentation. If you can download their white papers and the Android app, I'll tell you how they do it!
Is it possible to connect something like a 4G dongle to the usb port to create a roaming RF scanner and get the RSCP ECIO details from that? It's a bit mental but it doesn't look like we will be able to get this detail from the phone without paying the tens of thousands for the documentation anytime soon...
I tried to connect a Sierra Wireless device which can provide this info but I cannot seem to compile the module against the kernel.
I got QMI talking just fine on android 100%. But I need layer 1 info etc as well (DIAG)... Qualcomm docs look easy enough for the packet structure but now i just need access... And I'm totally stuck. USB is one way, but isn't there to get access locally? Like through UART or some other means? I believe all communication goes to the /dev/diag device but so far I have not been able to get access
E:V:A said:
So far, AFAIK, no one here at XDA (or elsewhere) have been able to successfully extract L1 radio parameters from the modem, using any form of API or other. So anyone who would successfully be able to do this, would be an instant XDA hero! (As for L3, I don't know.)
Click to expand...
Click to collapse
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Any thought about sharing solution?? Not cool man...
enigma99a said:
Well, I guess I am a XDA hero then I have successfully extracted L1 radio info, etc on Android itself. DIAG is pretty powerful and not very well documented so I had to figure everything out myself, but when it works you can get just about anything possible.
Click to expand...
Click to collapse
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
E:V:A said:
Is that right? There were never any heroes who didn't prove their worth. So why don't you share it with us? (Or if you don't want to share, at least tell us why not?)
Click to expand...
Click to collapse
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Hi at all!! My hero, enigma99 please tell me (or who knows)!!
I'm developing a app with SDK that use the java methods of classes like SignalStrenght and Telephony. But those methods dont work very well. (they are slow, and in much smartphone dont return the Ec/Io)
Do you think if in 3g tecnhology (UMTS, HSPA) the modem part always returns all measure (RSCP and Ec/Io)??
What's the way to follow for return this values? recompiling kernel? programming with NDK?
enigma99a said:
Yeah, sorry guys for the late reply. Basically I had to rewrite the diag driver to get diag info. And this project is for profit, so I can't put myself at a competitive disadvantage after spending many weeks on it But if anyone has questions, I would be happy to answer
Click to expand...
Click to collapse
Is this for sale yet? Curious minds would like to know.
Good morning. Just read something online about the Rowhammer exploit that has been used to grant root to the the g4 and was wondering if something similar could root the G5?
Sent from my LG-H820 using Tapatalk
http://arstechnica.com/security/201...tflips-to-root-android-phones-is-now-a-thing/
"Until recently, we never even thought about hardware bugs [and] software was never written to deal with them," one of the researchers, Victor van der Veen, wrote in an e-mail. "Now, we are using them to break your phone or tablet in a fully reliable way and without relying on any software vulnerability or esoteric feature. And there is no quick software update to patch the problem and go back to business as usual."
http://www.techtimes.com/articles/1...id-phones-at-risk-researchers-demonstrate.htm
The exploit has successfully pushed past key security defences that protect an Android device from malicious codes. The researchers embedded it in an app that requires no permissions. Once, downloaded, it then proceeds on systematically taking over core parts of the operating system.
https://www.vusec.net/projects/drammer/
Test App , Source Code and white paper * this isnt for root , this is their Drammer Test App ( as far as i can tell the best way to find out if it will work is for anyone that wants to use the test application available on this link , follow the instructions and allow it to work for about an hr- you know when it works when it starts working on the Template , Hammering and FLIP if it crashes or says service stopped it hasnt worked try again
---
/now its possible for this to work with any device , but with that said its going to cause a major problem , there's no way to even know if another app / game would be infected with the code , or even downloaded via an ap and then executed , once given just the permission to download and run , that's seems all it needs
So it possible to maybe use this to root in some way?
Sent from my LG-H820 using Tapatalk
kyuubi08 said:
So it possible to maybe use this to root in some way?
Sent from my LG-H820 using Tapatalk
Click to expand...
Click to collapse
Maybe not :/ The Device comes with 4GB of LPDDR4 memory
from the devs
We expect, for example, that devices equipped with LPDDR4 are less vulnerable. This is because the LPDDR4 standard includes optional hardware support for the so-called target row refresh mitigation.
Sorry if this is in the wrong location, if it is please let me know where to move it.
So the story goes I found an Amiibo Kiosk at my apartment dumpster. It was originally designed to run a single app meant to be interacted with by customers and a settings app meant to be accessed by a technician and nothing more. Using adb I managed to get into the /actual/ android settings menu instead of the custom "CSR" one that you can access by pushing some buttons on the back and perform a factory reset. If you need more information I documented everything I did here: https://forum.xda-developers.com/android/help/commercial-grade-android-tablet-issues-t3594279 the post is at the very bottom.
It's a giant 18.5 inch 720p commercial tablet from DUCO meant to be mounted in customer-service kiosks: (product page) http://www.ducotech.com/product/18-5-android-based-720p-hi-def-lcd-media-player/
I sideloaded arrow launcher, aosp keyboard, google chrome, and a stripped-down youtube front-end so it can be used as an actual tablet. Unfortunately Google Play services in not supported on this device (although I could probably spoof it as an officially supported device to make it work, but I want to fix my biggest problem first.)
My problem is that after a pretty consistent amount of time it unceremoniously black-screens with a pop from the speakers, then starts back up. I logcatted it and it shows nothing but wlan polls and ram cleanup before it shuts down, however I'll include it anyway since I'm sure that'll be the first thing anybody asks for.
My best guess is that there is some kernel watchdog resetting it since it's not being tickled by DUCO's CSR app that is normally installed when the system is sitting on a salesfloor.
Is there any way to check for this and/or disable it?
Additional info:
Running Android 4.1.1
Sun4i architecture
I attempted to install Busybox, but the tablet resets itself before Busybox can finish installation.
Logcat is here since the logcat.txt is a few kb too big to upload.
How did you get PowerShell to accept the line code. It errors everytime I type the codes you are recommending