Question about modifying the size of the text selection handle or cursor images in Gingerbread.
I managed to hack my framework-res.apk to make the text selection "cursors" smaller.
I changed the following files inside of framework-res.apk:
\res\drawable-hdpi\text_select_handle_left.png
\res\drawable-hdpi\text_select_handle_middle.png
\res\drawable-hdpi\text_select_handle_right.png
This only seems to have affected the text input boxes, when I select text on a webpage in the browser I still get the "big" cursors.
I took two screenshots to show the size difference.
Where should I be looking to modify the selection cursor size for the browser?
I looked in the Browser.apk but did not see any related text selection PNG files.
I'm running CM7 7.1 on a Droid Incredible if that will make any difference.
Please use the Q&A Forum for questions Thanks
Moving to Q&A
Taking notes over PDF slides with the scribe pen has really saved me a lot of hassle. I love this function of the flyer. There's really only one way it could be better: Fullscreen support, or at least "more screen" support.
Not only does the HC bar take up space, but the menu/title bar on top is even bigger. The pdf viewer has the screen real estate of a 5inch phone.
PDF editing seems like only a moderately used feature, so I don't see this getting done on it's own. I'm offering a very modest reward for a fix.
I would be willing to donate for the removal of the huge uppermost Title/menu bar in PDF viewer, so that a double-tapped fitted pdf page will fill the new space. See the attached image. You can leave the small menu button in the corner if possible, or just get rid of it if it's too difficult.
I'm hoping this is as simple as modifying a few variables in the apk. I could be very wrong.
I can live with just the HC bar at the bottom.
Note: I have tried apps like repligo and ezpdf which do offer fullscreen support. However, annotating and changing annotation options takes many more steps than the HTC pdf viewer.
Secondary goal:
Apps like honeybar and honey hide widget cause all pen written annotations to be shifted up.
I believe the solution to the first problem would also allow an easy fix of the shifting pen annotations. I would like the PDF viewer to accept pen strokes properly with a hidden HC bar.
No one's willing to give it a shot? Ah well.
This will be my only bump.
I've attached the (unmodified, I think) HTCPDFViewer.apk from /system/app from LeeDroid's 4.1.0 rom.
I was the guy who removed the obnoxiously large language bar from Sony Ericsson's keyboard back when I was still using my u20i phone... unless HTC is particularly irritating about how it structures its resources, you're right that it is a matter of decompiling the APK, adjusting numbers, and recompiling it. Merely hiding is not difficult (making the Menu button semi-transparent is probably too difficult, though, but you can pick a ROM with the hardware buttons enabled).
Unfortunately it is also incredibly tedious to decompile and recompile everything right, from my experience of the keyboard hack. I'm not really up to it at the moment. Hope you can do it.
I've poked around in the archive. I wonder if I could just delete the ti.tle bar png or layout file. There doesn't seem to be a definitive title bar png
I'm also experimenting with apk multitool.
Since it's a stock rom app, is this venture going to be a lot more complicated than editing an xml line and then recompiling?
Here's where I'm at. Everything I know about android programming I've learned tonight, so this may be confusing and stupid sounding:
The decompiled apk has several things which could refer to the title bar.
dimens.xml has lines like
<dimen name="global_title_height">35.0dip</dimen>
<dimen name="editing_panel_header_height">56.0px</dimen>
<dimen name="editing_panel_header_margin">47.0px</dimen>
<dimen name="editing_panel_no_footer_header_margin">35.0px</dimen>
However there are also thousands of header and title lines from other xmls.
Can I just use a theme line in the manifest?
It uses the ActPDFReaderTheme whose parent is the HtcActionBar.FullScreen from the com.htc.resources.apk
These link to the common_mainnav xmls and pngs in the resources.
Do I need to find an HTC theme from the com.htc.resources.apk that doesn't have a title bar? Could I edit the com.htc.resources.apk and edit the pngs or delete the referencing lines in the styles.xml?
Thanks. I'll keep digging.
And btw, the bounty's still out if anyone can do it faster. I don't have much free time.
I think I've got this. I'm real close
I figured out how to decompile, edit xmls, recompile, copy original meta-infs and androidmanifest, and adb push.
The dimens.xml in the viewer apk has no effect on the bar. It's a standard template htcactionbar.fullscreen
I could direct the apk to a new theme, but I've decided just to try deleting or shrinking the bar from the com resources apk.
Good luck! Remember the apk you push back must be a signed one, probably via hacking the modified xml files back into the original signed apk.
Now I've run into a snag.
No matter how many margin and layout dimension variables in the com resource I set to 1.0px, I still have a black bar above the pdf.
Then I tried changing the theme reference in the pdfviewer.apk. It loads the file picker without an action bar, but as soon as I click a file it crashes. It seems (I think) that the program has too many calls for the action bar. I'm not a programmer. Do you know how I can get the program to simply ignore any lines referencing the "actionbar"?
Lines such as: "invoke-virtual {v3}, Lcom/htc/pdfviewer/ActPDFReader;->getActionBarHeight()I"
I also tried <item name="android:windowNoTitle">true</item> after the theme and I have the same effect of no title bar but a forceclose after selecting a file
Could you post the entirety of the relevant xml layout file?
porcupineadvocate said:
Could you post the entirety of the relevant xml layout file?
Click to expand...
Click to collapse
Unfortunately there is no simple relevant layout file. I can't go any further with this project because I don't know programming. Here's my progress if anyone would like to give it a shot:
In the decompiled HTCPDFViewer is a \res\values\styles.xml
There is the line:
<style name="ActPDFReaderTheme" parent="@com.htc:style/HtcActionBar.FullScreen">
This tells the program to use the HTCactionbar.fullscreen template style in com.htc.resources.apk
Now there are two paths to take from here:
1) Changing the style template to @android:style/Theme.NoTitleBar.Fullscreen
or adding the requestWindowFeature(Window.FEATURE_NO_TITLE) line
Issue: This causes the file picker to load without a title fine, but as soon as a pdf loads, the program crashes.
How far I got: I simply deleted 2 lines referring to the actionbar in the PdfLoadingPage$LOADING_PAGE_Handler.smali and the pdf loads. However there is a now a black empty bar on the bottom, and any pen writing is being moved upwards.
I suspect this is because of the ActionBarMenuAdapter.smali that controls how the pen annotations are moved in relation to the actionbar. There are also 100 more lines referring the actionbar in the other smalis. You can find them all by searching the apk for "actionbar". A proper programmer could remove these lines, or more easily make every m_iActionBarHeight:I line refer to zero.
If someone can fix the programming, I suspect that this would also solve the hidden HC bar issue, allowing true fullscreen support!
2) Editing the com.htc.resources.apk
The styles.xml in this file has a NoTitleBar.Fullscreen theme that redirects to other xmls redirecting to different layout files and pngs.
I've looked through every dimens.xml and other xmls that may be even loosely linked to the actionbar. I even tried haphazardly changing every possibly connected dimension to 1.0px.
I then tried shrinking all of the related PNGs to 1x1 pixel.
The end result was just a funking looking grey and black bar at the top.
I have no idea where to find the dimensions controlling the size of the actionbar.
Thanks for any help! Warning: Recovery backup before pushing a new com.htc apk, if you don't do it correctly, things can get messy with the OS.
porcupineadvocate said:
Could you post the entirety of the relevant xml layout file?
Click to expand...
Click to collapse
Ok I may have lied. There are one or two files I wasn't sure about.
These are from the xmls in layout folders of com.htc apk.
Can you take a look and see if there are simple line(s) to change here? notepad++ is great.
I already attempted to edit all of the dimens.xml dimensions. I can't remember if I got all of the dimensions in these files too.
The bar seems to be about 56 pixels. I gathered that from reduced editing view dimensions but I could be wrong.
Not that it is a big deal for a minor issue like this in a low traffic forum like EVO View but "bounty threads" are strictly prohibited by xda.
I doubt the mods will hassle you since this isn't a heavily travelled thread but they might shut you down at any second. Good idea to get some PM's going with anyone who is helping you.
Good luck.
Sent from my PG41200 using Tapatalk
Post the decompiled HTPDFViewer, please. I particularly want to see the contents of res/layout/*.xml files.
As a tip, don't delete any elements; just resize them to zero height/width if possible. Deleting will cause crashes when the program tries to reference them.
porcupineadvocate said:
Post the decompiled HTPDFViewer, please. I particularly want to see the contents of res/layout/*.xml files.
As a tip, don't delete any elements; just resize them to zero height/width if possible. Deleting will cause crashes when the program tries to reference them.
Click to expand...
Click to collapse
Here it is.
Woops I didn't realize bounties were prohibited, especially with so many developers asking for "donations"
Delete this if you'd like. I didn't mean to break the rules.
Donations and bounties are different. Donations are thanks for work done, bounties are offer of compensation to do work. If they allowed bounty threads xda would be overrun with them.
No big deal. I doubt the mods even visit this thread. Just wanted to give you heads up to establish pm conversations in case they did
Sent from my PG41200 using Tapatalk
No progress since my last update on the programming front. However I have been playing with the lcd density changer.
Setting it to 170 from 160 and enabling the GB like bar on top has interesting results. The pdfviewer only edits properly when I use Honeyhide or Honeybar. So we know that disabling the notification bar and having a working pdfviewer is possible.
However, I found I have the best pdf editing real estate when I set the lcd density to very low, like 120. In fact, not only are the title and HC bars smaller, but the pen seems to be more accurate too!
Maybe this information will help with our goal.
EDIT: at 120 and below, the scribe color wheel pops up on the wrong side. Still works though. Other tablet functions are much slower and there's some screen corruption too. It's not a permanent solution, but works for annotating pdfs.
Hi @all.
I currently try to design a "simple" layout with android. What it should do:
At the top and bottom of the screen should be a bar with a little content. LinearLayout, horizontal.
Between the bars is the space for the content.
This content should be devided into a "large" upper region and a linear layout with (right aligned) buttons at the bottom.
If there is not too much content the content area should be display centered in the available space. If there are more elements in the content, the area should grow until it fills the complete space between top and bottom bars. The Buttons below the content should always be visible. The area for the content should be scrollable in this case.
I tried something like this:
RelativeLayout
LinearLayout TopBar (AlignParentTop)
Button1 Button2 ...
LinearLayout BottomBar (AlignParentBottom)
ButtomA ButtonB ...
This works fine.
Then i tried to add an additional element
FrameLayout (Above Bottombar, Below TopBar)
This FrameLayout fills the remaining space. Fine.
Now i need a layout like this:
RelativeLayout (wrap_content Width/Height)
ScrollView
LinearLayout CONTENT (sometimes small, sometimes really large)
LinearLayout ButtonBar (horizontal)
ButtonX ButtonY ...
If i attach the buttonbar to the bottom of the relative layout the relative layout grows and does no longer wrap around the content. Instead it's height fills the complete available space.
If i put the buttonBar into the upper Relative layout i can fit it between Content and bottomBar. But if the contentn grows the buttonBar slides down outside the screen.
Is it possible that such a simple layout is not managable with Android?
I am working for hours on this and always something does not work :-( HELP PLEASE!!!
Best regards, Udo
I'm not sure how do that, but it's possible. Maybe using a table layout (a table row for each element) and assigning them different weights...
Hi there, I'm not sure if I get what you mean, but here is my understanding of the question.
When your content becomes too large, your bottom bar gets pushed out of the view ?
Try adding this line >> android:layout_weight="1"
into the parent view just above your layout button bar
example :
<LinearLayout ** add to this view here >
<ScrollView>
</ScrollView>
</LinearLayout>
<LinearLayout for ButtonBar>
</LinearLayout>
let me know if it works
I tried weight - does not work. Currently I use margins as described in various articles. Ugly, but it works.
send by tapatalk
Hi,
still stuck with this layout... Another problem now. I tried to have an inner LinearLayout set sets its children to equal width.
I tried every combination of weight, weightSum, layout_width="0sp" etc.
If the textView "MainContent" contains a huge amount of text the radio buttons are compressed to a very narrow size. If the text in the radiobuttons and the textview are nearly equal in size the layout works well. But ONLY then...
The scroll problem still exists.
The layout should work as follows:
If the screensize is big the MainContainer should use no more space than it needs to display its children. It the should be centered on the available space (in my real app it is packed into a relative layout instead of the top-level linear layout in this example).
If the content is larger than the available space a scroller should appear for the content in the scrollarea. The Buttons in the LinearLayout under the scrollview should still be displayed and not scrolled out of the screen. I currently am able to solve the scrolling problem by setting a bottom-margon of e.g. 50sp to the scrollview and -50sp to the linearLayout containing the buttons. Problem here: There are cases where the LinearLayout has no Buttons. With the current solution the Button-Area consumes space in this case too - what i do not want.
On both problems (Scrolling and even distribution of MainContent and the radioGroup) i now am working for days without success.
Any help would be nice. It looks like a really simple layout - but seems to be impossible with android.
Best regards, Udo
Maybe u want to use Fragments (use supportlibrary v4 to Support devices lower than honeycomb)
Use a big one for the Main content. And a small one for the button bar.
So the Fragment may handle the Main content, like an whole activity does.
But dont ask how, cause i have no idea how to do this.
Ok maybe its the solution, so good luck.
Gesendet von meinem GT-I9000 mit Tapatalk 2
Hi,
i currently USE fragments ;-) This does not solve the layout problem...
At the moment i read into creating own custom layouts. Complicated but this seems to be the only way.
Best regards, Udo
Hi all,
I have a Galaxy Tab 2 10.1 with a 1280x800 display and recently enabled floating multi-window capabilities using this mod: http://forum.xda-developers.com/showthread.php?t=2449094
Now that I can have floating windows, I wanted to try and edit some games I play to not take up the whole screen and make them think I'm running on a phone with a small screen size (which I know they can, since I've played the same exact APK on a smaller screen size).
So what do I do? I download apktool, decompile the APK, and check the res/layout XML files. In this particular app's case, there are 3 XML files, and all the views are defined at layout_width and layout_height of fill_parent. I change them to something silly like 400px and 640px (to, say, run 4 of these in landscape mode on my screen).
Of course this doesn't work. Some parts are actually 400/640, but some draw at full screen size. My guess is that there are some parts that are drawn pragmatically that bypass the layout settings set in the XMLs and use calls like GetDeviceScreenSize() for dimensions or whatever. I can't find any other layout rules in the XML so I assume this is embedded in the smali files somewhere (pardon my android development nubbery here).
Now that you know the background, my question is: is there a way I can fool a particular app into thinking that my screen is smaller? I know I can change the entire devices DPI but that won't help me. I want to do this on an app-specific basis, sandbox style. Have I missed something simple other than red/layout that I can change to get this app to behave like I want it to?
If the answer to these questions is no, will I be able to achieve my goal by digging into the smali files? If so, would anyone care to share some advice?
Thanks in advance!
Is it possible for an app to access onscreen layout bounds of other apps , similar to layout bounds display under developer options.
Would use the screen space cordinates..
Thread moved to proper forum. Please make sure to post questions in proper Q&A forums when there is a dedicated forum already.
The closest thing you can get as a regular app is to (ab)use accessibility service capabilities.
What alternatives could there be to gather this info?