Can anyone share some details for developing new SDK add-on like the one Google map API? I do not find any details on how to build new SDK add-on?
Is that good approach to have SDK add-on for connecting to twitter, Facebook, YouTube applications? I mean the library would contain the methods to access the developer APIs supported by the social networking apps. I am looking out some ideas for developing new SDK add-on.
Let's assume I have added new service API in the android core framework. Now can I build a SDK add-on in order to access that service? (This add-on library would have simpler API calls that would in turn available the service from android core service)
1.) I have not tried this out much myself but there is a demo SDK-addon available in the platform distribution. Look in the vendor/samples folder of the Android Open Source Project. There is not much documentation on it. What is needed is that you create product make files for your SDK-addon and build your platform with this product description. It will generate the file system images needed to include with the SDK, documentation etc.
2.) I am not sure if SDK-addon is suited for connecting social services like you describe. Using a regular Java library and linking it directly with your application sounds like a better way unless your are building for a specific device. As I understand it the SDK-addon and framework extension mechanics are primarily for people who create their own devices and need to add device specific API:s to the SDK. One example would be the case where you are using Android to build a navigation system in a boat and want to include API:s where you can get information about speed, engine status, measured depth etc from some other hardware in the system. In that case you would build your system including the extra services and then generate an SDK addon for developers who would like to build applications specifically targeting your nautical use case.
3.) Yes, I believe you can. Remember however that SDK addons require system images that correspond to a device with the added capabilities and applications written using the SDK-addon will only work on devices that include this functionality.
Related
Do they share the code base and version number?
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
This may be a strange question, as I am particularly interested in Android Application Framework.
Do they share the code base and version number?
From an Android application developers's view point there is not much difference between Android OS and Android Things. I.e. you can successfully deploy an Android app developed for Android (OS version 7+) on a platform running Android Things.
Does Google release the same piece of code for both and just use different flags for mobile phones and Android Things?
No "flags" at all. It's rather a matter of adding new system (C/C++/Java) services specific to the supported platforms with its underlying hardware or removing the old ones, needed for mobile devices and not related to embedded systems. Actually Android Things is pretty much an inheritor of Brillo.
As a quick look consider the following overview of Android Things OS to see how it differs from Android.
With regards to the Android Application Framework, you can expect the vast majority of APIs to be the same on Android phones and Android Things. Specifically, this page details the APIs that are not available:
CalendarContract
ContactsContract
DocumentsContract
DownloadManager
MediaStore
Settings
Telephony
UserDictionary
VoicemailContract
Additionally, a few Google Play Service APIs are not available.
In terms of whether Google releases "the same piece of code for both" the answer is a bit complicated. Android's framework is a combination of a lot of files, some of which only make sense for specific form factors. Different build configurations state what files to include, which to not include, and how exactly to build the correct system image.
I need to create an app for WP8, Android and iPhone that uses the Azure Mobile Service. I am really impressed by the MvvmCross project so I really want to use it.
Before starting I have some questions:
Can I add the AMS SDK to the .Core project and will it work for all platforms?
Is the a easy way to handle the login views for the authentication providers on the different platforms?
I am a little bit confused by the profiles, which one should I use?
I would really appreciate if anyone can answer my questions,
Michi
Can I add the AMS SDK to the .Core project and will it work for all platforms?
The Core project is a Portable Class Library.
If you want to use Azure Mobile Service SDK in it, it means you need to add it as a reference to the Core PCL, which means the AMS SDK needs to be a PCL also.
Further more, if you need it for all platforms (Windows Store, Phone, iOS, Android) this means the AMS PCL needs to have an implementation which works on all these platforms.
Looking to https://github.com/WindowsAzure/azure-mobile-services, it looks like the PCL is ony for Windows 8 and Windows Phone 8.
There is however a Xamarin component for Azure Mobile Services, but it's not a PCL (if you download it and check it, there's a separate DLL for Android and iOS):
http://components.xamarin.com/view/azure-mobile-services/
http://www.windowsazure.com/en-us/documentation/articles/partner-xamarin-mobile-services-ios-get-started/
If you want to have a portable functionality in the Core to be used by the view-models, what you can do is define an service interface like IMyAMSClientService in the Core and have it implemented on each platform (you implement MyAMSClientService on each platform, in the app project). You will need to think about a mechanism to handle the AMS functionality in an unified way.
Is the a easy way to handle the login views for the authentication
providers on the different platforms?
Like I said above, you can have something like an IMyAMSClientService in the Core. The actual implementation of it will be on each platform and it will do the calls to the AMS SDK.
I am a little bit confused by the profiles, which one should I use?
I assume you refer to PCL profiles?
You don't need to use anymore any hacks to get the Xamarin profiles available when you create a PCL. Did you try to create a PCL? The Xamarin profiles should be there. You need to have Xamarin installed though.
I want to modify the core applications like Settings.apk and install on my own android phone.I don't want to publish it on market. I have following doubts
Where can I get source code for core applications?
What are the things I need to do this?
Please tell me steps to do this.
You can get the source code here: https://android.googlesource.com
Keep in mind that the packages there might not be the ones on your phone as each vendor can provide a replacement of their own, the Camera for instance is almost never the google app.
You will also have to decide which version you want since each OS version has revisions that take advantage of newer API's etc.
As far as what you need pretty much the same thing you need to build android apps, eclipse, the sdk, tools etc. http://developer.android.com
You will of course have to remove the application from your phone before installing the new one since your signing certificate will not match. There can be difficulties when you swap out your own version so be sure to save the original.
The Google Market offers an application purporting to run J2ME MIDP applications on the Nexus One.
I have tried this application but it only appears to run MIDP applications that are downloaded from particular web sites; it does not seem capable of picking up a MIDP application that is stored on the SD card in the phone.
I have suggested to the developers that they might like to add such functionality, but they have not been particularly responsive to my messages.
So I would like to build my own MIDP runner for Android and would like to see if I can find a pointer as to where to start, or even whether this is possible.
The MIDP application in question was supplied on CD along with a security camera system and permits remote viewing and remote control over the security system.
Clearly it wasn't built with the Android platform in mind. However, if it is possible somehow to run MIDP applications on Android (perhaps by creating some kind of sandbox environment for example) then I'd be quite keen to develop it.
MicroEmulator is a Java implementation of Java ME. You could try porting this to Android. The UI part should be re-written, as MicroEmulator is based on Java SE components that aren't available in Android. Also hardware access won't be possible. Device vendors implement J2ME APIs (camera API for example) and bundle them with the core J2ME. This won't be easy for you to do. You will need to study the JSR specification and implement it in Android.
You can use App Runner to port MIDP apps to Android.
I'm fairly new to Android and have gone through the basic tutorials. I thought I'd dig a little deeper and downloaded the source code to some of the "native" Android apps, like IM, Email, Voice Dialer, etc.
In importing the source of these native apps into Eclipse, I found that they reference classes that are not in the 2.1 API, i.e. classes such as android.content.Entity, android.net.http.DomainNameChecker, etc. As a result, I can't compile and play with this code.
So is there is a "hidden" API that the native apps use that is not available to the regular app developers? Is there a "native" SDK I can use to import these classes?
David
As with all hidden API:s these are hidden for a reason and that is that they are used by the framework or specialized applications and are not guaranteed stable or suitable for general development. It is not advisable to use non-supported API:s for your applications since they might break on future releases etc. The ones that you mention are part of the framework and used internally by the Android system.
That said, if you just want to explore Android you may build your apps as part of the platform build system and test them with your own build from the open source projects.
The article "Using internal (com.android.internal) and hidden (#hide) APIs" by user inazaruk shows you step by step a method to import hidden Android APIs.