I'd like to be able to use TIME and DATE macros in Java, just as I would in C. However, I'm aware they don't exist. I've looked at various sites, and seen suggestions such as http://www.rgagnon.com/javadetails/java-0532.html. I understand that this could be implemented by creating a custom build.xml, but I'm reluctant to break that far from the Android tool chain.
An Eclipse Builder might have been a viable solution, but modifying files outside Eclipse seems like an unwise thing to do.
Has anyone a suggestion for accessing build date/time from within their Android application without a custom build.xml? Is it possible to use the build.properties file, an Eclipse Builder, or something else?
I would recommend using a build.properties file written by ant script registered as a project builder. As part of ant builder configuration you can specify which resources to refresh post-build, so the fact that you are writing this file external to Eclipse isn't going to be much of an issue. Make sure to configure your source control system to ignore this build.properties file.
Related
I have a native Windows library I'd like to include as part of Windows build/package in my MAUI app. Is there a way to do this where it won't be included in the builds/packages of the other platforms?
I found a way to do this with Android native libraries: I simply place them in (ProjectDir)\Resources\lib\(Architecture), where (Architecture) is, for example, 'arm64-v8a'. Then I can simply flag them in the .csproj file as an AndroidNativeLibrary and all's well; they show up in my Android build and don't appear in any of the other builds (Windows, IOS, etc.).
Things I've tried:
Manually copying the Windows native lib (a DLL) to the generated AppX folder via a postbuild script. Not ideal. For one, the AppX folder isn't technically generated until after the build is finished; it's part of a packaging step (I believe). So, this kind of works, but isn't really the proper solution. I want the DLL to automatically be included by the packager.
Adding the DLL as an item to the .csproj. This means it gets automatically included in the AppX package, but is still not ideal as it subsequently winds up in every platform's build.
The most promising: referenced the DLL via a 'file' element in (ProjectDir)\Platforms\Windows\app.manifest. However, it doesn't seem like this manifest file plays any role in the build/packaging. Rather Package.appxmanifest seems to be the file that matters. If I throw intentional typos into app.manifest, building and packaging still succeed. I also added app.manifest to the csproj explicitly via ; it doesn't seem to care.
Anyway, any ideas/insight would be much appreciated.
Ok, I found a fantastic article that solves my problem: https://learn.microsoft.com/en-us/xamarin/cross-platform/cpp/
Not sure how I didn’t find this before; I was looking forever.
As a new android developer, I just know how to import the third dependencies made by other android developers.But now ,I write a simple custom view ,including a class : enter image description here and a declare-styleable:enter image description here,for convenience for the future,I want make it to a dependency or a jar.I don't know how to do it.Thanks for your help!
A .jar is a compiled Java bitcode for the jvm. Google android Java compiles into dex and it packed into a .apk. I would be utterly shocked if you could ever use a jar file. In general android apks files contain everything needed to run the app they don't tend to depend on anything else.
You can setup intents to pass things around throughout the larger environment but in general if you need the code for several projects, just include the source to be recompiled. You might be able to directly include a .dex but it would certainly not be preferred.
I understand this might be an extremely obvious and ridiculous question to ask, but please excuse me as I'm a beginner. I want to integrate this file into my project so I can call its methods:
https://github.com/RomainPiel/Shimmer-android
The question is, what do I do with it? Is it considered a "module", "library" or "file"? Should I manually copy the source files and create new classes in my project, and then call the methods from there? This would be the most straight-forward but in the "how to use" section in that package, it was mentioned "compile 'com.romainpiel.shimmer:library:1.4.0#aar'"
What I tried:
I downloaded the file as a .zip and then File->New->Import Module then navigated to the unzipped file. I believe I'm then supposed to add "compile 'com.romainpiel.shimmer:library:1.4.0#aar'" so I went to the gradle file to try to add it.
There are two: build.gradle (Module:app) and (Project:ProjectName).
I've tried adding to either and\or both and got this error: (Error:9,0) The project 'ProjectName' may be using a version of Gradle that does not contain the method. Did I do something wrong? Is it supposed to be this easy?
I would be extremely grateful to anyone who can point me in the right direction :)
You have three option
Using the GitHub Desktop you can clone the project and open it like a local project. Every change you make will be tracked. You can then commit and push using the GitHub Desktop. It's all UI and simple to use.
https://desktop.github.com
On Android Studio, when you open it, you'll see this, select GitHub and continue by adding your credentials.
You can then commit and push directly from that.
Using the terminal / command line.
If you are new, I recommend the first. It's simple to use and you get a hang of using it as it is the same steps with any project on any IDE you use.
Note: Downloading it as zip and then using it a bad idea because you're making it difficult on yourself because you can't keep track of changes and you'll have to re-upload everything every time. Which defeats the purpose of version control
If that GitHub account is not yours, then you'll have to fork the project, this way you'll have a separate version of the code on you GitHub on which you can modify. If it is yours then you're good.
Typically, you do not want to include external source code manually. This inhibits your build tool's (i.e. Gradle's) ability to manage that source code. It's very easy in Gradle to, say, set the version (like you have done by specifying "1.4.0") and then later remind yourself what version you have by merely looking at your build.gradle file. However, how would you go about doing that with raw source code? Typically developers do NOT put the version number of the source code in the actual source code - that's what they use their version control system (e.g. git) for, usually with tags.
Another aspect of Gradle is downloading and caching (and compiling) the external project for you. So that's nice.
With that said, you typically want to put that "compile..." line in your module's build.gradle file. Not the Project's build.gradle.
A module corresponds to your application (or library) that you are building or using. Some project's have multi-module configurations, where one module acts as a dependency for another (or several others). A Project in gradle is more of a 'meta' configuration that you can apply to all of your modules. The gradle docs recommend you focus on your module's configuration first and adjust the Project's configuration only if you have a specific need and reason to do so.
For the error you mentioned, you might have some unnecessary configurations in your build.gradle file, or the tool version numbers might not reflect what's on your system - if you copied and pasted from the internet, you might want to correct this by letting your IDE generate that file (the brute-force approach would be to create a new project entirely, and use its build.gradle files as a reference). Before you do that, you might want to check if your IDE provides any warnings inside that file.
You have to add the dependency to your module's gradle file.
There are two gradle file present in an android project. One is the project gradle and the second is the module gradle for each individual module.
You just have to copy the given
compile '......' in the dependency block.
I have seen samples for Mercurial ignore files for Visual Studio, amongst others.
I've just started playing around with Android development, and I also use this time to experimenting with Mercurial. So my question is: does anyone have a good example of a .hgignore file to use for Eclipse and Android development?
For starters I've got the following myself:
# use glob syntax
syntax: glob
# Ignore patterns
.metadata\
bin\
gen\
Are there any other ignore patterns that should be included? Should for instance the Eclipse files .classpath and .project be omitted from version control as well?
-- Edit below --
I haven't quite gotten the answers I hoped for yet, so I'll put out a bounty and try to specify a bit clearer what I'm looking for.
After experimenting a bit myself, I seem to have found that the suggested .hgignore listed above seems to be sufficient. The only addition I've made, is one line with .settings (this was a folder that appeared after I ran Android Tools -> Fix Project Properties). I've also found that (as mentioned by Ry4an) that the Eclipse files .classpath and .project should not be excluded.
I am however uncertain that this small ignore file will be sufficient when I get to projects a bit bigger than the basic tutorials (if it actually is all good, please explain why, and you'll get the credit). So to summarize what I'm looking for:
I want a concrete example for a .hgignore file for an Android project under Eclipse
The ignore file should be so that whenever I check out a copy of the repository at a new location, it should work straight away (i.e. without having to mess with paths and references, add missing files etc.)
Please also explain why your include file looks like it does (I want to understand why certain files/directories are excluded (and why some definitely should be included))
If you include OS specific excludes, please also state so (I'm running on Windows 7 btw.)
The eclipse files should definitely be added. The general guideline is to add:
everything that is hand written/typed
the minimal subset of everything else necessary to build the project
That last one is where your judgement comes in. It clearly excludes the .jar files you build yourself and your final .apk, but does it include third party .jar's you use? Some people do include them, but better is to include a configuration file for a dependency manager like 'ivy' which lets the next builder download the requirements they need automatically.
After auto-creating a project in my tools of choice, I'll just do a command like this:
hg status --unknown --no-status >> .hgignore
which adds the list of all unknown files to .hgignore. Then I go in and remove things I wants saved (ex: .project) and wildcard files that will grow siblings (ex: **.class)
There's a very nice sample .hgignore for Android at http://androidfragments.blogspot.com/2011/11/hgignore-for-android.html
Here is my hgignore:
syntax: regexp
\.DS_Store
.swo
.swp
.metadata/
/bin/
Whether it's a good one or not is a separate issue
well if its android projects than
local.properties should also be ignored
I have found a good example of .hgignore. It works for me.
#Mercurial Ignore Rules for Android
#Save as .hgignore in the repository base directory and add it to source control.
syntax: glob
*.class
*.apk
*.dex
*.ap_
*.suo
syntax: regexp
^(.*[\\/])?gen[\\/].*
^(.*[\\/])?bin[\\/].*
^(.*[\\/])?obj[\\/].*
^(.*[\\/])?log[\\/].*
^(.*[\\/])?obf[\\/].*
^(.*[\\/])?jars[\\/].*
^(.*[\\/])?jar-sources[\\/].*
^(.*[\\/])?javadoc[\\/].*
^(.*[\\/])?\.svn[\\/].*
^(.*[\\/])?\.metadata[\\/].*
^(.*[\\/])?\.settings[\\/].*
Source: http://androidfragments.blogspot.ru/2011/11/hgignore-for-android.html
I'm trying to modify framework.jar. My purpose is to modify the contents of SQLiteDatabase.java inside this jar. I've googled this quite a lot, and found that the way is to edit the .smali file and repackage and pushing the updated jar to the system. But the source of .smali seems to be hard enough to edit (as it's assembly code), so I was wondering if there's any other workaround to avoid this, and edit the Java source instead and then pushing it to the device. I'd really appreciate some help, thanks.
One possible hybrid approach might be to download a version of AOSP as close to what's used on your device as possible, make the changes you want to SQLiteDatabase.java in the AOSP source, and then build a framework.jar from AOSP, disassemble it with baksmali, and then copy over the SQLiteDatabase.smali from the AOSP build to your device-specific framework.jar.
There's one other kink you should be aware of - If your device is pre-odexed/pre-oated, then you'll need to deodex the entire framework and all pre-odexed/pre-oated apps, because modifying framework.jar will invalidate any existing oat/odex file.