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.
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.
I have seen that there are decompilers that works pretty well to show on fly code and resources of compiled APK.
I'm wondering if there is a way to edit and rebuild APK classes without export all sources and resources recreating a new project manually adding all libraries resources code etc. Since the APK already contains all the needed dependencies and resources configured to work together should be possible.
Often there are apps that have small bugs that would be easy to fix if only was possible edit and rebuild APK on fly
You can use Virtuous Ten Studio that allows you to import an APK edit smali code and resources and rebuild the edited version of the APK.
(You can also configure it to show Java code but since uses a "smali to Java" approach the generated code is imperfect.)
https://ibotpeaches.github.io/Apktool/
You can use Apktools to extract and compress APK-files
It is possible to manage/edit Smali files. They are similar to Java-files.
I have now switched to Android Studio and saving my projects in Git with Source Tree. Whenever I add or remove any library from my module, its .iml file also changes. It really doesn't matter if I commit the *.iml because they get auto-generated in others Android Studio. However, here
it says you should store *.iml . My question is, do we really need to share our *.iml with others? If yes, why?
General best practice is to:
make projects as IDE-agnostic as possible,
do not commit generated files.
So the answer is: it's better to make such files ignored for VCS.
Yes, .iml Files are suitable for version control (see this comment)
It is also true to make projects as IDE-agnostic as possible, however, sharing .iml files does not break anything for people developing with another IDE. For them, they are just a bunch of relatively small files that don't concern them.
A good practice for teams using different IDEs simultaneously is to store each IDE's project files in the VCS, only excluding those which contain paths, environment variables etc. specific to a single developers environment. This way, anyone using one of the supported IDEs can enjoy the benefits of a proper, shared setup, like for example:
sharing build configurations
sharing dependencies
configurations for automatic code quality checks
There are more use cases, depending on the specific IDEs in play.
Edit: For IntelliJ, also see this FAQ
I agree that they are IDE-dependant files irrelevant to code and they should not be shared. But, then you should know how to regenerate them.
You may encounter with situations while your remote repo does not contain these files and when you clone the code and open in IDEA, it just shows a bunch of errors. Why? *.iml files are not regenerated.
You must import from IDEA with "File" - "New" - "Project from Version control". Only this can generated the files for you.
Rule of thumb - "Anything thats can be generated from source code should not be checked in" .
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.
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