In my new Android app, I'm required to use a library when Android Version in 1.6 and 1.5 and include some other library when the version is more than 1.6.
I know how to get the Android SDK version, but I'm stuck at inclusion of specific library at run time.
Any Help ??
Libraries are included in your APK file. As such you cannot remove libraries from the APK at runtime.
As far as loading classes at runtime is concerned, you can always do that, but the content of the APK (the JARs / classes you include in them is static). You are offcourse free to load particular classes from it based on the API level.
If you're worried about the file-size of your APK, and you want to optimize the APK packaging and tweak your app based on the capabilities of the device of the consumer of your app, you should checkout this link :
http://android-developers.blogspot.com/2011/07/multiple-apk-support-in-android-market.html
It allows you to target different APKs based on device capabilities (ex: API level). That way, you can create 2 APKs with the specific libraries you want to use for a specific API level.
Related
Recent changes in android architecture have enforced all developers to make their android applications support 64bit.
I have gone through the documentations. But as it shows there to look for a "lib" folder that may supposedly have ".so" files.
I tried the same thing, but apparently I can't find and "lib" folder to begin with!
I have also attached a snippet of my apk-analyzer as shown in the image link https://imgur.com/a/L7qtLGc
Can anyone suggest me what can be done or how can I ensure my apps are 64bit supported.
Reference : Steps to find the apk needs to generate for 64 bit
Just Generate a Apk and Use
Build->Analyse Apk
to open the Apk.
In that Under lib folder check for these below files:
lib/arm64-v8a
lib/x86_64
If they are available them the application supports 64 bit.
For more refer this URL 64Bit
From Get your apps ready for the 64-bit requirement:
Blockquote Inspect your APK or app bundle for native code. You can check for .so files using APK Analyzer. Identify whether they are built from your own code or are imported by an SDK or library that you are using. If you do not have any .so files in your APK, you are already 64-bit compliant.
As Vladyslav Matviienko has pointed out, if you're not using native libraries, you won't see any .so file (nor lib folder) in your APK analysis, so your app is 64bit compliant.
Using platform channels, Flutter can interop with the native platform (i.e. reading battery level). On Android, this would require calling a Java method.
I'd like to use a third-party Java SDK (for AWS Cognito). Can I put this library somewhere in my /android, and interact with it? If so, how can I do that?
Yes you can.
You can see the documentation on that or if you want you can see
tutorial. It is helpful if you are using SDK that gives you
native code for both Android and iOS, otherwise it will be difficult.
Good luck!
If you haven't already got a plugin project started, create one.
Gather the third party jars somewhere - don't put them in the pluginproject/android/... folder.
Open the plugin project in your IDE - in my case IDEA - and add the third party jars to the Java classpath. (In IDEA, click Project Structure / Modules / select pluginName_android / Dependencies tab / green PlusSign / jars or directories - and select the individual jars or the whole folder. Leave the scope as compile and don't check export.)
Implement your android-specific code in Java (or Kotlin) in pluginproject/android/src/main/java/com/yourcompany.../.../PluginnamePlugin.java, where you will now be able to use the classes declared by the third party jars.
Add the dependencies to gradle so that it will compile. In pluginproject/android/build.gradle (NOTE - there are several build.gradles) add this at the end - after the android {} section
dependencies {
implementation files('../../../java/someapi/somejar.jar')
}
The path must be relative to the pluginproject/android folder. You can specify a whole folder with this syntax instead
implementation fileTree(dir: '../../../somewhere/somefolder', include: ['*.jar'])
Run the example application provided in the plugin project.
I'm not sure why it's not possible to put the third party jars in, say, pluginproject/android/lib, but that causes a dex error for me, whereas, leaving them outside of the pluginproject/ folder works.
I've only ever used well-behaved third party jars (no JNI, don't create their own Threads, etc).
The Android side of flutter uses Gradle (the same as any other android project). If you have an existing android app, you can probably port over most of the same settings from your gradle files.
Unless you've already done that and have a system for managing the jars, I would not recommend copying the jar files directly into your project & therefore source control.
Instead, use gradle's build-in dependency resolution. You should be able to follow Amazon's android sdk set-up directions. The difference is that you'll have to hook up the calls to the SDK through method channels and write your own interop code.
I'm using a library (https://github.com/PhilJay/MPAndroidChart) for plotting data in an android app. When app-release.apk is created by the program it is ready to be installed on the tablet I use for testing.
What is puzzling to me is how the parts of the library, which i use, follow with the release. In other scenarios, for example in Visual Studio and c# - program being installed on Window machine, libraries require dll files to be installed and registered on each targeted machine. In my scenario the library is written specifically for Android, but if I somehow managed to include a c++ or a c# library in my Android app using tools like libstdc++ or MONO, would it work the same way when it comes down to app-realease.apk?
Are all classes in a library included in the app-release.apk or just the parts that I use?
Thanks in advance and please let me know if the question is unclear before downvoting it!
Normally, when you build your APK, all the libs you have imported (jars) are included and transformed to dex files, as the rest of your code. So, yes all the classes are included, even if you don't use them.
You can use Proguard to remove them from the APK. Look at this post :
Use Proguard for stripping unused Support lib classes
Right now I'm trying to get Java3D to work with JDK 1.8.0 in Eclipse on OS X. I've tried following this tutorial (among many others) and am finding varying levels of no success. I believe part of the problem is that there are currently 3 separate locations with the Java3D .jars are ending up on the build path:
/Library/Java/Extensions/ as a part of the JRE system library
/System/Library/Java/Extensions/ as a part of the JRE system library
My personal libraries folder as external included .jar files
Earlier in project development, I hadn't updated the files in the Library folders (they were whatever came with the Mac), and in that case there were no Eclipse errors, but the project could not be run (UnsatisfiedLinkError: no j3dcore-ogl in java.library.path)
Now that I've updated both of the JRE system library .jar files, the code has errors: Access restriction: The type '...' is not API (restriction on required library '/Library/Java/Extensions/j3dcore.jar')
What's the proper way to clean up all these locations so that the project only references one set of these .jars, and where should these .jar's be?
There is only one way to clean up: uninstall all those obsolete versions of Java3D provided by Apple ("whatever came with the Mac") and follow my instructions.
The extension mechanism has been removed from Java 1.9, relying on it is a very bad idea. Only use a carefully chosen "personal libraries folder" whose scope affects only your application and not the rest of the operating system.
If you need some help on Java3D, rather use its official forum.
I've been reading up on PhoneGap and really like it. I'd like to see if I can use it with GWT to write Java apps that deploy to many different platforms (web, mobile web, android, iphone, winphone, etc.).
It looks like the PhoneGap SDK comes with different versions of cordova.js for each native platform you want to support. So it looks like the Ant build will have to somehow package the GWT-generated JavaScript to the correct version of cordova.js:
3098DJU39I4F9IF9.html + cordova-android.js
3098DJU39I4F9IF9.html + cordova-iphone.js
3098DJU39I4F9IF9.html + cordova-windows-phone.js
I'm generalizing here, and I know those aren't the correct file names (although, obviously, 3098DJU39I4F9IF9.html is the GWT-generated code).
But then something has to kick-off PhoneGap's ability to take each of those pairings and produce the correct packaged container: an APK, IPA or XAP for each platform respectively.
So I first ask: how does a PhoneGap developer normally go from 3098DJU39I4F9IF9.html + cordova-android.js to having a myapp-android.apk, or from 3098DJU39I4F9IF9.html + cordova-iphone.js to having a myapp-iphone.ipa? Does the PhoneGap SDK have a command-line tool that does this?
Once I understand that much, I'm trying to figure out how to automate this packaging/binding process from an Ant build. Are there any known Ant tasks that already do this? Or do I need to kick off a shell from inside Ant and just run the shell commands? Thanks in advance!
#rooftop is right, you have to build the native app using native SDK even if you are using Phonegap. The benefit lies in creating the UI and behavior of the app using HTML5, CSS and JS.
So, if you are not using any of the native functionality or custom Phonegap plugins, you can just have a bare minimum package structure of native apps for each of the platforms and then simply move the correct files into the concerned folders (in Android it is assets folder) of those package structures using copy task of ant. Thereafter, you can use command line compile and build tools specific to each platform to build and package the app.
Hope this helps.
EDIT: Added more details about other platforms
Basically, all SDKs contains command line tools. In fact I used to compile and build from command line, to automate the process, even for standard Windows apps (Console, Web Apps etc) which are usually performed via Visual Studio's easy to use environment. You can see this for extended tools over standard SDK for Windows phone development.
Similarly iOS is based on UNIX so there we get the power of majority of command line tools for compile, build and automation and XCode provides command line tools for building.
Further for Android, you may find this helpful.
You should really be using Cordova, the renamed version of PG that is an Apache project now. Command line tools were recently released for Cordova. I have not used them so I am not sure if they will help you with building or not. Typically the way you woul create the binary for the device, say an IPA file for iOS would be to actually use Xcode and the native SDK to compile and package your app. This means you need all of the native tools and SDK for each platform. There is also a hosted service from Adobe that will build the native bits for you for a fee. It used to be called phone gap build, not sure if that is still the name. You might want to look at IBM Worklight, as it does many if the things you asked about. The developer edition is free an Eclipse based for the IDE.