Could anyone suggest some detailed info about the internals of Android? I'm interested to know it's differences with other Linuxes, some detailed view of the Android architecture, etc. I've heard loads of scattered info, e.g. the Surface Flinger, the Stage Fright something, that it's got Wake Locks, etc., but I can't put that info together into something meaningful to me.
I just need to understand how Android works, but do it in detail. I'm not very much interested in the SDK or NDK.
Android uses an optimized Linux-Kernel, but not 'glibc' for it's communication between the Kernel and the System. Instead, 'Bionic' is used.
The Apps for Android are written in Java, but not compiled to standard Java-Byte-Code. Also, they don't use a JVM from Oracle. The JVM used by Android is the 'Dalvik Virtual Machine', which reads Dalvik-Byte-Code. The DVM is bases on Apache Harmony, which is an OpenSource JVM implementation.
Also, if found an article on the same topic: Link
Related
I'm a web developer and am thinking of digging into mobile app development. The languages I know so far are PHP, Python, SQL, Js, HTML and CSS, all of them pretty well now. Currently I'm starting to dig into Java, as it's the language to be used for native Android App Development, as far as I've learned. Interestingly, I'm coming across posts (also in this forum) saying that Java can also be used to develop iOS - compatible Apps, while other sources comment that Apple is completely against cross-devs, and that you should develop iOS apps using Swift when it comes to the native choice and optimal UX. So I was wondering about the answer in this forum; can you develop iOS apps using Java or not?
Post is a few months old now, but I figure someone with a similar question will probably find this with web search, so this reply is for them. (Disclaimer: I wrote Java professionally for about five years, and I grew up when Java was supposed to be the future.)
If the question is, "Can you write Java code and run it on iOS?" then the answer is, "Technically yes, but you almost certainly don't want to."
It requires jumping through all kinds of hoops and sleight-of-hand to make it work. The project linked in a previous answer, Codename One, is a pretty heavyweight framework and the kind of thing you'd only want to use if you were heavily committed to a Java codebase already.
There are advantages to knowing Java in 2022, but cross-platform mobile development isn't one of them.
Some reasons why you might want to learn Java:
Developing on Android. Android now supports/recommends Kotlin for new projects, but Java was the sole first-class language on the platform for 10+ years, so it's advantageous to be able to read/write/reuse Java code and libraries.
Using long-standing big-data tools (spark, hadoop, neo4j, etc.). While this domain has increasingly moved to Python over the past 5-7 years, there's still a lot of production Java code that someone needs to maintain. [Edit 3/31/22: See also the Apache http server, whose name never sat right with me because as far as I know, the people who wrote it aren't Apache.]
Stylistic similarity to C-family languages. Java can be a more intuitive introduction to C-style languages than jumping right into, say C++. These days, though, I would recommend C# over Java since it's used in more domains.
Continuity with some JS dialects. React code in particular is full of Object Oriented(tm) design conventions that are very strongly influenced by Java practices, and those design choices in turn have influenced changes in the JS spec. So being familiar with Java conventions can help make sense of that stuff. It can also help you identify which of those practices are bad ideas so you can avoid them in JS. [See footnote 1.]
As far as reasons why you won't see widespread Java usage outside of those legacy domains, I'd say there are a lot of good reasons people have moved away from Java since 2006 or so:
It's incredibly verbose, and requires a lot of esoteric knowledge about implementation details to write code that runs efficiently. This is the kind of problem that languages like Scala and Kotlin have tried to solve, while retaining compatibility with the JVM platform for ease of migration.
The JVM platform itself introduces substantial overhead, both in resource usage and integration complexity.
Changes in approach and policy since Sun's acquisition by Oracle. This is related to licensing issues (see Oracle v Google), as well as complexity/feature creep, which has given rise to compatibility issues across codebases.
Emergence of viable alternative languages in the 2000's and 2010's.
Widespread adoption of virtualization technology has yielded alternate ways to solve the compatibility issues that Java was designed to address.
It's ironic, since the motto of Java used to be "write once, run everywhere", but that's the way things go.
Footnote 1. Actually, this is kind of a trick question, since most commonly accepted Java practices are bad ideas. This can be demonstrated by the fact that in 1995, object-oriented Java applications would run in a typical web browser, whereas 27 years later Java is considered too heavyweight for that purpose.
Postscript, 3/31/22: This is my first and likely only Stack Overflow post. If you want to read more like this, check out my github: https://github.com/ubuvoid
Yes you can.
One tool used for this is Codename One.
https://www.codenameone.com/
Also for more info on this subject, feel free to consult this thread:
How can one develop iPhone apps in Java?
Yes, this is possible. https://github.com/Anuken/Mindustry is an open-source RTS game written in Java. It has an iOS port that is compiled via an open-source fork of RoboVM.
IOS works on objective C and Android works in Java and Kotlin. I don't know how much some conversion tool can help you to achieve all the functionality. So in my opinion answer is No.
Hybrid Application development can help you. You have one source code that will run in both platform. You have to develop the app again.
First: Java is used in more Domains than C#. Needed information because C# has no way to get over with ONE UI to Desktop, Mobile and Web.
By the way, the recommended Solution is CodenameOne or - if you want to implement your App with JavaFX - use Gluonmobile which is using the GraalVM, an ahead of time compiler for IOS.
In both Cases you have access to Hardware of the Device for Android and IOS because there is an abstraction which helps you with implementations for both Platforms - Android And IOS. Write in this Case one App and compile for both worlds.
I've been working on a writing a game for Android. Until now I've been using Java instead of the NDK, but I've decided to port my code to C++ (for performance, memory management and industry standards reasons).
Porting my application shouldn't be a problem (I've written my fair share of C++ applications), but I've been using RoboGuice as a dependency injection framework because otherwise my object graph would become too complex rather quickly.
I've been looking around, but I haven't found any resources about using a dependency injection framework in combination with the Android NDK.
Can someone tell me if there any such franeworks available. If so, which one would you recommend?
If you have a C++11 compiler for Android you could use several frameworks (I wrote Infectorpp) but there are others available. You should note that DI is quite limited in C++ due to the lack of reflection so you should make some compromises as not everything you did in RoboGuice would still be possible.
By doing a quick search seems that C++11 is possible on Android. I don't have an Android device and still not needed to emulate it, but if you have any feedback it will be wellcome (private message here or support ticket on google code is enough), the library is headers only so no special build stuff is required for it, apart enabling c++11 on your compiler wich is just one extra option by command line. If that will works good on Android then it will be definitely good also for PC. (Do not misunderstand please, I'm using it heavily, but seems very few people is interested in DI in C++ and so I get very little feedback)
There was also a nice framework cpp-resolver: a little awkard to use because you explicitly register factory functions for injecting ALL parameters, but very scalable, especially for server applications.. (decouple object lifetime management and works with plain old C++).
The most complete framework is probably wallaroo
If you search something really easy to use Infectorpp is a good choice
If you need control over lifetime (mostly servers): Cpp-resolver is perfect
If you need exotic features and configuration files: wallaroo
As side note, run-time configuration is possible also with frameworks that do not explicitly support it:
You just need a Factory that istantiate a different type based on a configuration file you could read through a class that you add as dependency to factories (Probably you don't need to know that since you were already using DI frameworks, but still good to know for occasional readers)
We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?
AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.
Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.
You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial
I'm going to implement aodv protocol as a linux module for a research project, and I need to implement it on Android later.I wonder if I could compile my codes into the android kernel and have my module work as in Linux (kernel 2.6 up).
Any suggestions would be greatly appreciated.
(P.S. There are already some aodv implementations on Android, such aodv-on-android and UoB JAdhoc, however, those are implemented in Java, not involving kernels)
The tagline goes: Android is Linux, so anything (portable) you do on Linux should be simple to make happen on Android.
This is mostly true, however there are a few things you'll want to keep in mind:
Portability: If you're writing your implementation on x86 and then moving the module to ARM for Android, be careful not to use any capabilities that don't exist on both. However, for something like a network protocol, you probably won't be running into a lot of these. The only one that comes to mind is the NIC.
Dalvik: Generic Linux distributions tend to run fairly close to the OS, meaning they regularly make system calls or libc calls, and the semantics of interactions with the kernel mostly carry over to the application. Android, however, has essentially a Java environment build on top of that, and the majority of applications only interact with that framework. For you, this means you will want to be aware of the possible need to modify the Android framework in order to make changes visible to applications.
The above point depends on your use case, however. If you plan on augmenting routing for existing applications to use aodv, then you'll want to hack around with Dalvik. If you'll be writing one proof of concept application, then you can write the portions that interact with aodv in C using the NDK, and avoid having to modify the application framework.
You probably already know this, but the kernel built system is sophisticated enough that you should be able to get away with writing your module once and compiling it for two architectures or platforms just by changing your configuration.
Hope this helps.
Not really an immediate source code question per se....but Im looking into doing some casual Android Programming, nothing heavy.
But it seems to use alot of XML and Java......what I wonder though is why is it that android is written mostly in C and XML (along with C++ and Java) with it being closely related to the Linux OS......but why is the "main" language for programming in android Java?
Just out of curiosity of course.
The "main" language, as you called it, is Java. You can use C/C++ via the NDK, but you won't need it unless you are doing some special stuff. If you wonder when you would need to use C/C++, take a look at the official documentation:
When to Develop in Native Code
The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
The Android framework provides two ways to use native code:
Write your application using the Android framework and use JNI to access the APIs provided by the Android NDK. This technique allows you to take advantage of the convenience of the Android framework, but still allows you to write native code when necessary. You can install applications that use native code through the JNI on devices that run Android 1.5 or later.
Write a native activity, which allows you to implement the lifecycle callbacks in native code. The Android SDK provides the NativeActivity class, which is a convenience class that notifies your native code of any activity lifecycle callbacks (onCreate(), onPause(), onResume(), etc). You can implement the callbacks in your native code to handle these events when they occur. Applications that use native activities must be run on Android 2.3 (API Level 9) or
You cannot access features such as Services and Content Providers natively, so if you want to use them or any other framework API, you can still write JNI code to do so.
I am just guessing but Java is a bit easier to program than C/C++ so its more attractive to new programmer which is also good for the platform success itself.
Another reason might be that an application written in java runs in a separate VM so it can be much easier controlled by android. If a vm is not responding the main OS can just kill it and the phone is still responding.
Suaron... From a stability point of view Java apps should be less likely to take down the device. So Java || C# || C++/CLI safer than C++ vs C vs Assembly. To this end the API is in Java and so most Apps are in Java.
On the other hand C/C++ gets closer to the hardware and is more appropriate for writing libraries that interact with hardware. It is much easier to shoot yourself in the foot with C++.
JAL