I use construct 2 to build my apps and then I export them to CocoonJS which then compiles them as a native app. I download an unsigned .apk file, sign it then upload it Google Play. The apps work great, just like they were natively written.
When I compile my app with CocoonJS it requires all of these permissions that my app doesn't need. How can I remove the unneeded permissions?
Until Ludei implement an optional permissions on their cloud compiler, we have to do a bit of "hacking" to fix the problem ourselves.
Get the attached apktool.zip, extract it to a folder C:\Android (to make it easier later).
https://static3.scirra.net/uploads/articles/1071/apktool.zip
Copy your release CJS compiled game.apk (from herein, referring to that APK file as game.apk) into C:\Android so its in the same folder as the extracted apktool files.
Open command prompt in C:\Android by right clicking somewhere in that folder while holding SHIFT key.
First, we need to install the framework of our CJS compiled game.apk, type this in:
apktool if game.apk
Its instant, with a feedback that it installed in location 127 or thereabouts. Now we have to decompile the APK, type this in:
apktool d game.apk game
It take awhile depending the size of your game & speed of your PC, but all the contents of your game.apk will be decompiled and stored in a subfolder with the same name as your game.apk, ie. game. Note, if you use different versions of apktool, you may need to change the flag to: apktool d game.apk -o game so it decompiles properly.
Browse the new game subfolder, you will see all the contents. What we are after is the AndroidManifest.xml, open it with Notepad++
Hi-res version: halfgeekstudios.files.wordpress.com/2014/07/androidmanifest.jpg
Remove the permissions by deleting the grey highlighted lines!
The permissions ACCESS_NETWORK_STATE & INTERNET are required, if you remove it, your game is likely to crash on startup. This is true even if you have no Ads or IAPs or Social plugins. CJS needs these since its got some built in analytics that require it. BILLING is also required if you implement IAPs. Interestingly, Google has decided that these three aforementioned permissions will now be considered normal and they do not warn users when games have these three only, only if it contains the other permissions!
Here, I'd like to point out this line:
You can edit your game to be on phones or tablets by setting them to false. If you set smallScreens & normalScreens ="false", the game is only compatible with tablets or vice versa (I've tested this with my own games). This is handy if you design your target to tablets and don't want to manually filter over 6,400 devices, one at a time. :D
Once the changes are done, save it. Go back to the command prompt, type this in to recompile it into a new APK:
apktool b game game_new.apk
Takes awhile, but you will get your game_new.apk that is modified. Now you need to proceed with normal signing and zip aligning prior to uploading to Google Play.
https://www.scirra.com/tutorials/1071/removing-permissions-from-cocoonjs-compiled-apk
You cannot remove it. Try other tools like Phonegap. phonegap
Related
Eager to retire our app's aging OBB Expansion Pack system and replace it with the shiny new Play Asset Delivery (PAD, formerly known as Dynamic Asset Delivery), I've been following the documentation. But I'm stumped as to what to do next. How do I get to a place where I can hit Debug and find the assets ready to go, like in the old days when my OBB was waiting in the phone at /storage/emulated/0/Android/obb/?
TLDR: My answer is below, but I would love it if there was a way to achieve speedy debugging with an install-time asset pack. The current workflow described in my answer requires 1) a wait of about 5-10 minutes to build the bundle, 2) build an APKS blob, then 3) install it from the splits.
Below is a record of my journey to understanding how to work with a ready-upon-install asset pack. I'm hoping that my account of my efforts will land some search hits from other confused developers and light their way.
HOW IT ALL STARTED
My goal: to achieve a situation as seamless as back when I would punch the Debug button in Android Studio, knowing the expansion back was snugly installed in the appropriate directory, to serve pictures and sounds to our app. Here I hoped to hit Debug and similarly find the pictures and sounds ready to use, but instead right at home in my Asset Manager.
In the tradition of the Expansion Pack docs, the PAD docs made --local-testing sound like a breeze. But then the trouble began.
So I first set up the very alpha v0.15 bundletool in hopes of experiencing "quick, iterative cycles" that would avoid having to upload to Play Store during development. So far so good! I used the --local-testing flag to generate a collection of APKs.
The confusion set in when I connected my device and ran the "bundletool install-apk" command. Bundletool says little, and didn't have much in the way of a -help screen. But it spat out these files:
ADB >> OK
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-xxhdpi.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-master_2.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-de.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-fr.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-nb.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-sv.apk"
Pushed "/sdcard/Android/data/com.myapp/files/local_testing/base-arm64_v8a_2.apk"
I thought one of them might be the name of my asset pack, "my_asset_pack.apk" or something like that. But none was.
So I was curious as to which of these files contains the assets I broke out into the asset pack separate from my base app assets. I recognized the localization strings ("de", "fr", etc.). But what about my non-localized media? (Could they be in base-master_2.apk?)
Was there more I needed to do to make these assets show up? So far my ready-upon-install assets didn't seem to be available from the Asset Manager on boot, so I must be missing a step.
EDIT: Updated to reflect name change from DAD to PAD.
I don't know how it is in Android Studio but in Intellij IDEA you need to change "Deploy" option from "Default APK" to "APK from app bundle" in edit configuration window. With this option changed I was able to debug my app using app bundle without problems.
OK, so the big picture is that our command line is going to do the work that the Play Store would normally perform when receiving our bundle, churning it through the mill and publishing it in APK format. The bundle spits out a blob of split .APKs which are then, in turn, used to perform installation on our device.
INSTALLING YOUR DEBUG BUILD WITH ON INSTALL ASSET PACK
In AS, go to "Generate Signed Bundle -> Android App Bundle."
Build a debug build with your credentials.
With Bundletool 1.0 or higher:
bundletool build-apks --bundle=./app-debug.aab --output=./my_app.apks --ks <path to my keystore.jks> --ks-key-alias=<keystorealias> --local-testing
Use our .apks blob for app installation:
bundletool install-apks --apks=./my_app.apks
Tap your newly installed app
Run -> Attach Debugger To Android Process.
Enjoy the presence of your assets right there in your AssetManager.
But have we achieved "quick, iterative cycles?" Eh, sort of. Takes maybe 10 silent minutes to build that blob on my Dell XPS under WSL. Maybe it's time to take out the checkbook for that 64-core Ryzen Threadripper.
DEBUGGING YOUR FRESHLY-INSTALLED DEBUG BUILD WITH ASSET PACK
Here's what works for me. Before building the bundle, I temporarily copy all the asset pack assets from </my_asset_pack_dir> into the normal base assets directory, /app/src/main/assets/. That way I can verify that the app can reach them through AssetManager. Then these temporary files could be ignored during build, or deleted by a script.
This way the assets can be tested without the 10 minute wait for .AAB -> .APKS -> split install.
I'm trying to modify the Androidmanifest.xml for the browser on my device so that I can execute an app by loading a URI in the browser.
I've been running around the file system in ADB SHELL all day, but can't seem to find it. Plus there is no FIND, nor LOCATE command on the system.
You can theoretically find the Androidmanifest.xml file in the APK.
Every APK contains the compiled source code of the application. There is no useable decompiler for APKs at the moment so it is not possible to change the content of one.
In addition to the compiled code and the other resources of the application, an APK also contains a signature from the developer, which will become invalid when the content is changed to verify the source of an APK. An Android system won't install an APK with an invalid signature, so even if you could change the content of the APK, you still couldn't use it.
The conclusion: You cannot do what you are trying to do.
Android Studio on Windows 10/11, it’s in: app/src/main.
I'm creating a software that will guide the user through a few steps, to publish an android application (APK file).
The way I am doing this, is that the APK file is already compiled, and all I need to do is replace an XML file in the package, and that will change the behaviour of the application. My big problem now, is that unpacking the apk file, and doing any tiny text edit, and then packing it again, breaks the signature and prevents the application from running on any device, giving a message that the signature is incorrect.
How can I solve this? I want to safely open the APK, write something in a text file, and close it again. Note that this operation will be done on the user's computer (after he purchases our application) so we're look for a command-line tool with no special requirements like JDK.
Any help?
Ok I reached the best "tested" solution - I'm posting it here to save other developers hours of googling. The only downside is that I will require the customer to install JDK on his machine, unfortunately. The reason is because I did not find any apk-signing tool that works purely on windows, without relying on JDK.
I have my android application created using Air, so this makes things easy for me - all of the air files are treated as resource assets. So have your APK archive file ready.
Once you have your modifications ready, put them inside a temporary folder named "assets". You will use the 7-zip command line tool (free: http://sourceforge.net/projects/sevenzip/) to update the contents of your apk. To have it working with your apk you will have to rename your apk's extension to zip - don't worry, you'll change it back later.
Now from a .bat file (or directly in the command prompt) from the location containing both your apk file (zip extensioned) and your assets folder, you'll call: 7za u APK-file.zip assets
Now your apk file is updated. Rename it back to .apk extension
Now you'll use the signAPK tool from here https://code.google.com/p/signapk/ and note that this is the only step requiring JDK installed. It also assumes that you have your key files ready (replace the dummy ones included in the package). Extract the file contents and call: java -jar signapk.jar key.x509.pem key.pk8 [android_app].apk [signed_android_app].apk
At the very end, you may find your signed apk file size drammatically increased. So you need to use the android's zipAlign tool: (darn, can't post the link since new users can only post a maximum of two hyperlinks)
you will be calling the command: zipAlign -c 4 [signed_android_app].apk
And voila! That's the route I'm taking.
If someone finds a way to do the signing process without relying on JDK (assuming the key files are ready) please share.
How can I solve this?
You don't. If you modify an APK file, by any means, it must be re-signed.
Android apk files must be signed. That signature proves that the contents of the apk have NOT BEEN MODIFIED from what was initially published. (Which is exactly what you are doing.) The signature at the same time, also proves who the author is.
So in a normal signed apk file:
You know who the author is. (Even if it's not something you as a human can understand.)
You know the contents were put there by the author, and not modified since.
This is a key security measure built into Android, is there for very good reason, and cannot be overcome. It prevents things like viruses from being embedded inside innocent apk files.
I am working on an automatic app updating solution for devices (LG p509 - Optimus 1) which we deploy to our customers. We have control of these devices and currently install a custom kernel on them (but not a full custom ROM). Since we are trying to do auto-updating of our app on the device, we need the system to be signed by a key which we control so we can sign our apps with the same key (to get the INSTALL_PACKAGES permission).
I have been having a few issues running AOSP builds on the device (using the LG released source for the device), and am trying to take a step back and evaluate our options. I have a few questions:
Is it viable to just pull the system.img off the phone and resign the contents? If so, where is the system apk located? I poked through the PackageManager source and it uses a systempackage (seemingly called "android") to compare apps with to see if they are allowed to have system permissions.
Has anyone here created a custom ROM for the device that could offer some advice on how just get our signature be the system signature?
Any insight would be appreciated.
Ok, so we figured it out. I am not going to go into full detail (too much writing), but here is the basic gist for anyone who stumbles on this:
If you want change the key which the system is signed with, you need to do the following steps:
Extract /system/ dir from the running phone
Inspect the .apk files (from /system/app and /system/framework) to figure out which ones are signed by the same key as the framework-res.apk. I used a modified version of the script linked here to figure out which APKs to sign.
If the APKs in /system/app which share the signing key with framework-res.apk are odexed, you need to de-odex them.
resign the APKs and the framework-res.apk and pack them in an update.zip (google how to do that).
On my specific device I had to resign both /system/framework/framework-res.apk and /system/framework/lge-res.apk from /system/framework and also had to de-odex and sign 20 .apks from the /system/app folder in order to get everything running smoothly.
The "system apk" is /system/framework/framework.jar. I've never tried to re-sign the system image but I've written code which was part of the system image (not within a normal apk project) and it became part of this jar. There are additional jars in this directory which may need to be re-signed also.
The signature is created randomly and placed in two files in your build environment, build/target/product/security/platform.pk8 and build/target/product/security/platform.x509.pem. I don't know how to extract these from a normal key store, however I've been able to copy them from one firmware build to another to ensure that both images had the same platform key. Also, I've been able to change the signature of APKs with this command: java -jar signapk.jar platform.x509.pem platform.pk8 Old.apk New.apk. You'll find signapk.jar in your build, at out/host/linux-x86/framework/signapk.jar
We have a manufacturer that wants to pre-install our application on their Android device. We sent them the APK and even though it installs fine when used by a user, it appears to not get installed correctly when included in the manufacturer's build image. FYI, our application uses the JNI layer and some libraries built with NDK. The exception we're seeing seems to indicate that the class loader cannot find the library and is unable to load it. They have verified that the library files are indeed present in the APK.
Since we dont make devices, its unclear why they are seeing this exception and what needs to be done differently when including a package as part of the Android build image.
Any Android folks here care to comment?
I have worked with pre-installed Android apps, that also uses library files, in my case jar files. I am assuming that you have added the appropriate lines to AndroidManifest.xml like <uses-library android:name..... I am also assuming that you have provided instruction on how to install your library files on handset, with instructions like adb push ... on the command prompt. If you havent, do provide them the instructions.
Another issue may be permissions, we had to get the library jar AND the permissions xml file installed, that may be the issue.
Also ensure that you are using the correct version of Android for testing. And if everything fails, ask them to send one of the handsets that is not working to you and you can then compare with the one in office and debug this. Good Luck, as all this can be pretty frustrating.
Besides moving the apk file into /system/app, you should ask the manufacturer to move the native libraries created by NDK (.so files) to /system/lib or the path specified by LD_LIBRARY_PATH.
Please refer to https://groups.google.com/d/topic/android-porting/r_Ao7_PWgKQ for more details.