Background: I have an android application that has been published in GooglePlay and I want to create SDK from that existing application so that others can use it as a library inside their apps.
So far: I was able to generate .ARR file from the existing app source code with little tweaks. and it is working pretty good.
The problem: is I have some sensitive information stored inside my app
since I made .arr file from my app codebase I'm little worried that they can easily get access to my SharedPreferenceManager (util class of mine to deal with SharedPreference) DataBaseManager so on and they can subclass library class and tweak the behaviors
So How can I avoid library users not to misuse my library to exploit my existing app?
is there any other way to export my app as a library?
The basic process would be as follows:
Figure out what you want to expose in your SDK
Move all of this into an android library module
Deploy the AAR
Can you explain a little more what you mean by "I'm little worried that they can easily get access to my SharedPreferenceManager (util class of mine to deal with SharedPreference) DataBaseManager so on and they can subclass library class and tweak the behaviors" ?
You can always utilize obfuscation techniques and finalize classes to make it difficult. I don't think you can guarantee absolutely no misuse, but I am not sure how this would effect your application. If you have a server, for instance, then you would still control the software there and be able to sanitize and sort through the input.
Related
I searched a little about this here but didn't found anything that helps me, maybe because it's impossible but I need confirmation.
The situation is the following:
I have an android app that integrate with many mobile POS, these card machines, and because I have many classes to integrate with these machines, the app became heavy for some POS stores, like Stone.
I saw that it's possible to impplement the libs modules and dependencies for specific flavors with android, so I would generate an specific appp, with just the classes that this integration use and nothing more, but I have everything together now, just like in the pics.
And when I build an app that will be used with Stone, for example, it will put all integrations in the JS interface.
I stated changing it, imlementing by flavor but as the implementation is per integration now, the Cielo class starts having problems with its dependencies because, as the app will be for Stone, it doesn't download the Cielo dependencies. The generation process crash.
When I started changing the structure, I manage to make the gradle build work, but after that, everything crashes.
There is something I can do ? Maybe impost only when the Cielo package really exists, or something like that.
If its needed to change the entire structure, it's ok, I just need to make it smaller but still in one place.
Thanks!
I tried useing flavors and separating the source sets alongside main directory, like:
-main
--assets
--java
-cielo
--java
-stone
bus it still have a problem when building because the import inside my main class.
You can split your application to multiple parts:
Main application which implements the app's features except an integration.
Android service API which defines API between the main application and an integration service
Integration services one for every platform. Each service have to implement API from point 2 to provide required contracts to the main application.
Finally you can deploy the main app and only one required integration service.
I'd like to allow specific third party developers to write plugins for my app without them accessing my app's main source code. And without me accessing their plugin code.
These plugins would extend specific classes, which the main app would scan for, register, and execute dynamically. I have this part working in a project with dynamic feature modules (DFM's), however so far these are all signed by the same cert and built together, by me.
However, the ask is that we each don't see each other's code. I believe you can only execute code in another package which was signed by the same cert.. so herein lies the issue.
I can definitely expose some code for them (the abstract classes / interfaces they'd be extending), but don't want to expose much more than that.
I'm thinking along the lines of a public api module + a private app module, but need help filling in the details as to who builds what with who's certificate. Any good ways to get this done?
Thanks..
I have an existing Android App that we now want to leverage as an SDK (or whatever is the equivalent on Android, a library?), so that the application could be included in another Android App as a library.
The concept is that we provide a "wrapper" class that customers make calls to, which would then interface with the existing code to do the functions, display stuff and do the work our App generally does.
My hope is to be able to not have to move code around and just create a wrapper/SDK/Library interface which I can just build differently in gradle, and the result of that (a Library object?) would be given to the customer to include into their App.
Hope I am making sense. If you need more info I can give a high level example of what the App is doing.
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
So... I'm trying to create a plugin for one of my apps. This plugin would require several views, images, an activity and a parser for CharSequences... Ideally, this plugin would be downloadable from the Android Market.
I understand how to create a library, but that would need to be included in the application.
I understand how to create an app as a service and just call it via intents, but I need direct access to objects and code that is neither parceable nor serializable.
What I have been looking at is eyes-free TTS. With their implementation, the developer includes a small TTS_library_stub.jar file in their app, which looks like it defines a lot of the necessary classes/objects.
So my question is, how would I go about building something like this and generating this "stub" .jar file, which would be included in my app? I've been trying to work my way through the TTS code, but it's a massive codebase, and I'm having trouble finding what I'm looking for.
Any help would be massively appreciated :)
The service and the app need to have the same sharedUserId in the manifest and be signed with the same key. Then the app and service can share eachothers assests, classloader and even run on the same thread. I have never included part of the GUI in a service, so maybe that is a limitation...not sure.
If there is a limitation, you must be able to work around it. Look at OpenIntents. It is open source, it is a service and you can download that from the Market. It provides a GUI file browser to any app that uses its intents.
Didn't full understand what you needed, but thought this might help.
If you want android library to be downloaded from market, It has to be standalone android application. (not android library project!). Then you can upload it to market, download it to phone and communicate with it via intent(which this library can handle) or service(aidl) or provider(the data from library) and perhaps receiver, but I never used it in that way.
If you would design your app for an OSGi environment like apache felix it might be possible to load libraries at runtime.
In their presentation they described how the whole concept is working.
Since only APKs can be shared in the android market you would need to write your own "update mechanism" which downloads your OSGi bundles (your plugins) and deploys them to felix.