android + scala + preinstalled scala libraries + disabled proguard throws ClassNotFoundException - android

Final purpose of this feat: Use android device for development by fast compiling without needing to use proguard each single time (which causes huge delays)
First try is on Sony Ericsson Xperia Mini Pro
I have installed in it Cyanogenmod which is already rooted and the root checker app has verified it.
This is the app I used to embed Scala library 2.9.1 inside android device:
https://github.com/jbrechtel/Android-Scala-Installer
The lines uses-library android:name="scala_... are now included inside the AndroidManifest
After the above actions I did some minor changes inside "project/Build.scala" like this line: useProguard in Android := false,
I am probably missing something because after recompiling and executing android:start-device I got java.lang.ClassNotFoundException
which is the error you are expecting to get when you have not done the previous steps (rooting device and installing scala libraries inside device)
Any ideas are welcome! Thank you
PS: Intellij is the chosen IDE for the current project so eclipse and the relative plugins is not an option

There is nothing wrong with what I have mentioned above!
BUT there is a command inside Android Scala Installer which requests the "/system" folder to be mounted as writable. Unfortunately this does not work on my gingerbread android phone and this might be the general case.
I simply commented out the operation of the mount /system as writable (and also the command mount /system as read only) and the libraries installed successfully!
Note that I set manually the permissions of /system as writable before installing libraries
In fact I forked the github repository and therefore you can find me implementation over here:
https://github.com/pligor/scala-android-libs
To summarize. Yes the only alterations needed in your scala android source code is to set the settings in Build.scala file for proguard to be false and you include the uses <uses-library android:name="scala_... inside Android Manifest.

Related

AOSP: How to build /platform/frameworks/base or /platform/frameworks/support separately in Android Studio

Is there a way to build AOSP's /platform/frameworks/base package source or support library source separately in Android Studio.
I wanted to read the framework (base and support) code in Android Studio and since I didn't want to be bothered about the rest of the packages in AOSP, I only imported the mirrored repo of these two packages as two separate projects in Android Studio. I want to browse through the code by using "jump to source" shortcut (cmd/ctrl+click) of the IDE. But this handy feature won't simply work properly in Android Studio. When I try to jump to the method definition which belongs to a different java source file (It says - "Cannot find declaration to go to"). This limitation of source editor is due to gradle build failure. The project just won't build and throws the following error.
Error:You need a symlink in prebuilts/sdk/99 that points to
prebuilts/sdk/current.Without it, studio cannot understand current
SDK. ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
Is there a way to fix this. I know I can simply browse the source code on http://androidxref.com/ too, but it's not as convenient and powerful as your IDE.
This is possible (having Android Studio be able to show you the framework code and let you use the usual IDE tools), though compiling won't work.
But the detail in your question seems to indicate you don't actually care about compiling, just about viewing/editing.
The first steps listed here:
http://ronubo.blogspot.com/2016/01/debugging-aosp-platform-code-with.html
might work for you. Basically:
Build your AOSP platform
( . build/envsetup.sh && lunch - && make ...)
Create the Android Studio project for importing to
( mmm development/tools/idegen && development/tools/idegen/idegen.sh )
Import the project
( open android.ipr from Android Studio)
Not without a huge effort.
For very many reasons.Ex:
1.the framework depends on different HALs and libraries from system/bionic/external
2.Compiling the framework uses specific tools from linux(flex,bison,libgl etc..)
3.Framework is built using the Android.mk system and needs a lot of flags and compilation macros from build/
I also can't imagine a motivation to do what you are trying to do. If it's going to run on any device, bare in mind device manufacturers modify the framework heavily, even the small ones. Actually the chipset manufacturers modify it and give it to manufacturers that modify it even more.
Error:You need a symlink in prebuilts/sdk/99 that points to prebuilts/sdk/current.Without it, studio cannot understand current SDK. ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
This notice already tell you should run the command:
ln -s ../../prebuilts/sdk/current ../../prebuilts/sdk/99
To tell build system use 'current version sdk' in prebuilts/sdk/current directory replace the temp sdk version 99.
could you try it?

Issue including executable with Android application when using Jelly Bean

I have ported a few useful free/open source tools to Android. One is Octave and the other is gnuplot. They work together in unison to provide Matlab like capability for free (as in speech) and free (as in beer). I have packed them inside apps in an interesting way. Specifically,
1) I include the executable and shared libraries inside the libs/armeabi directory. Have to give them funny name because of android naming conventions.
2) I create directories bin/ and mylib/. I give them full permissions.
3) I create links from bin/ to the executable in the unpacked lib/ directory. I give them the correct names and full permissions.
4) I create links from mylib/ to the shared libaries in the unpacked lib/ directory. I give them the correct names and full permissions.
5) I then use ld-linux.so.3 which is one of the libraries now in the mylib/ directory and the--library-path option to point at the mylib/ directory to launch the executable from the Android Terminal Emulator.
Octave works perfectly in all version of Android doing this, but gnuplot gives this error when I attempt to launch it when running Jelly Bean only:
error while loading shared libraries: gnuplot: failed to map segment
from shared object: Operation not permitted.
So, why would I have this error for one of these two executables made the same way? Why only in Jelly Bean? Also, on JB, if I make myself the super user, it all works again.
Any thoughts on how to debug? I have confirmed that all files are there and have the permissions that I intended they have.
Please help. You would be helping a free, open source, educational and useful app if you do.
The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.

