You can actually write C apps and compile them using the Android Toolchain to target the embedded Android linux system.
Code:
#include <stdio.h>
int main()
{
printf("Hello Google Android world!\nwww.pocketmagic.net\n");
return 1;
}
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
You need:
1) a linux box
2) the google source code
3) time and patience
A complete article here with detailed steps and tools:
http://www.pocketmagic.net/?p=682
Advantages:
- being able to implement new features that are not yet added to the SDK (eg. bluetooth)
- direct hardware access (eg. video memory)
- C vs Java
- etc
Hope this helps.
I guess technically, those are C apps for the G1, not really for android since they are not necessarily usable on other android devices.
MartinFick said:
I guess technically, those are C apps for the G1, not really for android since they are not necessarily usable on other android devices.
Click to expand...
Click to collapse
Well that would just be a generic C app compiled for armel. To do proper native on Android, one would have to use JNI. My understanding is that path also does not require root access. For more info:
http://groups.google.com/group/android-ndk
NDK = Native Development Kit
Jashsu, you are correct
That's just an arm binary, and will run on any linux distro on ARM with the libraries you include.
Android runs on-top of linux, and you will have to wait for the NDK to be able to code natively for it. But java is still a better idea for multi-platform support
Also, no root access is required to run code that doesn't require the access itself (raw i/o might need it for example)
Thanks for the feedback.
You might already know that using the Android toolchain libs, and the arm-eabi-gcc you can do direct-screen drawing, playing sounds etc. For those needing speed/hardware control the tools are already available.
Here's an update to this article:
A more convenient way to compile native C code, using the NDK. 3 steps and you can get the C code running on your Adnroid:
http://www.pocketmagic.net/?p=1462
Related
So I'm currently coding a One click AIO rom cooker for ALL OFFICIAL CM supported devices (if it's on the CyanogenMod Downloads page, it'll be included).
Pretty much all you have to do is:
1) Download the folder from my github (link will eventually be included in the thread)
2) select your device
3) Select your version of CM (CM7, CM9 or CM10). IF IT IS SUPPORTED OFFICIALLY (a one click compile CM10 for a HTC Wildfire is outside my coding knowledge and patience level)
4) Set Options (Name your mod, Compile a custom kernel or use stock, copy the rom to your SD card and reboot to recovery, etc)
5) hit go!
It will:
Set up your Linux install (should work for Ubuntu and Debian)
Download the CM Source
Download the required files for your specific device (provided it can be found in the CM repository)
Build the rom
If selected compile Kernel and then recompile including the new Kernel
Copy the rom to an easy folder for you to send to your SD card (or have it do it for you)
Should be easy to update, just repo sync, then recompile (I think)
Easy debugging. All errors are automatically logged to a easy to find file.
What does everyone think of this? I'm aiming to have it released around Christmas, At least a beta version (may not support all devices out of the box, but I will keep working to add more (I need to test each and every device to make sure the cooker works). This will be released under some open source license (currently researching)
Here's a screenshot of what I have working so far (not much but it's a start). It's based on the layout of Android Kitchen.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
With Google releasing monthly patches (which I believe is a good thing!), it's become a bit of a chore to install updates, especially so if, like me, you have a modified device stopping you installing OTA updates.
I wanted to do something to make it a bit quicker, so I made Nexus Flash! I guess you can think of it as minimal ADB & Fastboot packaged with a GUI.
I've decided I don't like the GUI layout, and I'm pretty sure most will agree, so I've already started working a new layout, bug fixes, and adding some extra features which I'm sure some may find helpful like an update manager (so you don't have to go to Github every time there's a new version), another example is a way to boot an image file too, for instance, Chainfire's CF-Auto-Root.
Currently, there isn't much validation of user input, so please only use it as intended for now. It shouldn't break your device if you don't use it correctly since ADB has built in measures to validate files to some degree at least.
However, I have to say, this program is provided without ANY warranty or guarantee. Using this program is at your own risk. I have tested this on my own Nexus 5X and it works perfectly.
The source code is released under the GNU GPL (General Public Licence) and can be found on Github.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Prerequisites for Windows:
You'll need the .Net framework 4.5.2 installed (Windows 10 already has this).
Prerequisites for Android device:
Your device must have an unlocked bootloader.
You must have USB debugging enabled.
You'll also need the Android ADB USB drivers installed too.
Guides can be easily found by searching for them, there's plenty of them around!
Links:
Binary - Github releases
Source code - Github
Issues or feature suggestions - please direct them to Github (preferred). Or simply create a comment on this thread.
Release notes
Version 1.0.0
Initial release!
I've had to delay writing the new update for this (because life gets in the way), but I promise I will get an update out ASAP!
Hello all!
I am back at it again with a new Android Debug Bridge GUI, now written in NodeJS!
Features:
Install APKs
Custom TWRP integration
Fastboot commands in one click!
Backup device via android or twrp backup methods
build.prop reader (soon to be editor)
Root checker (Soon to be root installer too for LineageOS devices)
Custom Commands
Multi-device support
It has the same basic features that my Older ADBGUI application had but with the added benefit that it will work on Windows, Linux, & Mac! (AndroidSDK needs to be installed on Mac in order to use, Minimal ADB installed on Windows in order to use, and android-tools installed on Linux in order to use)
Some features still do not work, but it is currently work-in-progress. It also can be used as a Kiosk in cell phone repair shops to quickly run diags on Android Devices.
This application is written in NodeJS and is built to run under Windows and Linux however it should (untested) be able to run under Mac as well.
This application should NOT - I REPEAT SHOULD NOT be run on a computer that can be directly accessed outside of the local network.
Downloads:
https://urgero.org/howto/linux/adbwui.md
Screenshots:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Very interesting your project. Good job!!!
FernandoSilva said:
Very interesting your project. Good job!!!
Click to expand...
Click to collapse
Thank you! It's based on my adbgui idea from 2012.
Sent from my Moto G4 Play using XDA Labs
#bump (sorry)
Is this the same project as photo attached??
What do you mean by ""This application should NOT - I REPEAT SHOULD NOT be run on a computer that can be directly accessed outside of the local network."" ???
Why would you not have the computer connected to WIFI? Is this a licencing issue?
I cannot understand why no one adjusts the name slightly when reviving these projects (e.g. adbGUI v2 OR.... adbGUI for MAC, etc).
So Linux only support??
EDIT: Looks like the project is now "ADBWUI" @ https://github.com/mitchellurgero/ADBWUI
flipmode_11 said:
Is this the same project as photo attached??
What do you mean by ""This application should NOT - I REPEAT SHOULD NOT be run on a computer that can be directly accessed outside of the local network."" ???
Why would you not have the computer connected to WIFI? Is this a licencing issue?
I cannot understand why no one adjusts the name slightly when reviving these projects (e.g. adbGUI v2 OR.... adbGUI for MAC, etc).
So Linux only support??
EDIT: Looks like the project is now "ADBWUI" @ https://github.com/mitchellurgero/ADBWUI
Click to expand...
Click to collapse
This project is stale. I wouldn't use it. The warning is there because it runs a webserver without any authentication for the UI. This project runs on NodeJS - so supports any OS that supports node.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Website
EtchDroid is an open-source application that helps you write images to USB drives, no root required.
You can use it to make a bootable GNU/Linux USB drive when your laptop is dead and you’re in the middle of nowhere.
Features
Supports raw disk images and most GNU/Linux distributions ISOs
Supports most DMG disk images (beta)
No root - everything is done within the bounds of the Android API
Free as in freedom
Planned features
Write common GNU/Linux distro in streaming from the Internet without storing it on the device
Supports most DMG disk images (beta)
Support for Windows installation ISO (will likely require root) (update: seems actually quite feasible)
Support for macOS installer creation from app/InstallESD.dmg
Support for Unetbootin-style image flashing
Downloads
Project website
Get from Google Play Store
Soon on F-Droid - see merge request
APKs from GitHub (expand the "assets" thing)
Source code
(note: latest version on Play Store is currently v1.0, while on GitHub you can find version v1.1. There's no functionality change between the two, v1.1 is a new build that includes some project structure changes for F-Droid compliance).
Support the project
If you like the app and would like to support the project, you can send me a donation through XDA, or check the website for more options.
XDA:DevDB Information
EtchDroid, App for all devices (see above for details)
Contributors
Depaulicious
Source Code: https://github.com/Depau/EtchDroid
Version Information
Status: Stable
Current Stable Version: v1.1
Stable Release Date: 2018-09-01
Created 2018-09-06
Last Updated 2018-09-06
Reserved
Reserved
Any chance to create a iso repository where we can download the iso files?
Many thanks for your great work
filnirv said:
Any chance to create a iso repository where we can download the iso files?
Many thanks for your great work
Click to expand...
Click to collapse
It's a planned feature, I'll work on it as soon as I have some time.
I just wanted to say thank you so much for this tool. It just saved my ass. I somehow ended up with a corrupt linux install on the Chromebook (only PC I had on hand) I use for work, and had to reinstall while in the middle of nowhere South Dakota.
I'll definitely be donating when I have the chance.
Hello,
i searching and trying now since 2months to get my library to run. Im using the free emulator NOX, MEMU, LD to test it.
Current emulator (MEMU) starting the app (ARM) now alot of other libraries (x86 and also ARM) getting loaded, but as soon the library i use mylib.so (ARM) gets loaded by the x86 process
houdini is not catching it (yes it has the correct elf magic code in it so which is used for identifying the elf and everything should go over houdini) but instead i get e_machine 40 error for
not supporting ARM on x86. Houdini is ignoring my lib.
Is it not possible to start an ARM library from a x86 process by using houdini? is it not the purpose of it, to make it work?
i placed the mylib.so in [ /system/lib/ ] is it maybe the case i need to put it in [ /system/lib/arm ] ?
What i am doing wrong.
Thank you.
AFAIK MEMU can run in 64-bit mode ( means run a 64-bit Android image ).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
xXx yYy said:
AFAIK MEMU can run in 64-bit mode ( means run a 64-bit Android image ).
Click to expand...
Click to collapse
thank you for answering but what would be different it is still the same architecture (x86 system) and ARM lib and also Android64bit is using houdini.
maybe a few more words about your thoughts would help me to understand.
LIBHOUDINI.SO ( the Intel-ARM translator what isn't freely available , means it isn't open source ) only is used on x86/x86_64 emulators like MEMU, and only if "native-bridge" is enabled in Android's build.prop file, AFAIK.
Yes, and its also working for other ARM libs but simply not for mine, and i would just like to understand. Why houdini is not starting my mylib.so from a x86 compiled process.
the normal output from houdini is:
C++:
10-05 12:08:57.325 3744 3744 D houdini : [3744] Added shared library /data/app/com.test.me/lib/arm/libqop.so for ClassLoader by Native Bridge.
but only mylib.so is not recongnized by it.