I'm working on a custom default android browser. I follow steps here AOSP to build my custom browser:
Clone android source code
Make changes on android browser
Build the Browser only for Nexus 4:
lunch full_mako-eng
make -j Browser
I rooted my Nexus 4 and install the Browser App. Everything is fine but I wonder if there is any other methods that simplier than above steps?
Can we just import the Browser into Eclipse or IntelliJ and build it directly to the phone?
At first, I want to point to some errors in your receipt.
Command make -jN builds all the sources of AOSP, where N is usually equal to "number of processor cores + 2". After the whole build of sources you can just build your browser application using command mmm packages/apps/Browser -jN snod
Browser application is a part of Android and thus, it is possible that it uses some system permissions that are not available for applications that are not installed on system image or not signed with system image. If it is not, then you can extract Browser application from AOSP, import it as a separate application into Eclipse and build it as a separate application (however, you will need to modify some resources).
Related
I apolagize in advance for the extreme noobiness of my question...
I'm on mac os and using cordova to build an app. I know nothing of java or c, so the only thing I did was to put my index, js and css files in the www folder and test it with the CLI.
$ cordova emulate /* with android and ios */
$ cordova run /* with android and ios */
$ cordova build
I was able to make the app work on android and ios virtual and real devices, and got the BUILD SUCCEEDED message on my terminal.
But to be honest none of this is familiar and if it wasn't for a tutorial I read one line at a time I wouldn't have been able to do it.
The probleme is the tutorial stops at the build step, and I can't find any other tutorial that explains very plainly and simply(not to say idiotically) how to go from there.
I'm left with lots of folder and have no idea what exactly is the app amongst all those files.
How can I put it on my website for download? Do I need an executable?
For iOS and android you would typically have two different types of files.
iOS uses .ipa files and android uses .apk files.
I am not sure about Cordova, but generally the cross platform software would generate those two types of files, these can then be put onto the device and run.
I'm sure you've found out more since 2014 but for others (like me landing here from google), in Windows, at the CMD command line, use
WHERE CORDOVA
..to find where the cordova builder is actually located.
For Android, your output is an *.APK file which should be announced at the very end for the cordova console output, eg:
C:/MyApps/TrialApp/phonegap/platforms/android/build/outputs/apk/android-debug.apk
..where C:\MyApps\TrialApp\phonegap\ is your phonegap project folder assuming you are using phonegap.
If you do not want to submit it to Google Play, you can host the *.apk on various hosts including your own site, a freebee like http://androidhost.org/ (care, may download trash to phones), http://slideme.org/ or https://www.voltcloud.io/ etc.
Hopefully that will give other newbies a heads up.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I am currently developing a Android Application. I couldn't install the Android Python APKs like the sl4a.apk and the PythonInterpreter.apk on my Android x86 emulator. I read that it is possible to recompile the APKs with NDK but I have not found a closer decription, yet. Has anybody experience with this and could provide a small tutorial?
Best Regards
Try the official Android emulator. If the APKs include native libraries, chances are those are compiled for ARM only. Google's emulator emulates the ARM instruction set.
To make sure, rename the APK to ZIP and look inside. The structure of the lib folder, if any, will give you an idea.
you just install an APK package available here: http://code.google.com/p/android-scripting/downloads/detail?name=beanshell_for_android_r3.apk&can=2&q=
SL4A then you will have to start, edit your script, the APK package is available here: http://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r4.apk&can=2&q=
Then you just google uses the SDK to emulate your scripts on a PC
you also just edit directly with a text editor on Android for example "920 text editor"
sorry for the Google translation
++ BeHuman
To install SL4A, you will need to enable the "Unknown sources" option in your device's "Application" settings, download the .apk and install it either by accessing http://code.google.com/p/android-scripting/ from your computer and click the qr-code or directly from your phone and click the qr-code and then run the downloaded .apk file.
After installing SL4A:
press the Home button
press Add button
go to Interpreters
press Home button again
press Add again
pick Python Interpreter and install it
and after that a new screen will appear with an Install button on the top, press it and it will download Python 2.6.2, at the moment, for you. Optionally there is a button so that you can download a few more Python modules.
To build your new files you have a great little tutorial here: http://jokar-johnk.blogspot.com/2011/02/how-to-make-android-app-with-sl4a.html
Just follow all of these steps and you will be able to make working .apk files written in Python for your Android phone.
I am looking for a utility that would quickly bundle up a phonegap app for android from an html directory. Perhaps something that would read some config.json file in that directory to automatically take care of all the configurations.
Basically I am looking to avoid doing all the setup of eclipse just to wrap my html5 app which already works fine on android through the browser.
Anyone have any good tricks or tools that can shortcut the whole process to something close to what I am dreaming about? I would love something where in 10 minutes I can have everything ready to deploy to the marketplace.
One option is AppLaud Cloud. Note, that it is still in alpha.
With AppLaud Cloud, you could create a Base App and then replace the contents of the assets/www directory with your html5 app.
You can emulate the app with the built-in Emulator, debug the app on device with Weinre, and build for deployment to the market.
Caveat: I'm the creator of AppLaudCloud.
Dreamweaver 5.5 has a function like the one you are looking for. I played with it briefly and is ok. More info here: http://blogs.nitobi.com/andre/index.php/2011/04/12/adobe-dreamweaver-5-5-supports-phonegap/
The plus: works with ios also(if you're on mac)
The minus: quite expensive stuff...
I would try using the new (undocumented) command line tools in the PhoneGap Android source. There is a command for creating a new app (https://github.com/callback/callback-android/tree/master/bin) and in the new app folder there is a command for debugging the app (on emulator or device).
You could also check out https://github.com/brianleroux/cordova which is a prototype for the command line tools that are now in the platform specific PhoneGap repos on github.
Going forward there will be more work done on Cordova but probably as an official PhoneGap repo / binary distribution.
I want to make some changes to the stock Mms Android application and install it on my device. However, I have problems with compiling the code checkout obtained from git. I have created a new Eclipse Android project with "use existing sources", setting the target framework to 2.1. However, Eclipse does not find some needed framework classes, e.g. android.telephony.SmsManager.
I have the whole Android toolchain set up and working (make finished without errors), Eclipse is running on Sun Jdk 1.5.
Perhaps my mistake was that I did not copy the .classpath file into the new project, I will check this. Never the less, should I succeed, will I be able to install this .apk into a non-rooted device?
The stock Android applications are not designed to be built using the Android SDK, mostly because many of them predate that SDK. Right now, they can only be compiled as part of the firmware.
Even if you wind up with an APK, you will not be able to install it separately from a replacement firmware, unless you change the package in the manifest. You cannot have two applications on the device at the same time with the same package, and since you will not be signing your APK with the digital signature used by the firmware, yours will not be able to overwrite the existing one.
If you have a device that supports replaceable firmware (e.g., ADP2, Nexus One), you may be able to create, sign, and install your own firmware, then replace that APK in the future without replacing all of firmware a second time -- I don't know how well that works.