while playing around with Android ART and the "native" code file .oat/.elf which is created at the app installation process, I did notice something odd.
For my understanding, if the device is using ART (Android >= 5.0), the app will start with the compiled oat file (/data/dalvik-cache/arm64/).
Thats why I was kinda surprised when checking the used fd's of an app and did not find the file there. Only the normal apk (/data/app//base.apk) is listed there.
Check this output of my "ls -l /proc/PID/fd"
So I thought maybe it's just not listed there. So I did exchange the oat file of that app by myself by compiling another classes.dex with the dex2oat tool.
So even after changing the file, the app starts normally without any strange messages or errors (also in logcat).
What is the explanation for this? What is the detailed process Android does when starting an app under ART?
I hope someone can clear that up for me. Thanks a lot.
Based on #Paschalis comment, I investigated here and the oat file is indeed memory mapped on Android 5.0 devices (emulator):
a6af4000-a6af9000 r--p 00000000 1f:01 7366 /data/dalvik-cache/x86/data#app#my.app.works-1#base.apk#classes.dex
Check via:
cat /proc/<PID>/maps | grep dex
Sadly this isn't true anymore for Android 6.0 devices (Nexus 5 & arm-Emulator).
The odex file is within the /data/app/<APP>/oat/<ARCHITECTURE>/ folder as 'base.odex`
/data/app/app.app.works-1/oat/arm/base.odex
I still haven't found a valid reference for this, it is based on experiments and observations
I am in the process of migrating my scripts from python SL4A to QPython (can't get SL4A to work on android lollipop).
I can't save a file to the disk
So I am using:
with open("foo.txt" ,"a") as f:
f.write(theInfo)
And I get
IOError: [Errno 30] Read-only file system: 'foo.txt'
I know what the error means, I just don't know where to save the file...
Thanks for the help,
marbs
The error is saying that you are in a protected part of a file system.
That means you may want to save the file in an un-protected part.
So, you may want to replace the "foo.txt" part with "/mnt/sdcard/foo.txt" or "/storage/sdcard0/foo.txt" or whatever is the path of internal storage on your phone.
Do you understand what am I saying?
Qpython has disabled writing to files, my recommendation is to find a different script interpreter like the inpython app on android, or the python module in Termux and run it from there.
I'd like to debug android NDK application, more precisely - I want to check what arguments (r4 - r8 r1 - r4 registers) are passed to function from shared library in apk.
What I have tried:
I've run gdbserver :1234 --attach on the device
I've run arm-linux-androideabi-gdb from ndk package by Google on the PC
I've set solib-search-path and written target remote :1234
So far, so good. Now I try to set breakpoint (break <function name>) (function name from
objdump), but I get repond: Cannot access memory at address <...>. info shared says the library is loaded, Does it mean I can't set breakpoint there? Or am I doing something wrong?
The ndk-build skript does much more then you would expect.
One of the things it to copy both the gdbserver, a file called gbd.setup and the generated .so into a hidden folder called .obj/armei/
There you will have to add the libraries you would like to debug because the symbols are referencing them.
The libraries are copied from the device to your PC by some adb shell pull - commands.
I wrote an article about the topic at: http://www.professional-android-development.com/articles/android-ndk-large-c-projects
When placing the libraries into the right folder, you can set your breakpoints.
Still, for some internal reasons, they can fail.
In this case run ndk-gdb --start (the first try will also fail), enforce the application to close and rerun ndk-gdb --start (this time not forcing the application to close).
"Cannot access memory at address <...>" usually means there is a mismatch between the .so file on your PC and the .so file that is on Android. Did you recompile and reinstall?
Btw, what is the reason you're not using "ndk-gdb"? That's a script (part of the NDK) that takes care of all the gory details for you.
I am getting the above error:
error opening trace file: No such file or directory (2)
when I run my android application on the emulator. Can someone tell me what could be the possible reason for this?
I am using android-sdk-20 and below lines are added to AndroidManifest.xml
<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="15" />
I have also added the line:
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
since I thought that there may be some issue with writing to the sd card.
It happens because you have not installed the minSdkVersion or targetSdkVersion in you’re computer. I've tested it right now.
For example, if you have those lines in your Manifest.xml:
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="17" />
And you have installed only the API17 in your computer, it will report you an error. If you want to test it, try installing the other API version (in this case, API 8).
Even so, it's not an important error. It doesn't mean that your app is wrong.
Sorry about my expression. English is not my language.
Bye!
I think this is the problem
A little background
Traceview is a graphical viewer for execution logs that you create by using the Debug class to log tracing information in your code. Traceview can help you debug your application and profile its performance. Enabling it creates a .trace file in the sdcard root folder which can then be extracted by ADB and processed by traceview bat file for processing. It also can get added by the DDMS.
It is a system used internally by the logger. In general unless you are using traceview to extract the trace file this error shouldnt bother you. You should look at error/logs directly related to your application
How do I enable it:
There are two ways to generate trace logs:
Include the Debug class in your code and call its methods such as startMethodTracing() and stopMethodTracing(), to start and stop
logging of trace information to disk. This option is very precise
because you can specify exactly where to start and stop logging trace
data in your code.
Use the method profiling feature of DDMS to generate trace logs. This option is less precise because you do not modify code, but rather
specify when to start and stop logging with DDMS. Although you have
less control on exactly where logging starts and stops, this option is
useful if you don't have access to the application's code, or if you
do not need precise log timing.
But the following restrictions exist for the above
If you are using the Debug class, your application must have
permission to write to external storage (WRITE_EXTERNAL_STORAGE).
If you are using DDMS: Android 2.1 and earlier devices must have an SD
card present and your application must have permission to write to the
SD card. Android 2.2 and later devices do not need an SD card. The
trace log files are streamed directly to your development machine.
So in essence the traceFile access requires two things
1.) Permission to write a trace log file i.e. WRITE_EXTERNAL_STORAGE and READ_EXTERNAL_STORAGE for good measure
2.) An emulator with an SDCard attached with sufficient space. The doc doesnt say if this is only for DDMS but also for debug, so I am assuming this is also true for debugging via the application.
What do I do with this error:
Now the error is essentially a fall out of either not having the sdcard path to create a tracefile or not having permission to access it. This is an old thread, but the dev behind the bounty, check if are meeting the two prerequisites. You can then go search for the .trace file in the sdcard folder in your emulator. If it exists it shouldn't be giving you this problem, if it doesnt try creating it by adding the startMethodTracing to your app.
I'm not sure why it automatically looks for this file when the logger kicks in. I think when an error/log event occurs , the logger internally tries to write to trace file and does not find it, in which case it throws the error.Having scoured through the docs, I don't find too many references to why this is automatically on.
But in general this doesn't affect you directly, you should check direct application logs/errors.
Also as an aside Android 2.2 and later devices do not need an SD card for DDMS trace logging. The trace log files are streamed directly to your development machine.
Additional information on Traceview:
Copying Trace Files to a Host Machine
After your application has run
and the system has created your trace files .trace on
a device or emulator, you must copy those files to your development
computer. You can use adb pull to copy the files. Here's an example
that shows how to copy an example file, calc.trace, from the default
location on the emulator to the /tmp directory on the emulator host
machine:
adb pull /sdcard/calc.trace /tmp Viewing Trace Files in Traceview To
run Traceview and view the trace files, enter traceview
. For example, to run Traceview on the example files
copied in the previous section, use:
traceview /tmp/calc Note: If you are trying to view the trace logs of
an application that is built with ProGuard enabled (release mode
build), some method and member names might be obfuscated. You can use
the Proguard mapping.txt file to figure out the original unobfuscated
names. For more information on this file, see the Proguard
documentation.
I think any other answer regarding positioning of oncreate statements or removing uses-sdk are not related, but this is Android and I could be wrong. Would be useful to redirect this question to an android engineer or post it as a bug
More in the docs
Try removing the uses-sdk part form AndroidManifest.xml file. it worked for me!
Don't use the Android Virtual Device with too low configuration. Let it be medium.
Write all your code below this 2 lines:-
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
It worked for me without re-installing again.
I didn't want to reinstall everything because I have so many SDK versions installed and my development environment is set up just right. Getting it set up again takes way too long.
What worked for me was deleting, then re-creating the Android Virtual Device, being certain to put in a value for SD Card Size (I used 200 MiB).
Additional information:
while the above does fix the problem temporarily, it is recurring. I just tried my application within Android Studio and saw this in the output log which I did not notice before in Eclipse:
"/Applications/Android Studio.app/sdk/tools/emulator" -avd AVD_for_Nexus_S_by_Google -netspeed full -netdelay none
WARNING: Data partition already in use. Changes will not persist!
WARNING: SD Card image already in use: /Users/[user]/.android/avd/AVD_for_Nexus_S_by_Google.avd/sdcard.img
ko:Snapshot storage already in use: /Users/[user]/.android/avd/AVD_for_Nexus_S_by_Google.avd/snapshots.img
I suspect that changes to the log are not saving to the SD Card, so when LogCat tries to access the logs, they aren't there, causing the error message. The act of deleting the AVD and re-creating it removes the files, and the next launch is a fresh launch, allowing LogCat to access the virtual SD Card.
You will not have access to your real sd card in emulator. You will have to follow the steps in this tutorial to direct your emulator to a directory on your development environment acting as your SD card.
Actually, the problem is that either /sys/kernel/debug is not mounted, or that the running kernel has no ftrace tracers compiled in so that /sys/kernel/debug/tracing is unavailable. This is the code throwing the error (platform_frameworks_native/libs/utils/Trace.cpp):
void Tracer::init() {
Mutex::Autolock lock(sMutex);
if (!sIsReady) {
add_sysprop_change_callback(changeCallback, 0);
const char* const traceFileName =
"/sys/kernel/debug/tracing/trace_marker";
sTraceFD = open(traceFileName, O_WRONLY);
if (sTraceFD == -1) {
ALOGE("error opening trace file: %s (%d)", strerror(errno), errno);
sEnabledTags = 0; // no tracing can occur
} else {
loadSystemProperty();
}
android_atomic_release_store(1, &sIsReady);
}
}
The log message could definitely be a bit more informative.
I am writting jni code for a netTV project apk. so I write code line like setgid(AID_AUDIO) in jni to make the current process have right to write data to the audio devices.
The problem is the setgit(AID_AUDIO) return fail because a common apk program can have user permission. I know that common apk cannot access to any device over jni, but my question is: how can I get my apk have system or root permission?