Develop Reference

How to install a PWA with Android WebView/TWA

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?

How can I programmatically install apps on android from a system app without being device owner?

I have tried to find a solution on this by searching the net for quite some time. If there is a working solution to my question on stackoverflow, it would be nice if someone points me to it.
So problem is very specific:
I like to implement an app updater that installs apps without any further user interaction as soon as the user has started the setup process.
This would something like the way it is done by GMS (Play Store).
Constraints:
The implementation has to work on devices back to Android 6.
I am an Android system developer and I want to integrate an update for our own hardware.
I have an existing app that is running as system app in the system context.
The app cannot be device owner, as this will block MDM support that customers might want.
I can access hidden APIs of the android system.
The solution may not require root access to the device and shall not use any hacks like calling pm install.
The device has to pass the Google approval what restricts everything to the use of the system APIs provided by Android. I think that this is the reason, why it is so hard to find a proper solution or pointer to a code sample for this.
Has anyone worked on this? Are there apps (like free app-stores) that implement something like this?
Edit: I have found a partial response to my question here: https://stackoverflow.com/a/5805299/6289291
The major difference is, that when building from within the AOSP tree, reflections are of course not required and there are some problems I encountered that I will try to summarize in a response to this question as soon as I have resolved those in a proper way.

Functional backwards compatibility in Android

I'm having some errors with running a developed application on a device with android 6.0.1 that runs perfectly on a device with Android 2.3.6. I'm using the same built application (compiled for an Android API 10) for both devices.
The errors are about the application being closed when a new Activity starts and when a contact is selected, I know how I could solve those problems for that device, but problem is that from what I had read I thought that android had no problems with being functionally backwards compatible (maybe there could be some graphical issues but nothing that would make the application crashing, as it is happening to me).
So I'd like to know if this is just some exceptional event that has happened to me, and the most likely thing is that, once I check these errors in some more android versions and fix the code of the app to run on them, something like these errors is not going to happen again, or if events like that are relatively common. If that's the case it sounds pretty painful to have to check and maybe develop accordingly for a lot of versions, so I'd like to know if there's some shortcut which, even if it doesn't offer 100% security of having the application correctly functionally developed, it gives a good percentage of security.

I think in general an app is forward compatible, but only if you ensure that you don't make use of private or undocumented api's.
For example when I first started playing with android there was a bunch of info on the web on how to send and received text messages that were not mentioned at all in the google documentation. Using that info (undocumented api) would have caused my app to break when KitKat came out and introduced and officially documented api for that particular purpose, since at the same time they removed the functionality that was available in the undocumented api. See here for details. of the above example.
Here is a link to some info on compatibility:
https://developer.android.com/guide/topics/manifest/uses-sdk-element.html
And a snip-it of the relevant section
Application forward compatibility Android applications are generally
forward-compatible with new versions of the Android platform.
Because almost all changes to the framework API are additive, an
Android application developed using any given version of the API (as
specified by its API Level) is forward-compatible with later versions
of the Android platform and higher API levels. The application should
be able to run on all later versions of the Android platform, except
in isolated cases where the application uses a part of the API that is
later removed for some reason.
Forward compatibility is important because many Android-powered
devices receive over-the-air (OTA) system updates. The user may
install your application and use it successfully, then later receive
an OTA update to a new version of the Android platform. Once the
update is installed, your application will run in a new run-time
version of the environment, but one that has the API and system
capabilities that your application depends on.
In some cases, changes below the API, such those in the underlying
system itself, may affect your application when it is run in the new
environment. For that reason it's important for you, as the
application developer, to understand how the application will look and
behave in each system environment. To help you test your application
on various versions of the Android platform, the Android SDK includes
multiple platforms that you can download. Each platform includes a
compatible system image that you can run in an AVD, to test your
application.

Installing apk without user input

I have been searching the internet wildly for an answer to this question.
We are creating custom android app for internal use only and we would be installing that on custom andoid devices. We would like to have full control of the device through the app. The end user of this device is not meant to use anything other than the app on this device. I have sealed out all the possibilities of getting out of the app except this one possibility where the program tries to update itself and asks for user permission.
Let me repeat again, This app is not meant to be put on market, only for use with custom devices designed for specific purpose. So security is not an issue here.
The device is rooted and we have done a lot of alterations with it. But I cant quite figure out how to make this update work.
If you have any ideas/solution please share it with me. I can do anything with my device, (even dig a hole in it if required :P) as they would be custom made, and would be packaged with us before going out. Just have to make it work.

If you are talking about internally installing the APK with like an update application specifically designed to update your other application which is not managed by Google Play you may want to look into this. So between xjaphx's answer and the link I just shared you will be able to install and maintain updates.

This is as simple as how it works.
Pre-condition:
Get devices rooted
Prepare Android development environment (Android SDK, platforms-tools)
A cable to connect PC and devices.
Steps:
Open command-line if Windows or shell if Linux
type: "adb push YourApp.apk /system/app"
That's done for installation of the app. Reboot and check whether your app works or not.

Use an intent from another Android application or use code?

I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?

In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).

Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.

Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.