In the current state of the project I'm currently working on, I have a classic Android Studio project with a classic app on it.
For some good reasons (it's an embedded app), I would like to include an auto-update feature in the app, which doesn't require to exit it (I must stay inside the app or another app and never show the underlying Android system).
I have two solutions to do this :
Create another "updater" app which updates the app using the package manager command. It requires a rooted device to work, but it would suit my needs : when an update is available, the main app closes itself and opens the updater app which updates the main app and starts it back
Have the actual code of the application stored to the external storage and turn the APK into a bootstraper which downloads and runs the app
The later solution is the better one since it doesn't require a rooted device.
This is why I would like to write an elegant system to achieve this ; the development of the app should not be crippled by this (e.g. I don't have to upload the new classes at each build, I don't need to do extra voodoo work to add activities or permissions to the manifest...).
I thought of using the build variants of Android Studio :
Debug variant : build the app like usual, don't use the bootstraper
Release variant : don't include all the classes in the APK, build an external JAR which contains them and use the boostraper in launcher intent
I saw how to load external classes from the external storage, but I couldn't find anything on how to externalize the whole app code, including activities. I have the feeling that we just can't.
Would such a system be possible to develop ?
Related
Scenario
I have an existing native android app in which I want to add some new features. These features have already been implemented as a PWA because some users needed to use them directly from the web.
I want to be able to open the PWA with an Android WebView (as if it was part of my native application) and install it 'locally'. With 'locally' I mean that the PWA should not be visible as an app in the phone, it would just be part of my existing native app. In a way, what I'm trying to achieve is a king of "plugin" system, where I could have extra features that the user can install to the native app.
Where am I stuck?
Opening the PWA with a WebView is fairly straight forward. The part that I am unable to do is installing the PWA. Maybe TWA could solve this issue, but I am not sure it is meant for that.
Moreover, ideally I would like to keep everything in a Fragment since I would like to have the toolbar and others created by the native app (that is why I've leaned more towards using WebView instead of TWA).
EDIT---------------
After messing around I was able to understand that it actually gets installed with WebView. Since I haven't been able to find any information about how it works online I've been researching it on my own.
First of all ServiceWorkerController is only available from Android 7 (24). I haven't been able to test if with Android 6 this can work or not due to the fact that I don't have any phone with that version and I can't update the WebView apk of my emulators for some reason.
Then, I found out that the webpage crashed in my newer emulators because the WebView apk installed was too low and didn't support some newer features. So another thing to take into consideration the WebView version installed. This apk gets installed separately from the Android version (it's as if it was an app on your phone). The solution to this is to just use a real device, because the apk is usually always up to date.
As you can see in the following picture the PWA gets installed inside the app folder and it also keeps all the info (databases, localstorage, sessionstorage, etc.) in there.
It is unclear how this data is handled (I created this question) but it appears to be at least in the following cases:
WebStorage.Instance.DeleteAllData()
App uninstalled
App Data Cleared
Clearing the Cache of the app doesn't delete the persistent data.
So now I would say that the question would be:
From which Android Version does the Service Worker install? Just from the Android version that has support for the webview apk version that supports Service Workers?
Does it depend at all on ServiceWorkerController? Or is it just a utility class to have more control over what happens?
I am extremely new to Android development. My company supports our own Android build for our devices using the AOSP build tree with some of our needed system services and APK's being build within the AOSP tree.
However, we are planning on moving to a vendor supplied Android build and we want to remove a system service from the AOSP tree and move it into a separately build and installed APK, but still be accessible as a system service to other installed applications.
Being so new to Android development I don't really even know where to begin.
As a first step I find where the APK for the system service is generated/output in the AOSP tree. I installed this APK onto our device. The installation appears to have worked. However, when an application runs that needs to use that system service, Android displays a message about how the system service has stopped.
1. What steps do I need to take to make this work?
2. What other information is needed to diagnose the problem? I'm so new to this I don't know what information I should be providing.
However, we are planning on moving to a vendor supplied Android build and we want to remove a system service from the AOSP tree and move it into a separately build and installed APK, but still be accessible as a system service to other installed applications.
Assuming you have made changes in ServiceManager to add your own system service in AOSP. Yes, it is possible to move your system service to a separate apk. This will reduce your platform dependencies. However, sepolicy changes will be still required(in order to add your service dynamically in ServiceManager). Here is the complete reference to add system service from apk:
https://devarea.com/aosp-creating-a-system-service/#.XOOD9KRS9EY
The installation appears to have worked. However, when an application runs that needs to use that system service, Android displays a message about how the system service has stopped
Please elaborate, what changes you have made, and root cause behind system service crash.
What steps do I need to take to make this work?
Suggest to move you system service to a separate apk. Please refer above link which explains creating system service (from apk).
When I create an APK while developing a Nativescript application, Nativescript stores all the application code in the generated APK file, and that helps me a lot in case something bad happened to the code[The code was deleted, Didn't commit changes I was working on for a long time,...]. When something bad happens to the code, I usually generate an APK from my android device using any APK Extractor tool and decompile it with JADX to obtain my original code and save my day.
Nativescript doesn't generate NEW APKs when I make changes to layout or js files[even though changes are applied on the android device]. Nativescript generates new APKs only when I build the project. and that doesn't help a lot when I need to restore my code after a lot of changes on it.
We're working on a nativescript application. We've been making changes on the application for about two days without generating new APK nor committing changes to git. The files where suddenly removed from pc and we don't know why.
We extracted an APK from the latest working version on the test android device, decompiled it and retrieved the code but the changes of the last two days weren't there.
Is there a way to restore the code from a Nativescript application installed on android devices? By restoring the code I mean even restore all the changes on the code after building the application.
Where/How does nativescript store the instant changes on the code for my application on the android device?
You can view your code by accessing the application data from adb.
connect to your application from adb
adb shell run-as org.nativescript.myapplication
and you can find your files in this directory
/data/data/org.nativescript.myapplication/files/app
It's not wise to depend on your APK for retaining your source code, you should probably use a Version Control System like Git, may be services like Github / BitBucket / GitLab etc., to maintain your source code.
While using a Version Control System, you should commit your changes regularly. That's the whole purpose here, even if you are not sure about your changes you can still use your own branch and keep the changes committed and merge to main branch only when it's fully ready.
I guess you are not using the --bundle option while you run / build the app which is recommended to keep your application lightweight at same time provides a minimal obfuscation using Uglify. With next major release of NativeScript this --bundle option will be marked as default, so you will no longer be able to extract your exact source code at all.
Also think if someone wants to hack your app while you haven't followed any obfuscation, it's easy to clone your work Or break the functionality as they wish. Learn more about securing your source code here.
Still regarding where the live changes are being stored, I think it will be within application data directory on Android.
So when you create mobile apps, you usually intend to distribute your app to multiple platforms and architectures. However, since object code usually is dependent on factors like the architecture, you would have to compile the app for all the different mobile phones out there. So is you application really compiled for all the different phones that the app will be made available for? Is this specifically targeted compilation then done whenever a user runs the app on his/her device? Like on the device itself or is the compilation done before the app is actually installed on the phone?
So is you application really compiled for all the different phones
that the app will be made available for?
Short answer: yes.
Is this specifically targeted compilation then done whenever a user
runs the app on his/her device?
No; this is done when the package is created (else you'd be sending all your source code in the app!) This means a package may contain multiple libraries required for it to run on multiple architectures.
Like on the device itself or is the compilation done before the app is actually installed on the phone?
For the shared object to be put into the package, compilation is done before the package is created. The required shared objects are copied onto the phone during installation of the package (and I suspect that the non-required ones are discarded, but it's possible they're not!).
There are however only a relatively small number of architectures that android supports; and while supporting them all does increase the size of the package, the size is rarely an issue.
Alternative:
If you don't want to put the shared object in the package, an alternative is to host them and download the appropriate one during runtime.
The problem with this is that this does impact user experience (I personally hate when I download an app, and then it states that it wants to download more; it feels like it's a mechanism of bypassing any security checks google want to do)
Okay, here's the situation:
I'm developing an application for a client (or trying to do so). It requires much (if not all) of the same functionality as the built-in SMS/MMS application. So, I thought - HEY! Android is open source right? I can take the application and modify to my needs, right?
So, I found the code on github for the MMS/SMS application (for some reason, based on the AndroidManifest file, it calls my project I built, "ConversationList"). But I get TONS of errors involving the import com.google.android.mms.* package and a couple other packages.
Everyone keeps saying "it's a private/internal package", and "download the entire AOSP". But, HOW do I do this on Windows, and WHY can't I just download the appropriate packages to use in the program?
ALL I want to do is build a project in Eclipse deploy it to my phone, and then modify the necessary code. If Android is open source, why so many secret/internal packages? This is frustrating.
Any advice?
So, I found the code on github for the MMS/SMS application (for some reason, based on the AndroidManifest file, it calls my project I built, "ConversationList"). But I get TONS of errors involving the import com.google.android.mms.* package and a couple other packages.
AOSP applications like this are designed to be built as part of a firmware image, not as standalone apps.
But, HOW do I do this on Windows
Most likely, you don't. Cygwin might work. More likely, you will need to use OS X or Linux, such as running Linux in VirtualBox. And the result of your build will not run on anything, except as part of a firmware build that you use to replace the firmware on a device.
WHY can't I just download the appropriate packages to use in the program?
Because that application is designed to be built as part of a firmware image, not as a standalone app.
ALL I want to do is build a project in Eclipse deploy it to my phone, and then modify the necessary code.
Then find a project that is designed to be built as a standalone app as your starting point. Or, work on modifying the project you are trying to use to work as a standalone app, by ripping out all the functionality that depends upon things that are not in the app itself.
If Android is open source, why so many secret/internal packages?
They are not "secret". They are part of the firmware.
For example -- since you appear to be familiar with Windows -- it is entirely possible that "apps" like Control Panel are not designed to be built independently from the Windows OS. If you were able to download the source code to Windows and tried to load Control Panel into Visual Studio, it is eminently possible that you could not create some standalone CPANEL.EXE file just via that one project. Rather, you would need to use a customized Windows OS build process to build the whole OS, which would then contain a CPANEL.EXE that would run within that built version of the OS.
Most of the AOSP apps work this way. Some have been forked to create standalone apps -- K-9 Mail came from the early version of the AOSP email app. I have no idea if anyone has done this with the stock AOSP Messaging app or not.
You could instead fork TextSecure[0] as it is no system application but looks very similar to the stock messaging application. The AOSP application needs to be installed on /system/app which requires root and might not be what your customer wants.
Please note that this application is copylefted (GPLv3) so you'd have to give your client access to the source code under the terms of the GPL if you fork.
[0] https://github.com/WhisperSystems/TextSecure