Does anyone know the fix to this error when trying to use an external core library?
Attempt to include a core VM class in something other than a core library.
It is likely that you have attempted to include the core library from a desktop
virtual machine into an application, which will most assuredly not work. If
you really intend to build a core library -- which is only appropriate as
part of creating a full virtual machine binary, as opposed to compiling an
application -- then use the "--core-library" option to suppress this error
message. If you go ahead and use "--core-library" but are in fact building
an application, then please be aware that your build will still fail at some
point; you will simply be denied the pleasure of reading this helpful error
message.
Related
Hi, I haven't posted 10 times yet, so hopefully somebody can move this to the Android Development section for me...
SurfaceFlinger has a mode called "COMPOSITION_BYPASS". This lets a fullscreen OpenGL window draw directly to the framebuffer, instead of SurfaceFlinger copying each frame to the framebuffer itself. It avoids a fullscreen copy and avoids a GPU context switch. It should be a major performance enhancement.
I haven't got it to work yet, but I've made some progress. Posting in case anybody has any good ideas to try...
The COMPOSITION_BYPASS mode is enabled in SF's Android.mk and the part that allocates the buffer for the client app is in Layer.cpp:387. I tried previously to enable COMPOSITION_BYPASS mode but got stuck because gralloc would not return a valid FD for any buffer allocated with GRALLOC_USAGE_HW_FB (i.e.: a framebuffer backbuffer).
I noticed in the new SGX drivers that gralloc.omap3.so has a constant string HALCompositionBypass. I *think* that adding a line like HALCompositionBypass=1 to /system/etc/powervr.ini might change the behavior of gralloc and give valid FDs out -- however, when I set it gralloc_open in FramebufferNativeWindow.cpp returns EFAULT!
Maybe some kernel poking is required...
Randall
Hello,
I have a simple question about the compilation in the cloud for wp8 apps. As detailed on the MS Blog post titled Compile in the Cloud with WP8, when a developer submits an WP8 (only) app to the store, the app is compiled in MDIL in order to optimize the subsequent execution.
Despite this, on my unlocked Samsung Ativ S I experienced that even in the case of wp8 app - and I mean, apps that target ONLY the WP8 platform - the DLLs are still in CIL and not MDIL, and so they can be easily decompiled with tool such as dotPeak.
My question is: where am I wrong?
Thanks,
Sandro.
.NET binaries have multiple pieces. One of them is the CIL, which is what something like dotPeek decompiles. There's also an area where JIT output can be stored, to speed up future execution. It sounds like what the Store is doing is JITing the apps for ARM processors, to reduce load time after installing (otherwise, JITing a large app on the phone can take a while; you can see this yourself if you ever sideload a large app). This slightly increases the size of the binaries, but improves performance. The CIL isn't removed though, either because they want to allow the phone to make different optimizations (for example, different amounts of CPU cache can effect when you would want to unroll loops or inline function calls vs. when you wouldn't) or just because the format of a .NET binary *expects* there to be CIL there.
GoodDayToDie said:
.NET binaries have multiple pieces. One of them is the CIL, which is what something like dotPeek decompiles. There's also an area where JIT output can be stored, to speed up future execution. It sounds like what the Store is doing is JITing the apps for ARM processors, to reduce load time after installing (otherwise, JITing a large app on the phone can take a while; you can see this yourself if you ever sideload a large app). This slightly increases the size of the binaries, but improves performance. The CIL isn't removed though, either because they want to allow the phone to make different optimizations (for example, different amounts of CPU cache can effect when you would want to unroll loops or inline function calls vs. when you wouldn't) or just because the format of a .NET binary *expects* there to be CIL there.
Click to expand...
Click to collapse
Can you please point me to any documentation that describes the .NET binaries format, in order to better understand the CIL and MDIL section and .NET binary structure in general ?
Thanks, Sandro
The ones I found were all pre-MDIL, I'm afraid. There's plenty of documentation of the general format of a PE binary - it's a public standard - but I'm not sure where the MDIL is stored, actually. I was mistaken about the normal JIT output; it's either stored in memory only for that process execution, or in an assembly cache (as when you run ngen.exe on a managed assembly).
I'm trying to learn a bit about android and ROMs and programming in general. I have limited experience but not a whole lot. I have my environment set up, CM11 source downloaded and my tf701t tree downloaded.
When I go to run 'brunch tf701t' I get a couple of minutes into the build and I run into the following error:
warning: [options] source value 1.5 is obsolete and will be removed in a future release
warning: [options] target value 1.5 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
libcore/luni/src/main/java/java/util/EnumMap.java:162: error: incompatible types: Object cannot be converted to E
return type.get(new MapEntry(enumMap.keys[prePosition],
^
where E is a type-variable:
E extends Object declared in class EnumMapIterator
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
3 warnings​
I'm using the Sun Java JDK jdk1.7.0_67. I fixed an earlier issue where I it was referencing the OpenJDK and killing the build almost right away. It COULD still be the JDK, there are so many damn versions out there.
I'm at a stopping point, not sure where to go on from here. Any help and suggestions are appreciated.
OK, I solved that error by uninstalling all JDKs, rebooting then installing Sun JDK 6.
Now it's on to the next problem.
Yes I was going to say I always drop to version 6 rather than 7 first if I get any java errors.
What is your next issue?
My next issue was missing proprietary files, specifically the icera ones. I'm also missing keystore.tegra.so.
I'm building on a VMWare 10 Ubuntu 14 virtual machine with 4GB alloted of ram and 75GB of cache on an aging HP QuadCore. Not even an i series, so it is slow going.
Sent from my K00C using XDA Premium HD app
I got past those errors by locating them and putting them in their proper locations.
The build process took about 8 hours. Zero hour arrived, I backed up my CROMBi-kk installation, loaded up my home cooked cm11 ROM, crossed my fingers and pressed the power button.
Success! Yay me! :laugh:
Everything booted up, wifi located and connected, signed into Google, CyangenMod and proceeded to restore my account.
It was pretty neat to see my name in the about section. :silly:
What I gained from this.
I need a new PC or at least I need to beef this one up a bit.. I bought the old girl in 2009.
I don't really like Ubuntu as a development environment. I don't like Unity, never have. I did install gnome-fallback, but I had issues with the minimal desktop, the dreadful screen blanking that I could just not turn off no matter how many settings and CLI tricks I used. I think I'm going to try Linux Mint next. IMHO it has lower overhead than Ubuntu and should, at least as a VM, give me some better performance.
My problem solving skills have not completely left me in my older years. I left IT some 15+ years to pursue a career in EMS and Firefighting, so my skills have been mostly backseat and hobby like. Being retired I've got the time to putz around and see what I can do. I was glued to Google remembering and dusting off my shell and CLI basics.
Now it is on to learning how to customize and tweak the ROM.
Hello,
i've spent few days experimenting and i'm totally lost.
I will write some example scenario:
I have function_1 in which give different results on every run (if last call >30s new results, <30s will give old one) (the time is checked using another "Utils class")
I'm hooking 3 processes which use some_method_1
I need to give them exactly same results from my function_1
The problem is every hooked process run another instance (?) of function_1, so i get bad results.
I've experimented a lot with Intents, BroadcastReceiver etc.
Tried implemeting them in initZygote but the problem was i don't know why but i can't load there sqlite file
Code:
SQLiteDatabase db = SQLiteDatabase.openDatabase(PATH, null, 1);
loading of file mostly works only in some parts of handleLoadPackage.
Tried invoking file loading, when all was loaded but still error 14, i guess it's about that BroadcastReceiver was in initZygote , and to be strict it was:
Code:
findAndHookMethod("com.android.server.am.ActivityManagerService", null, "systemReady", Runnable.class, new XC_MethodHook()
I would be glad for any help, thanks in advance!
Actually each process has its own memory. During startup, there is only one process (well, on 32-bit ROMs that is) called Zygote. That's where Android initializes some stuff that is required by every app, and where initZygote() is called. Every time an app is started, it gets a copy of the Zygote process, including its memory at that time, but from that point on, the memory is independent. There is no sync between the app's memory and Zygote anymore, in neither direction, and no sync between apps.
If I understand you correctly, you store the result and the timestamp in variables. As explained above, that variable is not shared between processes due to Android's (or Linux') general architecture. That's what you need IPC for, i.e. using services, intents, files, ... I don't know what exactly you're trying to do and which solution would fit best. Using files is usually the easiest way, but they're not really suitable if you have lots of refreshes and you might run into racing conditions. With intents, you have to check whether you can find a good way to send back the result. And services are generally possible (used e.g. by XPrivacy), but harder to implement, especially under Lollipop.
rovo89 said:
Actually each process has its own memory. During startup, there is only one process (well, on 32-bit ROMs that is) called Zygote. That's where Android initializes some stuff that is required by every app, and where initZygote() is called. Every time an app is started, it gets a copy of the Zygote process, including its memory at that time, but from that point on, the memory is independent. There is no sync between the app's memory and Zygote anymore, in neither direction, and no sync between apps.
If I understand you correctly, you store the result and the timestamp in variables. As explained above, that variable is not shared between processes due to Android's (or Linux') general architecture. That's what you need IPC for, i.e. using services, intents, files, ... I don't know what exactly you're trying to do and which solution would fit best. Using files is usually the easiest way, but they're not really suitable if you have lots of refreshes and you might run into racing conditions. With intents, you have to check whether you can find a good way to send back the result. And services are generally possible (used e.g. by XPrivacy), but harder to implement, especially under Lollipop.
Click to expand...
Click to collapse
IPC would be some good idea, thanks for hints Master, I appreciate your response!
//I aim only KK, don't plan to use LP
I don't know anything about rooting phones was just curious if maybe someone could take this exploit and use it for good use and we would be able to root our phones. I used a program called Quadrooter By Checkpoint and we are vulnerable to CVE-2016-2059 (Elevation of privilege vulnerability in Qualcomm networking component) and CVE-2016-2504 (The Qualcomm GPU driver devices allows attackers to gain privileges via a crafted application, aka Android internal bug 28026365 and Qualcomm internal bug CR1002974.). I'm on Marshmallow with the latest updates.
The article is here
http://thehackernews.com/2016/08/hack-android-phone.html
That is interesting, im not a developer, so im no help, only to test if someone comes up with something. 5.0 OF3.
Quadrooter is a menace, yes, in short time, around 2 months, the gpu may be destroyed only installing unchevked apks.
They are doing a new kind of apk, that i am searching how to forbid these "new" apk model, named as multi dex system.
This is running binary codes inside the cache of the app.
For example:
The telegram.apk is all disabled, the system is capting that all relative to trlegram.apk, is not running.
When you never imagine, a notification, appears on the bar, showinh a new message, but, why?
The app is disabled, but the cached-dex no.
This is a serious menace, because these cached codes are "temporary".
If some "cached dex" is executing, the ram memory goes down, and the system, does not captures this dex running.
Imagine another worst thing:
Any cached dex is programmed to copy and send some victim's bank password for determinated site, in background, on where the system will never shows the relathive dex process at least the relative apk that created this dex.
Be carefull only with the apks thst you install, and never use if is multidex .
You can check if is multidex or not before installing, if haves zipped or jar classes , don't install.
Or the device may be burned.
That is all
Sent fro SomeFon