I cross compiled my Go source code to Arm to run in Android .The program runs in the terminal in the Android device, but I get an error saying that /etc/resolv.conf is missing. My program heavily relies on the net/http library in making http calls.
How can I handle this error in Android?
As of right now you can't use the built in net/http to connect to hostnames, check this issue.
There are few workarounds you could use.
generate /etc/resolv.conf on your program start if you have root access, ugly but easy and simple.
store resolv.conf somewhere and patch http://golang.org/src/pkg/net/dnsclient_unix.go#L169 to use that custom path.
patch $GOROOT/src/pkg/net/dnsconfig_unix.go to get the nameservers by executing getprop net.dns1 and getprop net.dns2.
implement the full patch at https://gist.github.com/ernesto-jimenez/8042366
Related
I am developing a fully native application in using C++ and pure CMake as the build system - no Android Studio involved at all (proof of concept here)
The code builds, apk is generated and can be installed and run via ADB without issue but I cannot get gdbserver64 to attach to the process for debugging.
More details:
App is built against SDK/NDK API level 30
Attempting to debug on an Android 11 emulator instance without Google Play
I can run adb root just fine
Image already includes gdbserver and gdbserver64, attempting to use those
Developer options and USB debugging enebled in emulator
App has android:debuggable="true" in manifest
But every time I try gdbserver64 :5039 --attach $(pidof my.app.id)
I get /bin/sh: <app_pid>: inaccessible or not found
What am I missing? And no, I cannot just move to Android Studio - this is a cross platform project that needs to be buildable using only CMake.
According to my observation, this may be a bug of prebuilt gdbserver. It treats the parameter after --attach as a program name and tries to start it.
It's not really an answer, but in similar configuration to yours I got same error message and unable to overcome this. For me, switching to lldb helped, see e.g.
I am trying to build a custom rom in AOSP angler-debug (Nexus6p, 8.0).
Full build works fine.Then I change some code in
framework/base/core/java/..
and run
mmma framework/base
to rebuild the framework.
Here is the problem :
When I use adb sync to update framework, it leads to boot failure:
"didn't find class "com.android.providers.settings.SettingsProvider on path: ...."
"No original dex files found for dex location /system/priv-app/SettingsProvider/SettingsProvider.apk"
When I use make snod and fastboot flashall to flash system image, the device can boot correctly and the modified code effects.
Question :
Is there something different between these two commands?
There are some mechanisms in framework to make sure the framework.jar is the original one when device is flashed. It seems that other parts of framework does not have this limitation.
In my experience, if your change codes other than framework/base, adb sync is fine, otherwise flash system image to avoid weird things.
You should feel lucky that building speed is way faster in AOSP 8, when I worked with AOSP 5, build the framework/base is a disaster.
I'm interested in learning about the Android runtime (ART) and I'd like to be able to put a debugger on it so I can step through the code. I have an AOSP build that I've been running on an emulator.
What's the best way to attach and run source? Should I just use gdbserver on the emulator? Are there any IDEs that people use for native debugging?
Looks like you figured this out, but just for completeness, here's a link to some official documentation which basically covers what you said: http://source.android.com/devices/tech/debug/index.html
If you want to debug native code, you're going to need the source, which of course means getting the AOSP. After you've setup the AOSP, do the following:
In your AOSP directory, run "choosecombo". Select "debug" and pick an "eng" build of your choice.
Build the AOSP
Start the emulator (ie: on Linux, "emulator &")
adb shell into the emulator and run "setprop debug.db.uid 32767". This prevents debuggerd from attaching to a process that it thinks has halted and causing problems. See system/core/debuggerd/debuggerd.cpp in the AOSP for more info.
In the same shell that you built the AOSP, run "gdbclient [process name]". This will attach and load the debugging information for the process you are interested in. You can also attach to a pid, but you will end up having to load the symbol information yourself.
Enjoy debugging native Android platform code
I've got a usb camera working on android (via Android On-The-Go), and I'm looking to change the exposure of the camera. I've been able to get this to work by using v4l2-ctl on a linux machine, and I'm hoping to do the same on my Android device.
The install file mentions the following:
Android Cross Compiling and Installing:
----------------
v4l-utils will only build using the complete AOSP source tree, because of the
stlport dependency.
List of v4l-utils that supply an Android.mk makefile:
* utils/v4l2-compliance
* utils/v4l2-ctl
* utils/v4l2-dbg
To cross compile an utility you must first configure the shell with Android's
envsetup.sh to add the mm alias, before running lunch to select your target
device.
cd /path/to/aosp
source build/envsetup.sh
lunch
cd /path/to/v4l-utils
cd <utility>
mm
So I downloaded the android source, ran the first two commands and lunch successfully. I then cd'd into v4l-utils/v4l2-ctl and ran mm. I got the following error:
make: *** No rule to make target `out/target/product/generic/obj/lib/crtbegin_dynamic.o', needed by `out/target/product/generic/obj/EXECUTABLES/v4l2-ctl_intermediates/LINKED/v4l2-ctl'. Stop.
What can I try to fix this?
Note: Normal compilation works: I can make all of v4l2 with ./bootstrap.sh, ./configure, and then make.
I've figured out how to do it! I found that the instructions worked great, except for these two points:
Download and Build the Entire Android Source
Before doing anything, you need to download and make the full Android source. This means setting up your environment, downloading it, and then building it.
Make sure that you're downloading the correct version of the Android source (that is, the version that's running on your phone).
For a faster download, run repo-sync with -c, for the current branch only
I suggest getting a large hourly billed server and running it on there. The network connection will be better, and the machine is probably better than your own. I got an 8 core, 16GB machine on DigitalOcean.
When running lunch, I just chose the first option: aosp_arm-eng
Set the TOP Variable
When doing the mm step, you'll get an error saying Couldn't locate the top of the tree. Try setting TOP. So run export TOP=/location/of/android/source
When I enter this in the Windows CMD...
red -c -t Android hello.red
...Red outputs a file called hello with no filename extension. If I transfer this file to my Android device, it doesn't know what to do with it.
What additional steps must I follow to test my Red code on my Android device?
Which of those steps, if any, must I do differently, depending on whether or not my code will attempt to use the Android bridge?
The Android port is a work in progress done in the android branch. In that branch, using:
red -t Android <script.red>
will use the APK backend for the new packaging layer that will handle the whole process of APK generation for you (provided that you have a JDK1.6+ pre-installed). If all went well, you will get an APK in your working folder.
In case you need to debug the building process, you need to edit the system/formats/APK.r file and set on line 11 the verbose word to yes.
Note: We are working on removing all the external dependencies one by one.
EDIT: The Android Red port has been moved to a private branch and actively worked on. It will be made public once beta stage is reached.
Unless you package up the executable into an .APK, then for security reasons Android throws up some walls in your path to chmod +x it and run.
I followed these directions, just with:
$ cd /data/data/jackpal.androidterm/shared_prefs
$ cat /sdcard/Download/hello.bin > hello
$ chmod 755 ./hello
$ ./hello
Without rooting or otherwise, you wind up with that weirdness like using cat instead of cp, and slipping the file into a strange directory where execution is allowed.
Tested on Nexus 5.
I've not tried yet, but check this: http://www.red-lang.org/2011/12/arm-support-released.html
Also you may know, that there is an experimental Android version here: https://github.com/red/red/tree/android
It appears the question has been answered, but for those who want more, there is an article for getting started with Red for Linux and Android in the March 2014 issue of ODROID Magazine at http://magazine.odroid.com .
There is also going to be a short how-to article in the July 2014 edition (released in the next few days) by Gregory Pecheret that will demonstrate building an .apk from scratch in Red.