What are possible causes of "failed to map segment from shared object: operation not permitted", and how to debug?

I have two executables, both cross compiled to run in Android. I have put both on the device in the same directory. I have put all the shared libraries that they are dependent on in the same directory, including ld-linux.so.3. I run the executables by using:
ld-linux.so.3 --library-path /path/to/libraries executable_name
both work on older versions of Android when running as any user. The both work on the latest version of Android if running as root. Only one works on the latest version of android when running as any user. Instead it gives:
failed to map segment from shared object: executable_name operation not permitted
How can I find out what is different with the executable that won't run?
I read a lot online and most people that get this error, either:
A) don't have execute permissions for one of the libraries they are dependent on or the executable itself.
or
B) are trying to run from a directory that is mounted as NOEXEC.
both of these don't appear to be the case. It can find all libraries and I can load any library by itself and see what other things it is dependent on being resolved. Also, I can run basic scripts from the directories of interest.
The newer version of Android, Jelly Bean, is a different linux kernel version and I wonder if that is related.
What give? How do I debug?
Permission issue. Need to remount /tmp. The following command works for me (Centos 7):
sudo mount /tmp -o remount,exec
I had this error in a different context. For some reason it causes an error when trying to use the /tmp folder.
To solve this I simply:
mkdir tmp
export TMPDIR=`pwd`/tmp
The TMPDIR is a constant that tells where the temporary folder of the system is.
This solutions resolves by creating a directory where we are allowed to and settings this directory into the system. Therefore we can now write to the new system default temporary folder.
The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.
SELinux is enabled by default on Android 4.3, however it is supposed to be "permissive" [0]. Maybe your phone vendor added more restrictive rules.
[0] https://source.android.com/devices/tech/security/se-linux.html

Package Android apk with additional executables

As a follow up to an earlier question (Android ioctl - root permissions and usage), is it possible to create a separate native executable and package it in an APK?
The app needs root access and isn't going into the Android marketplace, but I'd like to be able to install it without using a script that pushes an extra executable onto the device.
There is an easy way to package an executable into an APK, and let the system installer take care of unpacking this executable, see How to package native commandline application in apk?.
The trick (tested up to Jelly Bean 4.3) is to name the file "libmyexecutable.so" and put it into libs/armeabi of your Android project (I assume an ADT or ant build). The Package Manager will unpack the file to /data/data/your.package.full.name/lib (it's a symbolic link, for backwards compatibility reasons, so maybe in some future version of Android this will not work anymore) on the device, with executable permissions.
Note that the file has all read-and-execute permissions, so you can use Runtime.getRuntime().exec() or system() from other apps, too.
Update:
These days, you should use libs/armeabi-v7a for 32 -bit ARM executables, and you probably need to prepare 64-bit ARM version of the same executables, too.
You can put it into assets and copy it to the app's private directory on first run. After you set the executable bit, you should be able to run it.

Generate core dump in android

I'm developping a android's aplication using some shared
libraries written by me and compiled with ndk-r5b. The application works,
y and the calls to the libraries works too, but I detected some errors,
segmentations faults, and I need to debug it, but, I don't know how debug
native code from android and I don't know if I can generate core dumps,
as in linux, for debug my libraries.
Any idea?
The ndk comes with ndk-gdb, which supposedly allows you to debug native applications. Also, if you download the whole andriod open source project, they also have some version of gdb used for debugging. Look in the docs/ folder of the ndk to learn about using it. This tutorial might also prove helpful: http://vilimpoc.org/blog/2010/09/23/hello-gdbserver-a-debuggable-jni-example-for-android/
However, as shown in a recent question I asked: Running ndk-gdb with package not found error on motorola phone I still can't get it to work.
Edit: You said in the comments you were using a Samsung Device: Samsung decide to wreck havoc on some of the crucial internals required for native debugging, but it's easily fixable if you have root access to the device. If you use the --verbose flag, you'll probably find that the error is different than that, a package unknown error. That's because it's looking in /data/system/packages.list, but samsung renamed that file to /dbdata/system/packages.list. So if you make a symlink to that file in /data/system/packages.list, (requires root access) it should work. Or at least so claims the ndk mailing list: http://osdir.com/ml/android-ndk/2011-03/msg00036.html

Categories

Resources