Trying to compile some samples from the Android SDK.
I just took the AccelerometerPlay example, ran the command:
Code:
android update project -p . -t 1
which creates the Ant build file, then
Code:
ant release
which builds release APK files.
The problem is, if I add something like:
Code:
import android.util.Slog;
to the .java file, the build fails, claiming that it can't find the file (even though it exists in {sdk_path}/sources/android-15
I'm guessing that it looks for .class files inside {sdk_path}/platforms/android-15/android.jar , where android/util/Slog.class doesn't exist.
How do I get this build to work?
I've tried adding
Code:
<src path="${sdk.dir}/sources/android-15" />
under the <javac> task in {sdk_dir}/tools/ant/build.xml, but it seems to throw out more errors, whilst also appearing to try to compile every single .java file there.
I'm new to Java so really don't know what I'm doing - can anyone please point me in the correct direction?
Thanks.
Anyone have any idea?
If you're new to Java, you may want to give Eclipse a try. You won't have to mess around with Ant too much and it will help you with your syntax/imports.
From your description, it looks like you'll want to add the .jar file you mentioned to the 'classpath' attribute of the <javac> element in your ant XML file.
- chris
Thanks for the reply cttttt.
What .jar file are you referring to? android.jar? Because that doesn't have the classes as far as I know.
Eclipse gets me even less further - I can't seem to install the ADT plugin at all. On Eclipse 3.7.2, it throws the WST error, and when I try the solutions "that work", I get thrown network errors.
(so at least I can get a build actually going with Ant)
Long ago, I said I'd start working on a high-level guide to creating firmware for one's own use (or possibly even eventually releasing to the wild). The idea was to make a high-level guide suitable for those who are comfortable with a Linux commandline but who might not be familiar with Android userland and tools available for working with firmwares.
So with this - I'm going to go through the steps I went through to create the deodexed XWKL1 firmware I've been using for the past two weeks, documenting it with notes as I go along about unusual "gotchas" that aren't necessarily in the documentation for the tools used.
Once I've gotten to the point where I have created a usable firmware, I'll post it here for consumption. Then I'll figure out what to do next - I've been lazy and happy with just using JKay mods lately.
Up next (after I reserve some posts): Deodexing
Obtaining firmware and deodexing
The best place to find I9100 stock firmware images for deodexing is, in my opinion, Intratech's thread in the I9100 Original Android Development forum. This thread is at:
http://forum.xda-developers.com/showthread.php?t=1075278
For the purposes of this guide, I'm originally going to use the XWKL1 download.
The next thing you need (in addition to a Linux box and the knowledge of how to use it...) is dsixda's Android Kitchen. While kitchens are generally frowned upon by firmware maintainers, deodexing manually is a massive pain in the ass and usually using dsixda's kitchen for this purposes is considered OK. To paraphrase gtg465x: "Deodexing with it is OK, but anything more and the ROM gods will frown upon you". Some of the other features of the kitchen like preintegrating busybox and rooting have issues - namely that they often inject old versions of busybox/su.
While the kitchen officially is supported on Windows, I cannot help you with any Windows-specific issues - you're on your own.
To get dsixda's kitchen, start with his GS2 thread at:
http://forum.xda-developers.com/showthread.php?t=1227549
I am going to use the latest version as of the time of this writing, which is 0.188
Extract the kitchen somewhere in your filesystem - I will refer to the directory unzipping the kitchen creates as $KITCHEN_ROOT
Extract factoryfs.img from the stock firmware TAR you downloaded earlier - you don't need anything else. You may need to fix its permissions by making it readable:
Code:
chmod a+r factoryfs.img
Place factoryfs.img in:
Code:
$KITCHEN_ROOT/original_update/
Start the kitchen by going to $KITCHEN_ROOT and running the menu:
Code:
./menu
Choose 1) Setup working folder from ROM
Accepting all of the defaults should work. It'll complain about not finding any kernel or cache - but this is OK. Neither of these are really needed as Hellraiser will take care of these later. The kitchen will ask for root permissions (sudo password) to extract the firmware contents. Say yes when it asks about a fake boot.img
Next, we deodex. Choose 0) Advanced Options
Choose 11) Deodex
Choose b) to deodex both /system/app and /system/framework
This will take a while. Go do something else. For example, I'm going to take a shower. (You don't need that much time - but I need a shower. )
Take a careful look at the last few lines of results here. If the deodex job worked perfectly, you should see no failure reports and 0 odex files in /system/framework or /system/app. However, for I9100 XWKL1, three .odex files will remain in /system/app, and you will see the following error:
Code:
Could not deodex the following (you can try to deodex these files again):
Maps.odex Phonesky.odex VoiceSearch.odex
Sometimes a second deodex pass will fix these, but not for these three files for XWKL1. You need to find a different way to fix them. Now I've heard that some advanced options like API Level mangling can fix these errors, but we're going to go with a simpler and easier approach for now.
We are now going to enter our last steps of the kitchen before we switch to manual maintenance of the firmware:
Return back to the main menu of the kitchen.
Choose option 99) Build ROM from working folder
Go ahead and use the defaults EXCEPT when it asks you to sign the firmware - note that this will zipalign all files (this is why zipalign scripts in init.d are rarely useful - on any decent firmware everything should already be zipaligned.)
Say no when it says to sign the firmware - since you're going to be making manual changes to the results, the signature will be broken.
You will now have a ZIP file in the following location:
Code:
$KITCHEN_ROOT/OUTPUT_ZIP/
DO NOT FLASH THIS FILE. IT STILL HAS SERIOUS ISSUES THAT REQUIRE REPAIR.
On to the next step... We take this firmware that is high in fiber and digest it a bit ourselfs, preparing to plop it out.
Fixing failed deodexes and debloating
If you were lucky, the firmware fully deodexed properly. However, often, it won't. For example, as covered in the previous post, with XWKL1, three files won't deodex. We will go through the process of manually dealing with these files in this post.
First, take the ZIP you obtained from the previous step, and unzip it to its own working directory somewhere. I will refer to it from now on as $FIRMWARE_ROOT .
You will find three APKs with .odex files in the following location for XWKL1:
Code:
$FIRMWARE_ROOT/system/app
Remove all three APKs and associated .odex files - these files are not useful to us. We now have to deal with the removed files.
Phonesky.odex
When I first saw this, I thought "WTF? I've never seen that before." - Time to Google it. It turns out that at some point, Google renamed the Market APK. It used to be Vending.apk, now it's Phonesky.apk - if we don't do something about this, the firmware will have no Market! So it must be fixed.
The good news is - The Market gets auto-updated frequently. As a result, we can obtain a replacement, AND that replacement is likely to be newer! What we need here is a device that is already running with a functioning Market.
Connect to your phone with ADB, and start navigating through directories. Downloaded apps are in the following location:
Code:
/data/app
Look for a Market APK there. (I need to take a few minutes to nandroid back to a different firmware - as mine currently has the latest market in /system, I don't have one in /data/app to pull.) OK, I'm on my UCKK6 Nandroid now, so, the Market is at the following location for me:
Code:
/data/app/com.android.vending-1.apk
Let's pull that into the right location in our firmware:
Code:
cd $FIRMWARE_ROOT/system/app
adb pull /data/app/com.android.vending-1.apk Phonesky.apk
OK, we've fixed the Market AND integrated the latest update!
Next up, VoiceSearch.apk:
While it is less critical than the Market, most users won't like a firmware without Google Voice Search. As this never gets auto updated and is not Market-downloadable, it's harder to find a working copy. Try deodexing other firmware bases (such as XXKI3) to get this file, or pull it from a firmware that has it properly deodexed. I grabbed mine from VillainROM 3.0 (Thanks Pulser!) initially, I'm going to try a different candidate before posting up my firmware this time around. This time, I'm gonna grab it from XWLA4. (Yes, after I finish with this guide based on XWKL1, I will be moving to XWLA4 to play with it. Also, yes - this file does deodex properly on LA4.)
Last, Maps.apk:
This is downloadable from the Market, so the safest thing to do is just remove it. However, you can use the same trick as with Phonesky.apk to grab the latest and greatest from an updated running system.
Code:
cd $FIRMWARE_ROOT/system/app
adb pull /data/app/com.google.android.apps.maps-1.apk Maps.apk
Note: If you outright remove Maps, you should also remove Street.apk - however if you are replacing Maps, you can leave Street.apk - it is often not in /data/app since it's updated far less frequently.
Removing Bloat:
Next, let's remove bloat. pulser_g2 has a great reference for what is safe to remove from I9100 firmwares at http://forum.xda-developers.com/showthread.php?t=1069924
First, disable OTA updates by removing:
Code:
rm wssyncmlnps.apk
rm syncmldm.apk
rm syncmlds.apk
rm fotaclient.apk
FM Radio is NFG on the I777, so kill it:
Code:
rm FmRadio.apk
SNS (Samsung's own social media integration) is a battery hog. Kill it, remove it all:
Code:
rm Sns*
rm SevenEngine.apk
Nuke the Hubs:
Code:
rm GameHub.apk MusicHub_10.apk ReadersHub.apk SocialHub.apk
Per ryude's post at http://forum.xda-developers.com/showpost.php?p=22719913&postcount=22, you can also:
Code:
rm $FIRMWARE_ROOT/system/lib/libnggame.so
Nuke the extra clocks - plenty of good ones on the Market:
Code:
rm DualClock.apk AnalogClock.apk DigitalClock.apk
Nuke Samsung's annoying panning tutorial:
Code:
rm PanningTryActually.apk
Nuke some other apps I never use, including all Samsung apps and widgets:
Code:
rm Kobo.apk Zinio.apk BuddiesNow.apk GenieWidget.apk PressReader.apk Samsung*
Live wallpapers are evil device-slowing battery eaters:
Code:
rm LiveWallpapers*
rm Microbesgl.apk
Some weird wifi file transfer stuff that is useless and starts a background service:
Code:
rm FTM.apk FTS.apk
Flashplayer can be installed from the Market:
Code:
rm install_flash_player.apk
Swype is 28 ****ing megabytes, I don't use it, and as I understand it, it sometimes conflicts with trying to update to newer versions. I was going to leave this in until I saw its size:
Code:
rm Swype.apk
rm $FIRMWARE_ROOT/system/lib/libSwypeCore.so
Some people will remove some of the DRM stuff such as SisoDrmProvider.apk - however the last time I tried to debloat DRM, I had some issues with even non-DRM videos. (Video player would hang on exit.)
At this point, we've fixed all of our failed deodexes and debloated. Now that we've digested that high-fiber kitchen product a bit, we can plop out our first flashable firmware image.
Code:
cd $FIRMWARE_ROOT
zip -r -9 ../PowerDump_XWKL1.zip *
This ZIP is actually flashable - if you wipe, flash this, then flash Hellraiser, you should have a working firmware. (going to test this now...) Note that with Hellraiser 0.3.1, you'll need to update to a newer Daily Driver (1/30/2012 or later) to get working Bluetooth HID. I'm going to put up 0.4.0 with DD 2/15-C later today. Note: If you want to flash one of JKay's themes, you must boot the firmware without the theme/mod at least once before flashing JKay. You may also want to flash one of ChainsDD's superuser packages - the firmware is not yet rooted.
Tested and uploaded - at this point in the process, this PowerDump will be your result - http://dev-host.org/I6C
Remember, it'll be a little rough, since you were digesting a high-fiber source and your system probably wasn't used to it, but it's still a good PowerDump.
Integrating Hellraiser and Flashing a Kernel
Integrating Hellraiser:
Actually, this one is fairly easy. We'll cover integrating the system aspects of it here, the remaining functions of Hellraiser (flashing kernel and modem) will be covered separately (kernel) or are irrelevant (modem - Hellraiser only flashes a modem because many I9100 firmwares include it - many people including myself believe modems should always be separate.)
Take either a Hellraiser ZIP file, or clone my github repo for Hellraiser at https://github.com/Entropy512/hellraiser_i777 - I strongly recommend looking through the commit history there to see what various changes were done and why. Some of them are just bringing in kernel updates, so you'll need to look through the kernel commit history around the data of kernel release to figure out important changes (like wifi tethering fixes in DD 12/21/2011 and BTHID fixes in 1/30/2012)
The root of this ZIP or the repo will be referred to as $HELLRAISER_ROOT - $FIRMWARE_ROOT is the same as in the previous post.
Copy all files from system/ in Hellraiser over the ones already in your deodexed firmware from the previous post.
Code:
cd $HELLRAISER_ROOT/system/
cp -aR * $FIRMWARE_ROOT/system/
The -a after the cp command means to "archive" (preserve as much file permissions and metadata as possible - although this probably doesn't really matter as the updater-script handles permissions), -R means to copy recursively (copy all directory contents, including subdirectories).
That's it - the system portion of Hellraiser 0.3.1 is complete. Hellraiser 0.4.0 will be a bit more complex when released, we'll get into this in a later post.
Adding a Kernel:
Flashing a kernel isn't too hard. Let's look at the updater-script that my Daily Driver releases use:
Code:
ui_print("Entropy's Daily Driver");
ui_print("2/18/2012 Standard Release - Part B");
show_progress(0.100000, 0);
ui_print("Flashing Kernel");
show_progress(1.000000,5);
assert(package_extract_file("zImage", "/tmp/zImage"),
write_raw_image("/tmp/zImage", "/dev/block/mmcblk0p5"),
delete("/tmp/zImage"));
ui_print("Thank designgears of Cognition X2 for the CWM kernel flashing example for I777");
ui_print("No more redbend_ua makes Entropy happy.");
Most of this is just user interface stuff - my show_progress lines are probably not quite right, but the worst case is they'll make the bar in CWM do funny things, no real damage.
Same for ui_print lines - they just print stuff in CWM. The real meat is this:
Code:
assert(package_extract_file("zImage", "/tmp/zImage"),
write_raw_image("/tmp/zImage", "/dev/block/mmcblk0p5"),
delete("/tmp/zImage"));
Place the zImage of the kernel you want to include in $FIRMWARE_ROOT/ and then add the above lines to your updater-script. Boom - your firmware will now flash a kernel. Maybe add some lines saying that you are flashing a kernel when you start - it's up to you.
Naming your firmware:
You can rename what your firmware displays in Settings->About Phone
Edit $FIRMWARE_ROOT/system/build.prop and change ro.build.display.id to what you want your firmware's name to be.
Fixing wifi region issues
Most I9100 firmware bases have the wifi region codes set for Europe. This can be overridden in Settings for 2.4 GHz wireless networks, but not 5 GHz wireless networks. The end result is that without modifications, I9100 firmware bases can only see 1-2 United States 5 GHz channels. Hellraiser does not handle this at the moment - I'm working on making Hellraiser 0.4.0 handle this issue.
Edit $FIRMWARE_ROOT/system/etc/wifi/nvram_net.txt and change the ccode from GB to ALL.
Change the ccode from GB to US in $FIRMWARE_ROOT/system/etc/wifi/nvram_net.txt_murata
At this point, 5 GHz wifi should work in the USA.
Adding Superuser (rooting your firmware)
This one is also simple. We're going to integrate the contents of ChainsDD's latest Superuser packages from his site: http://androidsu.com/superuser/
Grab the latest package, and unzip it.
Take system/app/Superuser.apk and put it in $FIRMWARE_ROOT/system/app/Superuser.apk
Take system/bin/su and put it at $FIRMWARE_ROOT/system/bin/su
Now edit your updater-script, first locate the following in your existing script:
Code:
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
Now, after this, take the following lines from ChainsDD's Superuser ZIP and add them:
Code:
set_perm(0, 0, 06755, "/system/bin/su");
symlink("/system/bin/su", "/system/xbin/su");
This sets the su binary to suid root, and symlinks it to /system/xbin
Everything else needed is already handled by our updater-script, since Superuser.apk needs no special permissions.
Integrating busybox and bash
This is going to be fairly basic right now - When you integrated Hellraiser earlier, it included bash and busybox, however, busybox isn't installed by the updater-script.
This will change that, it's straight out of the Hellraiser package, add it to your updater-script just before unmounting /system:
Code:
set_perm(0, 0, 0755, "/system/xbin/busybox");
ui_print("Installing busybox update...");
run_program("/system/xbin/busybox", "--install", "-s", "/system/xbin");
Note that this busybox binary was not compiled properly, and as a result has DNS issues. Later on I'll include info on compiling it properly - but for 95%+ of functions it works as it is.
The end result is at: http://dev-host.org/XCB
Wanted to be the first to say I can't wait as I've been following you since I got here! Your my inspiration
Sent from my SGH-I777
....rubs hands together!
Sent from my GT-I9100 using XDA App
I am soooo looking forward to this!!!
Keeping my eye on this.
Sigh... wish people would start moving their uploads since multiupload doesn't work!
c0ldburn3r said:
Sigh... wish people would start moving their uploads since multiupload doesn't work!
Click to expand...
Click to collapse
Yea I was just noticed that one to.
For glory!!!!!
I've used Ubuntu in a VM to create a Webos Doctor back when I had a Palm Pre, this looks... Fun.
Can't wait, this should be awesome.
Miget be looking to cook something up in a few weeks.
I already got a name too, Jersey Shore Rom. That's the area of NJ Im from.
Stay tuned!
Thanks for the tutorial, Entropy.
Am I the only person who thought the title said **** Rom? Lol
Sent from my GT-I9100 using Tapatalk
Good stuff Entropy! I'll be the first to admit I am a linux noob.. but I installed Ubuntu a few weeks ago and have been playing around.. learning a little here and there. Looking forward to this and learning more about android and linux! Thanks
MysticKing32 said:
Am I the only person who thought the title said **** Rom? Lol
Sent from my GT-I9100 using Tapatalk
Click to expand...
Click to collapse
It does say it
I'm so stoked for this!
Sent from my SAMSUNG-SGH-I777 using Tapatalk
but Entropy... why do all this when you could just take someone elses rom from the i9100 forums, hellraise it, then post it here in our forums just like everyone else has been doing lately???
task650 said:
but Entropy... why do all this when you could just take someone elses rom from the i9100 forums, hellraise it, then post it here in our forums just like everyone else has been doing lately???
Click to expand...
Click to collapse
LOL. Well, I usually just ran VillainROM, but I found a nasty bug in XXKI3. Actually, my experimentation with KL1 or LA4 may lead to VillainROM 3.1 (I eval the raw base, Pulser perfects it.)
I am trying to install a clean Android System WebView (packagename: com.android.webview) onto stock LG G5 RS988 RS98821d Android 7.0 that is rooted.
I downloaded an arm64 WebView APK from the Bromite Releases GitHub page:
https://github.com/bromite/bromite/releases
I tried installing the Bromite WebView APK to "/system/app/webview/" (0644 permissions) and rebooted, but the WebView implementation could not be used.
There are instructions regarding installing Bromite System WebView available:
https://github.com/bromite/bromite/wiki/Installing-SystemWebView
From my reading of the installation instructions, "res/xml/config_webview_packages.xml" from "/system/framework/framework-res.apk" must contain the an entry for the package with the particular package name ("com.android.webview" in this case).
After examining the stock "config_webview_packages.xml" member file, it appears that a reference to "com.android.webview" is not present. The "config_webview_packages.xml" XML file also appears to not be easily readable in a text editor. My guess is that it has some kind of signing.
What must be done to get the system to allow the newly installed WebView? My impression is that the "config_webview_packages.xml" XML file must be edited, but it is not clear how to do so, given that it does not appear to be just plain text.
I have attached a copy of the "config_webview_packages.xml" XML member file and the original framework-res.apk file zipped into a ZIP 2.0 archive.
XML files inside apks are compressed, you should unpack the framework-res.apk using a tool for apk editing, not just a zip archiver program. On Android, you can use APK Editor Pro, for example.
By the way, have you already uninstalled Chrome? If Chrome is installed, it will be forced as the standard WebView provider.
tremalnaik said:
XML files inside apks are compressed, you should unpack the framework-res.apk using a tool for apk editing, not just a zip archiver program. On Android, you can use APK Editor Pro, for example.
Click to expand...
Click to collapse
It was my impression that the APK files were zip files with a particular signature block. I shall try a tool like APK Editor Pro and report back.
tremalnaik said:
have you already uninstalled Chrome? If Chrome is installed, it will be forced as the standard WebView provider.
Click to expand...
Click to collapse
I have uninstalled/removed both Chrome and the Android System WebView (Google Apps version).
Ascii3 said:
It was my impression that the APK files were zip files with a particular signature block. I shall try a tool like APK Editor Pro and report back.
Click to expand...
Click to collapse
Now I'm on PC and I remember the name of the tool I use sometimes on PC: APKChanger. It's very complete, although very heavy (about 650MB with my current configuration);
If you have platform tools installed on your pc, or the whole Android Studio, you can also use
Code:
aapt d xmltree framework-res.apk res/xml/config_webview_packages.xml
to see the list of allowed webview packages.
Ascii3 said:
I have uninstalled/removed both Chrome and the Android System WebView (Google Apps version).
Click to expand...
Click to collapse
So we can be sure the problem is not the system forcing Chrome as default WebView provider. So, as Bromite's wiki states, "Changing the package name does not make installation easier/possible;", so the only solution is to add com.android.webview to config_webview_packages.xml, or, if it is already there, remove the requirement for Google's signature on the webview package. EDIT: I checked, on your file com.android.webview is missing, you just need to add it:
Code:
E: webviewproviders (line=20)
E: webviewprovider (line=21)
A: description="Chrome Stable" (Raw: "Chrome Stable")
A: packageName="com.android.chrome" (Raw: "com.android.chrome")
A: availableByDefault=(type 0x12)0xffffffff (Raw: "true")
E: webviewprovider (line=24)
A: description="Google WebView" (Raw: "Google WebView")
A: packageName="com.google.android.webview" (Raw: "com.google.android.webview")
A: availableByDefault=(type 0x12)0xffffffff (Raw: "true")
A: isFallback=(type 0x12)0xffffffff (Raw: "true")
E: webviewprovider (line=27)
A: description="Chrome Beta" (Raw: "Chrome Beta")
A: packageName="com.chrome.beta" (Raw: "com.chrome.beta")
E: signature (line=28)
C: "MIIDwzCCAqugAwIBAgIJAOoj9MXoVhH6MA0GCSqGSIb3DQEBBQUAMHgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEUMBIGA1UEAwwLY2hyb21lX2JldGEwHhcNMTYwMjI5MTUxNTIzWhcNNDMwNzE3MTUxNTIzWjB4MQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzEUMBIGA1UECgwLR29vZ2xlIEluYy4xEDAOBgNVBAsMB0FuZHJvaWQxFDASBgNVBAMMC2Nocm9tZV9iZXRhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo/wW27nRxVqGbFOyXr8jtv2pc2Ke8XMr6Sfs+3JK2licVaAljGFpLtWH4wUdb50w/QQSPALNLSSyuK/94rtp5Jjs4RSJI+whuewV/R6El+mFXBO3Ek5/op4UrOsR91IM4emvS67Ji2u8gp5EmttVgJtllFZCbtZLPmKuTaOkOB+EdWIxrYiHVEEaAcQpEHa9UgWUZ0bMfPj8j3F0w+Ak2ttmTjoFGLaZjuBAYwfdctN1b0sdLT9Lif45kMCb8QwPp0F9/ozs0rrTc+I6vnTS8kfFQfk7GIE4Hgm+cYQEHkIA6gLJxUVWvPZGdulAZw7wPt/neOkazHNZPcV4pYuNLQIDAQABo1AwTjAdBgNVHQ4EFgQU5t7dhcZfOSixRsiJ1E46JhzPlwowHwYDVR0jBBgwFoAU5t7dhcZfOSixRsiJ1E46JhzPlwowDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAZO2jB8P1d8ki3KZILvp27a2VM3DInlp8I8UgG3gh7nBQfTrnZr5M1PL8eFHqX7MEvAiGCMTcrPklEhjtcHK/c7BcdeCWq6oL56UK3JTl33RxJcjmjrz3e3VI6ehRSm1feNAkMD0Nr2RWr2LCYheAEmwTPtluLOJS+i7WhnXJzBtg5UpUFEbdFYenqUbDzya+cUVp0197k7hUTs8/Hxs0wf79o/TZXzTBq9eYQkiITonRN8+5QCBl1XmZKV0IHkzGFES1RP+fTiZpIjZT+W4tasHgs9QTTks4CCpyHBAy+uy7tApe1AxCzihgecCfUN1hWIltKwGZS6EE0bu0OXPzaQ=="
E: webviewprovider (line=30)
A: description="Chrome Dev" (Raw: "Chrome Dev")
A: packageName="com.chrome.dev" (Raw: "com.chrome.dev")
E: signature (line=31)
C: "MIIDwTCCAqmgAwIBAgIJAOSN+O0cdii5MA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDETMBEGA1UEAwwKY2hyb21lX2RldjAeFw0xNjAyMjkxNzUwMDdaFw00MzA3MTcxNzUwMDdaMHcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDETMBEGA1UEAwwKY2hyb21lX2RldjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOYPj6Y9rVt8xizSHDYjDEkDfFZAgSiZ9T6tevkQXsFyfaq3Gk3h2qssi29G6cTPJ2VXFKlVB71wSXv5p9/LEcDQPWQiO3Q2cLmgUXxyhJWXI3g96tPAhZQX2q6SC37ZQdiBR/raMO70DAkvCyBGtNplsvutzSE3oZ7LYfzB8vTbe7zCh3fDYSS/7xb3ZVvFqydHS40uVq1qqg1S80Pge7tW3pDGsPMZN7yA4yfmsvA1rbHm9N8t3Rc9hqzh6OxNAAgRB535YcsWL7iF+mpdFILXk3jLYT0nMvMnB83rsdgnRREjlGQYHl2mh8+6CqujsW/eICDq/LR6BYDyqHhk0ECAwEAAaNQME4wHQYDVR0OBBYEFKzsl07JglgpbeYDYGqsgqRDo+01MB8GA1UdIwQYMBaAFKzsl07JglgpbeYDYGqsgqRDo+01MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBACka6SFF6xAcj8L8O6R36++E09DTiGZEjvKT8eIycgcQQ+p1WUmPb6M2EJpN6zvvSE62ussmXdzf8rIyc0JXA8jbViZt62Y39epNENFxPTLN9QzXlT+w8AW73Ka3cnbOuL5EgoDl8fM79WVlARY3X+wB/jGNrkiGIdRm2IZIeAodWgC2mtXMiferyYBKz2/F2bhnU6DwgCbegS8trFjEWviijWdJ+lBdobn7LRc3orZCtHl8UyvRDi7cye3sK9y3BM39k0g20F21wTNHAonnvL6zbuNgpd+UEsVxDpOeWrEdBFN7Md0CI2wnu8eA8ljJD45v0WWMEoxsIi131g5piNM="
E: webviewprovider (line=33)
A: description="Chrome Canary" (Raw: "Chrome Canary")
A: packageName="com.chrome.canary" (Raw: "com.chrome.canary")
E: signature (line=34)
C: "MIIDxzCCAq+gAwIBAgIJAML7APITsgV7MA0GCSqGSIb3DQEBBQUAMHoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEWMBQGA1UEAwwNY2hyb21lX2NhbmFyeTAeFw0xNjAyMjkxOTA5MDdaFw00MzA3MTcxOTA5MDdaMHoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKDAtHb29nbGUgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEWMBQGA1UEAwwNY2hyb21lX2NhbmFyeTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANXfeAoZlr0ya1HBzIfAz/nLLjpPJeAPvuX5dueaxmiQgv2hNG22acriFuiiJI6TU0t8AIVJD5Ifbc4OOuA0zeFhdzWWGnmTRH6x27WI7bzOKnAqOvv21ZBmE9i8Vo++K13xWdTs3qVn1bn9oUONxFu0wKDzXYZhoj1Jom0RZGjXm16xuPlEuOzMcjiNBDoYuxPAXkMcK/G1gP4P4nAV8Rd/GGIjKRS/SUtcShhoAMOQhs4WIEkUrvEVRwhBDIbpM87oFbCVdBH38r0XS6F6CdhPJsKFhoEfq4c01HZqNmDpCPA8AAcCuSWqmXoTIqs7OqkWgduE2bInbWU7WMaTl+kCAwEAAaNQME4wHQYDVR0OBBYEFB/AsC4iPAqaLoNytNSx29qByI7+MB8GA1UdIwQYMBaAFB/AsC4iPAqaLoNytNSx29qByI7+MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAMb2Td3ro/+MGVnCPAbwBSOZMVLUKGqt6zr8CShW9mtFHnmy29EaWSYYAj1M4+6Vpkq85NsgBEck7rnUjV8A3Q0NKdTys1KRKJqVvQRBN6SwqQenSf/abxQCa8Z+69rh+3BkIU1HLtu5lrMDZwon5H91L5mpORn6vItd20uW132lwSDeUEW2CHslTrodoFuTUcSUlRiq/URfUH3baO1QHXkxpQwrBPKL5deJfcZnxh5MAtAGSQL7gHvayEFlDppETXdDO7vgGTH2dEK2TjKWALbGiKkxSqjRyTNt4/FOj10TqNRdUamj+ydVJgzGQ8bki4Vc6NnKm/r4asusxapkVR4="
E: webviewprovider (line=36)
A: description="Chrome Debug" (Raw: "Chrome Debug")
A: packageName="com.google.android.apps.chrome" (Raw: "com.google.android.apps.chrome")
On Android, I used APK Editor Pro 1.10.0 to modify res/xml/config_webview_packages.xml of /system/framework/framework-res.apk. A new APK with a generic signature was generated with the modification. I used the XML file editing option to select and modify the config_webview_packages.xml. The XML file editing functionality is given to be in beta and appears buggy.
I replaced the original /system/framework/framework-res.apk file with the patched one using the TWRP 3.2.3-0 file manager and attempted to boot to system. The system would start, but get stuck at the LG logo screen. I tried wiping data, and cache in recovery and booting again, but received the same result. I note that adb was available and usable after the boot process got stuck on the LG Logo screen.
My impression is that the patched framework-res.apk file is incompatible or defective. Perhaps APK Editor Pro 1.10.0 malformed the output APK (the XML editing feature appeared unfinished) or that the LG stock ROM expects framework-res.apk to have have a particular signature.
Perhaps a different APK editing tool should be tried. What could the problem be?
I have attached a ZIP archive containing the APK Editor Pro 1.10.0 modified framework-res.apk.
EDIT: Attachment has been removed; the file was defective and should not be used. Attachment is no longer necessary.
I have now patched framewor-res.apk successfully, and Bromite System WebView is working.
Did you use again APk Editor Pro or a PC tool?
The tools I used were Windows tools (and with a Java dependency in the case of Apktool) and were: Apktool 2.3.1 and WinRAR 5.6.1. I found that it is best to avoid newer versions of the tool unless trying to manipulate Android 9 Pie or newer resources.
Ascii3 said:
I have now patched framewor-res.apk successfully, and Bromite System WebView is working.
Click to expand...
Click to collapse
I know this is an old post, but how did you get it to boot?
I'm using apktool 2.5 and seems to be stuck on the boot screen as you were
burny02 said:
I know this is an old post, but how did you get it to boot?
I'm using apktool 2.5 and seems to be stuck on the boot screen as you were
Click to expand...
Click to collapse
From somewhere else it seems that you are now using Apktool 2.3.1.
After comparing my notes, my impression on what you are missing and some related notes:
The modified framework-res.apk should use the unmodified APK file's "AndroidManifest.xml" root file and META-INF directory contents. It is not sufficient for any of the content to be the same after decompiling.
Copy "AndroidManifest.xml" and META-INF directory from original framework-res.apk to modified framework-res.apk using zip program, if contents are different.
v2 APK signing scheme (which includes the APK file itself in validation), if present, would be broken, but the scheme's enforcement is not enforced on /system; v1 APK signing scheme (on APK contents ("AndroidManifest.xml" file and META-INF directory contents)) is still enforced.
I zipaligned output/modified framework-res.apk prior to transferring original "AndroidManifest.xml" file and META-INF directory contents, but I do not believe it matters for the purposes of getting a functional framework-res.apk.
EDIT: Some added things to keep in mind:
Sometimes clearing system cache and the runtimes cache is also necessary before system will boot after framework-res.apk replacement. Also make sure that the permissions of the replaced framework-res.apk file are at minimum whatever the original file permissions were. Depending on what software you use to replace the framework-res.apk file, the permissions set may be different.
I really appreciate the help, still does not work unfortunately.
Here is what I do:
adb pull framework-res.apk
apktool d framework-res.apk (tried most versions, mainly now 2.3.1)
Edit framework-res/res/xml/config-webview-packages.xml to:
Code:
<webviewproviders>
<webviewprovider description="Bromite WebView" packageName="com.android.webview" availableByDefault="true" isFallback="true" />
</webviewproviders>
Removing other dev versions with signatures etc
apktool b framework-res
zipalign -v 4 framework-res.apk framework-res-new.apk
Move META-INF and AndroidManifest.xml from the 1st original framework-res.apk > framework-res-new.apk (Have also tried moving res & resources from the new to the original...7Zip, WinRAR, CLI - Linux)
adb push framework-res-new.apk /system/framwork-res.apk
Modify permissions in TWRP > 0644
Move framework-res.apk from /system/ to /system/framework/framwork-res.apk (I read somewhere this is better than pushing directly. Neither worked)
Clear Davlik & Cache
Reboot
Hangs on boot screen
Any ideas if I am missing something important?
@burny02 - Please clarify whether the framework-res.apk you are trying to modify is for LG G5 stock ROM Android Nougat.
I note that you are using the "isFallback="true"" flag with the webviewprovider tag. The purpose of the isFallback attribute set to true (its default is false) is to specify that the WebView provider should be disabled by deault and should only become available when allow other WebView providers are disabled. Using the attribute with the true value with only a single WebView provider seems improper. I do not know if boot should fail if the attribute is present in the way that it is, but in both scenarios I would recommend its omission.
It has also been a while since I used Apktool versions and do not exactly remember the command lines. Do not take my not pointing to an issue with it as there necessarily not being an issue. One thing I would mention is that one typically first install a frameworks before decompiling and building. For the LG G5 RS988 Android Nougat, I believe installing the framework-res.apk as a framework was sufficient. You would specify on command line "apktool if framework-res.apk" and any tags you wish to explicitly specify, if any.
The moving of framework-res.apk to /system/ before /system/framework/ is oftentimes done by people to try to install a modified framework-res.apk with proper permissions and on a live system before the system crashes and reboots. Once framework-res.apk is copied to /system , but does not replace the framework-res.apk file, proper permissions can be set prior to using that file to replace the live framework-res.apk. It is still important to note that some software disregards permissions set when a file is relocated or copied, so this could be an issue if framework-res.apk is replaced with more restrictive permissions than the original framework-res.apk (less restrictive permissions should not usually be a problem for the app to be used). I particularity do not like the idea of the system crashing and prefer to make such changes offline (such as via the aid of a custom recovery).
Sorted. Got it working. Really appreciate the help, Ascii3
For anyone looking at this in the future, the isFallback back seems to stop booting, regardless of whether it is the only entry or not.
The procedure then works as above:
adb pull framework-res.apk
apktool d framework-res.apk (2.3.4 worked for me - SDK 24 Android 7.1 (LGG5))
Edit framework-res/res/xml/config-webview-packages.xml to:
Code:
<webviewproviders>
<webviewprovider description="Bromite WebView" packageName="com.android.webview" availableByDefault="true" />
</webviewproviders>
apktool b framework-res
Move META-INF and AndroidManifest.xml from the 1st original framework-res.apk > new framework-res-new.apk (Used 7Zip drag & drop)
adb push framework-res-new.apk /system/framework/framwork-res.apk
Modify permissions in TWRP > 0644
Clear Davlik & Cache
Reboot
I found the following unnecessary :
Installing framework (apktool if)
Zip-aligning
Moving to /system prior to /system/framework/ (Using TWRP, live system; it might be necessary)
burny02 said:
Sorted. Got it working. Really appreciate the help, Ascii3
Click to expand...
Click to collapse
Sure.
burny02 said:
For anyone looking at this in the future, the isFallback back seems to stop booting, regardless of whether it is the only entry or not.
Click to expand...
Click to collapse
The isFallback attribute is supposed to only be set to true for no more than one webviewprovider. Explicitly setting it to false (its default) should not be problematic (but does result in a larger config-webview-packages.xml file generated). Setting isFallback to true on the only webviewprovider item is not an intended use and apparently results in no boot.
burny02 said:
I found the following unnecessary :
Zip-aligning
Click to expand...
Click to collapse
I do not think zip-aligning apps is necessary generally . My understanding around the reason to do so is to try to optimize the packaged data to be more efficiently fetched in the manner which Android fetches the data.
@Ascii3 @burny02
Hello guys, sorry to exhume this post but I'm struggling and all other threads are maybe ten years old...
So I'm struggling to replicate what you did! I'm no expert but I can follow basic instructions.
So I do as you say, decompile framework-res.apk, modify the xml file (I just add the line). This step seems okay since I did some errors while editing the file and apktool would not recompile properly. Now this goes fine.
Then I got my freshly recompiled framework-res.apk, but 7zip on linux won't let me insert META-INF and AndroidManifest.xml. So I had to rename the extension .zip, do it, then rename in apk. Could this be an issue? It looks dirty.
Anyway, after this you didn't had to resign the apk? I read everywhere you had to, so I did. I did not zipaligned it since I used a resign tool I found on xda and I could not tell if I had to do it before or after resigning, but since you said you didn't zipalign it I thought whatever.
The problem is the following: after replacing framework-res.apk in /system/framework, the phone won't start, I get stuck on the starting screen and I could extract the following from logging:
01-24 04:15:17.470 +0000 4042 4042 I PackageManager: /system/framework/framework-res.apk changed; collecting certs
01-24 04:15:17.749 +0000 4042 4042 W PackageManager: Failed to scan /system/framework/framework-res.apk: Failed to collect certificates from /system/framework/framework-res.apk
Have you got any ideas of what I did wrong? It's my fourth soft-brick today, I'm getting a bit annoyed.
Thanks in advance
@LeSplendide did you ever get this working? Not sure if I'm having the same trouble, but I followed burny's instructions and my phone fails to boot. I checked logcat but I don't see anything relating to framework-res. I'm using magisk to overlay it because if I touch the /system partition for real, VoLTE stops working on my phone (known issue for this phone). I'm successfully overlaying stuff in /system/app and /system/priv-app so I do have overlaying generally working, though this is the first apk in the framework directory I've tried to overlay. Boy do I want to get this working. I've extensively degoogled and debloated this phone and the only glaring thing that remains is chrome handling webview.
TheShanMan said:
@LeSplendide did you ever get this working? Not sure if I'm having the same trouble, but I followed burny's instructions and my phone fails to boot. I checked logcat but I don't see anything relating to framework-res. I'm using magisk to overlay it because if I touch the /system partition for real, VoLTE stops working on my phone (known issue for this phone). I'm successfully overlaying stuff in /system/app and /system/priv-app so I do have overlaying generally working, though this is the first apk in the framework directory I've tried to overlay. Boy do I want to get this working. I've extensively degoogled and debloated this phone and the only glaring thing that remains is chrome handling webview.
Click to expand...
Click to collapse
I'm sorry I have no idea, rn Webview Implementation says I have Android System Webvew 102.0.5005 so I assume this is chrome webview? But I have no clue what I did or not but I know for sure I fixed my problem which was that Webview would crash when trying to sign in a google account on my MicroG'd LEAOS. Now this works so I guess I did make it work. All I found that could be a clue is a update.zip containing instructions and the webview in question. Iirc, the issue was that the zip needed to be signed so that twrp could flash it, so I think I just signed my zip and it worked but can"t tell for sure.