Android R IDs are generated by the IDE (Android Studio or Eclipse ADT).
Are they identical between builds?
If yes, will they be the same if generated on different machines?
Firstly, Android IDs are not generated by the IDE but by aapt, a command line tool which is run during a build. Yes, the IDE ultimately triggers it, but it isn't strictly part of Android Studio, it's part of the build tools package.
The numbers are essentially assigned alphabetically, so the resource IDs will be identical for the same project - but not if you modify the resource file tree. I am only prepared to guarantee that on the same file system, operating system and version of build tools. If you change any of those, all bets are off.
Ultimately, relying on this would be a really bad idea, because someone will break it by modifying the project one day, probably sooner rather than later.
I looked into this fairly extensively some years ago when I wrote an APK decompiler for the purposes of patching in resources.
Related
We've recently migrated from VS2017 to VS2019, building Xamarin Forms applications. We've had no problems with obfuscation for years and years, but now we've got a showstopper. To summarise: the project DLL inside the final APK file is the un-obfuscated version, not the obfuscated version.
If we build the Android app normally (in a Release configuration) it works fine: decompiling the file shows the obfuscated code as expected - completely unintelligible. It also successfully copies this from its working 'dfout' folder (under 'obj') to the 'bin' folder, so the build process propogates the obfuscated file as it should; everything is cool.
But...when you run 'Archive' to create an APK file...things work differently. After many hours of close examination we worked out exactly is happening, but we don't know why, and how to fix it: the project DLL (that should go inside the APK) is getting taken from the un-obfuscated code. The obfuscation then runs after the packaging has completed, leaving the correct DLLs in the 'obj' and 'bin' folders, but the one inside the packaged APK is the un-obfuscated version.
What on earth is going on here?
Found the solution to this in the comment thread of another StackOverflow question.
Basically it's an issue with Dotfuscator working with VS2019, which requires some new Dotfuscator targeting files to work. Initially these too didn't work, but after deleting all bin and obj folders and restarting VS in Admin mode did the trick.
Dotfuscator obfuscates stand alone assembly but not the APK archive
I've got an Android project built under Eclipse-Indigo that works just fine. I recently copied many of the files and rebuilt under Eclipse-Juno. The app runs if you install it and/or run it from Eclipse, but if you try to generate an APK, you get:
Conversion to Dalvik format failed: Unable to execute dex: multiple dex file define Landroid/bluetooth/IBluetooth;
Comparing the directories shows that src/android.bluetooth/IBluetooth.aidl and IBluetoothCallback.aidl are identical, but gen/android.bluetooth exists in the working version but not the broken one. Replacing these files manually makes Eclipse whine, of course, so the question is:
how do I control how Eclipse generates those particular files from the AIDL inputs?
Alternatively, if somebody has an intelligent suggestion as to how to get rid of the stupid error, I'll take that instead :-)
The answer is to NOT install the Android Development Kit, which seems to have borked libraries. Instead, install Eclipse for Java Developers, and install the Android SDK separately. This allowed the correct libraries to appear, and didn't give the stupid errors about duplicate dex files.
Is there some sort of alternative toolchain or language for Android, which can generate standalone APK files?
Ideally it should not depend on the huge and ever-changing, ever-upgraded official Android SDK.
As a parable, I am looking for a rough equivalent to how PowerBASIC and Mingw targets plain Windows just fine, despite Microsoft releasing new Visual Studios all the time.
Bonus points if this language or toolchain itself is an Android program...
As you may or may not be aware, the Android toolchain is based on a few simple ideas:
Your code is compiled using the plain old java compiler, and linked against the Android stubs (android.jar) for linkage against the system library.
After being compiled, the code is converted to dex format. You can actually run this yourself, just do a dx --help. The job of the dx tool is to take Java class files and convert them to dex code, a pretty straightforward compilation which involves going from a stack based to register based vm, and a few other changes.
After having this in place, an apk is built using a set of apk tools. It used to be apkbuilder, but this has since been deprecated. You can actually run this yourself as well. All an APK is is simply a collection of the manifest, resources, and a single file for all the code in dex form. (I.e., many .class files compile to a single .dex which is quite a bit smaller because of a wrapped web of pointers).
So the Android toolchain isn't really all that complex. The custom build process is handled by ant build rules, which are defined in an SDK wide build.xml, which you can find in the platform-tools/ directory (iirc). However, to generate new baseline projects using this custom build environment you simply use the android update project command.
While I'm not sure if this is the response you'd hoped for, I hope it will disambiguate the build process. It's not really all that complex of a toolchain, the majority of it is off the shelf Java, and not Android specific (all that makes it Android specific is library specific stubs for dynamically linked system code). Beyond this, once you have a set of classes, you need only run a few commands to make an executable APK which Android unpacks. I would suspect that any tool targeting the JVM (and capable of linking with the Android specific dynamically linked API) could perform a similar process of producing class files and using this toolchain to compile the rest of the way, though obviously the automated ant build process makes it much simpler.
EDIT:
After some more digging, I found this relevant android-developers thread. An unsettling quote:
At this time we simply don't have the resources to support people who
want to use their own build system, but we really wish we could. In
many ways we try to make it easy on other tools vendor by clearly
separating logic to eclipse or ant specific code (hence the multitude
of jar files everywhere in the tools and in ADT), but this is not one
of them.
However, you may also find this link helpful.
Terminal-IDE and AIDE are pretty much what I was looking for. Both runs on Android.
I am android developer.I am not aware of ant in android .I have downloaded a code from internet But It has file called build.xml but I am not able to find out what it is doing and for what purpose it is used please give some advise or some kind of tutorial.So I can understand its working thanks in advance.
When you are developing your application, Eclipse is the most convenient way of building the project.
However Ant is most useful when you come to produce a release version. You can set up your Ant build, such that it takes the same source files as the Eclipse project, yet produces a signed, zip-aligned version of the apk in completely separate output location.
By means of a custom build.properties file you can specify source and output locations, keystore names and locations and passwords. It also takes care of any Proguard obfuscation you may want.You can do all this from the command line with a single statement and know that you are going through a repeatable process, not vulnerable to a mouse click in the wrong place.
Have a look at Managing Projects from the Command Line and Building and Running from the Command Line
Take the build.xml from the sample project referred to and use it as a basis for your own project. It works pretty much out of the box.
This build file is an alternative (and less common) way to build your projects using ant.
Eclipse (and the Android plugins) do a n excellent job of saving you the trouble - just use the plugin to build your projects and export APKs.
Once upon a time, I avoided Eclipse for Android development. And life was good.
Along the way, I adopted a convention originally supported by the Android command-line build tools, of having a tests/ subdirectory containing the test code (e.g., MyProject/ being the home of the app, MyProject/tests/ being the home of the test suite). Android does an excellent job of allowing test code to reside in a separate-but-related project, and having it as a subdirectory kept the tests logically co-located with the project proper.
I am now switching to Eclipse, as I need to support it better for my subscribers. The only way for me to do a quality job of supporting it is to use it daily. And, since I have a quad-core with 4GB of RAM, Eclipse actually starts up in less than a minute. :-)
However, preliminary research suggests that Eclipse does not support sub-projects (i.e., one Eclipse project having another Eclipse project in a subdirectory).
So, my questions are:
Am I correct in this assessment, and if I'm wrong, are there any particular steps I should take to ensure that Eclipse is happy? I find that Eclipse can sometimes get a wee bit cranky...
How are Android developers organizing test projects relative to the project being tested? Peer directories (e.g., MyProject/ for the app, MyProjectTests/ for the tests)? Peer subdirectories under some targeted common top (e.g., MyProject/app/ for the Android app, MyProject/tests/ for the test suite?)? Something else?
BTW, I'm running Eclipse 3.5.2, if that matters.
Thanks!
I've been creating test projects with Eclipse 3.6.2 inside my main project just like you describe for command line tools (MyProject and MyProject/test are Android projects that both contain a src folder). You can create this test project using the New Android Test Project by deselecting "Default Location" and setting the path.
None of my projects are very large, but the only problem I've had so far is that you cannot use the MyProject/test folder under the MyProject project. To be able to right click and run as a test case, you have to access files directly from the MyProjectTest project. To prevent you from having problems, you can add a Resource Filter to hide the test folder in Project Properties > Resource > Resource Filters.
However, preliminary research suggests that Eclipse does not support sub-projects (i.e., one Eclipse project having another Eclipse project in a subdirectory).
What problems have you seen?
Depends on your toolset:
ADT >= v12 currently has flaky support for "a project within a project":
Creating an Android Test project in Eclipse
I have tried separate testproject, and separate test directory, but afaik "a project within a project" approach seems to be the way of the future.
This is becuase AndroidManifest.xml merging into the test project AndroidManifest.xml, is in the pipeline for the next ADT releases.