I am writing an SDK to be used in other applications, to enable them to use our service. Obviously, I am writing a library for that.
Note that user here means user of SDK.
The questions:
I need to have an activity in my library. Do users have to declare my activity in their application to use it? Can I have activity defined in the manifest of my library, export library as aar? Does this work?
My library needs some permissions, like to check if internet is available or not. Like the above issue, can I have my permissions defined in manifest of my library?
aar or jar? What is the difference, beside the things mentioned in Google docs. Any support issues with aar, idk like lower API versions not supporting it or other IDEs (Eclipse? Still used?) not supporting it? I mean some practical issues with aar, if there is any.
I'm also open to any documentation or any link to help me.
I have developed for Android in the past, last time was when Android Studio was just released in alpha. It seems like a new world now :)
I need to have an activity in my library. Do users have to declare my activity in their application to use it? Can I have activity defined in the manifest of my library, export library as aar? Does this work?
Users don't need to declare library activities in app manifest. It will work. But don't forget to declare theme inside your library style file and apply on your activities(Activities which are in library).
My library needs some permissions, like to check if internet is available or not. Like the above issue, can I have my permissions defined in manifest of my library?
All permissions which you need inside library module you can mention it inside library manifest. But you have to take care of asking risky permissions. Let say if your library need WRITE_EXTERNAL_STORAGE permission so whenever you are going to call library activity you need to ask such permission at run time. You will get more here
aar or jar? If you are going for pure android then go for aar. You will get more discussion on here
aar or jar?
both:
jar (standard non-android-library) with android independant code (java-interfaces, java-datastructures, datatransportation via webservice, businesslogic, ......).
benefit: the jar can be junit-tested without android on a desktop pc
benefit: the jar can be reused in java desktop apps.
aar (android specific library) gets the android specific data/code (manifest with requested-internet-permissions, activity with resources, code for requesting android permissions, android-sqlite-database).
the aar has dependencies to the jar
I successfully use this seperation in my android projects ToGoZip and APhotoManager
Related
Hello I would like to use some function from com.android.dialer.telecom.TelecomUtil inside some java class from an android I'm building but I don't know what dependency I should add to build.graddle to do so
Anyone familiar with this ?
TIA
I don't know what dependency I should add to build.graddle to do so
Assuming that you mean this edition of TelecomUtil, that is not in a library. It is a Java class in the Dialer app from the AOSP.
If you are writing your own AOSP app, such as a custom dialer as part of custom firmware, you can copy TelecomUtil.java into your own project, along with other Dialer app classes that TelecomUtil depends upon (e.g., com.android.dialer.common.LogUtil). Or, copy just the method(s) from TelecomUtil that you need.
If you are writing an ordinary Android SDK app, you can try doing the same thing. You may run into places where the copied code depends upon classes or methods are are not part of the Android SDK, though.
I'm developing an Android library which provides ways to reach into various system services and gather data for analysis. My classes make use of various system service managers (like WifiManager) to gather the data.
I'd like to structure the manifest of my library such that it doesn't grab all the possible permissions that all of these features require. Instead, I'd like to leave it up to the app consuming that library to declare only the permissions that it will need, which might be a smaller subset of what's used by the library.
This actually works in practice, because the manifests all get merged together during the build process, so the app ends up with the permissions it needs to use the features of the library. However, since the <uses-permission> tag isn't in the library's manifest, the code is all lit up with warnings from Android Studio.
Is there a way to annotate my library code such that the permission check is ignored?
Of course I can simply turn off the "Constant and Resource Type Mismatches" inspection in my Android Studio settings, but that won't help anyone else who's trying to use the library. I tried finding a reference to this inspection in the documentation (so I could kill it with #SuppressWarnings but haven't found it yet.
Is this even a worthwhile approach?
…or should I, instead, have the library grab all the permissions it needs, which would force a consumer of the library to turn off the ones it doesn't need using the tools:node="remove" property in its manifest? The problem here is that, as I add features to my library, my library's consumers would repeatedly have to circle back and explicitly remove those new permissions as well. I feel like that's not a great model and I'd rather leave the permission requests to my consumers.
Consider the following conversations on the subject —
Android: New permissions added behind my back after library updates (StackOverflow)
Hey, Where Did These Permissions Come From? (CommonsBlog)
In just randomly right-clicking around the issue I was able to choose the Suppress for method context command in Android Studio and it added the following annotation:
#SuppressWarnings( "ResourceType" )
So… yay! There's the answer to which annotation to use.
I'm still interested, though, in what people's thoughts are regarding the approach in general. Please feel free to hash that out in the answers section. ^_^
I want to use a library in my project? But I do not want this lib to have permission to access files, database or download something from network in my app. How can I achieve my aim ?
The library is provide by others, I need use some function in it, but i do not want it has permission to hack my app. Maybe i need something like sandbox to run this lib, but I do not know how to achieve this?
In your library projects, you can remove the permissions from manifest.
In terms of jar lib, there is no problem. Because jar libraries are going to use the app permissions only.
I have a Xamarin Android application I've been trying to create an update for. Right when everything was hooked up and working, and I finally made the release APK, I get a message from Google Play that the uploaded APK now requires two extra permissions. For reading and writing to external storage! I don't need these permissions in my application at all. I tried looking at my project's Android Manifest, and saw no such permissions listed there. Older versions of my application (using older versions of Xamarin Android) did not require these permissions. Why would Xamarin suddenly be injecting permissions I didn't specify?
I can confirm that this is the case with any application. I just created a new android app with it, and it requires external read/write permissions, with no apparent way to disable that requirement
Look in AssemblyInfo.cs, default template has this on the bottom of it:
[assembly: UsesPermission(Android.Manifest.Permission.Internet)]
[assembly: UsesPermission(Android.Manifest.Permission.WriteExternalStorage)]
Permissions can be set either through the AndroidManifest.xml file or through AssemblyInfo.cs. Delete those lines, and the permissions should not be set anymore.
Permissions from packages/components
Now that Xamarin Components and Xamarin-friendly NuGet packages are everywhere, it is worth noting that permissions can now be brought in by way of AssemblyInfo.cs from those references as well.
Since some libraries would be useless without certain permissions, this can make sense to avoid issues. However, if they aren't needed all the time, you can be introducing permissions you don't actually want simply by referencing a new package or component.
For optional permissions baked into the NuGet package, you may need to compile your own library without them to avoid the extra permission overhead. I haven't found a great way to easily identify these in packages where the source code isn't freely available. ILSpy didn't seem to output the AssemblyInfo.cs attributes.
Unfortunately, in old Xamarin.Android project templates, these permissions were added by default with a message that you could remove them if you didn't need them.
// Add some common permissions, these can be removed if not needed
[assembly: UsesPermission(Android.Manifest.Permission.Internet)]
[assembly: UsesPermission(Android.Manifest.Permission.WriteExternalStorage)]
Since they are such common permissions, most authors and consumers of the library wouldn't notice (as may have happened here in the Settings library from Xam.PCL.Plugins).
Since it's popular to have both a free and a paid version in the android market of the same app, I had decided to do the same. Initially I just duplicated the complete codebase and adapted some code here and there (added ads, built in some limitations etc) since there was no option to do library projects at that time, but that left me with two projects that are horrific to manage fixes to bugs as I need to do those twice.
Since r14 we can use library projects with resources, so that would be a great solution to this particular problem as far as I can tell. Therefore I've read up on library projects and conciderations, and I'm curious to know what the minimum amount of files needed in the projects of the different versions are. My questions therefore are;
Could I have all of the code in the shared project, and have bare bone project with basically just a manifest?
If so, should I? is this the optimal way conceptually? (so apart from the fact that it depends on my code base)
How should I deal with library package naming, are there specific rules?
Are there tools about that can compare code from two different projects and perhaps merge them auto-magically or auto-manually, and which one is preferred?
If I understand your problem correctly, you want to create multiple Android apps that are similar to one another (i.e., have a lot of the same source code), but which are different in particular (minor) ways, and you want each of these apps to have a distinct package, so that it can be separately uploaded and distributed on an app store such as Google Play. A Project Library is an excellent facility for accomplishing those goals.
I'm assuming that the differences between your various versions are minor, involving things like resources and the app name and package, and a switch that turns on certain features for a paid version while leaving them off for a free version.
Even if that is not the case, by using polymorphism in the ways described below, your various apps could differ in significant ways and still share a common Project Library.
A Project Library can be defined in Eclipse in the same way as any Android project can be defined, but it is marked as a Project Library (by checking the "Is Library" box near the bottom of the Android page of the library's Project Properties dialog) and cannot be compiled and run on its own. Instead, it is intended to be included by reference in one or more other projects which are actual apps (by adding a reference to it on the Android page of each such app's Project Properties dialog). These apps will use the Project Library, and thus will share its code and capabilities.
Each such referencing app will have its own manifest file (where their respective, different packages can be declared), and they can also define their own classes (including classes derived from the Activity and/or Application classes of the Project Library), so that these classes can be specialized polymorphically for each app that uses the Project Library (e.g., by overriding methods or by providing definitions for methods that are defined as abstract within the Project Library's Activity- or Application-derived classes), although you can also use those Library classes without modification (provided that they are not abstract) by simply referencing them within the manifest file (e.g., in an activity or application tag) of each app that uses the Library, just as you would reference Activity or Application-derived classes defined within the app itself.
If you decided to use this approach, then you would put your main source files in a Project Library, and would create a separate project for each app you want to produce, each of which would reference the Project Library. The manifest file of the Project Library would be overridden by the manifest of whatever project is being created using that Library (actually, I think that the Project Library's own manifest is completely ignored, not just overridden, but nonetheless it is useful to create a manifest for the Library, so that you can manually template - copy and edit - the manifest of each project that uses it from the Library's own manifest).
I have used this approach to create multiple android apps that share some of the same capabilities, and it has worked very well for me.
Regarding package naming, any old package name will work for a library project, but of course it makes sense to use the same prefix for the Library Project's package as you use for your various individual (e.g., free vs. paid) apps that use it, with something like ".library" as the last part of the name, while the various apps could have endings like ".myappfree" and ".myapppaid". Naturally, you would want to use your reverse domain name convention for the library's package prefix to prevent conflicts, just as you would for a package name of a released app.
In Windows, a nice, open-source tool for comparing code bases is WinMerge:
http://winmerge.org/
If I were in your position, however, I would only use this tool to manually identify differences, and would not attempt to use it to automate the refactoring of your code into a Library Project. That would be best done under your own (manual) control.
Finally, as an alternative, you might consider using a single app that is free and that has your free app's capabilities by default, with an option to upgrade to your full app's capabilities (delivered within the same APK) via an in-app payment, rather than having separate free and paid apps. In-app payments have improved a great deal in the past several months (with the release of version 3 of IAB), and although there are still some glitches, they have become a more practical alternative to the free/full dichotomy than they were at first.
Yes, you can have a project that is basically just a manifest specifying app name, name space, icon etc, with all the actual code and 99% of the resources in the library project.
Yes, I think you should use this approach. It's very common to use library projects to deal with the Free/Paid app problem.
I've not had any problems with naming, though you should be careful with any resources in separate projects to avoid using the same names.
I'm not aware of any tools, and if it were me I'd want to do it manually to be sure I'm merging what needs merging and keeping separate what needs to be separate. you've one significant refactor to do, but once all the duplication is removed I'm sure it'll be much easier.