CPM Plugins don't have permission to write external storage?

by RaviY » Wed, 02 Jun 2010 08:32:02 GMT


Sponsored Links
 I believe it is by design to not provide right permissions on the
sdcard to the mediaserver. If needed, you need to figure out a way to
pass an open file handle to your CPM component, and then use that to
do the writing.

-Ravi




-- 



Other Threads

1. SQLiteOpenHelper.getWritableDatabase ambiguous documentation



Then you already have a database.


Delete the existing database (e.g., using DDMS's File Manager). Then
call getWritableDatabase().

-- 
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android Training...At Your Office: http://commonsware.com/training

-- 

2. Memory mangement - GC infinite loop

Hello,

I ran into what seems to be a memory management issue in my app.

After running for a while, dalvik gc is triggered, but never finishes. I get an endless stream of these messages in logcat: D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 49ms D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 49ms D/dalvikvm(24822): GC freed 22018 objects / 528920 bytes in 50ms The application's normal execution obvoiusly stops, and never resumes. This is the first issue - GC is quite normal, but it never completing is not. For some reason, the Java VM tries to free the same objects over and over again, but never actually frees them. The second issue is that I used hprof and Java MAT to analyze what's taking up memory space. The report listed three problems: - 7 742 instances of *"java.lang.String"*, loaded by *"<system class loader>"* occupy *473 856 (26,56%)* bytes This is normal, created by my code. I certainly have work to do, making my code more optimized. My code doesn't hold on to these strings, so assuming issue #1 can be avoided, they should GC quite nicely. The other two entries are: 57 instances of *"org.bouncycastle.jce.provider.X509CertificateObject"*, loaded by *"<system class loader>"* occupy *268 096 (15,03%)* bytes. These instances are referenced from one instance of *"java.util.HashMap$HashMapEntry[]"*, loaded by *"<system class loader>" * 2 985 instances of *"java.lang.Class"*, loaded by *"<system class loader>"* occupy *659 560 (36,97%)* bytes. Biggest instances: * class com.ibm.icu4jni.util.Resources$DefaultTimeZones @ 0x40178af0 - 145 952 (8,18%) bytes. * class android.text.Html$HtmlParser @ 0x4006fd18 - 126 592 (7,10%) bytes. * class org.apache.harmony.security.fortress.Services @ 0x400731b0 - 51 456 (2,88%) bytes. * class android.content.res.Resources @ 0x4004e848 - 34 416 (1,93%) bytes. * class android.text.AutoText @ 0x400f6260 - 28 776 (1,61%) bytes. My application does not use time zones (just whatever the default one is implicit), HTML parsing, or X509 certificates. Why are they combined taking almost a megabyte of memory? How can I avoid it? My code certainly need to be more memory-optimized, but uses only about half the amount of memory already allocated inside my app by things I do not use. I would be grateful for any suggestions. -- Kostya Vasilev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com --

3. Emulator keeps slowing down after a couple of deployments/Run as Android Application in Eclipse

4. ASK: HTC Hero official Android 2.1 OTA update notification

5. TCP IP connection via Mobile Network

6. Android paid apps in Ireland

7. send MMS with Audio part via Intent