Ok, I have fedora 11 installed on most of my computers, since i love this distro to death. My big thing was trying to get adb to work. This is my guide to get it to work, for now.
First things first. Navigate to /etc/udev/rules.d as root. Create a rules file called 50-android.rules (touch 50-android.rules). NOTE: You are better off looking at the contents and picking a rules number set other than what is listed. Sometimes udev is picky. For the newbies, so if any rules start with '50', then change the number by one or two, like 51 or 52. Paste this into the file:
Code:
SUBSYSTEM=="usb",ATTRS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666"
Make sure you use ATTRS, not ATTR or SYSFS, since this is a newer updated udev system.
After that, run udevadm control --reload-rules to reload your rules files. Now just run ./adb devices as root to make sure it recognized your HTC dream. I am working on this fix right now so you don't need to be root, keep patient. Now you can adb shell into your device either as root OR normal user, just as long as you start the server as root. This is a permissions problem, and hopefully I can fix this and/or find a fix soon.
I wrote this because i searched high and low through google, and only found a few good parts as far as a fix. Hopefully this helps a few people out there.
Just wondering if this has helped anyone. If not, delete this thread or do whatever with it....
I have adb on my eeepc 900 with f11 I believe this method works too as well. although it says it has been tested with ubuntu, it works pretty well with f11.
http://www.talkandroid.com/android-sdk-install-guide/
Installing The Android SDK
First you will need to download the Android SDK pack .zip archive, once downloaded find a suitable installation location on your machine and extract the zipped files.
Please note: This installation location will be referred to as $SDK_ROOT from now on through this tutorial
Alternatively you can add /tools to your root path which will prevent the need to specify the full path to the tools directory along with enabling you to run Android Debug Bridge (adb) along with other command line tools.
To add /tools:
Linux
1. Edit the ~/.bash_profile or ~/.bashrc files looking for a line that sets the PATH variable.
2. Add the full path location to your $SDK_ROOT/tools location for the PATH variable.
3. If no PATH line exists you can add the line by typing the following:
4. export PATH=${PATH}:<path to your $SDK_ROOT/tools>
Click to expand...
Click to collapse
It helped me, since the creation of the file my OpenSuSE 11.0 recognizes the phone perfectly
Thanks a lot for your hint.
thanks it helped me. ill be looking forward to getting it to work without root
just use sudo instead
Just a heads up for user's using Ubuntu 9.10, this isn't needed. I connected my G1 to it and ran ADB with no adjustments to udev or anything else.
Pretty much it works out of the box.
Here is my version
download the .tgz file from googlecode
http://developer.android.com/sdk/index.html
sudo tar -xzvf android-sdk_r3-linux.tgz
Click to expand...
Click to collapse
Code:
sudo gedit ~/.bash_profile
heres my bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH=$PATH:/android-sdk-linux/tools
Click to expand...
Click to collapse
logout
login
connect android g1 device via usb to pc
open a terminal
Code:
adb devices
if you cant get a device try it with superuser.
Don't you think that this is all just a little bit excessive?
To make it work in F11, just do this;
Download SDK, extract.
To use, type:
/path/to/sdk/tools/adb
Another option is to edit the /etc/profile and add
PATH=$PATH:/<Path to android-sdk>/tools
This option will allow any user to use the adb tools when logged in or if you
su -
into another user
I wrote a short guide as well for Windows and Ubuntu. Might help others.
Unfortunately, as anyone with a passing acquaintence with ADB knows, the scrolling issue can be a killer. I swear the other day I pressed "up" twice and it composed "rm /sdcard/rootfs.img /sdcard/system.ext2" and executed it. We run Android on our SD's btw.. Was not cool. Instead, I use ADB via telnet and it works beautifully. Here's how:
Code:
adb shell telnetd &
adb forward tcp:9999 tcp:23
Now type this: "telnet localhost 9999"
Enter "root" and hit enter
Finally update PATH: "export PATH=/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin"
Okay, so 4 lines to enter and you have a "regular, sane" shell connection to the phone and you can actually scroll through history and text without it jumbling the text and executing random code. Enjoy.
lbcoder said:
Don't you think that this is all just a little bit excessive?
To make it work in F11, just do this;
Download SDK, extract.
To use, type:
/path/to/sdk/tools/adb
Click to expand...
Click to collapse
that works too as well but i would rather open up a terminal and type
sudo adb devices
sensimila said:
that works too as well but i would rather open up a terminal and type
sudo adb devices
Click to expand...
Click to collapse
WHY would you want to make it *MORE COMPLICATED*??
There is NO NEED for root.
/path/to/adb ...
THATS ALL.
This is kind of funny... i wrote this because i had trouble with it, so i am just sharing my fix...
In case this is interesting to someone:
The fix mentioned in the first post has to be applied to open SuSE x86 and x64 edition to make the G1 work. The external device works without it, but not the adb device.
Thanks again!
Just wanted to come and post that this does work with OpenSUSE 11.2 x86. Did this hoping to get adb to work with my LG Ally and it does. Thanks!
(Still) works for me on 64bit SUSE 11.4.
Before adding this file, I could not access my device with adb, received permissions errors.
Added this file, and I can shell into my device.
Permissions on adb itself was not the problem, it was access to the device when udev found it.
[edit]Actually used the lines from http://developer.android.com/guide/developing/device.html[/edit]
Hi!
I haven't really found any kind of guides on how to build a complete AOSP android build from source (kernel and software) for Allwinner A10 tablets like the Ainol Novo 7 Advanced or the Teclast P76Ti.
I have a Teclast P76TI (rev4), and the following guide is only tested on such a device. As it's mostly based on the source drop of the Ainol Novo 7 Advanced, it should also work on that too.
Part 1
Part 1: Preparations
A: Preconditions
For building and creating a LiveSuite flashable package you will need the following:
For building the kernel and android you will need a 64 bit Linux machine. Ubuntu 10.04 64 bit is preferred for Gingerbread builds
For creating the LiveSuite flashable images, and actually flashing you will need a Windows machine. Windows 7 x64 works fine, as should Windows XP 32 bit too.
You will also need a working LiveSuite image file, for your tablet. Make sure that you can flash it to your device without problems!
Virtual machines are fine, if you have enough memory available. To build Android in a VM, you should give it at least 2GB of RAM. Alternatively if you're using Linux, you can create a Windows VM for the image creation or flashing part.
For the rest of the tutorial I will assume you are using a Linux Virtual Machine on a Windows box.
For building the kernel and AOSP you will need at least 35GB of free space in your linux machine (the more the better). To create the images you will need an additional 2GB of space on your Windows machine.
B: Getting the kernel and AOSP sources
First initialize your Linux machine according to this page: http://source.android.com/source/initializing.html
Here are the most important commands:
Code:
$ sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
$ sudo apt-get update
$ sudo apt-get install sun-java6-jdk
$ sudo apt-get install git-core gnupg flex bison gperf build-essential \
zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs \
x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev \
libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown \
libxml2-utils xsltproc
$ mkdir ~/bin
$ PATH=~/bin:$PATH
$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
// Additonal commands for Ubuntu 10.10:
$ sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so
// Additonal commands for Ubuntu 11.10:
$ sudo apt-get install libx11-dev:i386
Now create a directory on your linux machine. The path should contain no spaces in it. Inside this directory first pull the kernel source from the allwinner github page:
Code:
$ git clone https://github.com/allwinner/linux-2.6.36 lichee
Make sure that the kernel resides in the lichee directory
Now download AOSP Android. We will use Gingerbread version 2.3.7:
Code:
$ mkdir android
$ cd android
$ repo init -u https://android.googlesource.com/platform/manifest -b android-2.3.7_r1
$ repo sync
Allwinner uses a special init, which has a few additional commands that you have to download too:
Code:
$ cd system/core
$ git pull git://github.com/sztupy/allwinner_android_system_core.git
$ cd ../..
You will also need the device descriptors for the tablets:
Code:
$ cd device
$ git clone git://github.com/sztupy/android_device_softwinner.git softwinner
$ cd ..
C: ARM compiler
You might simply use a compiler that is supplied for AOSP, they are inside the android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/ directory. Alternatively you can also download the ARM compiler of CodeSourcery. Get the arm-2009q3 / arm-none-linux-gnueabi version, and unpack it inside a directory.
If ready, go on to next step: building the kernel
Part 2: Building the kernel
Change to the directory of the kernel. Now edit the file scripts/build_sun4i_crane.sh
Change the line "export CROSS_COMPILE=" to point to the ARM compiler. For example if you extracted the CodeSourcery files to /opt then use:
Code:
export CROSS_COMPILE=/opt/arm-2009q3/bin/arm-none-linux-gnueabi-
The default .config file is more or less the same that is supplied with your tablet. On the Teclast P76TI you can actually extract the .config file used from /proc using "adb pull /proc/config.gz" Not sure about other vendors.
Now you have to compile. Issue the command:
Code:
./build.sh -p sun4i_crane
This will build the kernel and modules inside the the "output" directory.
Next step is to compile Android
Part3
Part 3: Building Android
Go to the android directory. Now setup android using:
Code:
$ source build/envsetup.sh
$ lunch
You will get simething like this:
Code:
You're building on Linux
Lunch menu... pick a combo:
1. generic-eng
2. simulator
3. full_passion-userdebug
4. full_crespo4g-userdebug
5. full_crespo-userdebug
6. crane_Ainol_Novo7A-eng
7. crane_Teclast_P76TI_REV4-eng
Which would you like? [generic-eng]
Here select your device (option 6 or 7 depending on your tablet)
After you have selected it issue a make command:
Code:
$ make
This will take a while. If you're using ubuntu 11.10 make might fail, but you can fix it using these fixes: http://groups.google.com/group/android-building/browse_thread/thread/3484e7797909d014
After the building is complete you have to create the image files. Run the following command:
Code:
$ ./device/softwinner/crane-tcp76ti_r4/mkfs.sh
(substitute tcp76ti_r4 with ainovo7a if you're using the other tablet)
The image files will be ready in the directory "out/target/product/crane-tcp76ti_r4/images/" or "out/target/product/crane-ainovo7a/images/"
Copy the three files from here (root.img, recovery.img, system.img), and the "bImage" file from the "output" directory of the kernel to your Windows machine.
The next step is creating the flashable image, and flashing your build
Part 4: Flashing
A: Initialize kitchen
First download my A10 flash kitchen from this site: http://android.sztupy.hu/dl/a10/a10_flash_kitchen_v1.zip
This is based on the ainol novo 7 soruce drop, but only contains the nescessary files, and has a few batch scripts to automate the process.
There is also a v2, wich also supports ICS firmwares: http://android.sztupy.hu/dl/a10/a10_flash_kitchen_v2.zip
First unzip the files to a directory. You will see a few directories and to commands here: extract_image.bat and create_image.bat
First we have to extract an official image for your tablet. Simply comply the image file to this directory, and rename it to "original.img". If done, run extract_image.bat. This command should extract your image to the _extract directory.
Next you need to extract the bootfs inside the _bootfs directory. You have multiple options on how to do this:
1. Get the bootfs from your device on-line using adb:
Code:
> cd _bootfs
> adb shell
$ cd /
$ mount -o remount,rw -t ext4 /dev/root /
$ mkdir bootfs
$ mount -t vfat /dev/block/nanda /bootfs
(Control-C: exit adb shell)
> adb pull /bootfs
2. Get the bootfs from the extracted image file using Linux:
A. Copy the RFSFAT16_BOOTFS_000000000.fex file to linux
B.
Code:
$ mkdir bootfs
$ sudo mount -o loop RFSFAT16_BOOTFS_000000000.fex bootfs
$ cp -a bootfs b2
$ sudo umount bootfs
C. Copy the contents of the b2 directory to Windows, inside the _bootfs directory of the kitchen
B: Create image
If you have initialized the kitchen, you have to copy the four files from linux (system.img, root.img, recovery.img and bImage) inside the _input directory. You will also need to rename the .img files to .fex (so they should be system.fex, root.fex, recovery.fex).
If you are done with this, then run create_image.bat. It will create an output.img file, that can be flashed to the device using LiveSuite.
Additional information for developers:
1. Difference between AOSP 2.3.4 and Novo7 android 2.3.4
Download the diff file from here: http://android.sztupy.hu/dl/a10/diff_ainovo_aosp.gz
Filelist of differences: http://android.sztupy.hu/dl/a10/diff_ainovo_aosp_filelist.txt
sztupy, did you figure out why eDragonEx and FSBuild have an apparently unused Lua library next to each? I was interested by it, as it might be possible that some parts of the apps are actually written in Lua (would it be possible? Lua in a native DLL?), what would help reversing it.
fonix232 said:
sztupy, did you figure out why eDragonEx and FSBuild have an apparently unused Lua library next to each? I was interested by it, as it might be possible that some parts of the apps are actually written in Lua (would it be possible? Lua in a native DLL?), what would help reversing it.
Click to expand...
Click to collapse
Yeah, saw that. Also their build script used "convert" on the image.cfg, but that file wasn't in lua anyway (except for the image parts part which seems to be a lua hash).
There are also a lot of compiled files that are compiled inside the image file and which are neither the bootfs nor android or the kernel. I don't yet know what they are for, but I think they are used by LiveSuite during the flashing.
sztupy said:
Yeah, saw that. Also their build script used "convert" on the image.cfg, but that file wasn't in lua anyway (except for the image parts part which seems to be a lua hash).
There are also a lot of compiled files that are compiled inside the image file and which are neither the bootfs nor android or the kernel. I don't yet know what they are for, but I think they are used by LiveSuite during the flashing.
Click to expand...
Click to collapse
I know most of the files from the flashing, they are the following:
- SYS_CONFIG is used as a command bunch for LiveSuite. It tells the app how to flash, what to flash, where, and it configures the device too (screen size, ram info, cpu info, etc)
- Boot0 and Boot1 bins are NAND bootloaders
- FED FES and FET tools are NAND flashing utilities, checksums, hardware scanner, and other tools used during flashing.
- '12345678' files are bootloaders, config files, and tools for SDMMC flashing, if there's a device with SDMMC internal instead of NAND, these are used
- Split seems to be some kind of ID string, I had no luck retrieving it's usage and meaning.
So you say, that the actual Lua parts are the image encryption parts of eDragonEx? Interesting, maybe I've missed that spot with my tool...
Might I ask if you have tried disassembling (and decompiling) unimg.exe? I had several problems with it, but that would greatly help understanding how the images are created. I've got a C# framework, with image config parser, etcetera etcetera, to be able to read and create images in a much more advanced environment (filtering user errors, having tools for everything (bootfs modding, script.bin reversal, etcetera), and creating a working image as a final result), and it only needs the image file format (and some of my work, to create a parser).
The problems with unimg were all about positive sp values, and as I'm not a big assembly programmer, I couldn't make out anything from that. Maybe you understand it a bit more
Illetve beszélhetünk egy kicsit magyarul is. Tabletrepublic-on írtam hogy vegyél fel MSNre és részletezem a különböző Crane SDK elemek funkcióit, működését, egyebeket, amit eddig sikerült kiderítenem az egészről.
Sajnos elég zavaros, mivel vagy négyféle csomagoló rendszer készíti a fileokat, és ezek közül csak egy működött rendesen (crane_pack.exe). Jó lenne megérteni ezt a file formátumot, hogy egy kicsit normálisabb módon hozhassam létre, különféle vacakolások nélkül.
fonix232 said:
I know most of the files from the flashing, they are the following:
- SYS_CONFIG is used as a command bunch for LiveSuite. It tells the app how to flash, what to flash, where, and it configures the device too (screen size, ram info, cpu info, etc)
- Boot0 and Boot1 bins are NAND bootloaders
- FED FES and FET tools are NAND flashing utilities, checksums, hardware scanner, and other tools used during flashing.
- '12345678' files are bootloaders, config files, and tools for SDMMC flashing, if there's a device with SDMMC internal instead of NAND, these are used
- Split seems to be some kind of ID string, I had no luck retrieving it's usage and meaning.
Click to expand...
Click to collapse
Thanks for these. Seems I was mostly right
So you say, that the actual Lua parts are the image encryption parts of eDragonEx? Interesting, maybe I've missed that spot with my tool...
Click to expand...
Click to collapse
I think lua is not really used anymore. It probably had more relevance back in the past.
Might I ask if you have tried disassembling (and decompiling) unimg.exe? I had several problems with it, but that would greatly help understanding how the images are created. I've got a C# framework, with image config parser, etcetera etcetera, to be able to read and create images in a much more advanced environment (filtering user errors, having tools for everything (bootfs modding, script.bin reversal, etcetera), and creating a working image as a final result), and it only needs the image file format (and some of my work, to create a parser).
The problems with unimg were all about positive sp values, and as I'm not a big assembly programmer, I couldn't make out anything from that. Maybe you understand it a bit more
Click to expand...
Click to collapse
No, haven't tried disassembling it yet. I was very glad that it worked, and that I could create a whole working build just from the sources. I know there are a lot of quirks, like if the extension of the file is not .fex, then it will encrypt(?) it, etc. I might try it, but currently I'm more interested in getting a working AOSP ICS on my tablet. Besides for disassembly I need to be in a special mood, which I'm not really in now
Illetve beszélhetünk egy kicsit magyarul is. Tabletrepublic-on írtam hogy vegyél fel MSNre és részletezem a különböző Crane SDK elemek funkcióit, működését, egyebeket, amit eddig sikerült kiderítenem az egészről.
Sajnos elég zavaros, mivel vagy négyféle csomagoló rendszer készíti a fileokat, és ezek közül csak egy működött rendesen (crane_pack.exe). Jó lenne megérteni ezt a file formátumot, hogy egy kicsit normálisabb módon hozhassam létre, különféle vacakolások nélkül.
Click to expand...
Click to collapse
Már egy jó ideje nem használok MSN-t. Skype/GTalk/email viszont van. Ha nem használsz olyanokat, akkor azért majd felrakom.
Made a diff between AOSP android 2.3.4 and the Novo 7 2.3.4 source drop. The list can be found at post 6: http://forum.xda-developers.com/showpost.php?p=22397984&postcount=6
Nice tutorial! Do you mind if I fork your Github repo and add the device tree for the Bmorn V11 to the lunch list?
sztupy said:
Made a diff between AOSP android 2.3.4 and the Novo 7 2.3.4 source drop. The list can be found at post 6: http://forum.xda-developers.com/showpost.php?p=22397984&postcount=6
Click to expand...
Click to collapse
Most of the things changed aren't even needed for the device - ril can be replaced with a local one (and suggested by Google to do so), just like recovery changes, in ICS we already have USB BT support enabler, so BT changes can be dropped, just like framework changes (they are for the softbuttons on the notification bar), camera and mediaplayer changes should be local too (in the device tree), so 99% of changes can be dropped.
Additions are different, some can be totally erased, and some are needed. From your github, I see that you've already began making a cleaned up, generic A10 tree, but I miss a few things - libsensor for one, stagefright, camera, and audio. The AOSP stock ALSA should work, if the proper audio config is placed in a ROM, but I have bad feelings about the missing libsensors source, and camera. Stagefright has a chance too to work, but camera definitely won't, and the used sensors aren't the common ones to be included.
Használok GTalk-ot is, ott is ugyanez a nicknevem, gmail utótaggal, szóval a szokásos
FezzFest said:
Nice tutorial! Do you mind if I fork your Github repo and add the device tree for the Bmorn V11 to the lunch list?
Click to expand...
Click to collapse
That's what github is for
fonix232 said:
Most of the things changed aren't even needed for the device - ril can be replaced with a local one (and suggested by Google to do so), just like recovery changes, in ICS we already have USB BT support enabler, so BT changes can be dropped, just like framework changes (they are for the softbuttons on the notification bar), camera and mediaplayer changes should be local too (in the device tree), so 99% of changes can be dropped.
Additions are different, some can be totally erased, and some are needed. From your github, I see that you've already began making a cleaned up, generic A10 tree, but I miss a few things - libsensor for one, stagefright, camera, and audio. The AOSP stock ALSA should work, if the proper audio config is placed in a ROM, but I have bad feelings about the missing libsensors source, and camera. Stagefright has a chance too to work, but camera definitely won't, and the used sensors aren't the common ones to be included.
Használok GTalk-ot is, ott is ugyanez a nicknevem, gmail utótaggal, szóval a szokásos
Click to expand...
Click to collapse
libsensor and stagefright are still there, as I could manage them to get compiled. Not that they work though. For the libcamera it depends on CedarX, which I couldn't manage to compile, that's why I removed it (for now). Besides CedarX unfortunately not "open-source", so in theory we couldn't use it either (well... not that I actually care about licence violations).
I'm still compiling ICS. Will put back libcamera and try to get the other hardware libs to work after I managed to get ICS to boot.
sztupy said:
libsensor and stagefright are still there, as I could manage them to get compiled. Not that they work though. For the libcamera it depends on CedarX, which I couldn't manage to compile, that's why I removed it (for now). Besides CedarX unfortunately not "open-source", so in theory we couldn't use it either (well... not that I actually care about licence violations).
I'm still compiling ICS. Will put back libcamera and try to get the other hardware libs to work after I managed to get ICS to boot.
Click to expand...
Click to collapse
Please be noted that ICS requires new stagefright, camera HAL, new GPU drivers, and so on.
ICS also should have some differences in the build tree, make a new branch for sure (as an example, it requires a device.mk and device_base.mk, both being the base containers without target definition, full_[devicename].mk for the actual full target, and cm.mk for CyanogenMod, what I'd suggest you to build).
I couldn't find any of the sources, but must have overlooked something. Will check it further.
hi, I'm the author of unimg(esxgx).
and your unimg is not up-to-date(the version still have bugs to lead to fail the packing process.
Here is the latest version (fix bugs but no virus alarm[compared with the former version]), and you can use it in the same way.
please update your file.
PS. yes, the unimg can unpack and pack all allwinner's firewares without diffculty, good luck.
sorry for my english.
fonix232 said:
Might I ask if you have tried disassembling (and decompiling) unimg.exe? I had several problems with it, but that would greatly help understanding how the images are created. I've got a C# framework, with image config parser, etcetera etcetera, to be able to read and create images in a much more advanced environment (filtering user errors, having tools for everything (bootfs modding, script.bin reversal, etcetera), and creating a working image as a final result), and it only needs the image file format (and some of my work, to create a parser).
The problems with unimg were all about positive sp values, and as I'm not a big assembly programmer, I couldn't make out anything from that. Maybe you understand it a bit more
Click to expand...
Click to collapse
I think you should use unimg.exe.
unimg is the only tool to unpack it correctly.
you know, allwinner didn't want me to release the tool in public last year(the tool is for sc9800[the former chip]). for some commercial reason, the offical toolchain of a10 only contains pack_tool.
so I released the tool with other tools(rootcr, rootpk,etc..) in a small group.
but some person posted it on the internet. so....
I developed the analysis tools in the form of many files(unimg, rootcr, rootpk, unimg2), because I want to keep each of the packing stages simple.
you can use a "bat" file / a GUI shell to communicate with each other, and that is what I expected.
I can't smoothly speak english, so I modified several times.
Thank you very much!
If I may ask, would it be possible to release the source code too?
fonix232 said:
Thank you very much!
If I may ask, would it be possible to release the source code too?
Click to expand...
Click to collapse
I cannot released yet, but I will release it in a proper time on github (I have been touching with allwinner company, so I have to consider many factors).
Hi all,
I don't think we have a Rasp-pi forum on here, so Im posting here. Also, such a forum would probably be for those wishing to run Android on their Raspberry Pi. This thread is for those who are using their Pi for android development
I had a hard time finding android-tools packages for the debian "wheezy" build that comes with the Pi, so I back-ported them and built some binaries, attached below.
This is useful for people who plan to use their Raspberry Pi for some sort of android tinker. ing, but don't plan on doing any actual development (and hence will not need the full SDK). These should save some time. My first contribution to XDA, so enjoy!
Mirror available via PM.
MD5 Hash: AB22B0251A8A1B1209EF1342167C1E09
SHA1: FA8113237AF1C8F64FA74BF800A866A7B681CD2A
INSTALLATION
Download, cd to the directory you downloaded,
Code:
tar zxvf android-tools-pi.tar.gz && cd android-tools-pi
There should be three binaries in the directory.
Install with
Code:
dpkg -i android-tools-*.deb
Best,
amk
EDIT: Whoops.. if a mod could move this to the Pi forums I'd appreciate it. Thanks in advance.
I downloaded the files and unfortunately the md5 doesn't agree.
C9D4DB0E4D350022888D1AF8921EF7E9 for android-tools-pi.tar.gz
4C27CA4B23E4C3E0AFF814B592871DF6 for android-tools-pi.tar
The first file, android-tools-adb, doesn't seem to be a valid debian archive format.
I tried downloading more than once. Could you check your upload went ok?
A link or list of the utilities would be helpful, save a search. Also how you did it. I see fastboot and fsutils.
Thanks
Hm, that's interesting. This is from so long ago it almost feels like a foreign language now haha.
I think I just compiled the source code to run on wheezy but doing so required a few tricks (I think it needed to use the newer c++ compiler not included in wheezy)
Also the reason I did this was so I could cross-compile android ROMs on my pi, which I soon discovered was the stupidest idea I've ever had in my life. It's great for doing adb/recovery/ssh stuff though
I can look into it, but it'll take me some time
I know the feeling, forgetting earlier work, I actually write notes now, but then one has to clip them together to be able to find them again.
The latest Debian image seems to be quite good, usually though one has to download the more specialist utilities. It's just that these packages don't exist online, but I expect the c++ compiler would be available. If it isn't easy to reproduce the steps I'll start looking for the source and compiler. It seems that no one else tested the packages, but the general process of compiling a package for the Raspberry, and getting it into the right format to load, might be of interest to others.
The CWM (Clock Work Mode) recovery utility 6.0.5.1 for the P3100 phone seems easy enough to install using odin.
I imagine you were compiling Replicant, probably not enough memory on a Raspberry so it might need a big cache file somewhere if that's even possible.
The ssh function to phone seems interesting. I use it quite a lot between Raspberry computers, especially if something freezes.
Thanks
FOR OLD VERSION:
Since your archive files are not working - i got "****** doesn't seem to be a valid debian archive format"
Go to http://ftp.acc.umu.se/mirror/cdimage/snapshot/Debian/pool/main/a/android-tools/
Download this files to PI:
android-tools-adb_4.2.2+git20130529-3_armhf.deb
android-tools-fastboot_4.2.2+git20130529-3_armhf.deb
android-tools-fsutils_4.2.2+git20130529-3_armhf.deb
In terminal go to file location and then :
Code:
dpkg -i android-tools-*.deb
Or easy
NOW:
Code:
sudo apt-get install android-tools-adb android-tools-fastboot
Done ... we got ADB on Raspberry PI
Errors
Thank for the information so far.
I downloaded the files and ran the commands. There seem to be dependency problems.
I ran the second command thinking it might solve the problem with adb from the first one. It didn't.
As I don't want to risk doing the wrong thing I am posting the command prompt output here.
Should I do as it suggests? "Try 'apt-get -f install' with no packages"
I don't know enough about the packages to say what the problem is without a lot more research.
[email protected] ~/Desktop/Android/NewTools $ sudo dpkg -i android-tools-*.deb
Selecting previously unselected package android-tools-adb.
(Reading database ... 89053 files and directories currently installed.)
Unpacking android-tools-adb (from android-tools-adb_4.2.2+git20130529-3_armhf.deb) ...
Preparing to replace android-tools-fastboot 4.2.2+git20130529-3 (using android-tools-fastboot_4.2.2+git20130529-3_armhf.deb) ...
Unpacking replacement android-tools-fastboot ...
Preparing to replace android-tools-fsutils 4.2.2+git20130529-3 (using android-tools-fsutils_4.2.2+git20130529-3_armhf.deb) ...
Unpacking replacement android-tools-fsutils ...
dpkg: dependency problems prevent configuration of android-tools-adb:
android-tools-adb depends on libc6 (>= 2.15); however:
Version of libc6:armhf on system is 2.13-38+rpi2+deb7u8.
dpkg: error processing android-tools-adb (--install):
dependency problems - leaving unconfigured
Setting up android-tools-fastboot (4.2.2+git20130529-3) ...
Setting up android-tools-fsutils (4.2.2+git20130529-3) ...
Processing triggers for man-db ...
Errors were encountered while processing:
android-tools-adb
[email protected] ~/Desktop/Android/NewTools $ sudo apt-get install android-tools-adb android-tools-fastboot
Reading package lists... Done
Building dependency tree
Reading state information... Done
android-tools-adb is already the newest version.
android-tools-fastboot is already the newest version.
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
android-tools-adb : Depends: libc6 (>= 2.15) but 2.13-38+rpi2+deb7u8 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
[email protected] ~/Desktop/Android/NewTools $
I wrote this guide to make it easy for everyone to be able to cross compile c/c++ for android, the easy way that I know. I admit, I am a total n00b to c/c++. I started learning to cross compile when I got my new nexus 9 for christmas. I, for some reason, couldnt get busybox installed on it. So, I had to manually compile and load it on there. After reading a hundred tutorials and none of them working, I got frustrated. Finally, I compiled a working version. And it was SO EASY. Anyway, Im specifically giving instructions for Ubuntu 14.04/14.10. First thing you need to do is download a package called binutils-arm-linux-gnueabi.
- sudo apt-get install binutils-arm-linux-gnueabi
- sudo apt-get install binutils-aarch64-linux-gnu (for aarch64, or arm 64bit, or armv8)
- sudo apt-get install binutils-arm-linux-gnueabihf (for armhf)
To compile busybox for your platform, you must download the source package you want to compile from http://busybox.net/downloads/. Then extract it
- tar xvf busybox.tar.gz
Then, cd into your root busybox folder.
- export ARCH=arm
- export CROSS_COMPILE=arm-linux-gnueabi- (dont forget the trailing dash(-))
This will setup your variables for compilation. Then
- make menuconfig (if you dont get a config menu, you need to "sudo apt-get install libncurses5-dev")
Now, go into the busybox settings -> Build options. Select the option "build busybox as static executable". You can select/deselect options by hitting the space bar. [ESC] key will take you back. Make sure to save your new configuration. Its almost time to compile! One last thing. If you want to add your name to it, go into the Makefile in the root busybox folder. At the top of the file, where it says EXTRAVERSION = .git, you can add something like -bynarie or whatever you want. That way when you run busybox on the terminal emulator on android, it will print out something like "BusyBox v1.24.0-bynarie". OK! Time to compile. Really simple:
- make install
This will compile every applet, and put everything in a folder called _Install. You will have busybox and busybox_unstripped in the root directory. Please, be aware that this busybox puts an applet named "su" in the bin folder in the _install folder. So, DO NOT COPY THE SU APPLET INTO YOUR ANDROID BIN FOLDER, OR YOU WILL LOSE ROOT!!! Now, to verify it compiled to the right architecture, do "file busybox" at the term and it should spit out something like "ELF 32bit ARM executable". If this is the case, congrats. We have successfully compiled busybox for android arm!! Copy the needed files over to your device and set permissions and you are done. The suggested way to move the busybox binary to your device is as follows:
- adb push busybox /data/local/tmp/busybox
- open adb shell and do "chmod 755 /data/local/tmp/busybox" or chmod it on your linux box before pushing.
- open file manager on device and move busybox to /system/xbin
- If properly done, should work.
For other nix programs like tar, the procedure is as follows:
- Open term, cd into root source folder
- ./configure CC="arm-linux-gnueabi-gcc" CPP="arm-linux-gnueabi-cpp" --host=arm-linux-gnueabi
- make
The CC variable is your C compiler command and the CPP variable is the C preprocessor, if you need to add a C++ compiler just add CXX="arm-linux-gnueabi-g++" but TAR is specifically C only. You can add all three variables I would assume to be safe. Most of the time, the readme or install documents will give you some guidance on cross compiling. But, this is how I successfully compiled TAR for arm and aarch64.
If you want to compile small/single source file c/c++, you will be using the same tools, but in a different way. Cd into your source file directory, and depending on which type of source it is (c or cpp), you will do the following:
- arm-linux-gnueabi-gcc helloWorld.c -static -o helloworld.out (for C)
- arm-linux-gnueabi-g++ helloWorld.cpp -static -o helloworld.out (C++)
Yep, its that easy. I cant guarantee 100% this will work on everything, but its a good starting point. And you dont even have to fool with the Android NDK. I find that the android ndk would mostly benefit "Apps" that need to integrate c/c++ code into them, not little console apps run from the terminal emulator. I hope someone finds this guide useful and if anyone has any problems trying to get somethin to work, you can respond and I will do my best to help.
thanks