Database Develop

Using External core Libraries

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.

[Developers] AdMob SDK 4.10 Released - memory leak fixed hopefully

For those of you developers who are using Admob, they just released a new sdk 4.10, which has some stability improvements. The previous version used to be improperly holding long lived references (the webview is the culprit) to the activity after they were closed. This would easily cause out of memory exceptions to surface (remember that rotating the screen calls onDestroy on the currently run activity and then reruns it - in this scenario every screen rotation would cause the activity to get leaked - baaaaad). The new sdk includes a method in the AdView class called destroy(). You should be calling this in your activity's onDestroy() method to prevent memory leaks.
EDIT: You will have to change the namespace to /lib/res/com.google.ads if you are declaring it in XML as well.

Still leaks...
Hi,
I've tried to incorporate the new SDK and there is still an obvious leak.
I posted a question on stackoverflow.com with all the details and sample code, including a screenshot from HPROF that shows where the leak is (just look for "Android AdMob causes memory leak ?" on stackoverflow.com)
Am I missing something ?

I can now paste links to all the relevant data. Any help will be appreciated
http://stackoverflow.com/questions/6148812/android-admob-causes-memory-leak
https://groups.google.com/group/google-admob-ads-sdk/browse_thread/thread/f48ca3a9d99eba63
https://groups.google.com/forum/#!topic/google-admob-ads-sdk/XnU2K2Q18aA/discussion

Seems that they get rid of AsyncTask (http://code.google.com/mobile/ads/docs/rel-notes.html).
In my app new version of AdMob (4.1.1) doesn't leak memory anymore.

Mine still leaks (detected by leakcanary)
implementation 'com.google.android.gmslay-services-ads:12.0.0'

[Q] Suspend to disk

Is there a way to implement this? http://www.kernel.org/doc/ols/2006/ols2006v2-pages-25-34.pdf I tried doing
Code:
echo disk > /sys/power/state
and it didn't seem to have any effect. Is there something in the kernel that needs to be changed? My current kernel being stock CM.

it would be kernel related, though I don't know if it is the only piece or not. a phone is essentially suspended to disk when it's off. the benefit, as compared to a computer, would be negligible I'd think.

Well after digging through darch's source I had lying around I found that it is supported and the files are there. I'm looking into enabling it and trying it out.
Files I found were in folder kernel/power/:
Kconfig
hibernate.c
Where Kconfig makes specific references to a hibernation shutdown.

[Q] Compilation in the cloud (really?)

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).

Kernel warning

While reading the kernel log I saw this:
Code:
**********************************************************
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for produciton use. **
** **
** If you see this message and you are not debugging **
** the kernel, report this immediately to your vendor! **
** **
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
**********************************************************
this is what the author of trace_printk() says:
Code:
trace_printk() is used to debug fast paths within the kernel. Places
that gets called in any context (interrupt or NMI) or thousands of
times a second. Something you do not want to do with a printk().
In order to make it completely lockless as it needs a temporary buffer
to handle some of the string formatting, a page is created per cpu for
every context (four per cpu; normal, softirq, irq, NMI).
Since trace_printk() should only be used for debugging purposes,
there's no reason to waste memory on these buffers on a production
system. That means, trace_printk() should never be used unless a
developer is debugging their kernel. There's macro magic to allocate
the buffers if trace_printk() is used anywhere in the kernel.
To help enforce that trace_printk() isn't used outside of development,
when it is used, a nasty banner is displayed on bootup (or when a module
is loaded that uses trace_printk() and the kernel core does not).

What does this mean?

Alien333 said:
What does this mean?
Click to expand...
Click to collapse
This function lets kernel developers debug fast path sections (Fast path forwards packets without extra processing in the kernel. Its better for speed). A normal printk doesnt work (well it might, but be extremely expensive) in these fast paths so the developer has to use this to see what is going on during debugging.
To facilitate this debugging, extra memory is used when trace_printk() is being used. This memory is reserved at a kernel layer so you likely lose memory for application use - how much and how often depends on how much of this debugging function they are using. Allocation of this memory is also expensive.
This debug method should be stripped out before packaging the kernel for the device but Xiaomi hasnt done this somewhere in the kernel and its throwing a warning.

Thread moved.

LOL They have packed debug version of kernel into rom which goes out to the masses... WTF Xiaomi? I hope that won't be the case for my device when I get my hands on it in a few days...

zelendel said:
Thread moved.
Click to expand...
Click to collapse
Oooo... You're in the Xiaomi forum now?

TheDriller said:
Oooo... You're in the Xiaomi forum now?
Click to expand...
Click to collapse
Everywhere and nowhere all at once lol

This is on 2 of my note 9's and a note 10, should I be concerned?