I've been searching for about an hour now and haven't found a thing. I think I'm missing something extremely obvious but I'm completely stumped. I'm trying to simply create a new android project in eclipse from an existing source, the Launcher found in the android 2.0 source. It creates the new project with no problems and everything looks like it is supposed to look except I have about 74 errors among various different classes. I've looked through some of the errors and many are variables that haven't been declared and others are references to classes that don't exist. I've tried numerous times with several different app sources with the same problem in every single app. I've even tried downloading the source for separate apks and the same thing happens. What am I missing?!
I'm pretty new to coding android apps but decent with java. My biggest problem is just getting the apps to compile without even making any modifications yet! Any help is appreciated
matt_stang said:
...I'm trying to simply create a new android project in eclipse from an existing source, the Launcher found in the android 2.0 source...except I have about 74 errors among various different classes.
Click to expand...
Click to collapse
The android.jar which is linked in to the project by ADT only exposes the public Android API (as seen in the official documentation.) Launcher, and other "system" apps included with the platform, almost invariably access a number of private APIs which are not exposed in the SDK, and cannot be built with ADT--at least, not easily.
As it turns out, android.jar can be edited to expose all those private APIs, which is something Brut.all has worked on as part of apktool, but he hasn't done this for an entire android.jar.
Your other alternative--and practically speaking, the only current alternative--is to build it the official way, by compiling a complete platform on Linux using the full Android build process, and including your Launcher customizations. After building the whole system once you can build just the desired APK, as I understand.
olearyp said:
The android.jar which is linked in to the project by ADT only exposes the public Android API (as seen in the official documentation.) Launcher, and other "system" apps included with the platform, almost invariably access a number of private APIs which are not exposed in the SDK, and cannot be built with ADT--at least, not easily.
As it turns out, android.jar can be edited to expose all those private APIs, which is something Brut.all has worked on as part of apktool, but he hasn't done this for an entire android.jar.
Your other alternative--and practically speaking, the only current alternative--is to build it the official way, by compiling a complete platform on Linux using the full Android build process, and including your Launcher customizations. After building the whole system once you can build just the desired APK, as I understand.
Click to expand...
Click to collapse
But I already have the whole system built on my mac.. so maybe is it a matter of pointing the project to the right directory for the private APIs? Or importing a android.jar from the built source to the project..? I'm very confused
matt_stang said:
But I already have the whole system built on my mac.. so maybe is it a matter of pointing the project to the right directory for the private APIs? Or importing a android.jar from the built source to the project..? I'm very confused
Click to expand...
Click to collapse
There is no android.jar with what you're looking for. If you already have the entire platform--either http://android.git.kernel.org/ or the CM source repository--just modify that, then build from the command line. AFAIK, you have to build from the command line, though, using `make'.
olearyp said:
There is no android.jar with what you're looking for. If you already have the entire platform--either http://android.git.kernel.org/ or the CM source repository--just modify that, then build from the command line. AFAIK, you have to build from the command line, though, using `make'.
Click to expand...
Click to collapse
That makes a lot more sense. Thanks
Related
Check it out here:
http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html
Yes, I heard they were making this actually happen...
As for building Apps in C/C++ Native..
Pros:
-More Stable
-More Unique (no Android UI features unless integrated)
-More Sophisticated
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
-Other open sourced / commercial apps will be more easily ported...some ideas?...START A THREAD!!!...but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
-Remember, this is a Development Kit...it just adds tools to the 1.5 SDK that allow you to create C based applications and build them in the android environment. All your apps should still work going back to RC-30 or even further back...depends on the kernel support I would guess.
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Other:
Load times? Ok, so for example if you have one app...say...TuneWiki...just an example of a popular resource hog...if it were to be redeveloped under C++ and optimized for the Android Modified Linux Kernel...your resources could easily be cut in half since you are not relying on the Dalvik VM.
SO...outcome?
Better for all, as long as you know what you are doing.
We should also see a huge upswing in crapware on the market from student programmers doing C++ projects on an easy open-sourced mobile platform (that has a public SDK).
So you'll see a lot of "Hello World" type apps that will have next to no function...have fun with those...................
From the Official NDK User Forum: Link
acidnine
Very nice post. Thanks for the insight.
acidnine said:
Pros:
-More Stable
Click to expand...
Click to collapse
The opposite actually. Poorly written interpreted code breaks elegantly in a vm. Poorly written compiled code can take a whole system down.
-More Unique (no Android UI features unless integrated)
Click to expand...
Click to collapse
You can't integrate any Android frameworks (UIs, etc) period.
-More Sophisticated
Click to expand...
Click to collapse
I've seen some very sophisticated Java and some **** C/C++. Don't assume that higher level programming languages are necessarily less sophisticated than lower level ones.
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
Click to expand...
Click to collapse
The NDK will enable some applications that couldn't previously have been done in the Dalvik vm for performance issues, but it isn't going to be a "flood". Fact of the matter is a lot of developers who have needed native performance or didn't want to rewrite a C/C++ codebase have deployed native code already.
but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
Click to expand...
Click to collapse
FF is written in C++... [edit: I should also point out that the NDK provides for native code support in the form of libraries (mainly as a helper for computation-intensive functions). Nothing in the way of window managers or other UI is addressed, meaning for the majority of "visible" C/C++ apps the developer would have to rewrite a significant portion in Java still.]
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Click to expand...
Click to collapse
I don't know what to say other than these two statements are generally incorrect. There are two main cons to using NDK as opposed to the standard SDK, and they are 1) Reduced (or no) compatibility on future Android devices 2) Significantly reduced ease of debugging.
very interesting...subscribed
jashsu said:
You can't integrate any Android frameworks (UIs, etc) period.
Click to expand...
Click to collapse
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
The NDK provides:
A set of tools and build files used to generate native code libraries from C and C++ sources
A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
Documentation, samples, and tutorials
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Click to expand...
Click to collapse
.milFox said:
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
Click to expand...
Click to collapse
Correct. As I pointed out above, the NDK actually is just a framework for building native libraries that standard dalvik apps then call. However, my point was that the libraries themselves (the products of the NDK) cannot access or invoke the Android framework. There is a pointed distinction.
At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.
neonrush said:
At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.
Click to expand...
Click to collapse
That is probably what the NDK is perfect for. It's CPU intensive stuff, already written in platform independent C/C++ that can then be called from within a nice Androidy UI.
So they basically added JNI to the SDK...
http://en.wikipedia.org/wiki/Java_Native_Interface
Can any of the devs here compile an android version?
https://wiki.mozilla.org/Mobile/Build/Fennec
I believe everything you need to compile it should be there. If I knew how to do this I would but I'm just starting to learn how to code.
*edit: attached source
Thanks
-Mr. Biggz
The code required to make a proper working Sprint Hero build doesn't exist to the public.
In terms of what? I thought source code was platform independent.
Without knowing anything about fennec it looks like it can currently be compiled for windows mobile or for phones that can install debian packages. While android is linux the applications on our phone are java based.
So while those instructions are for compiling it for linux but that wouldn't actually run on our phone. And source code isn't platform independent, there are hundreds of different languages. For example my kitchen is written in VB. You can't take the source code (which relies on win API) and compile it for another platform.
Mr. Biggz said:
In terms of what? I thought source code was platform independent.
Click to expand...
Click to collapse
Um kinda but not really. C for windows is much like C for linux but there are differences, you can usually port code from one to the other by just doing a primary build then hunting down the errors.
When it comes to cell phones much of the code is platform specific, the Android core kernel is based on linux but requires application specific tweaks per devise which is why we can't just pop 1.6, 2.0, or 2.1 on the HeroC, we don't know how HTC made a GSM only rom work on CDMA because they are hiding what they did to make it work.
Hi guys,
I know that there are a lot of people have been asking the same question but I couldn't find the right answer for it, except "it is not recommended". I understand why such approach is not recommended so let's not discuss that issue again here.
What I really want to do is to test some internal APIs in my app. We will, in the future, build our own ROM, but at the moment, we want to test some internal features to see if they serve our purposes. But once I import any internal Java class into my app's code, Eclipse displays errors (of course). And I am trying to get around by either copying that source code part from AOSD to our app or looking for some .jar files so that we can put them into Build Path and compile. But both ways didn't work.
Is there anyone here can help me to solve the problem?
And let's me know if I posted in the wrong forum.
reddevil00 said:
But once I import any internal Java class into my app's code, Eclipse displays errors (of course). And I am trying to get around by copying that source code part from AOSD to our app
Click to expand...
Click to collapse
That's what I did for an app just yesterday so I suppose that generally this approach is working. Though I had to include a hand full of classes until all errors were gone.
If you don't tell the detailed error messages then I guess noone can help any further.
Thanks ramdroid77. Seems that I got the right person
Ok, I want to use the following classes:
com.android.internal.telephony.Call
com.android.internal.telephony.CallManager
com.android.internal.telephony.Phone
Since these files depend on other classes as well, so I decided to copy the whole source code (.java files) in framework/base/telephony/com to src folder in my project. There were errors such as in AdnRecord.java "The method readStringArray(String[]) in the type Parcel is not applicable for the arguments()...".
But before trying to fix the errors, I realized that this seems not the correct way to do because those copied Java files will be compiled as well. But what I need is only the reference implementation of those classes to get over the compilation. When the app is run, it will invoke the real classes. That's why I changed to the second way looking for some .jar files that I can add to Build Path.
Btw, which approach did you use? Can you tell me roughtly how you did it? I'll follow and report the specific error messages then.
reddevil00 said:
But before trying to fix the errors, I realized that this seems not the correct way to do because those copied Java files will be compiled as well. But what I need is only the reference implementation of those classes to get over the compilation. When the app is run, it will invoke the real classes. That's why I changed to the second way looking for some .jar files that I can add to Build Path.
Click to expand...
Click to collapse
So compile all Android java files to jar and add it to classpath of your application.
Thanks guys. Sorted it out.
I had compiled Android source code earlier so I just needed to find those class files in the compiled source code and added to the classpath. Now it is working.
I am a programmer who has programmed in x86 Assembler, Visual C++ under Windows and DOS.
I need to be able to do own applications for Android KitKat 4.4.4
I need any help and information such as manuals, books, lists of commands, lists of functions, C compiler or, best, Assembler compilers for a given processor, etcetera.
I would like to code in Assembler. I guess I need an Assembler for a given processor and cell phone. In case not possible, I need a C compiler for Android 4.4.4 KitKat. I need the basic rules on how to code for this OS as well as the OS calls which I can use, as well as a description of function libraries which may come with the C compiler.
I prefer pure C than C++ or Java.
I have briefly searched the Internet with various key words and I have not been able to find anything relevant.
Please, does anyone have any information where I can get anything helpful.
I am totally new to this OS and I do not even know the shell commands. I do not have much information of the shell, although I have found a basic list on this forum and I use ls and ? and go by the name as a dumb fool.
Please, advise.
While Android is in Java, it also allows you to run C/C++ native code.
Search "Android NDK" and you will find the relevant documentation.
Arws Apps said:
While Android is in Java, it also allows you to run C/C++ native code.
Search "Android NDK" and you will find the relevant documentation.
Click to expand...
Click to collapse
Thanks. I have tried NDK. I am not sure whether I have installed this correctly but I would keep this.
Because NDK is hardware specific and I am not sure whether and how much Moto E XT1023 and others are supported, I have installed Android Studio 1.2 ad started with XML and Java. I have done similar things with HTML and Java for web sites. I would use XML as much as I can and Java only to get and set some variables, then I would use C for programming and then I would set Java variables and methods. I am not very happy with Java but there is not any other way for now. Hopefully, in the future, they would make XML a real language with all the resources available, functions and methods.
At least Java has a very C-like syntax, so in general it shouldn't be that difficult. In some sense it would even be easier (no memory management).
Arws Apps said:
At least Java has a very C-like syntax, so in general it shouldn't be that difficult. In some sense it would even be easier (no memory management).
Click to expand...
Click to collapse
Yes. You are right. I would prefer, however, a pure ANSI C. This can be done either as an interpreter to be hardware independent or as a compiler upon launch, the system would have a compiler, the user would download only the ASCI text. Upon launch, the compiler would be called first to compile and then the application can be launched. Then, the user can either keep the .exe or keep just the ASCI text, in which case, new compilation has to be done with every launch. A compilation would normally take one or a few seconds only for normal applications.
Hi all,
I'm currently investigating into a freshly developed application, from a security side. The app builds upon several libs and frameworks (i.e. Android Maps Utils 0.4 or Butterknife 7.0.1), so the first task I want to go through is to identify any weakness in those code pieces.
Is there any forum that would list security issues detected in common libs and frameworks used by developers? Tip: I'm not an Android developer...
Thanks in advance for any clue!
jlgarnier said:
Hi all,
I'm currently investigating into a freshly developed application, from a security side. The app builds upon several libs and frameworks (i.e. Android Maps Utils 0.4 or Butterknife 7.0.1), so the first task I want to go through is to identify any weakness in those code pieces.
Is there any forum that would list security issues detected in common libs and frameworks used by developers? Tip: I'm not an Android developer...
Thanks in advance for any clue!
Click to expand...
Click to collapse
Not that I am aware off. You could try to search in the metasploit framework or google with "<libname> vulnerabilities exploits" etc. But that is only likely to have interesting results for native libraries (written in C, part of the Android system like Stagefright)
Your best shot is by starting RE the library code or if open source, search the repo for any information leaks to the filesystem (bad crypto, sensitive information in preference files, bad handling of Bundle objects for IPC etc.)
Many thanks H4oxer! I'll follow this track and try to gather information on the various libs...